BIP 343: Mandatory activation of taproot deployment #1119
Conversation
michaelfolkson
force-pushed
the
bip-mandatory-activation
branch
from
42f936b to
37b55d2
Compare
|
Sounds like a bad idea: Signaling is ongoing and even in the first period there is a majority hashrate signaling. One thing we've learned is that there are mining devices which are currently unable to mine with the flagging set. This specification's "forced signaling" would effectively kick those miners off the network for weeks. It may well be that those miners are able to upgrade their firmware to get working, but if they cannot it would be unreasonable to kick them off the network instead of signaling in some other way... especially because in this proposal the forced signaling actually has no direct effect-- it's not actually used for anything. I realize this proposal was substantially written before signaling began and so it didn't benefit from the knowledge that there were device incompatibilities -- but that sort of thing is exactly why so many people were saying that it was premature to release software with mandatory signaling in the first place. The fact that this route wasn't taken by Bitcoin Core might turn out to be an averted disaster. |
Can you provide more details? Which mining devices? What proportion of network hash rate do these mining devices represent? Why are they unable to set the signaling bit? Will they be unable to set the signaling bit during a possible forced signaling phase that is due in November 2022 (approximately 18 months away)?
What alternative would you suggest for miner signaling?
Forced signaling appears to me to be greatly superior than a simple flag day. With forced signaling at least there is an (imperfect but still valuable) indication that a super majority of miners will be enforcing the soft fork rules once forced signaling has ended. And there will be an incentive to enforce the soft fork rules as otherwise they risk blocks during the forced signaling phase being rejected by the network. A flag day seems to me to be flying completely blind on whether miners will actually enforce the soft fork rules or not after the flag day.
The "averted disaster" is scheduled for November 2022 if it is needed at all. Assuming we get there that means miners signaling has failed to meet the required threshold for approximately 18 months. Whatever you suggest as an alternative to forced signaling will also present risks. |
|
I am confused. Were you unaware about the current issue of devices being unable to signal? I see it discussed in the logs of taproot-activation. As far as the details go-- what percentage of the hashrate are they, can they be fixed, and can they be fixed by your proposal's drop dead date-- those sounds like great questions that the proposers need to find answers to before making a proposal that would kick those participants off the network if they aren't be fixed by then. Going by the blocks they appear to be on the order of half the hashrate mining on poolin at the moment. Personally I'm hoping they can get fixed in days, in which case presumably taproot will activate based on the current proposal and this effort will be moot. If that doesn't happen, then any successor will need to deal with mining signaling compatibility.
I don't agree and I don't think you've substantiated your case. If they are not enforcing the consequence is that an invalid spend could be included and then a fork/reorg would be created. With forced signaling, a failure to signal will create a fork/reorg. This strikes me to be akin to checking that there is no round in the chamber of a gun by firing it at your foot. Except, in the case of the gun once you attempted to shoot your foot the gun is subsequently safe, but with this proposal the network can still fork over an invalid txn in addition to any forking created by the forced signaling. If you just want a mechanism to get information so that you would know which miners to nag or to prepare for disruption, you could signal in some way that wasn't forced and which didn't use the nversion so it wouldn't be faked. Without forcing there would be no incentive to fake it. Moreover, forced signaling (in the form of requiring nVersion to go up) was a property of softforks in the past and from experience we learned that the mandatory signaling resulted in almost universal fake signaling. The legacy of that experience is today is why no widely used pool software takes the version from bitcoind even though it provides it. Beyond the faking the forced signaling also caused needless stale blocks (and reorgs for older clients) that wouldn't have happened if the forced signaling wasn't there. We did this before and it was bad: It needlessly disrupted users and caused lasting damage to the ecosystem which we still haven't completely recovered from. I'm not aware of any reason to expect that the situation would be different now. But what is different was that when we first did this we simply didn't know any better and hadn't considered the possibility that issues like this would arise. Now that excuse doesn't exist anymore. And it isn't the case that the signaling is sometimes fake: It's always fake in the sense that the nversion is just some setting plugged into the pool software. It isn't read out of the bitcoind by anyone. Now hopefully, some potion of miners will attempt to fake it faithfully, but past experience on that hasn't been so good because it's so easy to mess that up-- just forget to update one of your nodes. But if all you want to measure is what miners say they're going to do, then a poll like taprootactivation.com is just about as informative (or even more informative, since they can tell you why they have/haven't deployed it and when they expect to do so) and doesn't carry any risk to users of the network. Moreover, even if we set aside the fact that the signaling is fake and so not particularly informative about the actual consensus rules in use (in both directions), and that forced signaling replaces one potential source of fork/reorg risk with two, -- the information that you'd receive is non-actionable. Say you learn that miners weren't signaling, there is some network disruption, some miners swap over to altcoins others hurry up and add some fake signals to. Great. Now what? What would you do with that knowledge? The forced signaling stops after two weeks. Is the situation fixed? No one knows. Was there even an actual problem to begin with or just pool server configs that hadn't been updated? No one knows. You say "once ended" but it doesn't do anything once ended, so it is completely uninformative once its ended. The parties mining may not even be the same weeks later, they can be running different software, failed over to backup nodes or pools that were never upgraded, etc. To the extent the forced signaling told you anything (that some miners updated their pool-server configs to set the version) it only tells you that about the specific period in time during which it was ongoing. In that sense it shares the same weakness with an informal poll like taprootactivation.com-- it's fundamentally non-binding.
That's saying that we're completely blind if miners will enforce P2SH or not. Sure, they can stop enforcing it at any time just like any other consensus rule, but they'll rapidly go broke as the network ignores their invalid blocks and except for liteclients which are unprotected by enforcing full nodes no users will even see their invalid blocks, so it isn't something we worry about. The whole idea that miners are required to signal sounds like a form of the erroneous belief that miners control the network. The true situation is that the network controls the miners. If they stop enforcing some of the network's consensus rules they won't be miners for long. :) The only reason that miners are even involved in activation at all (aside from their ordinary position as users of the system) is because a strong supermajority hashpower enforcement is sufficient to safely activate a new consensus rule without creating any persistent forks, even if we don't have anything else. So if Bitcoin adds consensus rules that activate if and only if a supermajority hashpower enforces then they can be deployed much faster-- as fast as you can get a supermajority hashpower-- without having to wait for all economically relevant nodes to upgrade, which might take years. It lets the community be confident that a lasting split is unlikely. If you're potentially eschewing the hashpower and accepting a risk of a split, then the advantage of speedyness is lost and it's a lot less clear what value there is in worrying about what miners are doing at all. They'll get in line eventually or they just won't be bitcoin miners anymore. All of the argument being made in favor of forced signaling is, AFAIK, backwards justification. Forced signaling was previously proposed in the context of an overlapping activation. E.g. A 3 year activation that would expire, but which could be forced signal to activate by a later proposal made after (say) the first year established popular support. In that case it would at least accomplish something of value: Triggering the enforcement of older nodes that hadn't yet been updated to the latest rules. And it might not have any effect at all, if the original proposal activated prior to timeout. But absent an overlapping activation the forced signaling is just a vestigial mechanism that AFAICT exists because that's what Luke implemented and there is virtually no development resources available to go in and review/validate anything else. Now a few people seem to have invested their reputation in supporting a contentious mechanism with a weak justification that has previously been shown to work poorly. I don't think the prospects of that are good, but then again, some pretty stupid altcoins are pretty popular so maybe you can get someone to run it. |
|
@gmaxwell: Thanks for this, some interesting challenges here. I still think a forced signaling phase in 18 months (if needed) is the least worst solution. In effect the only alternative seems to be a flag day which I see as inferior unless one exists in a theoretical, idealized world. More details below.
Indeed with regards to Poolin devices the last I heard Alejandro expected those devices to be upgraded and signaling before the end of the Speedy Trial deployment let alone a forced signaling phase in approximately 18 months.
The advantage of giving 18 months notice. That's a long time to prepare.
In an idealized world (that doesn't exist) we could all agree on a flag day and know for certain that all miners will enforce the soft fork rules after the flag day. In reality we don't know. We have had 18 months where we've been unable to glean how to convince miners to reach the signaling threshold and hence whether they will be enforcing the soft fork rules at all let alone after a certain block height. So in the absence of that idealized world we want to do everything in our power to ensure miners will enforce the soft fork rules after a particular block height and that the network has some "signal" (even if imperfect) that that is what miners intend to do. You seem to argue that we should push all the confusion after that defined block height for potentially multiple weeks where nobody is sure when exactly the soft fork rules started being enforced by the network. That potentially results in weeks of confusion and large re-orgs. I am arguing that you should try to resolve it in the 2 weeks before that block height so we can be as confident as we can be (clearly not 100 percent confident) that the network is enforcing the soft fork rules after a defined block height. Rejecting blocks that aren't signaling during that forced signaling phase is an attempt to bear a cost on miners who are attempting to block the activation or are merely uninformed. A rejected block gives them a financial incentive to reconsider blocking the activation and a financial incentive to address being uninformed.
With respect "in some way" that "it wouldn't be faked" isn't precise enough. If you have a specific suggestion that you think is an improvement on current miner signaling please flush out the exact details and send it to the bitcoin-dev mailing list. I will address the rest of your points later. It will get too long otherwise. As I said at the start, forced signaling is an imperfect solution. You can poke holes in it all you want. But its only competing viable alternative is a flag day which is strictly worse in my view. A scenario in which miners have failed to meet the signaling threshold for 18 months is a highly suboptimal scenario. Once you are in a highly suboptimal scenario the only thing you can search for off the shelf is the least worst solution. I am of the strong view that a forced signaling phase is that least worst solution. If you want to propose an alternative to forced signaling or a flag day that is probably best directed at the bitcoin-dev mailing list and has arrived too late imo to be considered for Taproot activation. |
It is users requiring miners to signal. If users are requiring it of miners I don't think that equates to miners controlling the network.
I'll repeat that if we get through 18 months without miners reaching the signaling threshold we are in chain split risk territory whatever we do. We don't know if a supermajority of miners will enforce the soft fork rules and if they will when they will. A rational position would be to say "Let's call it off" as we don't want to risk a chain split and hence hand miners a permanent veto over soft fork activations. I would disagree with that position but I do at least consider it rational. What isn't rational is saying we want to activate the soft fork, we don't want to hand miners a permanent veto, we shouldn't do forced signaling, we shouldn't do a flag day, there must be a perfect philosopher's stone solution that will come down from heaven and solve all our problems. You are free to spend the next few months and years pursuing that solution. Personally I think your many talents would be better directed at other problems where there are elegant solutions rather than these rough and ready "least worst" solutions.
Assuming we get to November 2022 with no Taproot activation I hope as one of the architects of Taproot you would support an effort to finally get it activated rather than opposing that effort to ensure Taproot sits in the doldrums for years because we can't meet the miner signaling threshold and we can't get overwhelming consensus on what to do next. That is a choice you will have to make in the run up to November 2022 (assuming we get there which I hope and presumably you hope we don't). |
|
This proposed BIP uses BIP 8 as is and that includes the MUST_SIGNAL phase of BIP 8. Anyone is free to draft a BIP that doesn't use the MUST_SIGNAL phase but it won't be removed from this particular proposed BIP. Anyone is also free to open a PR to BIP 8 to remove the MUST_SIGNAL phase though again I suspect one of the authors of BIP 8 would NACK it. Arguments for and against the MUST_SIGNAL phase in BIP 8 are summarized in this StackExchange post. I will endeavor to update it and improve it to address any further challenges. (Challenges and counterarguments are most definitely useful for this and hence are well received). |
luke-jr
changed the title
|
Assigned BIP number 343. Please rename file and update README |
|
Thanks for this @luke-jr. Renamed file and updated README. Travis is failing though.. will try to fix. |
3 participants
This PR specifies a BIP 8(LOT=true) deployment to activate Taproot. Mandatory signaling would attempt to be enforced in approximately November 2022 (defined by block height) assuming the signaling threshold is not met before then.
Original mailing list discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018783.html