{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-25\n📝 Original message:On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e I'm sorry but this is absolutely not the case, Milly. The reason that\n\u003e people get defensive is that we have a carefully constructed process that\n\u003e does work (thank you very much!) and is well documented.\n\u003e\n\nThere is no process for handling hard forks, which aren't bug fixes.\n\nSoft forks have a defined process of something like\n\n- BIP proposal + discussion\n- Proposed code\n- Dev acceptance\n- Release\n- Miner vote/acceptance\n\nThe devs have a weak veto.  If they refuse to move forward with changes,\nminers could perform a soft fork on their own.  They don't want to do that,\nas it would be controversial and the devs know the software better.\n\nThe miner veto is stronger (for soft forks) but not absolute.  The devs\ncould checkpoint/blacklist a chain if miners implemented a fork that wasn't\nacceptable (assuming the community backed them).\n\nWhen ASICs arrived, it was pointed out by some that the devs could hit back\nif ASICs weren't made publicly available.  If they slightly tweaked the\nhashing algorithm, then current generation of ASICs would be useless.   The\npotential threat may have acted as a disincentive for ASIC manufacturers to\nuse the ASICs themselves.\n\nMoving forward with agreement between all involved is the recommended and\ndesirable approach.\n\nConsensus between all parties is the goal but isn't absolutely required.\nThis escape valve is partly what makes consensus work.  If you dig your\nheels in, then the other side can bypass you, but they have an incentive to\ntry to convince you to compromise first.  The outcome is better if a middle\nground can be found.\n\nHard forks are different.  The \"checks and balances\" of weak vetoes are not\npresent.  This means that things can devolve from consensus to mutual\nveto.  Consensus ceases to be a goal and becomes a requirement.\n\nThis is partly a reflection of the nature of hard forks.  Everyone needs to\nupgrade.  On the other hand, if most of the various groups upgrade, then\nusers of the legacy software would have to upgrade or get left behind.  If\n5% of the users decided not to upgrade, should they be allowed to demand\nthat nobody else does?\n\nThere is clearly some kind of threshold that is reasonable.\n\nThe fundamental problem is that there isn't agreement on what the block\nsize is.  Is it equal in status to the 21 million BTC limit?\n\nIf Satoshi had said that 1MB was part of the definition of Bitcoin, then I\nthink people would accept it to the same extent as they accept the 21\nmillion coin limit.  It might cause people to leave the coin though.\n\nIt was intended to be temporary, but people have realized that it might be\na good idea to keep it.  In effect both sides could argue that they should\nbe considered the status quo.\n\nI wonder if a coin toss would be acceptable :).  \"Come to an agreement or\nwe decide by coin toss\"\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/b2ce86a5/attachment-0001.html\u003e"}