-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Possibly relevant to this discussion (though old)
https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I think?) and https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork (which cites gavin's gist shown above) On 06/25/2015 05:42 PM, Milly Bitcoin wrote: > That description makes sense. It also makes sense to separate out > the hard fork from the soft fork process. Right now some people > want to use the soft fork procedure for a hard fork simply because > there is no other way to do it. > > I am under the impression that most users expect > changes/improvements that would require a hard fork so I think some > kind of process needs to be developed. Taking the responsibility > off the shoulder of the core maintainer also makes sense. The hard > fork issue is too much of a distraction for people trying to > maintain the nuts and bolts of the underlying system. > > I saw a suggestion that regularly scheduled hard forks should be > planned. That seems to make sense so you would have some sort of > schedule where you would have cut off dates for hard-fork BIP > submissions. That way you avoid the debates over whether there > should be hard forks to what should be contained within the hard > fork (if needed). It makes sense to follow the BIP process as > close as possible. Possibly adding another step after "Dev > acceptance" to include input from others such as > merchants/exchanges/miners/users. It will only be an approximation > of "decentralization" and the process won't be perfect but if you > want to move forward then you need some way to do it. > > Russ > > > On 6/25/2015 4:05 PM, Tier Nolan wrote: >> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach >> <m...@friedenbach.org <mailto:m...@friedenbach.org>> wrote: >> >> I'm sorry but this is absolutely not the case, Milly. The reason >> that people get defensive is that we have a carefully >> constructed process that does work (thank you very much!) and is >> well documented. >> >> >> There is no process for handling hard forks, which aren't bug >> fixes. >> >> Soft forks have a defined process of something like >> >> - BIP proposal + discussion - Proposed code - Dev acceptance - >> Release - Miner vote/acceptance >> >> The devs have a weak veto. If they refuse to move forward with >> changes, miners could perform a soft fork on their own. They >> don't want to do that, as it would be controversial and the devs >> know the software better. >> >> The miner veto is stronger (for soft forks) but not absolute. >> The devs could checkpoint/blacklist a chain if miners implemented >> a fork that wasn't acceptable (assuming the community backed >> them). >> >> When ASICs arrived, it was pointed out by some that the devs >> could hit back if ASICs weren't made publicly available. If they >> slightly tweaked the hashing algorithm, then current generation >> of ASICs would be useless. The potential threat may have acted >> as a disincentive for ASIC manufacturers to use the ASICs >> themselves. >> >> Moving forward with agreement between all involved is the >> recommended and desirable approach. >> >> Consensus between all parties is the goal but isn't absolutely >> required. This escape valve is partly what makes consensus work. >> If you dig your heels in, then the other side can bypass you, but >> they have an incentive to try to convince you to compromise >> first. The outcome is better if a middle ground can be found. >> >> Hard forks are different. The "checks and balances" of weak >> vetoes are not present. This means that things can devolve from >> consensus to mutual veto. Consensus ceases to be a goal and >> becomes a requirement. >> >> This is partly a reflection of the nature of hard forks. >> Everyone needs to upgrade. On the other hand, if most of the >> various groups upgrade, then users of the legacy software would >> have to upgrade or get left behind. If 5% of the users decided >> not to upgrade, should they be allowed to demand that nobody else >> does? >> >> There is clearly some kind of threshold that is reasonable. >> >> The fundamental problem is that there isn't agreement on what >> the block size is. Is it equal in status to the 21 million BTC >> limit? >> >> If Satoshi had said that 1MB was part of the definition of >> Bitcoin, then I think people would accept it to the same extent >> as they accept the 21 million coin limit. It might cause people >> to leave the coin though. >> >> It was intended to be temporary, but people have realized that >> it might be a good idea to keep it. In effect both sides could >> argue that they should be considered the status quo. >> >> I wonder if a coin toss would be acceptable :). "Come to an >> agreement or we decide by coin toss" >> >> >> _______________________________________________ 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 > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI= =n7Pa -----END PGP SIGNATURE----- _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev