BIP341: speedy trial activation parameters

ajtowns commented at 5:09 pm on April 13, 2021: contributor

Adds mainnet and testnet3 activation parameters. This uses the “speedy trial” approach [0] with some refinements to the exact mechanism [1], as implemented in bitcoin/bitcoin#21377 . Parameters are selected based on previous discussions [2] [3] [4]. The parameters are:

starttime = 2021-04-24 00:00 UTC
timeout = 2021-08-11 00:00 UTC
min_activation_height = 709632 (est mid November 2021, mainnet only)
threshold = 1815 / 2016 blocks (90%, mainnet only)

In terms of block heights, that will likely mean the first signalling period for mainnet should start at height 681408, approximately April 29th UTC, and will likely mean signalling will continue for 8 retarget periods until height 697536 (which if blocks arrived at 10 minute intervals, would be due around 2021-08-20).

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html [1] https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847 [2] (90%) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html [3] (May/August/Nov) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html [4] (specific parameters) https://github.com/bitcoin/bips/pull/1081

BIP341/342: document current deployment status a516c135ab

BIP341: bip9 speedy trial parameters 0f95720639

BIP341: document simplified bip9 states d582d0bd31

BIP341: add testnet3 parameters ce5f89fe0d

BIP341: add brackets to avoid ambiguity due to precendence rules around bipwise ops 93d1b15285

ajtowns cross-referenced this on Apr 13, 2021 from issue Speedy trial support for versionbits by ajtowns

ajtowns commented at 5:16 pm on April 13, 2021: contributor

Yes, @jnewbery’s nit picking is so powerful it can travel back in time to before a PR is even opened. Beware.

Anyway: added rationale links to the PR description, rather than the BIP text. I left the “midnight” there since that’s the same language that was used in the csv and segwit deployment text and the epoch timestamps should already clear up any ambiguity.

jnewbery commented at 6:30 pm on April 13, 2021: member

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

Sjors commented at 7:13 pm on April 13, 2021: member

I’m not a fan of documenting (potentially) structural changes to BIP 9 inside the BIP of a specific soft fork. See also #1101 (comment)

luke-jr changes_requested

luke-jr commented at 7:51 pm on April 13, 2021: member

Concept NACK. This is contrary to the community consensus around BIP 8, and a technically inferior solution.

Edit: For the record, I thought this NACK was being posted on the equivalent Bitcoin Core PR.

achow101 commented at 8:25 pm on April 13, 2021: member

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

JeremyRubin commented at 8:28 pm on April 13, 2021: contributor

ACK 93d1b15; verified all timestamps make sense

michaelfolkson commented at 8:30 pm on April 13, 2021: contributor

I’m not a fan of documenting (potentially) structural changes to BIP 9 inside the BIP of a specific soft fork.

I agree with @Sjors . If Speedy Trial may be used for future soft forks it is not Taproot specific. The PR author has talked at length about using Speedy Trial for future soft forks.

achow101 commented at 8:40 pm on April 13, 2021: member

I’m not a fan of documenting (potentially) structural changes to BIP 9 inside the BIP of a specific soft fork.

I agree with @Sjors . If Speedy Trial may be used for future soft forks it is not Taproot specific. The PR author has talked at length about using Speedy Trial for future soft forks.

In the interest of getting taproot activated soon, this PR is the fastest option. However, for future soft forks (and the addition of the LAST_CHANCE state), a new BIP should be written.

Rspigler commented at 8:48 pm on April 13, 2021: contributor

As mentioned here, I also agree a new BIP should be written, but I see no harm in it happening later (and there needs to be activation details in BIP341 anyway).

in bip-0341.mediawiki:297 in 93d1b15285

293@@ -294,7 +294,43 @@ Examples of preimage for sighashing for each of the sighash modes.
294 
295 == Deployment ==
296 
297-TODO
298+This BIP is deployed concurrently with [[bip-0342.mediawiki|BIP342]].

ariard commented at 9:04 pm on April 13, 2021:

Procedurally, should mention bip340 ?

jonasnick commented at 9:13 pm on April 13, 2021:

bip340 on itself can not be deployed because it doesn’t describe consensus rules. It is deployed only as part of bip341 and 342.

ariard commented at 7:19 pm on April 14, 2021:

Thanks, make sense

ariard commented at 9:07 pm on April 13, 2021: member

ACK 93d1b15 modulo is it intentional to not mention bip340?

JeremyRubin commented at 9:07 pm on April 13, 2021: contributor

I don’t support modifying existing BIPs that have been deployed on the network except to correct them when they diverge.

Better to make a new BIP entirely as a descriptive summary of ST afterwards.

This is OK for now.

jonasnick commented at 9:10 pm on April 13, 2021: contributor

Re [1] bitcoin/bitcoin#21377 (comment) and changing the state transitions compared to BIP9. The reasons given are “at least one signaling period is guaranteed” and “if the timeout falls in the middle of a signaling period, then that period will still count towards the activation”. The former seems to be only relevant in case >50% of hashrate set inaccurate timestamps and the latter can help if the time for signalling is short. However, one could alternatively imagine just moving the timeout two weeks back if this is a concern. Am I missing the true reasons for changing the state transitions?

It may also be helpful to refer to the state machine diagram.

I’ve used the following script to estimate the occurance of block 709632, which outputs Tue 09 Nov 2021 with an average block interval of 593 seconds (and Nov 11 with 10 minute intervals). Fwiw, I think the language in the BIP is fine despite the slight difference.

0block1=600000
1time1=$(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $block1) | jq .time)
2bestblockheight=$(bitcoin-cli getblockheader $(bitcoin-cli getbestblockhash) | jq .height)
3time2=$(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $bestblockheight) | jq .time)
4av_blk_interval=$(awk "BEGIN { print ($time2 - $time1)/($bestblockheight - $block1) }")
5echo $av_blk_interval
6secstogo=$(awk "BEGIN { OFMT=\"%f\"; print (709632 - $bestblockheight) * $av_blk_interval }")
7date -d "+$secstogo sec"

