From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 75BEBC0001 for ; Fri, 5 Mar 2021 23:39:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4E3EB4ED79 for ; Fri, 5 Mar 2021 23:39:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUCK0fq4nMbq for ; Fri, 5 Mar 2021 23:39:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp4.osuosl.org (Postfix) with ESMTPS id B1E754ED78 for ; Fri, 5 Mar 2021 23:39:23 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id b1so6650962lfb.7 for ; Fri, 05 Mar 2021 15:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UoFRvesiU/icZKorH5riFXrUPJrOb6Ub4AHr/WOPosk=; b=gjGk6GnFwlcxxljLVgYGa/vMAuEkNsnDmy4RyG5X3UIABCNEoA17XYnvH8O6PShw/i NvWhce8UINPz7ufhcGN7E5oz9Pui/3+n2rKUWAxJOTvnTSwFeZNs9sGkgPpYl31EKw9f XgEuiqR9PvVmekui6vPXpnJWrF0js5f1QBkWDkxLnSZimOvwOlXpQrch9K3spRApssbT 0gT0oAugra7EC+kvdc2J4IfJyj/ZeDkqaxv4BuJqpcj185s+Ynde/TikdpeExIIxRXQR eo7uWcif99aCmM57GY+0PXOMCMGbEKut/r1uHzyndnN/yfXGpx7cU14SepyRerJkz1Pm hlPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UoFRvesiU/icZKorH5riFXrUPJrOb6Ub4AHr/WOPosk=; b=cqu2hcqZH+h7bPdUr/UJtuGsGYX+58GL8tljopG4iLSjd2WdXc4QAOJatK7ctU16rd yvpR4kiX1837puFzURDT/wxT2kYhLXrfivURU4seV9HggYGWqVGKm4U3rXoX6wqHV0mO 0VyuaKFxvJRulyoaah5qrI8CJnwh04WEFpHPU377QBoeZU3K3ESdpZ0Od2ssj7zTTunM 3sL1bWrIsWg7j8day6K8MiMF31yXGG/b6XnkHEuG0bjT45sKxkCwMkOrTowmBh16ohnh /jW4d+Ix04K+TDD4axT7hLJJ5teEvddtqMVQR/gvw9wh8igqRWM+uhaDoUnSUn9wqsdR oQnA== X-Gm-Message-State: AOAM533kK7MWfXOEGp4OWISbXLzHsdTOcZ43tpUL/RXKVb6RngWm+0SW vBSDGW0vF/lthmmrqz9IiwVv2dksz85F/pMdo/oTFEHYvvg= X-Google-Smtp-Source: ABdhPJxhe0oJ2vf3wZ0Wr57WY4BNu1Z4XyKfEBuri/hemzsrgZY7N76KnuZiDnM29qIunv/v5BZtTzW8Tq+9LK2hjO4= X-Received: by 2002:ac2:5e6a:: with SMTP id a10mr7062324lfr.181.1614987560823; Fri, 05 Mar 2021 15:39:20 -0800 (PST) MIME-Version: 1.0 From: Ariel Luaces Date: Fri, 5 Mar 2021 15:39:24 -0800 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +0000 Subject: [bitcoin-dev] Supermajority then simple majority Taproot Activation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 23:39:26 -0000 I found a hint of common ground in reddit that I absolutely loves and just had to share here on the ML to discuss Luke's suggestion: To minimise the signal from 90% to 50%+1 during the MUST_SIGNAL phase. https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkbdcg/ I think this proposal is a natural evolution: >From the creation of BIP9 to enable soft fork activations with low risk under widespread miner support https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki To miner aggression against segwit, resulting in shaolinfry's releasing the BIP148 and BIP91 proposals and a UASF client, resulting in the Bitcoin civil war, resulting in settlement through economic pressure. To shaolinfry's creation of BIP8 to force a soft fork when encountering minority miner apathy/malice and a desire for the majoity of users to deploy https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki To Greg Maxwell's suggestion of two round activation with BIP9 followed by a flag-day activation (couldn't find the link, it's mention in Matt's Modern Soft Fork Activation proposal) To Matt Corallo's suggestion to do a BIP9 deployment followed by a BIP8 deployment with a six month waiting period in between (Modern Soft Fork Activation) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html To Luke Dashjr's addition of lockinontimeout to BIP8 to consolidate the functionality of BIP8 and BIP9 https://github.com/bitcoin/bips/pull/550 To AJ Towns' suggestion of a gradually decreasing activation threshold and a user configurable option between conditional activation and guaranteed activation at the end https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018043.html To Gregorio Guidi's suggestion of decreasing the threshold to 1.2% as the locked in date approaches, allowing for activation failure and removing of the LOT flag https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018476.html To Ariel Lorenzo-Luaces' (me) suggestion of switching the final threshold to 50% to pose a reorg threat to non-upgraded miners instead of risking a minority fork https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018529.html To Luke Dashjr's suggestion of switching thresholds to 51% during the MUST_SIGNAL phase instead of a gradualy decreasing threshold https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkejqt/ (I hope I'm not missing anything) To Matt Corallo seemingly liking the idea? It's hard to tell. I think Luke's proposal fixes a lot of concerns on both sides of the LOT discussion. I went through all the Taproot activation discussion I could find, as well as some old segwit activation discussions, and here I summarize points that will hopefully convince all supporters from all sides of the Taproot activation discussion. Some points are repeated but framed differently based on the reader's predisposition (LOT=true or LOT=false or flag day). Something to note is that this is not a compromise, I mention it at the bottom. The case for this new proposal for supporters of LOT=true first: 1. no veto bug) Miners wouldn't have veto power. If 51% of miners are signaling during MUST_SIGNAL phase Taproot activates. This proposal follows the will of the community. (point 5 on Matt's Modern Soft Fork Activation proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) 2. signaling used for coordination instead of voting) The requirement for a 95% supermajority vote disappears since those, what would have previously been seen as, votes are irrelevant during the MUST_SIGNAL phase. The 51% threshold is also seen as a coordination mechanism for users to gauge miner support to automatically split from an unupgraded miner minority. 4. low threshold UASF) It's much much easier to do a UASF marketing blitz since only 51% of mining power needs to enforce the new rules and the supermajority is not required. Mining power (51% of it needed) will probably be convinced if exchanges, wallet software, and a moderate number of users are on the Taproot activation side (significant economic activity). This was a major problem in 2017 because it was uncertain whether signaling miners were running BIP9 or UASF. 5. no UASF minority chain) If LOT=true is released and it never achieves 50% signaling then there would be a fork and the UASF chain will be exposed to attacks or destabilization due to miners switching between chains. This proposal avoids that situation because it guarantees that a majority of mining power is supporting Taproot so the chain can't be attacked. You never really wanted to fork off from your friends right? 3. nodes stay in consensus) If Taproot does not achieve a supermajority but does achieve a simple majority (>51% PoW) at the end of activation then upgraded users, upgraded miners, and non-upgraded will all follow the taproot-active ruleset, leaving a minority of miners to be exposed to reorgs if they don't enforce the new Taproot rules. At this point the economic majority will very clearly be in the taproot-activated chain so this creates strong pressure for the minority of miners to capitulate or hard/soft fork off. (I imagine they will capitulate... unless they want to have fun being poor) 6. no double spends) No need to stress about writing code to prevent double spends the chain will stay together. 7. no PoW change) No need to stress about changing the PoW unless the miner majority doesn't signal. In that case a flag day is needed with a PoW change so the forked chain is safe. It's too risky to have to re-upgrade, in the middle of Taproot deployment, to a new client to deploy a PoW change in the event that the majority mining power is not on board. 7. minority miners forced to comply or fork off) Zealous miners against the proposed feature are forced to hard fork with an anti-Taproot fork if signaling is greater than 51%. The hard fork will have 49% in the worst case, probably much less if we assume humans are greedy. The miner minority may attack if they are confident they will succeed. But their success is unlikely due Nakamoto consensus. 8. no early adopter dilema) There is no reluctance of upgrading because it's more likely the new version will be on the chain with the most PoW. This fixes the early adopter dilemma. 9. no late adopter stress) Since the result of activation keeps all users together and minority miners are forced off, late adopters don't need to worry about upgrading their client to not risk being reorged. They will be on the taproot activated chain. 10. majority attracts the undecided) At 51% of mining power and an economic majority I would say Greg Maxwell's "opposed unless there is clear consensus on LOT=true" is very well satisfied. (paraphrase provided by michaelfolkson http://gnusha.org/taproot-activation/2021-02-16.log) 11. discovered bugs can back out deployment) With forced activation there is no way to back out activation unless all users revert to using a previous version or upgrade to using a new fixed version. But it's not guaranteed that all users will revert or upgrade. This proposal allows a cancelation if we force the majority of miners to not signal. 12. no alt-nodes) A UASF media blitz can achieve activation with 51% miner support and can be executed with a client released by core instead of an alt-node. 13. no dev+miner forced changes) Users maintain sovereignty in future soft forks by maintaining the option of creating anti-feature hard fork or soft fork movements as long as they have enough mining power to maintain a safe chain. Miners and devs don't have ultimate power. (unless a supermajority of both groups agree to an anti-user feature but I find that unthinkable right now since the economic majority wouldn't comply easily, may happen in the future, who knows) 14. no dev forced changes) Avoid a power grab from core developers and a minority of users. They can't force a feature change because miners and an economic majority together can veto. At minimum the forced feature requires 51% mining power and zero user support, even in that case majority users still have options. (point 10) 15. less miner polling pre-deployment) One of the rationales to lower the activation threshold from 95% to 90% is due to 89% verbal miner support https://taprootactivation.com/ . I saw some people wanted to go as low as 85% or 80%, hell someone on the ##uasf channel wanted to drop threshold to 65% to incentivize non-upgraded nodes to join the UASF alt-node http://gnusha.org/uasf/2021-03-04.log . With this proposal it doesn't matter if miners don't overwhelmingly support the feature so their verbal input is less significant. Deployment can happen as soon as 51% of mining power express verbal support, unlike what's happening right now where miner apathy is delaying deployment because no one is sure whether a supermajority is achievable. 16. new status quo) I'm not sure I understand when Luke says LOT=true is status quo but this proposal probably fixes that too? This proposal kind of acts like a flag day with the protection of a majority PoW. The case for this new proposal for supporters of LOT=false first: 1. discovered bugs can back out deployment) The activation can be canceled and the chain will remain united if any problem is found. (point 1 on Matt's Modern Soft Fork Activation proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) 2. miner minority can't cancel) Only 51% of mining power can cancel if a bug is found so a minority of miners can't abuse the threat of canceling for political reasons. 3. no need for miner promises) In the back of the minds of LOT=false supporters there is always the doubt of "what if we really can't trust miners?". We can ask them and make them promise that they will support the upgrade but we can never really know. With this proposal we don't need to worry about a miner minority promising to signal and then breaking the promise. 4. no UASF aggression at the start) Miners aren't antagonized because they are still part of the signaling process and they keep their right to run any client they want without the threat of a UASF. Though they will eventually mine orphan blocks if they don't upgrade, which is probably true for a handful of miners even today. 5. UASF is optional) If miners seem to be stalling or not signaling users have the option of running a media blitz without having to coordinate the release of a new UASF client. This removes the complications of multiple client releases interacting to activate the same feature. 6. UASF is reactive) Forcing miners to upgrade with a media blitz and a threat to create a hard fork later will be after miners are shown to be apathetic or malicious. Users have time to gather information while the MUST_SIGNAL period approaches. 7. no user forced changes) Removes the precedent of users forcing changes on miners because they must attain 51% miner support. If users have less than 51% miner support they must hard fork instead. 8. safe supermajority activation) The threshold will remain in supermajority territory 95% before the MUST_SIGNAL phase. When a supermajority is achieved there will be minimal disruption and minimal detriment to Bitcoin's security. (point 3 on Matt's Modern Soft Fork Activation proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) 9. users have time to upgrade) Users will have an appropriate amount of time to upgrade. (whatever time it takes to achieve supermajority) (point 2 on Matt's Modern Soft Fork Activation proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) 10. no long deployments) In case of miners not reaching a supermajority due to apathy we won't have to wait six months and then another release and another long deployment. 11. no UASF minority chain) Users won't be reorged because if at the end of activation support is below 51% taproot wont activate and users will stay together. 12. no big reorgs) If more than 51% of miners support Taproot then upgraded users, non-upgraded users, and minority miners will stay on the same chain. Some non-upgraded users and miners will be at risk of creating and following orphan blocks. But the likelihood is that the miner minority will upgrade if we assume that they are self-interested and don't want to mine orphan blocks. This results in a small risk of chain split and small risk of big reorgs. (point 4 on Matt's Modern Soft Fork Activation proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html) 13. no late adopter stress) If mining power majority is not achieved during activation then all miners stay on the same chain and late adopters don't need to worry about the risk of some UASF chain overtaking theirs. 14. no divergent consensus rules) The chain can stay together and our friends won't fork off because we will all be running the same client and the client will be backwards compatible. 15. no need for redeployment) If activation fails it's clear that it happened due to a lack of a majority of clients supporting the change and a lack of a strong enough economic group to force miners to upgrade. So if activation fails we can be sure that we won't be releasing the feature again or the feature must be released as a hard fork if a group of users really really want it. 16. no co-optable deployment) No more LOT flag so code can't be easily modified to create divergent consensus from a core release. 17. no incentive to force signaling) A big reason for users to force signaling is for reorg protection in case they are in a minority chain. With this proposal the UASF chain is protected from reorgs by a miner majority so no need to force signaling. 18. no configurable consensus) No more LOT flag so no need for a parameter/config value to force users to pick a side on upgrade. Forcing the choice on users guarantees there will be users running a UASF but at the same time reduces the likelihood of a successful UASF due to other users running LOT=false. 19. no alt-nodes) If this proposal gains consensus and it can be released in core then we will avoid the issue of fracturing groups of core forks jockeying for user support. 20. miners can test features before deployment) If changes can be written to core without contention or risk of divergent consensus. Core can release RCs for miners and users to test the feature. I think it would have helped to know the segwit-ASIC boost conflict before segwit signaling even though there is no guarantee that it would have been disclosed. But maybe having this ability will be useful for other features. 21. no false flagging interference) No need for two activation periods so no need to worry about buggy miner signaling software (false flagging) that may continue to signal for the prior deployment. This is a potential issue for modern soft fork activation. (this issue is mentioned by AJ Towns in the decreasing threshold proposal https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki) 22. no dev vilification) Core developers can't be portrayed as having ultimate power because they at least require 51% miner support. 23. safe supermajority threshold) Since the threshold will drop to 51% during MUST_SIGNAL we could take the luxury of raising the supermajority threshold back to 95% instead of 90%. This increases the risk of miner stalling but that's the worst that could happen, which is pretty good IMO. 24. no flag day) Avoids the pressure of devs pulling the trigger on a flag day because this proposal removes (reduces?) the likelihood that there will be a future chain split. This takes a lot of pressure off of devs releasing this deployment. 25. no Taproot death) If we go with LOT=false first and it fails, there is no getting around the fact that one group will want LOT=true and the other group will want to drop Taproot altogether. I think devs will still have a hard time deploying LOT=true after LOT=false. 26. no procrastinating) Since the deployment period doesn't need to be too long for a safe LOT=true (after a failed LOT=false signaling period) then there isn't a risk of users and miners procrastinating upgrades until the last 3 or so months before the flag day. 27. another activation failure does not kill the MASF method) If LOT=false fails again it was likely we would have never used it again. That would be the death of quick MASF. But with this proposal the only way to fail is if a majority of miners are against the feature and have been unconvinced by an economic minority media blitz. In which case the feature is contentious but the activation method remains intact. The case for this proposal for supporters of a straight flag-day: 1. no divergent consensus rules) all nodes will be compatible and backwards compatible so they will all stay with the same consensus rules. 2. discovered bugs can back out deployment) A flag day can't be canceled. With this proposal if we find a bug it's easy for miners to revert to an old version to get signaling below 51%. 3. signaling is available) With signaling we can all see the progress of the activation. We will know if it's near a supermajority, we will know if it's near the 51% milestone. Without signaling we might fail to gather adoption and not even know which miners were actually running the new version. 4. majority hash power will stay together) All users and the majority mining power will stay on the same chain. It's possible that a minority of mining power will fall out of consensus if they don't enforce Taproot rules but if we assume they will act in their best interest then they will upgrade once the simple majority of mining power is signaling. Minority miners that are staunchly against upgrading or are just really really really lazy and maybe take mining as a hobby will fork off. But It's not possible to force those minority miners anyway. For example there could be a minority of miners running pre-segwit software today. 5. no redeploy to move the date) With a 95% threshold and a 51% at the end we can be certain that the change will or won't activate. So no need to scramble to move dates or potentially release a LOT=false client earler than the flag day. Any of that scrambing is gone because we just wait. The worst that could happen is a 6% miner minority can delay the change until the MUST_SIGNAL period. 6. it's clear who wins under contention) Flag day activations need as much economic adoption as any other method. With a flag day, any contention in the feature will lead to entrenched groups and a split is inevitable. With this proposal the economic majority decides by forcing miners to signal one way or another by threatening a hard fork. But with this proposal it's clear that who wins the debate is who wins 51% miner support so the economic majority (if it's very small will likely reconsider not forking off). With a flag day, who wins the debate is only clear years after the flag day based on market capitalization. 7. can start building early) Developers will have high assurance that the change will activate after the 51% threshold is reached so they can start building after 51% and don't need to wait until the supermajority. 8. MASF is available) Activation can happen very early with a supermajority since Taproot is not contentious. (still the most likely outcome, by far!) 9. no dev forced changes) Avoid a power grab from core developers to rush a flag day that doesn't have enough economic majority. Once the client is released the chain split is nearly guaranteed. With this proposal devs would need a miner majority and a supporting economic majority or an apathetic economy supermajority. The case for this new proposal for supporters of gradual decreasing activation threshold: 1. no gaming thresholds) Miners can't suddenly signal at 55% threshold to force 45% of non-signaling miners to scramble an update. The case for this new proposal for supporters on all sides: 1. conservative enough for core) If we can fix all the kinks and achieve some consensus I think this proposal will be safe enough to be supported by core devs. 2. remove activation contention) If things go well we might get a few more rounds of soft fork activation without contention. 3. no ambiguity on which chain is bitcoin) If there is a minority group that forks off then the chain called Bitcoin will be the one with the most economic support and miner support. With this come the benefits that 21 million stays 21 million and $1 trillion stays $1 trillion. Unless a majority of mining power is trying to force a soft fork that antagonizes the economic majority. Tthis miner oppression would then be considered a 51% attack and maybe a PoW change is in order. 4. *this is a real solution not a compromise*) I think this solution fixes so many issues on both sides of the LOT debate that I see it as better than either solution independently. This is a real solution and the added benefit is that it's a solution that coincidentally brings both sides of the debate together. 5. only contentious changes make contentious activation) Contentious activations will be ones that have near 50/50 miner support. Features like that will probably never even get to the activation stage and Taproot is not one of them. 6. no LOT drama) The LOT flag is removed so no more default to argue over. No more drama. And no cover for social attacks on bitcoin. 7. no mid-deployment changes) Deployment is on complete autopilot so users don't need to change any configuration in the middle of deployment period. Leave it to bitcoiners to turn bitcoin's biggest flaw (51% attacks) into a feature (51% upgrade pressure). The Bitcoin space is so fascinating. I hope there isn't some giant obvious flaw I'm missing. Please tell me if I am. Or add to the arguments if you'd like. Cheers Ariel Lorenzo-Luaces