The Fork You Don't Want To Pick Up: A #Bitcoin Reflection

---

This is a reflection on the proposed fork by @gavinandresen.

First of all, there is no question at all that issues facing bitcoin raised by @gavinandresen (Gavin Andresen) and @OctSkyward are real and should be addressed. Some of these were summarized by @OctSkyward (Mike Hearn) in a post at: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

It is also true that not all the ways in which they presented their arguments have been logically valid, nor have some of their arguments been helpful to resolving the issues and problems facing bitcoin. When Matt Whitlock proposed some alternatives to the 20 MB step function - http://bitcoin-development.narkive.com/iHmMh6bZ/proposed-alternatives-to-the-20mb-step-function - one of Gavin's responses was to state that he would "lobby(...) the merchant services and exchanges and hosted wallet companies and other bitcoind-using-infrastructure companies (and anybody who agrees with me that we need bigger blocks sooner rather than later) to run Bitcoin-Xt instead of Bitcoin Core" ~ moving on to suggest that this would be followed on by "getting big miners" to support him, thus, to "prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens."

"Left behind."

These are not my words, but Gavin Andresen's. He is a Chief Scientist of the Bitcoin Foundation; and has been working on the code for bitcoin longer than almost anyone. It is extremely discouraging to the community to hear him speaking in this way.

Furthermore, we don't know about the extent to which the current funding changes and the role of MIT is playing into this. You can get some background on what MIT is doing to fund three bitcoin Core developers here:
http://cointelegraph.com/news/114046/mit-to-take-over-funding-of-three-bitcoin-core-developers
The Bitcoin Foundation itself is no longer can be viewed as a supplier of funds for bitcoin development, that changed, and core development is handled by MIT. It would be interesting to know what would happen to the funding if Gavin's fork were to be successful... Does MIT Media Lab's Digital Currency Initiative plan on reducing bitcoin Core funding (or causing it to wither up) and redirecting any and all MIT crypto funding to XT? At this point, we don't know, but that is entirely possible. A hard fork poses serious risks to the funding of bitcoin development because it would likely cause both technical and organizational splits in terms of where any development funding would ultimately go. So questions here about what is going on with the MIT Media Lab’s Digital Currency Initiative and Gavin Andresen, and what their agreements or plans are for where funds are going in the future (Core? XT? Somewhere else?) are certainly in order. They shouldn't have any agreements ~ because bitcoin is supposed to function as a result of consensus, not non-disclosure agreements or competitions of two versions of bitcoin (xt / core) to MIT 'investors,' and if that is what is happening, they should publish it now before someone else does down the road.

What will happen if Gavin forces people to "fork over" to Bitcoin XT? Nothing good, really.

First, the bitcoin network will be split off in two, which will mean that those following Gavin and his demands that people follow him (who knows where) will install versions of software that result in increasing centralization of the bitcoin software.

Second, those people who are smart enough to not follow the fork over to Bitcoin XT need not do anything. They will just remain with their current wallet version to avoid the upgrade. But this poses its own problems too, as developers of wallets will certainly attest to.

Finally, Bitcoin XT is developed and intended for app developers and merchants and is currently described as of the time of this post as experimental. That will certainly change in the future, but it is hard to justify calling for people not only to hard fork - a highly questionable practice in a consensus driven software community - but as well, calling for people to use a piece of software that is so obviously tailored to the corporate community (clearly a staged piece of work; designed first and foremost to garner votes from large corporate types as Gavin seeks "community support" for XT). See the description for it here - which is likely soon to be edited (but which you will see from checking history)
https://github.com/bitcoinxt/bitcoinxt/blob/0.10.2A/README.md

Cameron Garnham added into the thread,
"First off, I am glad that the idea of dynamic block size adjustment is
gaining some attention, in particular the model that I proposed.

I wanted to take some time and explain some of the philosophy of how,
and why, I proposed this this particular model.

When Bitcoin was first made, there was a 32MB block size limit; this
was quickly found to be open to spam (and potentially DOS, as the code
was not-at-all optimized to support large blocks), and was reduced to
1MB, this was a quick fix that was never intended to last; at some
point the network should come to an understanding, a consensus if you
will, of what (and how much) belongs in a block.
The core point of this is that miners have always, and will always;
hold the power, to decide what goes into blocks; this implicitly,
obviously, includes how large blocks are. Miners are able to come any
sort of agreement they wish, providing the bitcoin clients accept
their blocks as valid."
(...)
"the proposal introducing a consensus protocol for block sizes;
instead of just having a hard limit (enforced by everyone), instead,
we have a constant factor above the average block size over a fixed
intervals that is soft-forked by only the miners. (The next simplest
mathematical construct).
This proposal is entirely a soft-fork and may be implemented without
changing any client code what so ever. In-fact, it could be
implemented by only a simple 51% majority of miners, with-or-without
gaining the wider community consensus."

This was a very reasonable point to make by Cameron and I think it should be plain to see that a hard fork is thoughtless and unnecessary, while a soft fork has many advantages that will satisfy the situation.

Raystonn thoughtfully stated as part of this discussion,
"developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. My opinion is these things are better left to a decentralized free market anyhow."

Gavin himself seemed to see the value of the dynamic adjustment being proposed, though he protested its arrival by claiming its advocates were trivializing the issues (which they most certainly were not):
"Can we hold off on bike-shedding the particular choice of parameters until
people have a chance to weigh in on whether or not there is SOME set of
dynamic parameters they would support right now?"

In sum:

The hard fork being proposed ~ Bitcoin XT ~ is the fork you don't want to pick up.

Reply · Report Post