achow101 commented at 9:31 pm on April 13, 2021: member

Re [1] bitcoin/bitcoin#21377 (comment) and changing the state transitions compared to BIP9. The reasons given are “at least one signaling period is guaranteed” and “if the timeout falls in the middle of a signaling period”. The former seems to be only relevant in case >50% of hashrate set inaccurate timestamps and the latter can help if the time for signalling is short. However, one could alternatively imagine just moving the timeout two weeks back if this is a concern. Am I missing the true reasons for changing the state transitions?

The purpose of changing these state transitions is to resolve one of the issues with BIP 9, specifically the one where miners can choose to skip the activation period. In this case, it was done in order to make MTP versionbits deployments more similar to BIP 8. Both changes are necessary in order to allow the guaranteed single signaling period be sufficient to activate the soft fork.

Consider the following scenario: a MTP versionbits deployment where start time is at time A, and timeout time is at time B. Miners then perform a timewarp attack which keeps the MTP before time A, and then once real time passes time B, they timewarp to make MTP past time B.

With BIP 9, that soft fork would go from DEFINED to FAILED and the entire activation window is skipped. There are no signaling periods. Removing this possibility is touted as one of the benefits of BIP 8.
With only the change removing DEFINED -> FAILED, once MTP passes time A (so after it is pushed past time B), the soft fork becomes STARTED. However when the next period begins, it immediately transitions to FAILED because the time B is already passed. Signaling is not evaluated, and even if the threshold is reached in that period, it is not possible to activate. This is functionally equivalent to BIP 9.
With both state transition changes, once MTP passes time A, the soft fork becomes STARTED. When the next period begins, signaling is evaluated first, and if it is over the threshold, then the soft fork transitions to LOCKED_IN. If the threshold is not reached, it transitions to FAILED.

Thus both changes to the state machine are required in order to have at least one useful signaling period.

Now you could have a debate about whether this is actually useful, but I proposed this change because it was one of the benefits provided by BIP 8. By doing these state machine changes, we are able to get similar signaling period guarantees that BIP 8 provides, and doing so seemed to be not invasive as well as somewhat simplifying the state machine

jonasnick commented at 9:51 pm on April 13, 2021: contributor

@achow101 Thanks for the explanation. I was aware of the suggested changes to the state machine are required to guarantee a signaling period, so it seems like this is an optimization worth having in ST IMO but also not strictly required.

sipa commented at 10:03 pm on April 13, 2021: member

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

benthecarman approved

benthecarman commented at 10:13 pm on April 13, 2021: contributor

ACK

in bip-0341.mediawiki:331 in 93d1b15285

327+        if (block.nHeight < min_activation_height) {
328+            return LOCKED_IN;
329+        }
330+        return ACTIVE;
331+
332+For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).

jonatack commented at 10:56 pm on April 13, 2021:

Verified the datetime conversions but agree with @jnewbery that the wording is ambiguous.

0>> Time.at(1619222400).to_time.utc
1=> 2021-04-24 00:00:00 UTC
2
3>> Time.at(1628640000).to_time.utc
4=> 2021-08-11 00:00:00 UTC

0For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (2021-04-24 00:00:00 UTC), timeout is epoch timestamp 1628640000 (2021-08-11 00:00:00 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).

jonatack commented at 11:05 pm on April 13, 2021:

The base value of 2016 isn’t currently mentioned in BIP341.

0For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90% of the difficulty adjustment period of 2016 blocks) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).

JeremyRubin commented at 11:18 pm on April 13, 2021:

it’s actually incidental that it lines up with difficulty, can be configured differently if needed.

1815/0.9 = 2016.66, 1814/0.9 = 2015.55 so 2016 is directly implied as the threshold block.

jonatack commented at 11:31 pm on April 13, 2021:

Sure, but explicit would be better. It’s only indirectly referred to in the code example.

in bip-0341.mediawiki:333 in 93d1b15285

329+        }
330+        return ACTIVE;
331+
332+For Bitcoin mainnet, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1815 blocks (90%) instead of 1916 blocks (95%), and the min_activation_height is block 709632 (expected approximately 12 November 2021).
333+
334+For Bitcoin testnet3, the starttime is epoch timestamp 1619222400 (midnight 24 April 2021 UTC), timeout is epoch timestamp 1628640000 (midnight 11 August 2021 UTC), the threshold is 1512 blocks (75%), and the min_activation_height is block 0.

jonatack commented at 11:06 pm on April 13, 2021:

(The same observations apply for this testnet3 sentence.)

ghost commented at 11:48 pm on April 13, 2021: none

and a technically inferior solution @luke-jr Can you please explain this part or share relevant links where you have already mentioned it in details? I have been following ML, SE, GitHub, IRC, Reddit and Twitter but don’t want to assume things that maybe incorrect.

ajtowns commented at 1:23 am on April 14, 2021: contributor

@jonasnick @achow101

Now you could have a debate about whether this is actually useful, but I proposed this change because it was one of the benefits provided by BIP 8.

I think for speedy trial the practical difference between these state changes and adding an extra two weeks to the timeout for mainnet is effectively zero. (For testnet3 two weeks might be more than one period, so that might have measurably different behaviour, but not in any important way)

But I think there was a benefit in making it easier for some people to review: if you’re reviewing by checking that the final result makes sense, the final result being simpler is a big win. (That’s a trade off against making it harder for reviewers who were comfortable with the old code and are verifying the differences, because there are more differences; but it seems to me there aren’t that many people who understand the current code in depth for that to work, and so this was a good trade off to make)

Sjors commented at 7:36 am on April 14, 2021: member

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

If the timeout date needs to be tweaked a bit to account for community holy days that’s also fine by me :-) @luke-jr are you refering to BIP 8 with LOT=true or to the speedy trial variant? In the latter case, I don’t think the difference in technical quality is that big. Height based is also not strictly better, because it’s a bigger change. That’s why I merely have a preference for the height based variant, but it’s not a show stopper for me.

