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

@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