:: Re: [unSYSTEM] Block size limit deb…
Pàgina inicial
Delete this message
Reply to this message
Autor: Josh Walker
Data:  
A: System undo crew
Assumpte: Re: [unSYSTEM] Block size limit debate
The analysis is missing another set of variables but the point is right — I
didn't used to believe so, but I have come to believe the incentives can
work themselves out.

The missing bit is of little import, too. His conclusion that the optimal
size is coinbase-only at present fees neglects the fact that Bitcoin would
be quite literally worth zero if no transactions occurred. There is an
equilibrium that would be found, but it's not zero. Since blocks are
already rarely full, that suggests we're near that equilibrium already. In
the longer term, once the 1 MB limit becomes an issue, I believe the point
stands, and the constraints of disk space and bandwidth can work themselves
out.

This violates the decentralized intent of Satoshi, but then that's been
broken mining-side forever anyway, and not for block size or txfee
incentives mismatch. If he was who we think he was, it's why he left the
community anyway. He failed to create a truly decentralized algorithm.

I'm going to segue and ramble a bit, here.

Probably this flaw won't be an issue for a decade at least, though; and
that may be giving The Powers too much credit, but anything in tech moves
faster. Point is, much like we evolved from Napster (Liberty Dollars) to
the original BitTorrent (Bitcoin, of course), the final form of
cryptomoney has not yet been realized.

I think the tech exists to make it the improved version, and I think it
looks like parallel multi-algorithm (none of this daisy-chained bollocks
like X11), which has been done once in an alt which no one noticed because
we don't need it yet; it's all but dead now. That, without going into it,
solves almost all the issues existing with Bitcoin and friends' incentives
mismatches and other flaws. We'll make it so algos expire at regular
intervals — intervals faster than ASIC dev time should suffice; pre-ASIC
centralization wasn't really problematic.

But none of this will happen because it's all theoretical, in the hazy
future. Until there is an actual, extant threat to Bitcoin sufficient to
incentivize its creation AND adoption, via a real market need, we'll talk
about Bitcoin's flaws, but we'll still use it. :)

With BitTorrent, user issues (privacy, throttling) were solvable by
encryption and VPNs. The Achilles heel was the torrent file itself, as
indexers (the search engines) were getting hammered despite only hosting
links, not content. That was enough for some courts though. IsoHunt and
similar cases were startling enough that development of DHT as a
replacement for .torrent files damn near finished overnight. TPB adopted it
and quit hosting actual .torrents, and the rest is history.

It's not impervious but it's close enough. One can always be unmasked; it's
just cost prohibitive for The Powers to do so, just like your locked
door discourages thievery juuuust enough. So will it be with Bitcoin. When
need demands it, a protocol evolution will be made.

Open source evolves very much like simple cellular organisms in a Petri
dish. As long as The Powers don't nuke the shit, strong cells survive and
pass on their strength. We owe The Powers an ironic debt of gratitude for
being such an unintentionally good motivator for tech's evolution, you know?

—J

On Monday, September 22, 2014, Noel Maersk <veox@???> wrote:

> On Thu, Sep 11, 2014 at 10:03:01AM +1000, Washington Sanchez wrote:
> > ...
> >
> > Ok, so what's right/wrong with my summary above? Are there any new
> > solutions to this problem?
>
> Someone around the UnSYSTEM lists has recently mentioned these
> discussions from late last year, might be relevant.
>
> "On the optimal block size and why transaction fees are 8 times too low"
> http://sourceforge.net/p/bitcoin/mailman/message/31610851/
>
>     Final conclusions is that the fee currently is too small and that
>     there is no need to keep a maximum block size, the fork probability
>     will automatically provide an incentive to not let block grows into
>     infinity.

>
> "Even simpler minimum fee calculation formula"
> http://sourceforge.net/p/bitcoin/mailman/message/31633371/
>