search

tothemoon-org / extension-blocks

Extension blocks soft-fork specification
40 stars 6 forks source link

Signal/marker bytes conflict with other proposals #5

Open pinheadmz opened 7 years ago

pinheadmz commented 7 years ago

This proposal specifies using bit 2 for BIP9 signaling. I'm wondering if you're aware that Sergio Lerner's SegWit2MB proposal also signals bit 2:

https://github.com/SergioDemianLerner/bitcoin/blob/d96b54500a2a2cff81a4d6a82472af83cc1828b6/src/chainparams.cpp#L100

Also I noticed the coinbase OP RETURN extension block commitment is labeled with header bytes aa21a9ef, what is the rationale in choosing a string that is only one bit different from the segwit commitment header bytes aa21a9ed?

jujumax commented 7 years ago

Sergio's proposal is an balanced attempt to find rough minimum consensus between SW/Core vision and users looking to scale on-chain, and require a HF. If a HF has a community consensus is a good proposal.

This proposal address the malleability issues as SW and let new L2 as LN and RSK work also more on-chain TXs.

If we can re-design Bitcoin Protocol from zero probably we did it different based on the understanding we have today, but we can't, SW is not getting activated and a HF require coordination and we have always a risk of a chain fork resulting in 2 Bitcoins.

The beauty about this proposal is a SF so the chain fork risk is avoided if implemented correctly and does not require any hard-coordination among node owners.

Is probably the best scaling option based on the options we have, avoiding a HF, opening L2 and expanding an on-chain capacity.

pinheadmz commented 7 years ago

@jujumax I'm just asking the developers why they chose bit 2 for BIP 9 signaling, and aa21a9ef for the commitment header.

jujumax commented 7 years ago

Ok I got your point, probably is something to fix it, because Sergio proposal went public after this proposal was in process, looks both were working in parallel.