fresheneesz commented at 9:59 am on April 14, 2021: contributor

ACK

Others have mentioned preferences for height-based landmarks and I also agree that height is a better thing to use. However, because we have not finalized consensus for height-based landmarks, pure BIP9 ST is what I think we should go with. I would very much like to see improvements to BIP9 move forward concurrently with and independently of a BIP9 Speedy Trial. But I strongly disagree that improvements to the deployment process should block taproot. However, if the fastest way to taproot is via upgrading BIP9 with height-based landmarks in replacement of MTP, or using a LOT=false BIP8, I would happily ACK that as well. LOT=true I very much NACK however, since it guarantees chain splits in all but the least contentious cases.

Kixunil commented at 12:40 pm on April 14, 2021: none

@luke-jr

This is contrary to the community consensus around BIP 8

How? If this activates together with BIP 8 it will not lead to a chain split, so they should be compatible.

That being said BIP 8 seems superior to me as well. I view ST as a way to resolve deadlock.

jonasnick commented at 5:33 pm on April 14, 2021: contributor

if you’re reviewing by checking that the final result makes sense, the final result being simpler is a big win. @ajtowns Fair point.

I share the view that the deployment section of BIP 341 isn’t the perfect place to specify subtle BIP9 changes, but given the speediness objective and that the rationale has been collected in this thread, it’s fine.

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

michaelfolkson commented at 8:07 pm on April 14, 2021: contributor

@prayank23:

@luke-jr Can you please explain this part or share relevant links where you have already mentioned it in details? I have been following ML, SE, GitHub, IRC, Reddit and Twitter but don’t want to assume things that maybe incorrect.

See this for why the majority of reviewers prefer a consistent use of block height rather than a mix of block height and MTP: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277

I link to various comments there.

gmaxwell commented at 9:40 pm on April 14, 2021: contributor

@michaelfolkson many (a super-majority, I believe) of the people you are enumerating as opposing this construction have in fact explicitly ACKed this PR or the PR implementing it in core.

gmaxwell commented at 9:44 pm on April 14, 2021: contributor

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

As per: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-819792337

michaelfolkson commented at 11:58 pm on April 14, 2021: contributor

@michaelfolkson many (a super-majority, I believe) of the people you are enumerating as opposing this construction have in fact explicitly ACKed this PR or the PR implementing it in core. @gmaxwell: Indeed they have. There are a number of things that make me uncomfortable about this.

There is only one contributor (this PR author) who is NACKing a consistent use of block height (which would also allow it to fit neatly into BIP 8 that has already been reviewed). The rationale he has given for NACKing a consistent use of block height is because MTP is better for test networks. I do not think this is a reasonable rationale for NACKing a choice for a consensus code change on mainnet.
There are two NACKs against using MTP, both from long term contributors. One from the author of an activation BIP (BIP 8) and another from the author of a MTP BIP (BIP 113).
I suspect (though this is admittedly pure speculation) that many of the slight preferences listed (including myself) are trying to be as reasonable as we possibly can because we don’t want to delay Taproot activation any further. But I don’t think any of us understand why test networks are a reason to NACK consistent use of block heights. Nor do we understand why a competing PR (now closed) had to be opened because the PR author felt so strongly about using MTP (and not a consistent use of block heights).
There is an alternative client that was intending to be compatible with a BIP 8 Speedy Trial deployment in Core but won’t be if Core uses a mix of MTP and block height. Not only has the PR author’s insistence on using a mix of block height and MTP wasted a huge amount of time for all of us but it also now threatens a possible split network if Core activates and the alternative client doesn’t or vice versa (due to block height, MTP differences). Although this risk is small, if you add it to the possible timewarp attack those are two risks that could be avoided by using a consistent use of block height. I’m not a fan of taking risks (however small) with activation because of the stubborn insistence of one individual.

Having said that if this gets merged and the Core PR #21377 gets merged in its current form I and everybody else will have to do our best with what we have (including probably setting up a new BIP for Speedy Trial). But I do want everyone to be clear on what risks we are taking and why we are taking them upfront. If reviewers are comfortable despite that (which it sounds like they are as a supermajority) then so be it.

JeremyRubin commented at 2:29 am on April 15, 2021: contributor

Release parameters/notification: @Roasbeef BTCD @evoskuil libbitcoin @chjj bcoin @matiu bitcore @piotrnar gocoin @luke-jr Knots

Does this seem acceptable to you all? Are there other implementations out there that I missed on this listing?

Bear in mind that as a soft-fork with minactivationheight, this would give you until November to release a fully validating client conforming to this spec, and if you don’t want to implement the signaling activation logic above, you can wait to release your client until after lock in and be guaranteed at least 3 months for your users to upgrade. Further, as a soft fork, if you don’t implement taproot at all you’ll still follow the most-work chain (but you’d be SPV on correctness).

achow101 cross-referenced this on Apr 15, 2021 from issue Speedy trial activation parameters for Taproot by achow101

Roasbeef commented at 2:51 am on April 15, 2021: contributor

ACK https://github.com/bitcoin/bips/commit/93d1b1528592ca129109b4630c17fa5372e4048a

Params for the deployment look good to me. I’ve already implemented the version bits state machine modifications for btcd and plan to update this PR accordingly. I’ve been working on the taproot changes for btcd in the background (including wallet support in btcwallet) and should be finished with them in say a month or so (working on nights and weekends). We already have basic keyspend stuff working, just need to consolidate it all. I think we’ll be able to get everything reviewed+tested (likely adding signet support along the way) by November.

MarcoFalke referenced this in commit 7cb0bcb681 on Apr 15, 2021

jnewbery commented at 8:31 am on April 15, 2021: member

@luke-jr - this PR now has ACKs from the three original authors (@sipa, @jonasnick, @ajtowns).

The BIP process is that this should now be merged.

