Re: [bitcoin-dev] Making the case for flag day activation of taproot
On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote: > While I support essentially any proposed taproot activation method, including > a > flag day activation, I think it is premature to call BIP8 dead. > > Even today, I still think that starting with BIP8 LOT=false is, generally > speaking, considered a reasonably safe activation method in the sense that I > think it will be widely considered as a "not wholly unacceptable" approach to > activation. If everyone started with lot=false, that would be true -- that was how segwit then BIP148/BIP91 worked, and was at least how I had been assuming people were going to make use of the new improved BIP8. But it seems more likely that when activation starts, even if many people run lot=false, many other people will run lot=true: see Luke's arguments on this list [0], Rusty's campaign for a lot=true option [1], the ##uasf channel (initial topic: Development of a Taproot activation implementation with default LOT=true) [2], or Samson's hat designs [3]. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html [1] https://rusty.ozlabs.org/?p=628 https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311 [2] http://gnusha.org/uasf/ [3] https://twitter.com/Excellion/status/1363751091460956167 With lot=false and lot=true nodes active on the network, a chain split occurs if the activation is blocked: perhaps that might happen for good reasons, eg because there are implementation bugs found after activation settings are merged but prior to activation locking in, or perhaps for neutral or bad reasons that cause miners to be opposed. In the event of a huge conflict or emergency as bad as or worse than occurred with segwit, a chain split might well be the lesser evil compared to the activation being blocked or delayed substantially; but as default scenario for every consensus change, before we know if someone might find a problem while there's still time to back out, and before we know if there is going to be a huge conflict? It doesn't seem as focussed on safety as I'd expect from bitcoin. > After a normal and successful Core update with LOT=false, we will have more > data showing broad community support for the taproot upgrade in hand. In the > next release, 6 months later or so, Core could then confidently deploy a BIP8 > LOT=true client, should it prove to be necessary. BIP8/lot=true is great for the situation we found ourselves in with BIP91/BIP148: there's an activation underway, that is being unexpectedly opposed, we want to ensure it activates, *and* we don't want to have everyone have to do a new round of software upgrades. But if we're able to calmly put out a new release with new activation parameters, with enough time before it takes effect that everyone can reasonably upgrade to it, that's a pretty different situation. First, since we're giving everyone time to upgrade, it can be a clean secondary deployment -- there's no need to try to drag the original lot=false users along -- we're giving everyone time to upgrade, and everyone includes them. Second, lot=true implies we're doing some unsignalled consensus change anyway -- blocks would be considered invalid if they don't signal for activation as of some height, with no prior on-chain signalling that that rule change has occurred. So if we're allowing that, there's no principle that requires signalling to lock in the change we're actually trying to activate. So at that point why not simply reverse the burden of proof entirely? Run an initial "speedy trial" type event that allows fast activation via miner enforcement prior to everyone having upgraded; and if that fails but there haven't been valid reasonable objections to activation identified, run a secondary activation attempt that instead of requiring 90% signalling to activate, requires 90% signalling to *fail*. Miners not upgrading is then not a blocker, and even if a few miners are buggy and signal accidently, that doesn't cause a risk to them of having their blocks dropped, or to the network of having the upgrade blocked. If there are good reasons to object to the fork being activated that are discovered/revealed (very) late, this also provides an opportunity to cleanly cancel the activation by convincing miners that the activation is undesirable and having them agree to signal for cancellation (via BIP-91 style coordination or even BIP-148 style mandatory signalling, eg). And, on the other hand, if 90% of miners are opposed to a soft fork for some selfish or bad reason, with that much hashpower they could easily do a 51% attack on the network after activation to prevent any new features being used, so cancelling activation in that case is probably not worse in practice than it would be continue with it despite the opposition. I think a state machine along the lines of: DEFINED - for 6 months after code release STARTED - exactly 1 period
Re: [bitcoin-dev] Making the case for flag day activation of taproot
Replies inline. Several sections removed, where I basically agree. On 3/4/21 08:47, Russell O'Connor wrote: Appologies as I've rearranged your comments in my reply. I agree with you. I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such a flag day activation. If there is support for it to be merged, that would be fantastic. I think we should proceed along these lines forthwith. However, the existence and/or release of a flag day activation code does not in of itself preclude concurrently developing and/or releasing a BIP8 LOT=false deployment. Activating taproot is "idempotent" after all. We could even do a Core release with a flag day activation while we continue to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having a flag day activation code merged would take a lot of pressure off further BIP8 LOT=false work. Hmm, while this is certainly true at a technical level, it adds a lot of complexity both in terms of discussion, and for users - "I already upgraded to Taproot, why did I just see a fork with an invalid Taproot spend?". As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state, then running BIP8 LOT=false alongside a flag day activation at timeout may be the way to go. Once a flag day deployment is released, the LOT=true people would have their guaranteed activation and would be less interested in an alternative client. And without a MUST_SIGNAL state, I believe the LOT=false deployment won't lead any hashpower that is following standardness rules to create invalid blocks. This is indeed a significant improvement over BIP 8 in my opinion. However, as I pointed out on a Reddit discussion with Aaron, I'm still incredibly worried about users pushing for some UASF-style forced-signaling guerilla faster-activation. It may absolutely be the case that Taproot activates quickly or that such users are a tiny minority of transacting. However, as we saw with BIP 148/UASF, even a tiny minority of transacting users can set the tone and claim victory over how a soft-fork activates. I worry that even your approach here runs the risk of yet further normalization of consensus rule diversity on the network. Maybe my worry is overblown, and I'm certainly not going to try to solely stand in the way on this one, but now that we're stuck in yet another overblown debate, we might as well take it as an opportunity to reinforce the idea that consensus rule diversity runs the risk of consensus failure, and isn't a reasonable risk. > Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe > activation method in the sense that I think it will be widely considered as a "not wholly unacceptable" approach to > activation. How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this list have publicly committed to? Firstly, it is an open network. Anyone can join and run whatever consensus rules they want. People have run divergent consensus rules on the network in the past and it will continue to do so in the future. It is troublesome when it happens in mass, but it isn't fatal. We can't prevent it, and we should continue working to keep the protocol robust in the face of it. And we certainly shouldn't be bullied by anyone who comes threatening their own soft-fork. Apologies. I should have phrased my comment better. My worry, at a broad level is that (a) people have taken the events around the Segwit BIP 148 UASF to mean that a very small minority of users can (and maybe should) push consensus rules through threats of breaking consensus and (b) there is a very vocal group today which is reinforcing this belief by ignoring the complex context around Segwit and behaving similarly with regards to Taproot. Indeed, there is nothing we can, or should, do to actively prevent people from running their own software which interprets Bitcoin's consensus rules in...creative ways. But that isn't to say there is no use worrying about it. 95% of Bitcoin users aren't aware that this debate is even happening. Of the remaining 5%, 90% haven't had the time to research and think deeply enough to form an opinion. Our responsibility is to the 99.5% of users. Sure, individuals running different consensus rules won't cause immediate harm to others, but the net effect of many users doing so and especially the community normalizing such behavior very significantly can. Ill-informed transactors running such software (including wallet providers with users who were unaware of the events) can be screwed out of their Bitcoin. This outcome very well could have occurred in the case of the BIP 148 UASF, and repeating the same pattern many times will not help to de-risk that. Even simply doing nothing may not prevent divergent consensus from appearing on the network. Playing
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On Friday 05 March 2021 14:51:12 Ryan Grant via bitcoin-dev wrote: > On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev > > wrote: > > So that leads me to believe here that the folks who oppose LOT=true > > primarily have an issue with forced signaling, which personally I > > don't care about as much, not the idea of committing to a UASF from > > the get go. > > The biggest disconnect is between two goals: modern soft-fork > activation's "Don't (needlessly) lose hashpower to un-upgraded > miners"; and UASF's must-signal strategy to prevent inaction. > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547 >.html > > This question dives to the heart of Bitcoin's far-out future. > Of two important principles, which principle is more important: > > - to allow everyone (even miners) to operate on the contract they > accepted when entering the system; or There was never any such a contract. Even full nodes must upgrade in a softfork, or they lose their security and become comparable to light wallets. > - to protect against protocol sclerosis for the project as a whole? What? > Do miners have a higher obligation to evaluate upgrades than economic > nodes implementing cold storage and infrequent spends? If they do, > then so far it has been implicit. LOT=true would make that obligation > explicit. Miners either make valid blocks or they don't. The only thing they "need" to evaluate is the market for their work. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev wrote: > So that leads me to believe here that the folks who oppose LOT=true > primarily have an issue with forced signaling, which personally I > don't care about as much, not the idea of committing to a UASF from > the get go. The biggest disconnect is between two goals: modern soft-fork activation's "Don't (needlessly) lose hashpower to un-upgraded miners"; and UASF's must-signal strategy to prevent inaction. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html This question dives to the heart of Bitcoin's far-out future. Of two important principles, which principle is more important: - to allow everyone (even miners) to operate on the contract they accepted when entering the system; or - to protect against protocol sclerosis for the project as a whole? Do miners have a higher obligation to evaluate upgrades than economic nodes implementing cold storage and infrequent spends? If they do, then so far it has been implicit. LOT=true would make that obligation explicit. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
Mike was wrong about a number of things, and in the end decided that Bitcoin was pointless, as people could not defend it against the state. He used this as the basis for his defense of large blocks and centralized mining. When that didn’t work out he quit, to work on centralized systems. People can of course do what they want, but unnecessarily splitting from the existing chain reduces utility, which seems counterproductive. BCH is a good example of this. Compatibility isn’t “dangerous”. Old nodes don’t need to know what new nodes are doing. If the person operating one needs to validate a taproot payment to himself, he would have to upgrade. Otherwise it’s of no consequence, his node is economic (relevant) only in relation to the legacy payments he receives, which he can continue to validate. e > On Mar 4, 2021, at 15:22, Vincent Truong via bitcoin-dev > wrote: > > > > I must remind everyone of Mike Hearn's proposal not many years ago, which > ought to be on everyone's mind right now. "Every soft fork should be a hard > fork, and that soft forks are inherently dangerous because old nodes are > tricked to not know what the new nodes are doing" (paraphrased). Whether > taproot is dangerous is not the issue; whether old nodes should or should not > ignore new rules, is. > > Flag day activation of a soft fork is basically proposing a hard fork, but > without saying or doing it at full commitment. May as well just do a flag day > hard fork. > > Bitcoin Cash/Bcash has already tested for you how a market driven hard fork > should work. Bitcoin didn't die. We should be learning from the mistakes made > in those early hard forks to not repeat them when Bitcoin hard forks - like > having replay protection written before deployment. > > If it's not evident within the first 6-12 blocks which fork is winning, then > the market will trade it out. Just like what happened with Bitcoin Cash/Bcash. > > Not only that, it stops the drama of Bitcoin Core devs from "being in > control" of consensus. The market will choose, you just create the safest way > for users to participate. The market is consensus. Rough consensus is just > the conversation starter. > > >> On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, >> wrote: >> The bitcoin world is close to total gridlock on the question of how to >> activate taproot. There's no agreement on activation[1][2], and if an >> agreement isn't reached then nothing happens. That would be really >> terrible because we'd miss out on the benefits of taproot and >> potentially other future soft forks. >> >> A major problem with BIP8 is that it would result to a situation where >> different parts of the bitcoin ecosystem run different consensus rules. >> Some people will run LOT=true and others LOT=false. Worst of all, it >> becomes vulnerable to a twitter/reddit/social media blitz which could >> attempt to move the date of miner activation around. >> >> Twitter and reddit drama provide a perfect cover for social attacks on >> bitcoin. >> >> Forced signalling leads to brinksmanship. Where two or more sides >> (backed up by social media drama) enter into a game of chicken with >> deployed nodes. If one of them doesn't concede then we get a damaging >> chain split. And the $1 trillion in value that the bitcoin network >> protects is put at risk. From the point of view of a miner or big >> exchange stuck in the middle, if they look at the ecosystem of twitter >> and reddit (especially if you think about all the problems with bots and >> sockpuppets) they have no idea which consensus rules they should >> actually follow and exactly what date they take effect. Miners, >> exchanges, merchants and the rest of the ecosystem exist to serve their >> customers and users, and trouble happens when they don't know what their >> customers really want. Social media attacks are not just a theoretical >> concern; back during the block size drama, the bitcoin reddits were >> targetted by bots, sockpuppets and brigading[3]. >> >> Enter flag day activation. With a flag day there can be no >> brinksmanship. A social media blitz cant do anything except have its own >> followers fork away. Crucially, miner signalling cant be used to change >> the activation date for nodes that didn't choose to and just passively >> follow signalling. Changing the activation date requires all those users >> to actually run different node software. >> >> Flag day activation works simply: we choose a block height and after >> that block height the new taproot rules become enforced. >> >> >> Supporters of the permissionless, "users rule" approach of LOT=true >> should be happy because it completely takes miners out of activation. >> >> Supporters of the safe, conservative approach of LOT=false can be made >> happy with a few ways of derisking: >> >> * Getting mining pools, businesses and users to look at the code and ask >> if they (a) think its either neutral or good for
Re: [bitcoin-dev] Making the case for flag day activation of taproot
I must remind everyone of Mike Hearn's proposal not many years ago, which ought to be on everyone's mind right now. "Every soft fork should be a hard fork, and that soft forks are inherently dangerous because old nodes are tricked to not know what the new nodes are doing" (paraphrased). Whether taproot is dangerous is not the issue; whether old nodes should or should not ignore new rules, is. Flag day activation of a soft fork is basically proposing a hard fork, but without saying or doing it at full commitment. May as well just do a flag day hard fork. Bitcoin Cash/Bcash has already tested for you how a market driven hard fork should work. Bitcoin didn't die. We should be learning from the mistakes made in those early hard forks to not repeat them when Bitcoin hard forks - like having replay protection written before deployment. If it's not evident within the first 6-12 blocks which fork is winning, then the market will trade it out. Just like what happened with Bitcoin Cash/Bcash. Not only that, it stops the drama of Bitcoin Core devs from "being in control" of consensus. The market will choose, you just create the safest way for users to participate. The market is consensus. Rough consensus is just the conversation starter. On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > The bitcoin world is close to total gridlock on the question of how to > activate taproot. There's no agreement on activation[1][2], and if an > agreement isn't reached then nothing happens. That would be really > terrible because we'd miss out on the benefits of taproot and > potentially other future soft forks. > > A major problem with BIP8 is that it would result to a situation where > different parts of the bitcoin ecosystem run different consensus rules. > Some people will run LOT=true and others LOT=false. Worst of all, it > becomes vulnerable to a twitter/reddit/social media blitz which could > attempt to move the date of miner activation around. > > Twitter and reddit drama provide a perfect cover for social attacks on > bitcoin. > > Forced signalling leads to brinksmanship. Where two or more sides > (backed up by social media drama) enter into a game of chicken with > deployed nodes. If one of them doesn't concede then we get a damaging > chain split. And the $1 trillion in value that the bitcoin network > protects is put at risk. From the point of view of a miner or big > exchange stuck in the middle, if they look at the ecosystem of twitter > and reddit (especially if you think about all the problems with bots and > sockpuppets) they have no idea which consensus rules they should > actually follow and exactly what date they take effect. Miners, > exchanges, merchants and the rest of the ecosystem exist to serve their > customers and users, and trouble happens when they don't know what their > customers really want. Social media attacks are not just a theoretical > concern; back during the block size drama, the bitcoin reddits were > targetted by bots, sockpuppets and brigading[3]. > > Enter flag day activation. With a flag day there can be no > brinksmanship. A social media blitz cant do anything except have its own > followers fork away. Crucially, miner signalling cant be used to change > the activation date for nodes that didn't choose to and just passively > follow signalling. Changing the activation date requires all those users > to actually run different node software. > > Flag day activation works simply: we choose a block height and after > that block height the new taproot rules become enforced. > > > Supporters of the permissionless, "users rule" approach of LOT=true > should be happy because it completely takes miners out of activation. > > Supporters of the safe, conservative approach of LOT=false can be made > happy with a few ways of derisking: > > * Getting mining pools, businesses and users to look at the code and ask > if they (a) think its either neutral or good for their business or use > case and (b) they believe others view it similarly and that the > consensus changes proposed have a good social consensus around them. > > * Setting the flag day far in the future (18 months or 2 years in the > original proposal[3]). > > > == What if flag day activation is used maliciously? == > > What if one day the Core developer team is co-opted and uses the flag > day method to do something bad? For example, a soft fork where sending > to certain blacklisted addresses is not allowed. The bitcoin user > community who wants to resist this can create their own > counter-soft-fork full node, where the first block after the flag day > MUST pay to one of those addresses on the blacklist. This forces a chain > split between the censorship rules and the no-censorship rules, and its > pretty obvious that the real bitcoin which most people follow will be > the chain without censorship. > > For example, if a group of users didn't agree with taproot then they >
Re: [bitcoin-dev] Making the case for flag day activation of taproot
As one of the folks that prefers LOT=true I can certainly attest to the fact that at least some of us would be willing to do a flag day activation instead. As far as I'm concerned, flag day does not give a very small percentage of the user base (5-10% of minerz) the ability to veto a change that has broad support and is non-invasive. However, I must question the incongruence between those who oppose LOT=true and support a possible flag day activation. In my mind, all that LOT=true does is concatenate a flag day activation after a LOT=false deployment, where, as Russell noted, activation is an idempotent operation. So that leads me to believe here that the folks who oppose LOT=true primarily have an issue with forced signaling, which personally I don't care about as much, not the idea of committing to a UASF from the get go. More generally, I want to remind everyone that this is a change everyone supports (so far). So letting the activation method kill the proposal altogether would be tragic. If those with specific objections to various activation methods can be clear about what those objections are, and, even better, suggest small adjustments to various proposals on those grounds, I think we have a far more optimistic path forward on getting Taproot activated. Bitcoin may not have voting, but it certainly can have compromise to come to consensus on these things. I don't think anyone in the UASF crowd is impatient with respect to the actual guaranteed activation timeline, what I get the sense of is a burnout on the arguments, paired with no action. To the degree that we can make progress on coming to an agreement that makes people comfortable, even if you don't get everything you want, I think. Keagan On Thu, Mar 4, 2021 at 11:04 AM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Appologies as I've rearranged your comments in my reply. > > On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo > wrote: > >> >> On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote: >> > > After a normal and successful Core update with LOT=false, we will have >> more data showing broad community support for the >> > taproot upgrade in hand. >> >> I think this is one of the strongest arguments against a flag day >> activation, but, as I described in more detail in the >> thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we >> aren't there enough already. >> > > I agree with you. I also think we have plenty of evidence to proceed with > taproot and could proceed with a PR for such a flag day activation. If > there is support for it to be merged, that would be fantastic. I think we > should proceed along these lines forthwith. > > However, the existence and/or release of a flag day activation code does > not in of itself preclude concurrently developing and/or releasing a BIP8 > LOT=false deployment. Activating taproot is "idempotent" after all. We > could even do a Core release with a flag day activation while we continue > to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having > a flag day activation code merged would take a lot of pressure off further > BIP8 LOT=false work. > > As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL > state, then running BIP8 LOT=false alongside a flag day activation at > timeout may be the way to go. Once a flag day deployment is released, the > LOT=true people would have their guaranteed activation and would be less > interested in an alternative client. And without a MUST_SIGNAL state, I > believe the LOT=false deployment won't lead any hashpower that is following > standardness rules to create invalid blocks. > > >> > In the next release, 6 months later or so, Core could then confidently >> deploy a BIP8 LOT=true >> >> Could you clarify what an acceptable timeline is, then? Six months from >> release of new consensus rules to activation (in >> the case of a one-year original window) seems incredibly agressive for a >> flag-day activation, let alone one with >> forced-signaling, which would require significantly higher level of >> adoption to avoid network split risk. In such a >> world, we'd probably get Taproot faster with a flag day from day one. >> > > Whatever timeline people are in favour of. I think having a year or more > between the LOT=true or flag day more and the anticipated second release > date is fair myself. > That would suggest a 2-year timeout from the start to give plenty of room. > > Of course, if we start with a flag day from the start then we can just do > 1 year and we don't need a second deployment. > > We could also do a "Let’s see what happens" with a short 3 or 4-month > deployment and still do a follow up activation if that is more agreeable. > That would give a net of about 1.5 years or so because we don't need to > anticipate the second relase date. > > I'm good with whatever, and I'm happy to make more concrete suggestions if > that is necessary. I think there exist
Re: [bitcoin-dev] Making the case for flag day activation of taproot
Appologies as I've rearranged your comments in my reply. On Wed, Mar 3, 2021 at 5:14 PM Matt Corallo wrote: > > On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote: > > After a normal and successful Core update with LOT=false, we will have > more data showing broad community support for the > > taproot upgrade in hand. > > I think this is one of the strongest arguments against a flag day > activation, but, as I described in more detail in the > thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we > aren't there enough already. > I agree with you. I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such a flag day activation. If there is support for it to be merged, that would be fantastic. I think we should proceed along these lines forthwith. However, the existence and/or release of a flag day activation code does not in of itself preclude concurrently developing and/or releasing a BIP8 LOT=false deployment. Activating taproot is "idempotent" after all. We could even do a Core release with a flag day activation while we continue to discuss BIP8 LOT=false if that gets the ball rolling. Certainly having a flag day activation code merged would take a lot of pressure off further BIP8 LOT=false work. As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state, then running BIP8 LOT=false alongside a flag day activation at timeout may be the way to go. Once a flag day deployment is released, the LOT=true people would have their guaranteed activation and would be less interested in an alternative client. And without a MUST_SIGNAL state, I believe the LOT=false deployment won't lead any hashpower that is following standardness rules to create invalid blocks. > > In the next release, 6 months later or so, Core could then confidently > deploy a BIP8 LOT=true > > Could you clarify what an acceptable timeline is, then? Six months from > release of new consensus rules to activation (in > the case of a one-year original window) seems incredibly agressive for a > flag-day activation, let alone one with > forced-signaling, which would require significantly higher level of > adoption to avoid network split risk. In such a > world, we'd probably get Taproot faster with a flag day from day one. > Whatever timeline people are in favour of. I think having a year or more between the LOT=true or flag day more and the anticipated second release date is fair myself. That would suggest a 2-year timeout from the start to give plenty of room. Of course, if we start with a flag day from the start then we can just do 1 year and we don't need a second deployment. We could also do a "Let’s see what happens" with a short 3 or 4-month deployment and still do a follow up activation if that is more agreeable. That would give a net of about 1.5 years or so because we don't need to anticipate the second relase date. I'm good with whatever, and I'm happy to make more concrete suggestions if that is necessary. I think there exist acceptable timelines here. > > client, should it prove to be necessary. A second Core deployment of > LOT=true would mitigate some of the concerns with > > LOT=false, but still provide a period beforehand to objective actions > taken by the community in support of taproot. We > > don't even have to have agreement today on a second deployment of > LOT=true after 6 months to start the process of a > > LOT=false deployment. The later deployment will almost certainly be > moot, and we will have 6 months to spend debating > > the LOT=true deployment versus doing a flag day activation or something > else. > > That was precisely the original goal with the LOT=false movement - do > something easy and avoid having to hash out all > the technical details of a second deployment. Sadly, that's no longer > tennable as a number of people are publicly > committed to deploying LOT=true software on the network ASAP. > First things last: > Even today, I still think that starting with BIP8 LOT=false is, generally > speaking, considered a reasonably safe > > activation method in the sense that I think it will be widely considered > as a "not wholly unacceptable" approach to > > activation. > > How do you propose avoiding divergent consensus rules on the network, > something which a number of commentors on this > list have publicly committed to? > Firstly, it is an open network. Anyone can join and run whatever consensus rules they want. People have run divergent consensus rules on the network in the past and it will continue to do so in the future. It is troublesome when it happens in mass, but it isn't fatal. We can't prevent it, and we should continue working to keep the protocol robust in the face of it. And we certainly shouldn't be bullied by anyone who comes threatening their own soft-fork. Even simply doing nothing may not prevent divergent consensus from appearing on the network. Playing conservative isn't playing
Re: [bitcoin-dev] Making the case for flag day activation of taproot
would it help by first setting a regular period of e.g. 6 months when only at that time would consensus rules ever be changed? not, "6 months from now taproot will be introduced', a rule, "*any* consensus change regardless of what they are (including NO change) will *ONLY* be made at regular interval period X months". this stops dead efforts by bots to announce "consensus! rules! are changing!" because if it's not at the exact time-period it's clearly bullshit. l. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On 3/3/21 14:08, Russell O'Connor via bitcoin-dev wrote: While I support essentially any proposed taproot activation method, including a flag day activation, I think it is premature to call BIP8 dead. Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe activation method in the sense that I think it will be widely considered as a "not wholly unacceptable" approach to activation. How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this list have publicly committed to? After a normal and successful Core update with LOT=false, we will have more data showing broad community support for the taproot upgrade in hand. I think this is one of the strongest arguments against a flag day activation, but, as I described in more detail in the thread "Straight Flag Day (Height) Taproot Activation", I'm not sure we aren't there enough already. In the next release, 6 months later or so, Core could then confidently deploy a BIP8 LOT=true Could you clarify what an acceptable timeline is, then? Six months from release of new consensus rules to activation (in the case of a one-year original window) seems incredibly agressive for a flag-day activation, let alone one with forced-signaling, which would require significantly higher level of adoption to avoid network split risk. In such a world, we'd probably get Taproot faster with a flag day from day one. client, should it prove to be necessary. A second Core deployment of LOT=true would mitigate some of the concerns with LOT=false, but still provide a period beforehand to objective actions taken by the community in support of taproot. We don't even have to have agreement today on a second deployment of LOT=true after 6 months to start the process of a LOT=false deployment. The later deployment will almost certainly be moot, and we will have 6 months to spend debating the LOT=true deployment versus doing a flag day activation or something else. That was precisely the original goal with the LOT=false movement - do something easy and avoid having to hash out all the technical details of a second deployment. Sadly, that's no longer tennable as a number of people are publicly committed to deploying LOT=true software on the network ASAP. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On 2021-03-03 20:48, Chris Belcher wrote:
On 03/03/2021 17:30, yanma...@cock.li wrote:
Is that supposed to be a good thing? "We should do X because it'll
work"
doesn't prove X is actually good. These things can be evil, but they
can
also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!
It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain
rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.
Tell their software to do it, yes, but fork it? That seems like a big
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin
Core to do something, it seems like a bad thing that it would favor the
Core devs' wishes ("Get Taproot done") over mine.
That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.
[...]
You're right in suggesting that it will work, but the reason why it
will
work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.
It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone
either
wants taproot or has no opinion about taproot.
Both can be true at the same time. This is going to work because
basically nobody opposes Taproot. But if you did have some people
opposing Taproot, it would still work, because nobody would want to
disobey Core.
Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?
Example 1: There is currently a specific mining pool planning to
blacklist addresses on sanctions lists. If they were to
convince/bribe/threaten Core to soft-fork so as to burn one specific
UTXO worth $1, the only direct victim of that would be the holder of
that UTXO, who loses only $1 from it.
Example 2: A soft fork to decrease the block size by 0.1%.
If we assume that the current block size is optimal and censorship is
bad, it seems simultaneously true that
1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1
loss to one guy
You might say that these are minor changes. Sure. But that's what I'm
saying: if the change is big ("egregious") enough to seriously
inconvenience people, they would fight it, but if it's trivial (thought
still bad), the inertia of Core would force them to accept it.
Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.
(Nitpick: Miners would probably not support it, because less people
would be willing to pay that fee.)
Sure, and this change would be resisted because it seriously
inconveniences people. But what if it's just 2sat/vbyte?
At least you shouldn't hard-code it and require dissenters to fork
away.
I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the
default
value sure, but requiring a fork to change it is, in my opinion,
oppressive.
What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor,
in
fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.
I don't disagree. The ability to do a counter-UASF should also be added,
if it's envisioned somebody might want to do that.
Basically, I think that Core should provide users with the tools to
express their views and to exercise their economic power, and they could
give them default values according to what they think best.
However, they shouldn't force people to use a forked client if they want
to disobey them. That would be to abuse the power vested in the
development group.
On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its
own
followers fork away. Crucially, miner signalling cant be used to
change
the activation date for nodes that didn't choose to and just
Re: [bitcoin-dev] Making the case for flag day activation of taproot
While I support essentially any proposed taproot activation method, including a flag day activation, I think it is premature to call BIP8 dead. Even today, I still think that starting with BIP8 LOT=false is, generally speaking, considered a reasonably safe activation method in the sense that I think it will be widely considered as a "not wholly unacceptable" approach to activation. After a normal and successful Core update with LOT=false, we will have more data showing broad community support for the taproot upgrade in hand. In the next release, 6 months later or so, Core could then confidently deploy a BIP8 LOT=true client, should it prove to be necessary. A second Core deployment of LOT=true would mitigate some of the concerns with LOT=false, but still provide a period beforehand to objective actions taken by the community in support of taproot. We don't even have to have agreement today on a second deployment of LOT=true after 6 months to start the process of a LOT=false deployment. The later deployment will almost certainly be moot, and we will have 6 months to spend debating the LOT=true deployment versus doing a flag day activation or something else. I don't think we need to start self-sabotaging our efforts to get taproot activated this year just yet. Let's cherry-pick the commits of PR #19573 to split it up into non-MUST_SIGNAL and MUST_SIGNAL components, and get some reviews on that first. Then afterwards we can decide if BIP8 is dead or not. On Wed, Mar 3, 2021 at 9:39 AM Chris Belcher via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The bitcoin world is close to total gridlock on the question of how to > activate taproot. There's no agreement on activation[1][2], and if an > agreement isn't reached then nothing happens. That would be really > terrible because we'd miss out on the benefits of taproot and > potentially other future soft forks. > > A major problem with BIP8 is that it would result to a situation where > different parts of the bitcoin ecosystem run different consensus rules. > Some people will run LOT=true and others LOT=false. Worst of all, it > becomes vulnerable to a twitter/reddit/social media blitz which could > attempt to move the date of miner activation around. > > Twitter and reddit drama provide a perfect cover for social attacks on > bitcoin. > > Forced signalling leads to brinksmanship. Where two or more sides > (backed up by social media drama) enter into a game of chicken with > deployed nodes. If one of them doesn't concede then we get a damaging > chain split. And the $1 trillion in value that the bitcoin network > protects is put at risk. From the point of view of a miner or big > exchange stuck in the middle, if they look at the ecosystem of twitter > and reddit (especially if you think about all the problems with bots and > sockpuppets) they have no idea which consensus rules they should > actually follow and exactly what date they take effect. Miners, > exchanges, merchants and the rest of the ecosystem exist to serve their > customers and users, and trouble happens when they don't know what their > customers really want. Social media attacks are not just a theoretical > concern; back during the block size drama, the bitcoin reddits were > targetted by bots, sockpuppets and brigading[3]. > > Enter flag day activation. With a flag day there can be no > brinksmanship. A social media blitz cant do anything except have its own > followers fork away. Crucially, miner signalling cant be used to change > the activation date for nodes that didn't choose to and just passively > follow signalling. Changing the activation date requires all those users > to actually run different node software. > > Flag day activation works simply: we choose a block height and after > that block height the new taproot rules become enforced. > > > Supporters of the permissionless, "users rule" approach of LOT=true > should be happy because it completely takes miners out of activation. > > Supporters of the safe, conservative approach of LOT=false can be made > happy with a few ways of derisking: > > * Getting mining pools, businesses and users to look at the code and ask > if they (a) think its either neutral or good for their business or use > case and (b) they believe others view it similarly and that the > consensus changes proposed have a good social consensus around them. > > * Setting the flag day far in the future (18 months or 2 years in the > original proposal[3]). > > > == What if flag day activation is used maliciously? == > > What if one day the Core developer team is co-opted and uses the flag > day method to do something bad? For example, a soft fork where sending > to certain blacklisted addresses is not allowed. The bitcoin user > community who wants to resist this can create their own > counter-soft-fork full node, where the first block after the flag day > MUST pay to one of those addresses on the blacklist. This forces a chain > split between the
Re: [bitcoin-dev] Making the case for flag day activation of taproot
It is good that social media drama can only make its own followers fork away. In bitcoin people represent themselves, if they want certain rules enforced they should have to actually tell their software to do that. The problem with BIP8 is that social media drama has a incentive to promote brinksmanship. It is not correct to say that this will work because "nobody will disobey Core". In reality it will work because basically everyone either wants taproot or has no opinion about taproot. Your argument depends heavily on the word "egregious". I've shown that for harmful changes like censorship can be resisted by the bitcoin community. Can you come up with an example of a bad change which won't be resisted? Here's another example of an easily-resisted change: A Core team that's been compromised might do a flag-day UASF where transactions are only confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The community could resist this by doing a counter-UASF where a transaction paying just 1 sat/vbyte is required to be included in the first block after the flay day. What alternative do you suggest? If you advocate allowing miners to activate soft forks then that still won't protect users. Because miners won't save users in my above example of a 1000 sat/vbyte price floor, in fact miners would see their income greatly increased if the soft fork was successful. So in fact the ability to do a counter-UASF is always what actually protected users, miner protection is nothing something to count on. On 03/03/2021 17:30, yanma...@cock.li wrote: > On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote: >> Enter flag day activation. With a flag day there can be no >> brinksmanship. A social media blitz cant do anything except have its own >> followers fork away. Crucially, miner signalling cant be used to change >> the activation date for nodes that didn't choose to and just passively >> follow signalling. Changing the activation date requires all those users >> to actually run different node software. > > Is that supposed to be a good thing? "We should do X because it'll work" > doesn't prove X is actually good. These things can be evil, but they can > also be legitimate opposition to a change. Taking away the power of a > "social media blitz" is not guaranteed to be a good thing! > >> What if one day the Core developer team uses the flag >> day method to do something bad? The bitcoin user >> community who wants to resist this can create their own >> counter-soft-fork full node. This forces a chain >> split. The real bitcoin which most people follow will be >> the chain without censorship. > > [edited for brevity] > > That will only work for really egregious changes. In practice, most > people will trust Core on all other (non-egregious) decisions, because > of the inertia inherent in disobeying them. > > What you suggest may be an efficient way to ram taproot through, but is > it inherently good? Nothing is free. This seems like de-facto forcing > people to go along with you, because you're convinced you're right. In > this case, you are, but you'd be convinced you'd be right even if you > weren't so. > > You're right in suggesting that it will work, but the reason why it will > work is because nobody wants to disobey Core. It seems immoral to > exploit this fact. > > At least you shouldn't hard-code it and require dissenters to fork away. > I exhort you to consider making all this controversial stuff settings > that can be changed by RPC command or command-line flag; set the default > value sure, but requiring a fork to change it is, in my opinion, > oppressive. > > (Also consider some compromise, such as ">95% miner support before flag > day or >33% on flag day") > > Best wishes > Yanmaani ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Making the case for flag day activation of taproot
On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote: Enter flag day activation. With a flag day there can be no brinksmanship. A social media blitz cant do anything except have its own followers fork away. Crucially, miner signalling cant be used to change the activation date for nodes that didn't choose to and just passively follow signalling. Changing the activation date requires all those users to actually run different node software. Is that supposed to be a good thing? "We should do X because it'll work" doesn't prove X is actually good. These things can be evil, but they can also be legitimate opposition to a change. Taking away the power of a "social media blitz" is not guaranteed to be a good thing! What if one day the Core developer team uses the flag day method to do something bad? The bitcoin user community who wants to resist this can create their own counter-soft-fork full node. This forces a chain split. The real bitcoin which most people follow will be the chain without censorship. [edited for brevity] That will only work for really egregious changes. In practice, most people will trust Core on all other (non-egregious) decisions, because of the inertia inherent in disobeying them. What you suggest may be an efficient way to ram taproot through, but is it inherently good? Nothing is free. This seems like de-facto forcing people to go along with you, because you're convinced you're right. In this case, you are, but you'd be convinced you'd be right even if you weren't so. You're right in suggesting that it will work, but the reason why it will work is because nobody wants to disobey Core. It seems immoral to exploit this fact. At least you shouldn't hard-code it and require dissenters to fork away. I exhort you to consider making all this controversial stuff settings that can be changed by RPC command or command-line flag; set the default value sure, but requiring a fork to change it is, in my opinion, oppressive. (Also consider some compromise, such as ">95% miner support before flag day or >33% on flag day") Best wishes Yanmaani ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Making the case for flag day activation of taproot
The bitcoin world is close to total gridlock on the question of how to activate taproot. There's no agreement on activation[1][2], and if an agreement isn't reached then nothing happens. That would be really terrible because we'd miss out on the benefits of taproot and potentially other future soft forks. A major problem with BIP8 is that it would result to a situation where different parts of the bitcoin ecosystem run different consensus rules. Some people will run LOT=true and others LOT=false. Worst of all, it becomes vulnerable to a twitter/reddit/social media blitz which could attempt to move the date of miner activation around. Twitter and reddit drama provide a perfect cover for social attacks on bitcoin. Forced signalling leads to brinksmanship. Where two or more sides (backed up by social media drama) enter into a game of chicken with deployed nodes. If one of them doesn't concede then we get a damaging chain split. And the $1 trillion in value that the bitcoin network protects is put at risk. From the point of view of a miner or big exchange stuck in the middle, if they look at the ecosystem of twitter and reddit (especially if you think about all the problems with bots and sockpuppets) they have no idea which consensus rules they should actually follow and exactly what date they take effect. Miners, exchanges, merchants and the rest of the ecosystem exist to serve their customers and users, and trouble happens when they don't know what their customers really want. Social media attacks are not just a theoretical concern; back during the block size drama, the bitcoin reddits were targetted by bots, sockpuppets and brigading[3]. Enter flag day activation. With a flag day there can be no brinksmanship. A social media blitz cant do anything except have its own followers fork away. Crucially, miner signalling cant be used to change the activation date for nodes that didn't choose to and just passively follow signalling. Changing the activation date requires all those users to actually run different node software. Flag day activation works simply: we choose a block height and after that block height the new taproot rules become enforced. Supporters of the permissionless, "users rule" approach of LOT=true should be happy because it completely takes miners out of activation. Supporters of the safe, conservative approach of LOT=false can be made happy with a few ways of derisking: * Getting mining pools, businesses and users to look at the code and ask if they (a) think its either neutral or good for their business or use case and (b) they believe others view it similarly and that the consensus changes proposed have a good social consensus around them. * Setting the flag day far in the future (18 months or 2 years in the original proposal[3]). == What if flag day activation is used maliciously? == What if one day the Core developer team is co-opted and uses the flag day method to do something bad? For example, a soft fork where sending to certain blacklisted addresses is not allowed. The bitcoin user community who wants to resist this can create their own counter-soft-fork full node, where the first block after the flag day MUST pay to one of those addresses on the blacklist. This forces a chain split between the censorship rules and the no-censorship rules, and its pretty obvious that the real bitcoin which most people follow will be the chain without censorship. For example, if a group of users didn't agree with taproot then they could create their own counter-flag-day-activation which requires that a transaction is included that does an invalid-spend from a taproot output in the first block after the flag day height. This is always possible with any user activated soft fork. In BIP8 LOT=true it could be done by rejecting block headers with certain version bits signalled. == But it will take so long! == We seem to be at a deadlock now. This will take less time than any other method, because other methods might never happen. BIP8 is dead and from what I see there's no other credible plan. We've already waited years for taproot. I remember listening to talks about bitcoin from 2015 of people discussing Schnorr signatures. And given how slow segwit and p2sh adoption were its pretty likely that we'll waiting a while for taproot to be actually adopted. == A social media blitz could still try to activate it early == The brinksmanship only works because miner signalling can make many other nodes activate early, even if those other nodes didn't do anything. There can't be a game of chicken that puts the bitcoin network at risk. If a group of people did adopt alternative node software which has a shorter flag day, they actually have a risk of slow blocks. Because they cant trick or force any other nodes to come along with them, they are likely to only have a small economy and therefore would lose a lot of hashrate. Imagine trading bitcoins for cash in person and instead of waiting 10
