BIP 341: Add Speedy Trial activation parameters #21393
Conversation
achow101
force-pushed
the
taproot-speedy-trial
branch
from
df76e1d
to
022546f
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
achow101
force-pushed
the
taproot-speedy-trial
branch
from
022546f
to
4304f29
Compare
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].threshold = 1916; // 95% of 2016 | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].m_min_activation_height = 0; // No minimum activation height | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].startheight = 681408; | ||
| consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].timeoutheight = 695520; |
There was a problem hiding this comment.
The last period before timeoutheight here overlaps with the current BIP8(True) deployment plan. So if this period specifically were to reach 90% signalling, nodes would activate Taproot at height 697536, but ST-only nodes would still wait until 709632 instead.
There was a problem hiding this comment.
The data suggests there is considerable more consensus around ST than BIP8(True). Therefore I think the onus is on the UASF release to fit around the ST release rather than vice versa.
achow101
force-pushed
the
taproot-speedy-trial
branch
5 times, most recently
from
4323685
to
e0b8280
Compare
achow101
force-pushed
the
taproot-speedy-trial
branch
from
7a29c04
to
93c7225
Compare
|
Why was this closed? |
The current plan is to go with the MTP based version of ST, so this PR is no longer applicable as it uses the height based. However if significant issues end up being found there, then this can be reopened. |
|
I can find any record of consensus being reached about that “current plan” in GitHub or mailing list discussions.
… On Apr 7, 2021, at 2:22 PM, Andrew Chow ***@***.***> wrote:
Why was this closed?
The current plan is to go with the MTP based version of ST, so this PR is no longer applicable as it uses the height based. However if significant issues end up being found there, then this can be reopened.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018746.html (Note that the coin flip was not what made the decision) |
|
One email from one contributor? That’s not how consensus decisions have been made in the past or ought to be made going forward.
There were serious concerns raised by respected developers about MTP as recently as two days ago. There are devs who concept NACK’d MTP. Were these devs comprehensively polled for their opinions in light of this new change?
If you no longer want to maintain/champion #21393 that’s understandable. But someone else should probably open a new PR with the changes.
… On Apr 7, 2021, at 3:34 PM, Andrew Chow ***@***.***> wrote:
I can find any record of consensus being reached about that “current plan” in GitHub or mailing list discussions.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018746.html
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
#19573 is reopened and rebased |
It is a summary of a discussion that occurred in an IRC channel involving many people.
Many (including myself, note that I had NACK'd a previous iteration of #21377) were as they were part of the discussions that took place on the IRC channel. Changes to #21377 have been made that I personally find acceptable.
The purpose is to focus review and attention on a single proposal rather than competing proposals. Many contributors have stated that they will not provide in depth review to either proposal until a specific one is chosen. So this was closed in order to focus review onto the other proposal. From the IRC discussions, it appears that #21377 has rough consensus and has a reasonable chance of being the proposal that is actually used. However, if it is found to be deficient, then this PR will be reopened. The outcome of the discussions was that most were okay with either this PR or #21377, and the decision for which to move forward on fell to the PR authors. As such, the objections to this PR and #21377 were analyzed, and we determined that #21377 could be modified that satisfied all of my objections to it, but no solutions could be found for the objections brought for this PR. There are others who still object to #21377 but they have not provided any concrete/specific objections when asked. Therefore #21377 has rough consensus and this PR does not. |
|
@maaku i'd encourage you to review the IRC meeting logs http://gnusha.org/taproot-activation/2021-04-06.log |
|
There is no consensus on MTP nonsense. Claiming there is, is just a neo-NYA attempt. "Dev muscle" does not have any standing to override community consensus on BIP8, especially in favour of a clearly inferior "solution". |
|
Also note, from my email:
everyone who signed on to the coinflip acknowledged a preference for going with something that @ajtowns and @achow101 agreed would work and was conceptually close to either PR. If the measured blockhash LSB coinflip had gone either way, we'd still have converged on the same. So @achow101 is correct that it is not the coin flip which made the decision. |
Maybe for the entertainment value, I can't think of any other reason why anyone would want to do that. If you think MTP concerns aren't bikeshedding @maaku and shouldn't be subject to coin tosses I'd recommend you comment on #21377. @achow101 is doing his best in the circumstances (and shouldn't be subject to this circus imo). |
I don't know which devs he is referring to nor which concerns, so if he wants to verify for himself his best bet is to review the meeting notes. if @maaku had an original concern he felt wasn't addressed he's capable of reading the logs and seeing if they were addressed sufficiently. encouraging someone to comment without reading relevant discussions is encouraging political grandstanding and theater, and I'll kindly ask that you not engage in encouraging blindly brigading a PR cheers |
|
I read the logs fully before commenting, by the way. My original note in this issue was that I couldn't find a record of consensus being reached in GitHub or the milling list archive. According to the contribution guidelines of this repo those are the places in which consensus is reached and decisions are made about consensus-affecting pull requests. It is against policy for consensus decisions to be reached in IRC meetings, even on the official #bitcoin-core-dev much less an undocumented, less-official offshoot channel. Jeremy, you're not building consensus; you're ignoring people who disagree with you, then accusing some of them of conducting "political grandstanding and theater" and "blindly brigading a PR". Please try to be more respectful of your fellow developers and hold good-faith assumptions about those who disagree with your views. |
Andrew said "it [appeared] that That seems to me like an entirely reasonable position. I think all of us frequently make decisions about what to work on next based on a huge variety of factors we expect to affect project consensus---and most of those factors are never mentioned on the public mailing list. It seems to me that this is just another case of that. |
|
I'm doing no such thing.
It is not against any policy for consensus decisions to be made in IRC, nor were any made beyond personal commitments to review one PR or another, so you must be mistaken. Further, bitcoin core's CONTRIBUTING.md is not binding. Note that everything is a should. If folks choose to discuss in other venues that is more than fine, as long as the process is inclusive. What I did was organize and host 2 meetings and summarize meeting notes from each. The meetings were scheduled well in advance such that anyone could join, and were announced also on #bitcoin-core-dev IRC at the start to get any stragglers in. The ##taproot-activation channel was explicitly made to serve as a venue for anyone interested to discuss activation, and to allow the main core development channel to maintain focus on other work. When you don't have a substantive critique of work being done, it's natural to claim a process and procedure fault. But the process has been open for anyone to participate and I've put ample personal work into organizing and summarizing. If there is a process you think that is more conducive to consensus, feel free to take the lead on implementing it. I'm certainly not ignoring anyone who disagrees with me. My intention with hosting the meetings was to be able to cast a wide net for opinions and share back outcomes of that to the mailing list. I've responded in good faith to other developers whose positions I disagree with, and held organized space for others to voice their concerns. There was no censorship of content in the meetings, and all views were responded to there. I'm glad to hear that you did read the logs. I'm more curious in your comment for you to substantiate
The two NACKs I am aware of are from Luke and from Rusty. I cannot personally say that their NACKs are irrelevant, but it seems to be the sentiment among developers given that Luke has declined to substantiate his NACK with a technical argument e.g.:
https://twitter.com/JeremyRubin/status/1379591448425734148 etc It seems not to matter much W.R.T. achieving consensus for luke, as whatever client is released by core, Luke seems dead set on preparing a UASF client with chain split risk (which has been NACK'd by many many contributors for years and years now, speaking of ignoring consensus). & WRT to rusty's NACK, it's been addressed here https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3695024 as well as on the mailing list. Further, Rusty's NACK is not technical in nature, it's procedural, as he's previously noted that the activation mechanisms themselves are probably sufficient for activating, he just dislikes the precedent. Are there other NACKs I am missing? In contrast to the NACKs, there are many ACKs on a speedy trial w.r.t. harding's post https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f for either MTP or Height, many ACKs for this approach during the meeting, and a myriad of developers who are working towards reviewing AJ's pull request to ensure it is technically sound. Further, it's not new quantum physics, it is minor tweaks to an existing activation mechanism. Activation mechanisms do not generally have the same bar for consensus as do changes to bitcoin like Taproot because we aren't "stuck with them" beyond the single instance they are used. So whereas deep technical consensus on e.g. Taproot is much more critical, the activation code we're working on need only work once (that doesn't mean insecure code would pass review). Lastly, most users/developers/etc seem to be more concerned with when taproot will be available, as opposed to if it is MTP or height. As such the meeting's have been making an effort to coordinate review for a release sometime this month, so Taproot can be active in November. Lastly I just want to note that I do appreciate your concern for wanting to make sure voices are heard and represented, hence I'll repeat my earlier question to check and see if you have any technical concerns with the current proposal you feel have not been addressed as of yet. |
|
@JeremyRubin on block height vs MTP: March 8th “I have a preference for fully height based design, correct.” March 24th “There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against height.” April 6th “The following folks in the meeting agreed to abide by the flip.... jeremyrubin" With you we have gone from preferring height to literally NACKing height to thinking height vs MTP is bikeshedding and worthy of a coin flip. AJ Towns has Approach NACKed height based on test network considerations. He wasn't listed as one of those "abiding by the flip" There are multiple people who have expressed a preference for block height but don't feel strongly enough about it to Approach NACK a PR using a mix of MTP and block height. There are two StackExchange answers here discussing block height vs MTP. |
|
The ACK/NACK system is broken so I stopped using that terminology after the segwit debacle. But it seems I have no voice here unless I state my position clearly in those terms, so here it is: I'm NACK taproot, for reasons I've published elsewhere. Counter-factually assuming that were not the case, then I'm NACK speedy trial for the same reasons Rusty has given on the mailing list. Now finally assuming that I was for taproot via speedy trial, then I'd be NACK MTP and approach-ACK a BIP8(LOT=false) with just a few technical concerns regarding thresholds and start/stop heights that I'm ultimately flexible on. Segwit activation exposed a number of problems with the BIP9 activation state machine which was based on MTP windows. These concerns include:
Every single one of the above points has been made on the mailing list or in relevant Github discussions. I don't think that any of them have been adequately addressed by MTP advocates. For example, pointing out that "timewarp could cause more uncertainty than +/- 2 weeks" ignores a few facts: (1) timewarp is NOT a normal condition and would itself be seen as an attack on the network; (2) timewarp would require the coordination of more miners than it would take to block taproot anyway; and (3) having monotonically decreasing estimation error without a two-week floor is critical to scheduling needs. I think many of us who were involved in that prior work that went into segwit lessons learned and BIP8 review are sitting around dumbfounded and speechless at what has happened. What is the point of doing all that advanced planning if it's immediately thrown away precisely when it is needed? I'm not surprised if Luke-Jr and Jorge seem obstinate on this. They've invested literally years on this problem so that we'd have a solution when it is needed, as it is now, and getting buy-in from the developers at the time... only to have all that casually thrown away. (Because of a freaking coin flip?) So instead of doing useful work, I am here getting nerd-sniped into a technical discussion about MTP-vs-height which I thought was settled four years ago. And you know what, I have better things to do so I won't be commenting further and won't bother reviewing #21377. It has a concept-NACK from me. But the matter of process there are some things here that are important to discuss. We have always, always held the mailing list to be the ground truth for consensus in theory, and in practice have used GitHub for this purpose as well. Consensus decisions have not been made in person or on IRC. Discussion happens, of course, but not polling of developer consensus. That happens on Github and via mailing list discussions. To have an IRC meeting (at an inconvenient time for many participants!) make a consensus-affecting decision about Bitcoin Core is ridiculous. To have done by coin flip is just plain insulting to those of us who have actually invested review effort into this and have strong technical arguments for one side or the other. If it was a joke it was in bad taste. Nothing is wrong with @achow101 and @ajtowns deciding what they want to focus their time and effort on based on an IRC discussion. That's cool. But don't assume it is more than that. There are a lot more stakeholders involved. Btw @JeremyRubin, should is a synonym for must in technical and procedural contexts. |
|
Thanks for this @maaku. I will update my StackExchange answer based on some of the above. I apologize (to the extent I personally bear responsibility) for wasting your time. |
AJ has a branch for using UASF with MTP: ajtowns@f802805
I know you said you're not planning on commenting further, but I'm unaware of these incentives in the absence of a UASF. If a UASF is done with AJ's branch above, then all miners can do is delay activation---which they can also do with a height-based approach by not mining blocks. Arguably, it's better to use the MTP mechanism that allows miners to continue producing blocks at a reasonable rate for a while (until difficulty changes kick in, assuming they don't timewarp) so the economy keeps functioning than it is to lose that hash rate entirely.
This is the first I've heard of anyone saying it was important to them to staff for start and end times. I've only previously heard (and expressed) this concern related to activation time, which in BIP9 and 21377 are based on heights (BIP9 a relative 2016 blocks; 21377 a static min_activation_height, if used). BIP8 also uses a relative 2016 blocks for voluntary miner activations and a static activation height for forced activations, so I'm not sure what your concern is here regarding activation.
BIP8 has also been modified for speedy trial, so I don't think the argument for conservatism is well founded. |
|
Someone asked me out of band if my concerns had been addressed here, apparently since it was referenced on #21377 and on IRC. No I don't feel my concerns have been addressed.
I know that UASF with MTP is possible, so there's no new information here. What I said was that it's not as simple. This is because, as you note, all considered activation mechanisms involve a relative height-based lockin period. This means that for mixed MTP-based activation schemes it is impossible to pick a single absolute height or time beyond which you can be certain that the activation mechanism has failed. This is unlike a fully height-based solution like BIP8 where adding UASF can be as simple as a literal one-liner, turning That's not how LOT=true works in BIP8, but it would be a totally safe UASF activation mechanism if Bitcoin Core were to release with BIP8(LOT=false). And my point is that we have a responsibility to either (a) offer LOT=true as a configuration parameter (Rusty's argument, and my own); or (b) design activation mechanism which have these sorts of perfectly safe, trivial to review UASF mechanisms built-in. Also I think this point need making: there will be a UASF client. I don't know if there will be a UASF movement like we saw last time, but there will be a UASF client. The lesson I learned from 2017 is that "devs propose, miners activate, users override" isn't statement about fallback mechanisms but rather how things need to be structured from the beginning. I was not the only one to learn this lesson. The only reason I won't be making a UASF client myself or having my miners run it is because I think taproot shouldn't activate. But there are others from that 2017 time who I won't name who feel the same as I do regarding lessons learned and who I have no doubt will make and run a UASF client. What we don't know now is whether the UASF movement will be fridge, principled radicals or a real movement like it was in 2017. But to assume that there will be NO UASF client is a fantasy.
You can use timewarp to keep MTP in the past prior to the start point, and keep it there for the entire duration, and then zoom it forward to the present with a mere six blocks once the wall clock has exited the activation window. That would skip activation entirely. It's an unlikely outcome I think because it takes less hash power to simply block activation than to execute a timewarp, and the timewarp is more destructive. But we should nevertheless choose designs that have defense in depth against possible attacks, on the justification that we can't see all possible motivations for executing such an attack. E.g. maybe a miner wants to do a timewarp attack anyway (to play out subsidy) and then uses blocking taproot as more agreeable excuse for why they did it, to try and get away with it. It's better to use height-based activation windows because it blocks off the possibility of an activation-related timewarp entirely, instead of a fragile argument about miner incentives.
Any state machine transition should be watched in realtime, not just activation. Especially if it is a first-time deployment using a new state machine.
The modification for speedy trial could be as simple as extending the lock-in period from one 2016 block period to twelve, or approximately six months. That would be, again, a literal one-liner change to BIP8 and does not modify the state machine structure itself. My conservatism is over the size of the code delta from BIP8 or BIP9. |
Actually, you said height was "way easier" than MTP. I think that may have been the case with BIP148 where signaling had to complete before BIP141's stop time, but AJ's revised code eliminates stop time as an issue and so I think the review burden between MTP and height is much closer to parity now. That was a key part of the recent compromise and, given your responses, I suspect it is actually new information to you. It seems to me the slight difference in MTP vs height activation of a UASF is insignificant compared to all the other code, documentation, outreach, testing, etc that needs to be performed to ensure regular users don't lose money because of a disagreement over activation between some users and some miners. Given that comparative insignificance of total effort, I think it's reasonable for people to consider using MTP rather than height when MTP provides them other advantages they want.
That oneliner is also compatible with the original BIP9 and with #21377. To maintain compatibility with signets, the
Not in AJ's MTP UASF design, as I mentioned in my previous reply ("with AJ's branch above, then all miners can do is delay activation"). |
Maybe I'm too much of an engineer, but "easier" and "simpler" are synonymous to me, when we're talking about design space. Anyway sorry for not being consistent in my language.
As short as his revised diff is (and it's not a one-liner), it's still mixing MTP and heights so it's not safe under all edge cases, like extreme divergence of inter-block time from expected. You're comparing apples to oranges. Yes you can do a similar one-liner with #21377. But with some bad choices of parameters and/or some serious chain manipulation by miners you end up in edge cases with undesired outcomes. These are edge cases that are supremely unlikely to happen by chance, but that doesn't mean we can ignore them. There may be entities out there that want to timewarp the chain (for that sweet, sweet subsidy) and are looking for an excuse. Don't give it to them. As I mentioned before, using heights for all threshold transitions cuts off this attack surface entirely. It's a strictly safer construct.
No, it's not. No matter what value you pick for the absolute height or MTP of UASF activation, it'll be something that could overlap with the final activation period of BIP9 or #21377 in weird edge cases (mostly due miner manipulation of block times). You have to go either all-MTP for all state transitions, or all-height to permanently fix this and remove the miner incentive to perform timewarps. Since we're pretty fixed on 2016 block adjustment windows for very good engineering reasons, it's easier to go all-heights than all-MTP. So that is what BIP8 did.
This requirement never made sense to me. We're talking about signets that don't yet exist. Any future signet could simply activate taproot from genesis. Make that the default. (Also, listen to Greg Sanders. He and I have operated plenty of signets over the years, and every one of them had a truckload of configuration options that shipped along with them. There's literally no point to an all-default signet. Just use regtest for that.)
Are you talking about the fact that AJ's design forces at least one consideration period? We're already conditioning this discussion on a timewarp attack being executed, which requires enough of a mining cartel to also block taproot activation. So I'm not sure why you think it would still activate? If a cartel large enough to cause a timewarp wants to block taproot, they will. So don't give them a reason to. |
Again, I agree it's easier to analyze its safety, but I think the relative difference between it and MTP in the context of all the other things that need to be done for safety's sake is small, so it's reasonable to consider the other impacts these parameters have on users and developers. If we always chose what was easier to analyze, we wouldn't be adding new features to Bitcoin at all.
Why is overlap an issue for a flag height? If a flag node already accepts the risk of falling out of consensus, it can start enforcing new rules before other nodes have finished waiting for a signal to also start enforcing those rules.
Taproot is already activated by default on new signets from genesis, which was convenient to do because signet was released in the same version of Bitcoin Core that contained taproot's code (minus activation code). The concern is that signets being created now will require every one of their users to run with custom parameters (or a custom client) if they want to use future height-activated soft forks on that network. That's a coordination headache that would be nice to avoid.
We're talking about UASF where activation is mandatory. In an MTP UASF, that guaranteed consideration period becomes the mandatory signaling period, so (As I said) all miners can do is delay. In my original response, I also noted: "[miners] can also [delay] with a height-based approach by not mining blocks. Arguably, it's better to use the MTP mechanism that allows miners to continue producing blocks at a reasonable rate for a while (until difficulty changes kick in, assuming they don't timewarp) so the economy keeps functioning than it is to lose that hash rate entirely." (As an aside, I don't think timewarp is a realistic concern. It's easy to detect, it's a problem for all Bitcoin users, it's easy to block on an ad hoc basis, and it's easy to deploy a tradeoff-free soft fork permanently eliminating it as a concern. At least it's easy if we can agree on an activation mechanism :-) |
Adds mainnet, testnet, and regtest parameters for the proposed Speedy Trial activation method.
The mainnet and testnet parameters are specified in bitcoin/bips#1081. The mainnet parameters were discussed on the mailing list, the testnet ones were made up in the process of writing this PR because no one discussed testnet activation parameters.
For regtest, I chose to mirror the number of retarget periods that mainnet would experience, just on the regtest threshold and retarget period.
Also adds a small test for activating on regtest.
Requires #21392