I'm really happy to see people trying to cooperate to get SegWit activated. But I'm really unsure about the technicalities about Silbert's proposal.
If we're going to do a hardfork, it makes most sense to assist Johnson in his spoonnet/forcenet proposals. Just doing a simple 2MB without fixing anything else is very uninteresting, and a hardfork without addressing replay protection seems really unprofessional to me. And proposing a hardfork in 4 months in the future, is completely insane. You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months. I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB September 2018, or 2019 (together with forcenet/spoonnet). And if not, BIP148 is gaining momentum once again so that sounds much more interesting. Hampus 2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Someone sent me a copy of the Barry Silbert agreement, an agreement forged > between a select number of participants https://pastebin.com/VuCYteJh > > Participants agree to immediately activate Segwit, however, under a > different activation proposal. Since I have spent the last few months > researching various activation strategies of the current BIP141 deployment, > as well as redeployment, I feel I am quite well placed to comment on the > technicalities. > > To be clear, the proposal as far as I can see does not activate BIP141, > but is a completely new deployment which would be incompatible with the > BIP141 deployment. I'm not sure how that can be considered "immediate" > activation. Surely immediate activation would just be for miners to start > signalling and segwit would be activated in 4-5 weeks. The proposal seems > to require a lower 80% threshold, I assume because they were unable to > convince 95% of the hashpower to go trigger activation. > > There are a few options to activating segwit now, the first being for 95% > of hashrate to signal. The second is for the community to deploy BIP148 > UASF which will force miners to signal segwit. Being a UASF it is date > triggered. The third option is a redeployment of segwit on a new bit, but > requires waiting for the existing deployment to time out, because all the > p2p messages and service bits related to segwit must be replaced too (which > is what BIP149 does). > > A fourth option, first suggested to me by James Hilliard, was to make > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded > this up a few weeks ago https://github.com/bitcoin/ > bitcoin/compare/master...shaolinfry:segsignal but didnt get around to > posting to the ML yet. This effectively lowers the threshold from 95% to > 65% as coded, or could be upped to 80% or whatever was preferable. > > I think this removes the primary risk of BIP148 causing the creation of > two chains, and gives an improved chance to get segwit activated quickly > (assuming a majority of miners wish to go this route). But hash a primary > disadvantage of still leaving the activation in the hands of miners. If it > doesn't work out, then BIP149 can then be used as proposed, but it'll be > even safer because we'll have futher guaged support. > > References: > > SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master... > shaolinfry:segsignal > BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki > BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki > > I think the Barry Silbert agreement is very ill considered, and clearly > lacking peer review from the technical community. Suggestions of a HF in 4 > months are completely unrealistic and without technical merits. But more > importantly, closed door agreements between selected participants is not > how to garner consensus to change a $30bn decentralized system. The purpose > of my email is to try and assist in the "immediate activation of segwit" > which only requires hashrate to participate; and to provide some techincal > input since I have done a great deal of research and development into the > topic. > > Given the history we've already passed the point where we should be > expecting miners to cooperate in lowering their own fee income with a > capacity increase; but we should be open to all reasonable options in the > interest in moving things forward in a safe and collaborative way. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
