Hallo,
I was thinking about a way to clarify current heated and politicized blocksize debate. Simple statements about different levels of support encoded in coinbase would be helpful and would allow predictable conditions for various agents in Bitcoin ecosystem.
During BIP100 / 101 (XT), pools signed their coinbase "BIP100" if they preferred it. At the XT announcement, many block makers said they'd support XT but *never* made an XT compatible block.
Would something like this be possible today? There are of course lists about which pool support what branch (Bitcoin Classic, maxblocksize increase, Bitcoin Core, Roadmap, ...). But such lists are biased depending on the source, policies develop and statements from various representatives are fuzzy and sometimes contradictory.
We have several large pools, but despite this the mining is not centralized, because these pools are composed of large number of individual miners. Clear policy expressed in coinbase would be guide for these small miners where to (re)direct their mining power according to their opinions.
Base of my proposal (which is open to comments and suggestions) is this:
- four levels of support (active/passive/opposed) (+//-)
- Main branches as simple strings (Core, Classic, Unlimited, Roadmap, 1MB, 2MB, 4MB, 2-4-6, BIP10x).
- Strings signed by some simplified way, if possible
For example:
- String: "*Core+,Roadmap+,Classic,4MB-*" means:
- Active support for Core and Roadmap (Our poll will generate blocks according to Core&Roadmap specification)
- Passive support for Classic (We will not generate blocks according to Classic specification. However, we will build on them.)
- Opposition to 4MB (We will never generate 4MB blocks and we will actively orphan such blocks - that is consider them invalid and inconsequential. No matter where this proposal comes from (included in Core, included in Classic) and which Developers support it.)
- String: "*Core,Roadmap(RBF)-,Classic+,4MB*" means:
- Passive support for Core (We will consider <1MB blocks as valid)
- Opposition to RBF (We will orphan/ignore blocks containing any RBF transactions as specified by Roadmap)
- Active support for Classic (We will happily and preferentially generate 2MB blocks according to Classic specification. We will build on them.)
- Passive support for 4MB (We will not generate 4MB blocks, but we will not ignore such blocks - We will reluctantly bulid on them.)
Of course strings can be more detailed (*SegWitCore-,SegWitClassic+,>1MB+,>8MB(until2018)-*). Interpretation would be matter of external actors (I think someone would probably create webpage for this.] But all interpretations would allow fallback to verifiable data for everyone.
As to the signing... I placed strings between two * symbols for a reason. I think this is the way they should be in coinbase followed by some simple signature. Reason for this: Any pool can pose as another pool (eg. BitFury can put "Slush" string in coinbase, Slush can put "Eligius" there etc.) and by this way fake statement of someone else. Simple privkey/pubkey pair where privkey signs *string* between ** and pubkey published on pools webpage/stated by trustworthy source/pool operator can solve this. Statements can also be signed by Bitcoin address publicly stated by pool in advance. But the signature should be short enough?! I do not have specific idea how to do this.
It would be nice if every pool would state several different (even contradictory) policies and open different addresses/ports for its hashers to "vote" on them a dynamically change their votes. Data analysis people would love this! But of course pool operators can express their policies by limiting the choice or not signalizing at all.
So...what do you think?