jonatack commented at 9:11 am on April 15, 2021: contributor

ACK 93d1b1528592ca129109b4630c17fa5372e4048a

stackjohn commented at 10:23 am on April 17, 2021: none

Will this page be updated with the relevant info?

https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki

michaelfolkson commented at 11:07 am on April 17, 2021: contributor

@stackjohn: It has not been decided whether the Speedy Trial as implemented in Bitcoin Core is BIP 9 or a new BIP number. So I don’t expect the page you link to be updated for a while (if it ever is updated). I (and others) think Speedy Trial should get a new BIP number rather than revising a final BIP that has been used for prior soft forks.

gmaxwell commented at 11:46 pm on April 17, 2021: contributor

@luke-jr Echoing @jnewbery ’s comment, are you unavailable to merge this?

michaelfolkson commented at 10:57 am on April 18, 2021: contributor

@gmaxwell: I’m not going to express a view on whether this BIP PR should be merged or not. I don’t have the experience in these matters to think of arguing with you or @luke-jr. I would say though that shoehorning a new activation BIP (or serious revisions to an existing activation BIP) into soft fork BIP(s) isn’t great precedent. Future soft fork authors could do the same with a controversial soft fork BIP (to be clear I don’t think Taproot is controversial) and then ACK including a new activation BIP within their soft fork BIP. Obviously they will ACK it because they want their soft fork to activate.

Is it important this is merged? Bitcoin Core is going forward with Speedy Trial (mix of MTP and block height) regardless from my understanding. I don’t think it is waiting for this BIP PR to be merged?

gmaxwell commented at 3:42 pm on April 18, 2021: contributor

@michaelfolkson This is exactly how it works.

E.g. https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#Deployment and https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki#Deployment which was set by #359

or

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Deployment which was set by #464 (and a couple other PRs)

or

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Deployment which was set by #227

and so on. The BIPs that don’t get revised were mostly written after they were deployed, were trivial, were never deployed, etc.

fresheneesz commented at 8:46 pm on April 18, 2021: contributor

@gmaxwell I have similar thinking to Michael. Regardless of how things have previously worked, I think revising or creating deployment BIPs in the same proposal as feature deployments themselves is not ideal. A better process would be to separate those concerns and develop deployment protocols separately from feature deployments that use them. It would be ideal for the community to settle on a particular deployment BIP (or set of deployment BIPs) that consensus says is/are acceptable, and then when we need to do a feature deployment, the process would be to simply pick from one of those existing finalized deployment protocols. That would allow feature deployments to move forward faster, as there would need to be no argument about how to deploy (beyond simply which existing deployment protocol to select), related improvements could be worked on without blocking any feature deployments, and changes to deployment protocols would have the benefit of a lot more review time to ensure they don’t have design flaws,

Are there reasons I’m not thinking of that we wouldn’t want to do it that way?

sipa commented at 8:50 pm on April 18, 2021: member

This PR represents the BIP authors’ now completed soft fork proposal, free for anyone in the ecosystem to adopt and/or implement, or not. I haven’t seen any reasons why the BIP document shouldn’t be updated to reflect that reality.

As BIP 2 states:

The BIP author may update the draft as necessary in the git repository. Updates to drafts should also be submitted by the author as pull requests. @fresheneesz I think that’s an orthogonal discussion.

gmaxwell commented at 9:09 pm on April 18, 2021: contributor

It sounds you me like you both may misunderstand the BIP process and purpose. BIPs are much more descriptive than prescriptive. No one can be required to run anything in the ecosystem, so what the BIP represents is some proposal which the authors recommend or which the authors themselves are running and which you might need to understand to interoperate with them.

There are a number of junk BIPs– ones that propose ill-advised or outright broken things, and a large number of ones that no one has ever actually deployed. This is fine, the BIP process doesn’t tell you if a spec is good or not. It just tells you what it is, provides a basic presentation framework, and a method of distribution where the ones actually need ed

I think that all that not allowing drafts to be updated would accomplish would be just holding off on them until the thing they are describing is already deployed and entrenched and would presumably move development of their content to another venue until that point, which would reduce the potential for input and collaboration if it had any effect.

As far as separating deployment: I’m think that would generally have negative value, because a proposal without deployment does nothing and a consensus proposal with incompatible deployment is incompatible regardless of the rest. Bitcoin isn’t Mr. Potatohead, except in specific cases you can’t just mix and match parts and expect working results. For document management reasons it can make sense to split a proposal into multiple documents but generally there should be a top level document that incorporates the sub-documents by reference– they’re not freestanding proposals. For activation in particular there will always be specific owing to the fact that each thing starts activation at a different time, but also potentially differences in their trade-offs based on the sort of demand for or impact of the specific change. Of course, if you don’t agree with how the authors have split things up you can work it out with them or make your own proposal(s). —- though whole this discussion is pretty far afield of on-topic here.

fresheneesz commented at 10:43 pm on April 18, 2021: contributor

@Sipa and @gmaxwell Its certainly likely I misunderstand the BIP process and purpose. And I agree, my comment is orthogonal and off-topic. Sorry about that. Would love to discuss elsewhere.

Rspigler commented at 10:59 pm on April 18, 2021: contributor

I agree with @gmaxwell ’s points. Especially that BIP341 should have a Deployment section, like other soft forks.

However, I also believe that ideally, the BIP9 changes listed here (ST proposal state machine) should be it’s own BIP. The deployment info would then just be activation params of this new BIP, which were set here

I don’t see any reason why this can’t happen after activation though (since the emphasis is on “speedy”).

JeremyRubin commented at 11:38 pm on April 18, 2021: contributor

