Skip to content

Instantly share code, notes, and snippets.

@michaelfolkson
Last active April 14, 2021 10:42
Show Gist options
  • Save michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f to your computer and use it in GitHub Desktop.
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."
@Rspigler
Copy link

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?

@michaelfolkson
Copy link
Author

michaelfolkson commented Apr 12, 2021

@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.

@michaelfolkson
Copy link
Author

michaelfolkson commented Apr 12, 2021

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.

@JeremyRubin
Copy link

JeremyRubin commented Apr 13, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment