Speedy Trial support

If you have an opinion on ST (Speedy Trial) proposal please ACK/NACK this so we can log the level of support for this proposal

Details of the proposal are here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html

edit (April 14th 2021)
Jeremy Rubin has asked me to add the following:

"[bitcoin/bips#1104](https://github.com/bitcoin/bips/pull/1104) has been proposed (and implemented via
[bitcoin/bitcoin#21377](https://github.com/bitcoin/bitcoin/pull/21377)) as a concrete interpretation of @harding's original 
proposal. Feel free to re-ACK on the BIP PR (and in the core PR if you feel qualified to review) if this plan matches your 
expectations, or raise any concerns otherwise."

@TheBlueMatt I have left my involvement in Bitcoin but couldn't stop myself in this discussion when someone shared the link even if it affects my life. Your name and website is used in DNS seeds of Bitcoin Core (Total 9), have contributed a lot including Stratum v2 and still active. Why so negative, right now? Why so positive about privacy, tokens etc. on twitter all the time? If you want development on Bitcoin and layer 2 using Bitcoin we need Taproot and it improves lot of things. If you ignore everything, it improves IBD for full nodes mentioned here: https://bitcoin.stackexchange.com/a/103809/103136

Stop misleading people that it helps only 5% or only large multisigs. Thanks.

Why so negative, right now

Hmm, it seems my comment here was misunderstood in the past two comments. I didn't mean to suggest that Taproot isn't something we should land, its great! I've spent a ton of time trying to move the activation discussion forward! My note was more a general philosophy of forks - many, many soft forks (and to a large extent Taproot) are designed such that they don't have an impact directly on a large number of Bitcoin users, adding features that are useful for some, but largely not hurting others. That's great, but it also means that we should be considering this property when we talk about activation methods - if a large number of Bitcoin users aren't going to be directly impacted by a fork (as is the case with Taproot - wallets don't have an incentive to use it quickly, though over time it would be nice if users migrated to it for various reasons), then we should have an activation method which includes those users not needing to be active in the activation process (but allow them to "stop" such an activation if they are being negatively impacted by the fork).

I would close this for new comments but you can't on a gist. Can you take any further discussion on activation not directly related to the Speedy Trial proposal to ##taproot-activation Freenode channel or the bitcoin-dev mailing list? I will start to delete new comments that aren't directly related to Speedy Trial from this point onwards (admittedly I have been as guilty at straying off topic as anyone else).

I'm going to rescind my ACK for Speedy Trial. The whole point of "Speedy" Trial was that it wouldn't be a long drawn out process with people playing games NACKing use of BIP 8 and NACKing block height (in favor of MTP) because of test networks of all things. BIP 8 and use of block height were discussed in the community meetings pre Speedy Trial and garnered a vast amount of consensus. Test networks (testnet, signet) are there to test the optimal solutions on mainnet. You don't change solutions on mainnet so they better fit testnet, signet. This is blatantly obvious.

Hence Speedy Trial has lost its "Speedy" and in my opinion we are back to where we were before Speedy Trial was proposed. So I'm a NACK on Speedy Trial. I'm also pretty appalled by some of the shenanigans that have been going on to delay what should have been a simple PR review path post Speedy Trial being proposed. If this is in any way a precedent for how people will behave for future soft fork activations this strengthens @rustyrussell's argument for his NACK.

By my count, there are 83 full ACKs, 3 ACKs with reservations, and (now) 3 NACKs. Sounds like overwhelming support of Speedy Trial.

@michael, I understand this process has been frustrating, and thanks for putting in effort to move things forward. It seems like you are most frustrated with the process by which we're building consensus, rather than Speedy Trial itself. Its a bit confusing to me that this is leading you to NACK Speedy Trial, when it really sounds like you should be NACKing something a bit more meta: the consensus building process.

I might be a bit out of the loop, but there's clearly conesnsus for Speedy Trial, and you're saying there's also consensus for BIP8 and block height. Have we lost a clear consenus on BIP 8vs9 and block height vs MTP? If so, shouldn't the next step be to come to a consensus on those two parameters and then push go rather than scrapping Speedy Trial altogether?

Just adding my NACK here for the record.

ST/BIP8 was reasonable as a subset of a proper longer-term BIP8, but even considering digging BIP9 out of its grave is just plain absurd and defeats the purpose of ST (to be a compromise subset between disagreement on LOT within the scope of the consensus around BIP8).

Furthermore, a fundamental premise of ST was that it would start ~immediately and end quickly. But over a month has passed already with only movement backward, second-guessing things we already had consensus on.

IMO, ST is simply dead at this point.

It’s not clear to me why BIP8 or any compromise with it was ever considered seriously. It was clear at the time that the wrong lessons had been learned from segwit. This whole BIP8 fiasco is just the fallout from that. BIP9 would be just fine.

@luke-jr can you give a definition for what consensus is? Is there a concrete and consistent definition you are applying that BIP8 LOT=true is satisfying that the current ST MTP start/stop + height of activation minimum is not meeting that can be applied here and in the future?

There seem to already be a process for activating softforks. BIP9.

The reason i like BIP9 is because its simple and it encourages consensus and gives plenty of time for this to form if it hasnt formed already and people are just waiting to signal.

@fresheneesz: I'm not frustrated by the process, I consider myself partly responsible for the process up until this point. So in that sense I can only be frustrated with myself. I don't know why there have been games (NACKs of technical minutiae with very weak rationales, community meetings to discuss technical minutiae, coin flips...) over BIP 8 vs 9 and block height vs mix of block height and MTP for Speedy Trial. I wasn't expecting them when Speedy Trial was proposed. If I had expected them I wouldn't have supported Speedy Trial in the first place. The whole point of Speedy Trial was to avoid gridlock and have a smooth (but rigorous) PR code review and merge path. I am very disappointed it hasn't turned out that way especially given the community support for this proposal.

By my count, there are 83 full ACKs, 3 ACKs with reservations, and (now) 3 NACKs. Sounds like overwhelming support of Speedy Trial.

Agreed, if the Core Speedy Trial PR #21377 can get merged I think we should work around that. If it can't get merged I think an alternative release to Core is our only hope for getting Taproot activated. In that scenario I would support BIP 8(LOT=true).

Regardless, the time for theoretical discussions and new proposals (or rehashing old ones) is over imo. I certainly won't be partaking in them. The initial proposed timetable for Speedy Trial had a startheight of May 1st. We are at April 11st and we don't have a merged PR in Core nor do we have any sense of what the timetable will be or what the finalized parameters are.

@luke-jr can you give a definition for what consensus is?

It’s not clear to me why BIP8 or any compromise with it was ever considered seriously. It was clear at the time that the wrong lessons had been learned from segwit. This whole BIP8 fiasco is just the fallout from that. BIP9 would be just fine.

@JeremyRubin, @evoskuil: Please take discussion of non-Speedy Trial topics to ##taproot-activation on IRC or the bitcoin-dev mailing list. Thanks

I'm going to rescind my ACK for Speedy Trial.

Agreed, if the Core Speedy Trial PR #21377 can get merged I think we should work around that.

Not trying to troll. I understand you are frustrated. But is it a final NACK or ACK?

@Rspigler: I personally won't be issuing any more ACKs or NACKs related to Speedy Trial, here or on Core PRs. I have tried to advance Speedy Trial in good faith (e.g. looking over the PRs and identifying that not only had we agreed on revised BIP 8 in the community meetings but a majority of reviewers had a slight preference for consistent use of block height) especially when I recognized that Speedy Trial had more community consensus than either BIP 8 (LOT=true) or BIP 8 (LOT =false)). Had I known at the time that there would be "NACKs of technical minutiae with very weak rationales, community meetings to discuss technical minutiae, coin flips...) over BIP 8 vs 9 and block height vs mix of block height and MTP for Speedy Trial" I would have NACKed Speedy Trial from the beginning.

I understand why Luke is angry and he should be. As he says Speedy Trial was supported by him (and me) because it had more consensus than either BIP 8 (LOT = true) or BIP 8 (LOT=false). For a small number of contributors (2?) to NACK using block height consistently across Speedy Trial and insist on not using BIP 8 is just bizarre to me in the context of where we were pre Speedy Trial and in the absence of a strong rationale to NACK using block heights consistently (test networks are not a strong rationale imo and nor is UASF marketing).

I am personally reviewing #21377 because I want to be as familiar with it as I can be and there is a very unlikely chance I find a bug etc in the code. But I won't ACK or NACK the PR and I won't issue any further ACKs or NACKs on this gist. I risk damaging my reputation (more than I already have) and making a mockery of the Core review process. In the very unlikely chance I find a bug I will of course raise it immediately.

For additional context see this and this from @maaku. He is staying out of this as he has quantum security reservations leading to him NACK Taproot itself. Regardless he writes better than me on BIP 8/9 and block height/mix of block height and MTP. He is also an author of a BIP on MTP.

bitcoin/bips#1104 has been proposed (and implemented via bitcoin/bitcoin#21377) as a concrete interpretation of @harding's original proposal. Feel free to re-ACK on the BIP PR (and in the core PR if you feel qualified to review) if this plan matches your expectations, or raise any concerns otherwise.

@michaelfolkson perhaps update the top post to point people appropriately