FYI, conversation starting at [4/18/21 09:31] in ##taproot-activation, presented without comment for informing the above discussion.

 0 <harding> luke-jr: are you gonig to merge [#1104](/bitcoin-bips/1104/) ?
 1 <luke-jr> harding: I will do what I am obliged to do, but I haven't look at that PR yet, so can't comment specifically.
 2 <harding> luke-jr: when do you expect to look at it?
 3 <michaelfolkson> harding: Is this merge needed or just a nice to have? 
 4 <harding> luke-jr: hours, days, weeks?
 5 <luke-jr> harding: I try to look through the bips PRs at least once a month, but I don't have a regular schedule
 6 <jeremyrubin> I think merge is required personally; you can't see open PRs on a document by looking at it
 7 <harding> luke-jr: ok, I think that's unacceptably slow.  Would you consider giving someone else merge access in addition to yours so they can perform simple duties like   merging 1104? 
 8 <luke-jr> harding: maybe. I'll have to think about it;.
 9 <harding> luke-jr: are you deliberately stalling?
10 <luke-jr> nope
11 <luke-jr> last time I wanted to add another BIP editor, I was met with unexpected objections, so it's not as trivial as it might seem
12 <jeremyrubin> can you set a deadline for doing this one? 
13 <michaelfolkson> It is a touch complicated if there is disagreement on what the parameters are and what activation BIP is being used. Clearly Core and the BIP authors      area in agreement on what the parameters are
14 <luke-jr> at the same time, BIP10x didn't have any sort of community support either
15 <michaelfolkson> I think it would be top priority if it was holding up Core progress. But I don't think it is holding up Core. It is just a (very) nice to have
16 <luke-jr> harding: what's the rush anyway?
17 <harding> luke-jr: in my personal case, I would like to report that the parameters have been added to BIP341 in the same weekly Optech newsletter where I report about      them being merged into Bitcoin Core.
18 <luke-jr> I see. When is that? 
19 <michaelfolkson> luke-jr: Optech goes out Wed but obviously needs to be drafted before that
20 <harding> luke-jr: Newsletter is published Wednesday; I plan to finish writing the draft today.  Here's our regular writing and publication schedule: https://gist.github.  com/harding/0dffdde00761262ca094219c33b8ff22

michaelfolkson commented at 8:42 am on April 19, 2021: contributor

@gmaxwell:

I think that all that not allowing drafts to be updated would accomplish would be just holding off on them until the thing they are describing is already deployed and entrenched and would presumably move development of their content to another venue until that point, which would reduce the potential for input and collaboration if it had any effect.

I don’t think anyone here is proposing draft BIPs shouldn’t be updated with the agreement of the BIP authors. The problem is the extent to which what should be a new activation BIP (Speedy Trial, mix of MTP and block height) with its own BIP number is instead shoehorned into the soft fork BIPs.

As far as separating deployment: I’m think that would generally have negative value, because a proposal without deployment does nothing and a consensus proposal with incompatible deployment is incompatible regardless of the rest. Bitcoin isn’t Mr. Potatohead, except in specific cases you can’t just mix and match parts and expect working results. For document management reasons it can make sense to split a proposal into multiple documents but generally there should be a top level document that incorporates the sub-documents by reference– they’re not freestanding proposals. For activation in particular there will always be specific owing to the fact that each thing starts activation at a different time, but also potentially differences in their trade-offs based on the sort of demand for or impact of the specific change.

There is nothing wrong with a soft fork BIP stating that it is using BIP 9 with these specific parameters. Or that it is using BIP 8 with these specific parameters. That is clearly what has happened in the past and should continue to happen in the future. That is different however to using the equivalent of a new activation BIP, skipping the new activation BIP step and just including it within the soft fork BIP instead. That is not what should happen in the future even if it happened in the past.

Of course, if you don’t agree with how the authors have split things up you can work it out with them or make your own proposal(s). —- though whole this discussion is pretty far afield of on-topic here.

The alternative parameters in Bitcoin Core 0.21.0-based Taproot Client (using block height consistently) use BIP 8 as it currently stands. There is no need to revise a BIP or set up a new BIP for the alternative parameters. This is one of the multiple reasons why I and others argued for using block height consistently.

E.g. https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#Deployment and https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki#Deployment which was set by #359

Thanks for these links. This is context that I’m missing and why I’m not taking a view on whether this should be merged or not.

JeremyRubin commented at 6:02 pm on April 19, 2021: contributor

Much ado about nothing.

This is being politicized. Noting that BIP8 had changes rather recently to introduce min_active_height that were not ACK’d in their final revision, and receiving only 3 ACKs for a prior draft (5 if you count author + merger), and only 1/2 of the BIP8 authors advice was solicited/received. This lack of procedure and control lead to the BIP text being merged with a glaring inaccuracy (4096 not being a multiple of 2016).

In contrast, this PR has 12 ACKs if I’ve counted correctly + 1 author (13 total), 3/3 original authors?

Further, ACKs on BIP8 are wholesale unrelated to Taproot. If you wanted to propose it’s inclusion as alternative parameters I would invite you to 1) merge this first 2) make a separate PR describing the alternative and seek similar acknowledgement that this PR has received before merging.

Time’s due to merge it, especially now that RC1 is live.

michaelfolkson commented at 10:39 am on April 21, 2021: contributor

@JeremyRubin:

Noting that BIP8 had changes rather recently to introduce min_active_height that were not ACK’d in their final revision, and receiving only 3 ACKs for a prior draft (5 if you count author + merger), and only 1/2 of the BIP8 authors advice was solicited/received. This lack of procedure and control lead to the BIP text being merged with a glaring inaccuracy (4096 not being a multiple of 2016).

If you have a problem with process or a merge decision on another BIP PR please raise it on that PR. A suboptimal process or merge decision (on the assumption it was that, which would be disputed) is not an argument for a suboptimal process or merge decision on this PR.

viaj3ro commented at 2:27 pm on April 21, 2021: none

does this PR still need to be merged by @luke-jr and if yes, what is the holdup, Luke?

michaelfolkson commented at 3:24 pm on April 21, 2021: contributor

@viaj3ro: It doesn’t help when individuals state:

This is being politicized.

followed by

