-
-
Save michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f to your computer and use it in GitHub Desktop.
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." |
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.
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
@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.
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.
@JeremyRubin, @evoskuil: Please take discussion of non-Speedy Trial topics to ##taproot-activation on IRC or the bitcoin-dev mailing list. Thanks