BTW: Just curious, and maybe our BIP is not needed anyways, but did you have a look at my comment with regards to not-quite hard forking?
Sorry, I spent most the day watching submissions and comments get deleted from /r/bitcoin.
I think a BIP (or something like it) is very much needed. We have to get people to stop thinking about "Bitcoin Core" versus "Bitcoin XT," and just thinking in terms of "do I want to run software that supports bigger blocks?" In that respect, our proposal is ideal because we could show how it would be compatible with both Bitcoin Core
and Bitcoin XT. The node operator just needs to set his block size limit to, say, 32 MB, and his node will always
follow the longest proof-of-work chain composed of valid transactions. Moreover, we don't need 75% of the hash power to run Bitcoin XT to activate BIP101. Instead, we need 75% of the hash power to set that flag bit. That flag bit could be set with a patched version of Core, or by running the version of Bitcoin that we're proposing.
To answer your question about the
not-quite-a-hard-fork idea, I think it's a great! But like you said earlier,
simple is better. We need to be clear that all we're really proposing is to move the block size limit from the consensus layer to the transport layer.
The stuff like my signalling idea and your "BSL governor" idea don't need strict consensus. There could be several competing implementation with various degrees of interoperability. It would still work fine.
Peter, how do we get your voice of reason better heard amidst all this noise?
I feel like what happened today mirrors the current state of the election cycle. The masses are moths to the flame of drama, and we've been served up a heaping helping today.
You recognize the critical aspects. Wall Street, Bankers, and the rest of the world is never going to commit to a currency which is yet to prove it can solve its own problems. Bitcoin is open source, and we are at the inflection point where it stands to begin its journey to a world currency. We
must demonstrate to the world that, somehow, an open source project can solve its own problems.
A hard fork is contentious.
For months, I thought on this problem. Yeah I'm a 15-year SE, and I've followed Bitcoin closely since 2011. But I'm not in the trenches like you guys. My technical breadth may be broader, but you guys blow me away in depth. Predictably, my voice has not been heard.
My attempts have been at trying to find a conciliatory path.
In my mind, the only way this could ever happen would be to burn a cycle. First we'd need to deploy a mechanism which allows for an open-source voting mechanism to be embedded within the protocol. Simultaneously, that voting behavior would be used to control block size.
I find it difficult to argue against your position. The off-the-cuff Sybil attacks, I presume, are refuted by the detailed analysis you provided in your recent, excellent paper. (Though I do have concerns about bad actors for whom monetary gain is not their primary motivator.)
It seems to me what you propose gives everyone what they want.
Nobody is discussing this today. It is all about "Is the Satoshi email real", censorship, and everyone trying to figure out whether they will be entrenching themselves on the side of "Forks are evil" or "this is necessary", making the problem worse.
What to do?