ACKs on BIP8 are wholesale unrelated to Taproot

when that individual knows perfectly well there is an alternative release “Bitcoin Core 0.21.0-based Taproot Client” that is using BIP 8.

I am not in favor of a rushed merge here. This PR is not blocking progress for Core or the alternative release and I’d request individuals don’t continue to pressure for a fast merge.

If the BIP 341 authors (@sipa, @jonasnick, @ajtowns) would weigh in on whether they would ACK or NACK (or have no opinion) including the parameters of the alternative release “Bitcoin Core 0.21.0-based Taproot Client” that would be helpful. They are the same as Bitcoin Core’s other than starttime and timeout are defined in block height rather than MTP. In the vast majority of cases these should be equivalent but it is theoretically possible that they aren’t equivalent. The alternative release also uses BIP 8 rather than an undetermined BIP number in Bitcoin Core’s case.

JeremyRubin commented at 3:26 pm on April 21, 2021: contributor

@michaelfolkson I agree; BIP8 is irrelevant. I guess we have consensus then ;).

If you want BIP8 to somehow informationally apply to deployment for BIP-341, once again I am asking to 1) merge this first 2) make a separate PR describing the alternative and seek similar acknowledgement that this PR has received before merging.

As it stands and without reference to anything else this PR accurately describes the code available in Bitcoin Core and has been widely ACK’d so it is sticking one’s head in the sand whilst claiming the sky isn’t blue not to proceed.

We’ve eclipsed @harding’s request of merge before this week’s OpTech, and the start time is 3 days away, and signalling 10.

What goal is it furthering to continue to delay here? Whose agenda is it serving? Feigning neutrality while continuing to instigate tired arguments on this BIP is not a neutral stance. What’s stopping you from opening a PR to the BIP describing the UASF parameters?

michaelfolkson commented at 3:34 pm on April 21, 2021: contributor

@JeremyRubin:

What’s stopping you from opening a PR to the BIP describing the UASF parameters?

I am very happy to open a competing PR to this one with parameters of both Core and the alternative release. If @ajtowns (this PR’s author) would like me to do that he can let me know and close this PR. I am not particularly interested in opening a competing PR if this PR can simply be updated with the alternative release’s parameters.

JeremyRubin commented at 3:43 pm on April 21, 2021: contributor

You’ve misinterpreted what I’ve asked of you, here is what I am saying you can do if you want:

0gh pr checkout 1104
1git checkout -b taproot-uasf-params
2vim bip-0341.mediawiki
3git add bip-0341.mediawiki
4git commit -m "Updated BIP341 to contain informational references for the UASF Client"
5gh pr create

michaelfolkson commented at 3:48 pm on April 21, 2021: contributor

@JeremyRubin: Sure I can open a PR to AJ’s branch. I will do so tomorrow if that will help this PR along.

JeremyRubin commented at 3:52 pm on April 21, 2021: contributor

This doesn’t open a PR to AJ’s branch, it opens a PR to the bitcoin/bips repository. This PR should be merged, and your updates can be considered independently when you’ve prepared them.

michaelfolkson commented at 3:56 pm on April 21, 2021: contributor

@JeremyRubin: In your opinion that is what should happen. Thank you for letting us know your opinion. Again I’d ask you not to pressure for a quick merge. If you wouldn’t pressurize Bitcoin Core maintainers for quick merges please don’t do it to BIP maintainers either.

JeremyRubin commented at 4:06 pm on April 21, 2021: contributor

It’s not my opinion that this should be merged, it’s the professional advice and consent of the 13 contributors who have ACKd this revision including 3 out of 3 of the original authors of the BIP.

Should Bitcoin Core Maintainers leverage their role similarly against overwhelming consensus without providing any justification, or ‘pocket vetoing’ by refusing to review in a timely fashion, I would recommend that their commit access be revoked or another maintainer be added.

Once again I refer you to https://bitcoincore.org/en/about/. Emphasis added below:

Team

The Bitcoin Core project has a large open source developer community with many casual contributors to the codebase. There are many more who contribute research, peer review, testing, documentation, and translation.

Maintainers

Project maintainers have commit access and are responsible for merging patches from contributors. They perform a janitorial role merging patches that the team agrees should be merged. They also act as a final check to ensure that patches are safe and in line with the project goals. The maintainers’ role is by agreement of project contributors.

Contributors

Everyone is free to propose code changes and to test, review and comment on open Pull Requests. Anyone who contributes code, review, test, translation or documentation to the Bitcoin Core project is considered a contributor. The release notes for each Bitcoin Core software release contain a credits section to recognize all those who have contributed to the project over the previous release cycle. A list of code contributors can be found on Github.

jonasnick commented at 4:37 pm on April 21, 2021: contributor

If the BIP 341 authors (…) would weigh in on whether they would ACK or NACK (or have no opinion) including the parameters of the alternative release “Bitcoin Core 0.21.0-based Taproot Client” that would be helpful. @michaelfolkson I don’t understand what exactly you’re suggesting and why. Feel free to open a separate PR, but I’d prefer to avoid discussing this here because this PR is approved and just waiting to be merged.

laanwj commented at 5:23 pm on April 21, 2021: member

@JeremyRubin if @ajtowns thinks this can be merged, it can be merged, however the bitcoincore.org page you are quoting is not relevant here, only the BIP process (as described in BIP1 and BIP2) is applicable to this repository

MarcoFalke commented at 5:33 pm on April 21, 2021: member

Indeed. Bitcoin Core processes (as well as ACKs, apart the ones from BIP authors) are largely meaningless to the BIP process. The BIP authors are free to write anything they want in their BIP (as long as it is technically remotely sound). For the exact details on the BIP process, you can refer to https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

JeremyRubin commented at 6:45 pm on April 21, 2021: contributor

Yes, I’m merely responding to @michaelfolkson’s claim that “If you wouldn’t pressurize Bitcoin Core maintainers for quick merges please don’t do it to BIP maintainers either.”

