{"type":"rich","version":"1.0","author_name":"npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wt","author_url":"https://nostr.ae/npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wt","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-25\n📝 Original message:That description makes sense.  It also makes sense to separate out the \nhard fork from the soft fork process.   Right now some people want to \nuse the soft fork procedure for a hard fork simply because there is no \nother way to do it.\n\nI am under the impression that most users expect changes/improvements \nthat would require a hard fork so I think some kind of process needs to \nbe developed.  Taking the responsibility off the shoulder of the core \nmaintainer also makes sense.  The hard fork issue is too much of a \ndistraction for people trying to maintain the nuts and bolts of the \nunderlying system.\n\nI saw a suggestion that regularly scheduled hard forks should be \nplanned.  That seems to make sense so you would have some sort of \nschedule where you would have cut off dates for hard-fork BIP \nsubmissions.  That way you avoid the debates over whether there should \nbe hard forks to what should be contained within the hard fork (if \nneeded).  It makes sense to follow the BIP process as close as \npossible.  Possibly adding another step after \"Dev acceptance\" to \ninclude input from others such as merchants/exchanges/miners/users.  It \nwill only be an approximation of \"decentralization\" and the process \nwon't be perfect but if you want to move forward then you need some way \nto do it.\n\nRuss\n\n\nOn 6/25/2015 4:05 PM, Tier Nolan wrote:\n\u003e On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach \n\u003e \u003cmark at friedenbach.org \u003cmailto:mark at friedenbach.org\u003e\u003e wrote:\n\u003e\n\u003e     I'm sorry but this is absolutely not the case, Milly. The reason\n\u003e     that people get defensive is that we have a carefully constructed\n\u003e     process that does work (thank you very much!) and is well documented.\n\u003e\n\u003e\n\u003e There is no process for handling hard forks, which aren't bug fixes.\n\u003e\n\u003e Soft forks have a defined process of something like\n\u003e\n\u003e - BIP proposal + discussion\n\u003e - Proposed code\n\u003e - Dev acceptance\n\u003e - Release\n\u003e - Miner vote/acceptance\n\u003e\n\u003e The devs have a weak veto.  If they refuse to move forward with \n\u003e changes, miners could perform a soft fork on their own.  They don't \n\u003e want to do that, as it would be controversial and the devs know the \n\u003e software better.\n\u003e\n\u003e The miner veto is stronger (for soft forks) but not absolute.  The \n\u003e devs could checkpoint/blacklist a chain if miners implemented a fork \n\u003e that wasn't acceptable (assuming the community backed them).\n\u003e\n\u003e When ASICs arrived, it was pointed out by some that the devs could hit \n\u003e back if ASICs weren't made publicly available.  If they slightly \n\u003e tweaked the hashing algorithm, then current generation of ASICs would \n\u003e be useless.   The potential threat may have acted as a disincentive \n\u003e for ASIC manufacturers to use the ASICs themselves.\n\u003e\n\u003e Moving forward with agreement between all involved is the recommended \n\u003e and desirable approach.\n\u003e\n\u003e Consensus between all parties is the goal but isn't absolutely \n\u003e required.  This escape valve is partly what makes consensus work.  If \n\u003e you dig your heels in, then the other side can bypass you, but they \n\u003e have an incentive to try to convince you to compromise first.  The \n\u003e outcome is better if a middle ground can be found.\n\u003e\n\u003e Hard forks are different.  The \"checks and balances\" of weak vetoes \n\u003e are not present.  This means that things can devolve from consensus to \n\u003e mutual veto.  Consensus ceases to be a goal and becomes a requirement.\n\u003e\n\u003e This is partly a reflection of the nature of hard forks.  Everyone \n\u003e needs to upgrade.  On the other hand, if most of the various groups \n\u003e upgrade, then users of the legacy software would have to upgrade or \n\u003e get left behind. If 5% of the users decided not to upgrade, should \n\u003e they be allowed to demand that nobody else does?\n\u003e\n\u003e There is clearly some kind of threshold that is reasonable.\n\u003e\n\u003e The fundamental problem is that there isn't agreement on what the \n\u003e block size is.  Is it equal in status to the 21 million BTC limit?\n\u003e\n\u003e If Satoshi had said that 1MB was part of the definition of Bitcoin, \n\u003e then I think people would accept it to the same extent as they accept \n\u003e the 21 million coin limit.  It might cause people to leave the coin \n\u003e though.\n\u003e\n\u003e It was intended to be temporary, but people have realized that it \n\u003e might be a good idea to keep it.  In effect both sides could argue \n\u003e that they should be considered the status quo.\n\u003e\n\u003e I wonder if a coin toss would be acceptable :).  \"Come to an agreement \n\u003e or we decide by coin toss\"\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/f1c23619/attachment.html\u003e"}