I understand they’re separate processes with separate rules, and am pointing out that the bitcoin core community principals state plainly that maintainership is accountable to the community.

To the extent that one wants (as Michael seems to) to consider Core procedure, I don’t think it makes the point that Michael was hoping which is more or less “let Luke decide when he wants to decide, and let him decide what he wants to”.

That BIP-0002 doesn’t document any sort of accountability to the community in the editor’s fulfillment or neglect of their duties seems like a bug that should be fixed, absent any current controversy. Understandably so, as the current situation is surprising to me, but perhaps such a loophole is not surprising to BIP-0002’s author, who is also the current BIP Editor.

edit: in any case, this seems like a separate issue from the fact that #1104 is RTM, perhaps this discussion should take place on the mailing list or as a PR to BIP-0002

ghost commented at 2:54 am on April 22, 2021: none

ACK https://github.com/bitcoin/bips/commit/93d1b1528592ca129109b4630c17fa5372e4048a

We can always have different opinions and disagreements however don’t see any good reason to delay this PR being merged after so many ACKs

michaelfolkson commented at 2:30 pm on April 23, 2021: contributor

@JeremyRubin:

Yes, I’m merely responding to @michaelfolkson’s claim that “If you wouldn’t pressurize Bitcoin Core maintainers for quick merges please don’t do it to BIP maintainers either.”

That isn’t a claim. That is a strong request that if you wouldn’t do one please don’t do the other.

It looks like a new BIP maintainer (@kallewoof) has been proposed to the mailing list so hopefully he can take a look at this if Luke doesn’t look at this in the meantime. Please do not make a habit of calling for a new maintainer every time you disagree with a merge decision or the timeliness of a merge.

For the sake of @kallewoof (or whoever the new BIP maintainer is) this has ACKs from all the BIP 341 authors and according to existing BIP processes this should be merged. It is complicated by the existence of an alternative release (Bitcoin Core 0.21.0-based Taproot Client) which is using BIP 8 and consistent block height rather than no existing activation BIP and a mixture of MTP and block height (Bitcoin Core). But as I said since the BIP 341 authors have all ACKed the parameters in this BIP 341 PR then according to existing BIP processes this should be merged as is.

edit: s/if/since as @gmaxwell suggestion below. No deliberate intent from me on that wording.

kallewoof commented at 1:28 pm on April 24, 2021: member

@ajtowns

“bipwise ops”

Nice pun? (Or you meant to write bitwise (Last commit message).)

LGTM otherwise. I will merge once/if I have editor rights, unless convinced otherwise in the meantime.

viaj3ro commented at 1:59 pm on April 24, 2021: none

@gmaxwell

I am opposed to the addition of Kalle Alm at this time. Those who believe that adding him will resolve the situation with Luke-jr’s inappropriate behavior re: PR1104 are mistaken.

Well, the idea is to add @kallewoof because having just one maintainer is problematic in many ways. Luke himself wanted to add another one in 2018 already and is now asking again.

In light of this, I’m not sure if the reasoning for your opposition is warranted.

michaelfolkson commented at 11:53 am on April 25, 2021: contributor

@viaj3ro:

Agreed. If @kallewoof becomes a BIP maintainer and merges this then this PR situation is resolved. If @gmaxwell has a broader concern about @luke-jr in general in his capacity as a BIP maintainer then he should outline his concerns in detail on the bitcoin-dev mailing list. Personally I think asking someone to merge in activation parameters into a BIP that are not identical to the activation parameters that are being used in an alternative release that @luke-jr is contributing to is not fair to @luke-jr.

Either it is important this PR is merged speedily or it isn’t important this PR is merged speedily.

If it is the former, then merging in activation parameters must somehow convey some significance in “finalizing” what the activation parameters are. If this is true then I am not sure the BIP authors should decide what the finalized activation parameters and what activation BIP is used. I’d rather there was a separation of concerns and BIP authors weren’t deciding how their own soft fork BIP is activated.

If it is the latter, I don’t know why anyone is putting pressure on Luke to merge this speedily. It doesn’t matter and is entirely insignificant. Before attacking Luke they should probably reexamine their own logic.

viaj3ro commented at 3:24 pm on April 25, 2021: none

Maintainers are not supposed to be gatekeepers. Holding this PR hostage due to some potentially consensus incompatible client seems strange.

That being said, Luke insists the only reason he hasn’t merged it, is due to him being too time constrained at the moment. Removing some of the burden by having more than one maintainer seems like the best and only reasonable solution.

luke-jr merged this on Apr 25, 2021

luke-jr closed this on Apr 25, 2021

luke-jr commented at 9:55 pm on April 25, 2021: member

(For the avoidance of doubt: Merging this does not imply anything other than the BIP 2 criteria being met; the community has chosen a different activation method than that described here, and this specification does not change the network rules without community support any more than the BIP 10x sequence did)

luke-jr commented at 10:00 pm on April 25, 2021: member

Release parameters/notification:

@luke-jr Knots

Does this seem acceptable to you all? Are there other implementations out there that I missed on this listing? @JeremyRubin As I have said many times previously, this is impractical for me to support in Knots.

gmaxwell commented at 10:05 pm on April 25, 2021: contributor

the community has chosen a different activation method than that described here

What on gods green earth are you talking about? Support for ST has been overwhelming and most in discussions nearly close to unanimous barring a couple people (mostly yourself and folkson) seemingly gaslighting by opposing it with an argument that perplexingly “the community” has already chosen something else.

Even your deceptively stated– deceptive because it explicitly promoted people to choose your option EVEN IF they preferred this proposal– twitter poll found your own position in a minority: https://twitter.com/LukeDashjr/status/1384196789184581633 a more neutrally presented twitter poll is almost 4:1 against your proposal: https://twitter.com/AaronvanW/status/1384205266737004558 discussion on the lists and in the PRs is even more stark.

JaimeCaring commented at 10:15 pm on April 25, 2021: none

Thank you @luke-jr for merging this PR.

A community lead process to fix and restore trust in the BIP process begins here: https://github.com/JaimeCaring/OpenBIPs/issues/2

JeremyRubin commented at 10:31 pm on April 25, 2021: contributor

@luke-jr noted. Checking out https://github.com/bitcoinknots/bitcoin/blob/0.21.x-knots/src/consensus/params.h, it appears to be BIP9 height based activation parameters, so bitcoin PR 21377 should be able to be merged relatively cleanly, no?

~I also couldn’t find any references for any ongoing work or plans for support of BIP341 in Knots – do you suppose you’ll be completing that work in the next 3 months?~ Knots might be a good candidate for using a “pre-buried deployement”, should ST reach sufficient signaling, you can just do a flag day at the min_active_height.

Or are there other considerations I’m missing?

edit: struck through point was inaccurate – github search doesn’t index branches other than master/main it seems.

michaelfolkson commented at 10:42 pm on April 25, 2021: contributor

the community has chosen a different activation method than that described here @luke-jr: I disagree with this statement. The community on the whole seems unconcerned by the BIP 8 versus no BIP and block height versus MTP/block height aspects of Speedy Trial though I share your concerns on a personal level that a huge amount of time was wasted on this and I think what was merged in Core ended up being marginally the inferior solution that went against the majority of reviewers’ slight preferences.

Support for ST has been overwhelming and most in discussions nearly close to unanimous barring a couple people (mostly yourself and folkson) seemingly gaslighting by opposing it with an argument that perplexingly “the community” has already chosen something else. @gmaxwell: I have not stated “the community has already chosen something else” or expressed that argument anywhere. I’d ask that you don’t blindly associate all of Luke’s views with me just because I agree with him on some things.

gmaxwell commented at 0:09 am on April 26, 2021: contributor

went against the majority of reviewers’ slight preference. @michaelfolkson Please stop doing this.

I have not stated “the community has already chosen something else” or expressed that argument anywhere.

Isolated miscommunications happen, for sure, but:

2021-04-19.log:13:38 <@michaelfolkson> belcher: Pre Speedy Trial the only decision was the LOT parameter in BIP 8. To say there’s no consensus on BIP 8 is frankly ridiculous

2021-04-19.log:13:47 <@michaelfolkson> Staying quiet as consensus over BIP 8 emerged in meetings is strange to me

2021-04-20.log:04:43 <@michaelfolkson> viaj3ro: “clearly no consensus” This is at best disputed. The community meetings in February had near universal support of using BIP 8

2021-04-20.log:09:49 <@michaelfolkson> This BIP 8 not having consensus thing… I understand what they are trying to do lol. But it is nonsense.

I don’t see how it’s possible to misinterpret these statements. But if I am misreading them I am surely not alone– my search for a few examples showed a number of similar complaints in public specifically about you:

2021-04-22.log:06:30 < aj> michaelfolkson: in my opinion, you’ve been using “community consensus” as a proxy for “what i think, since hey, i’m part of the community”

04:52 < viaj3ro> and that is why everyone is now supporting mix of hights and MTP and a few guys still claiming BIP8 has consensus is getting stranger and stranger by t he day … 05:01 < viaj3ro> well, I read the logs…. you keep repeating it everywhere. And now it has lead to a consensus incompatible client with a deceptive name which you also support

I’d be more prone to assume you simply changed your mind … since all those examples are from at least a couple days ago but you appear to be saying something remarkably similar, at least to casual inspection, in this very message with “went against the majority”. If I squint and consider that you’re saying that you’re not saying that– then I can see the difference but it’s subtle. It would be easier to distinguish your position from Luke’s if you would lead by example and distinguish your positions clearly yourself.

You could start by actually arguing your positions on their own merits instead of constantly argument-from-authority channeling luke, especially when arguing with people like Pieter who has absurdly more experience and authority on this subject matter. … or other contributors who, on investigation, have actually been opposing your position.

michaelfolkson commented at 0:48 am on April 26, 2021: contributor

@gmaxwell:

2021-04-19.log:13:38 <@michaelfolkson> belcher: Pre Speedy Trial the only decision was the LOT parameter in BIP 8. To say there’s no consensus on BIP 8 is frankly ridiculous

2021-04-19.log:13:47 <@michaelfolkson> Staying quiet as consensus over BIP 8 emerged in meetings is strange to me

2021-04-20.log:04:43 <@michaelfolkson> viaj3ro: “clearly no consensus” This is at best disputed. The community meetings in February had near universal support of using BIP 8

2021-04-20.log:09:49 <@michaelfolkson> This BIP 8 not having consensus thing… I understand what they are trying to do lol. But it is nonsense.

All of these were defending against the argument that consensus around BIP 8 in earlier community meetings somehow dissipated afterwards. I have said on multiple occasions that Speedy Trial garnered more community consensus than either BIP 8(LOT=false) or BIP 8(LOT=true). The slightly inferior MTP, undefined BIP Speedy Trial didn’t result in the community withdrawing their support for Speedy Trial either. But there was no reason not to use consistent block height and allow Speedy Trial to fit neatly into BIP 8 in my view. Community support for BIP 8 never dissipated.

You could start by actually arguing your positions on their own merits instead of constantly argument-from-authority channeling luke, especially when arguing with people like Pieter who has absurdly more experience and authority on this subject matter. … or other contributors who, on investigation, have actually been opposing your position.

I am not going to pit Luke against Pieter on soft fork activation experience and authority. I have no idea what Pieter’s view is on revised BIP 8, UASF for example. I do know Pieter has stayed out the activation discussion for months (wisely in my view). But whoever it is, I make no excuse for channeling Luke, Pieter, yourself, Rusty or whoever else who has been thinking about these topics for many years more than I have.

unknown cross-referenced this on Feb 15, 2023 from issue New BIP: Ordinal Numbers by casey

BIP341: speedy trial activation parameters #1104

Team

Maintainers

Contributors