Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
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."
@harding

This comment has been minimized.

Copy link

@harding harding commented Mar 6, 2021

ACK

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 6, 2021

ACK

@djpnewton

This comment has been minimized.

Copy link

@djpnewton djpnewton commented Mar 6, 2021

ACK

@stortzm

This comment has been minimized.

Copy link

@stortzm stortzm commented Mar 6, 2021

ACK

@haakonn

This comment has been minimized.

Copy link

@haakonn haakonn commented Mar 6, 2021

ACK

@andrewtoth

This comment has been minimized.

Copy link

@andrewtoth andrewtoth commented Mar 6, 2021

ACK

@windsok

This comment has been minimized.

Copy link

@windsok windsok commented Mar 6, 2021

ACK

@yogh-io

This comment has been minimized.

Copy link

@yogh-io yogh-io commented Mar 6, 2021

ACK

@achow101

This comment has been minimized.

Copy link

@achow101 achow101 commented Mar 6, 2021

ACK

@cryptagoras

This comment has been minimized.

Copy link

@cryptagoras cryptagoras commented Mar 6, 2021

ACK

@chris-belcher

This comment has been minimized.

Copy link

@chris-belcher chris-belcher commented Mar 6, 2021

ACK

@jb55

This comment has been minimized.

Copy link

@jb55 jb55 commented Mar 6, 2021

ACK

@PulpCattel

This comment has been minimized.

Copy link

@PulpCattel PulpCattel commented Mar 7, 2021

ACK

@chrisguida

This comment has been minimized.

Copy link

@chrisguida chrisguida commented Mar 7, 2021

ACK

@AdamISZ

This comment has been minimized.

Copy link

@AdamISZ AdamISZ commented Mar 7, 2021

ACK

@sgeisler

This comment has been minimized.

Copy link

@sgeisler sgeisler commented Mar 7, 2021

ACK

@pqai3

This comment has been minimized.

Copy link

@pqai3 pqai3 commented Mar 7, 2021

ACK

@pox

This comment has been minimized.

Copy link

@pox pox commented Mar 7, 2021

ACK

@devrandom

This comment has been minimized.

Copy link

@devrandom devrandom commented Mar 7, 2021

ACK

@Kixunil

This comment has been minimized.

Copy link

@Kixunil Kixunil commented Mar 7, 2021

ACK (with preference for a bit longer deadlines)

@taxmeifyoucan

This comment has been minimized.

Copy link

@taxmeifyoucan taxmeifyoucan commented Mar 7, 2021

ACK

@MaxHillebrand

This comment has been minimized.

Copy link

@MaxHillebrand MaxHillebrand commented Mar 7, 2021

ACK

@jamesob

This comment has been minimized.

Copy link

@jamesob jamesob commented Mar 7, 2021

ACK

@sipsorcery

This comment has been minimized.

Copy link

@sipsorcery sipsorcery commented Mar 7, 2021

ACK

@shesek

This comment has been minimized.

Copy link

@shesek shesek commented Mar 7, 2021

ACK (PGP signed)

@FelixWeis

This comment has been minimized.

Copy link

@FelixWeis FelixWeis commented Mar 7, 2021

ACK

@craigraw

This comment has been minimized.

Copy link

@craigraw craigraw commented Mar 7, 2021

ACK

@prayank23

This comment has been minimized.

Copy link

@prayank23 prayank23 commented Mar 7, 2021

ACK

@nopara73

This comment has been minimized.

Copy link

@nopara73 nopara73 commented Mar 7, 2021

cACK (deployment depends on available Bitcoin Knots release with bitcoinknots/bitcoin#30 fixed)

@calkob

This comment has been minimized.

Copy link

@calkob calkob commented Mar 7, 2021

ACK

@gr-g

This comment has been minimized.

Copy link

@gr-g gr-g commented Mar 7, 2021

ACK

@kallerosenbaum

This comment has been minimized.

Copy link

@kallerosenbaum kallerosenbaum commented Mar 7, 2021

ACK

@svanstaa

This comment has been minimized.

Copy link

@svanstaa svanstaa commented Mar 7, 2021

ACK

@Sjors

This comment has been minimized.

Copy link

@Sjors Sjors commented Mar 7, 2021

Provisional ACK, if that's a thing. See also comment on draft PR.

@brg444

This comment has been minimized.

Copy link

@brg444 brg444 commented Mar 7, 2021

ACK

@Zaxounette

This comment has been minimized.

Copy link

@Zaxounette Zaxounette commented Mar 7, 2021

ACK

@21isenough

This comment has been minimized.

Copy link

@21isenough 21isenough commented Mar 7, 2021

ACK

@rxgrant

This comment has been minimized.

Copy link

@rxgrant rxgrant commented Mar 7, 2021

ACK,
with a preference for the BIP 8 block height variant.

@benthecarman

This comment has been minimized.

Copy link

@benthecarman benthecarman commented Mar 8, 2021

ACK

@nothingmuch

This comment has been minimized.

Copy link

@nothingmuch nothingmuch commented Mar 8, 2021

ACK with reservation:

If a BIP8(1y, true) client is still intended shipped (seems unclear[1]) then for both implementations to remain in consensus in the event that ST activates successfully ST should be specified in terms of heights (as opposed to MTP as in bitcoin/bitcoin#21377) and the LOT=true implementation should have a matching startheight and activation delay / extended lockin period. In this way both implementations will take into account the same blocks for signalling and if the threshold is exceeded, activate on the same block.

Alternatively the ST timeout and LOT=true startheight should be set so that if ST fails to activate LOT=true will only begin counting signalling blocks after ST times out which would avoid any overlap in the signalling periods[2] and with it the need for compatibility in the activation delay.

[1] https://gnusha.org/uasf/2021-03-06.log at 17:12 vs. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018599.html

[2] https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 suggests startheight=693504 for BIP8(1y, true), https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018585.html suggests timeout=695520 for ST, which leaves open the possibility of both implementations locking in during the same period but activating on different heights.

@kallewoof

This comment has been minimized.

Copy link

@kallewoof kallewoof commented Mar 8, 2021

ACK

@urota

This comment has been minimized.

Copy link

@urota urota commented Mar 8, 2021

ACK

@ben-kaufman

This comment has been minimized.

Copy link

@ben-kaufman ben-kaufman commented Mar 8, 2021

ACK

@openoms

This comment has been minimized.

Copy link

@openoms openoms commented Mar 8, 2021

ACK

@LLFourn

This comment has been minimized.

Copy link

@LLFourn LLFourn commented Mar 8, 2021

ACK. Would also ACK a lower threshold down to 2/3.

@cdecker

This comment has been minimized.

Copy link

@cdecker cdecker commented Mar 8, 2021

ACK

@Emzy

This comment has been minimized.

Copy link

@Emzy Emzy commented Mar 8, 2021

ACK

@jonatack

This comment has been minimized.

Copy link

@jonatack jonatack commented Mar 8, 2021

ACK

@emc99

This comment has been minimized.

Copy link

@emc99 emc99 commented Mar 8, 2021

ACK

@stevenroose

This comment has been minimized.

Copy link

@stevenroose stevenroose commented Mar 8, 2021

ACK -- Though I'd like to add that I hope a failed ST will not become a major driver in favor of LOT=true in subsequent conversation.

@tromp

This comment has been minimized.

Copy link

@tromp tromp commented Mar 8, 2021

ACK

@fjahr

This comment has been minimized.

Copy link

@fjahr fjahr commented Mar 8, 2021

ACK

@decryp2kanon

This comment has been minimized.

Copy link

@decryp2kanon decryp2kanon commented Mar 8, 2021

ACK

@guerillaV2

This comment has been minimized.

Copy link

@guerillaV2 guerillaV2 commented Mar 8, 2021

ACK

@iC0rraxX

This comment has been minimized.

Copy link

@iC0rraxX iC0rraxX commented Mar 8, 2021

ACK

@louneskmt

This comment has been minimized.

Copy link

@louneskmt louneskmt commented Mar 8, 2021

ACK

@pinheadmz

This comment has been minimized.

Copy link

@pinheadmz pinheadmz commented Mar 8, 2021

ACK 🚀🌈🦄

@timalpha

This comment has been minimized.

Copy link

@timalpha timalpha commented Mar 8, 2021

ACK

@igreshev

This comment has been minimized.

Copy link

@igreshev igreshev commented Mar 8, 2021

ACK

@oliverkane

This comment has been minimized.

Copy link

@oliverkane oliverkane commented Mar 8, 2021

ACK

@charlespax

This comment has been minimized.

Copy link

@charlespax charlespax commented Mar 8, 2021

ACK

@Smiggel

This comment has been minimized.

Copy link

@Smiggel Smiggel commented Mar 8, 2021

ACK

@laggyx500

This comment has been minimized.

Copy link

@laggyx500 laggyx500 commented Mar 8, 2021

ACK

@jimmysong

This comment has been minimized.

Copy link

@jimmysong jimmysong commented Mar 8, 2021

ACK

@jakesyl

This comment has been minimized.

Copy link

@jakesyl jakesyl commented Mar 8, 2021

ACK

@JeremyRubin

This comment has been minimized.

Copy link

@JeremyRubin JeremyRubin commented Mar 8, 2021

ACK, but I agree with some of @nothingmuch's reservations and they're worth evaluating more carefully.

I'd add that the benefit of height over time is getting a known number of periods to attempt activation. I'd note that given the short 3 month period, without catastrophic events, picking expected to be mid-period MTPs would be unlikely to drift enough that we'd be short or surplus a period), so I think it would be OK to rely on the existing BIP9 code for that purpose and for these rough parameters (without setting precedent). We can further by default switch on/off signalling based on heights instead of times which also helps keep the actual network behavior closer to expected.

I don't believe startheight is required to keep consensus with a potential BIP8 (either LOT) release after ST (as we can determine the start height looking at the block header that started ST). stopheight v.s. stoptime is relevant, but less so because if the BIP8 is using a longer timeout then we're not trying to match those anyways (although the period counting thing would be nice for coordinating pools trying to activate both, were there to be an interceding release, it's not required). Earliest Active time, as a new concept entirely, can just be replicated in BIP8, but if it doesn't strictly need to be time, I think there are advantages to keeping all BIP8 parameters as heights.

So in sum:

I think it is likely safe to proceed with ST using starttime, stoptime, and earliestactivetime, so long as starttime and stoptime are targetting expected mid-period times (there's some nuance is selecting these based on what the thresholds are) and stoptime-starttime is small enough to prevent large drift, we'll likely get a known number of signalling periods and that seems enough for me.

@JeremyRubin

This comment has been minimized.

Copy link

@JeremyRubin JeremyRubin commented Mar 8, 2021

Sharing bitcoin/bitcoin#21377 (comment) which makes a solid case for using activation height, which I don't think invalidates any of the ACKs but is worth reviewing as people consider the tradeoffs in narrowing of parameters.

@viaj3ro

This comment has been minimized.

Copy link

@viaj3ro viaj3ro commented Mar 8, 2021

ACK

@evoskuil

This comment has been minimized.

Copy link

@evoskuil evoskuil commented Mar 8, 2021

ACK

@anditto

This comment has been minimized.

Copy link

@anditto anditto commented Mar 9, 2021

ACK

@shangzhou

This comment has been minimized.

Copy link

@shangzhou shangzhou commented Mar 9, 2021

ACK

@christianriley

This comment has been minimized.

Copy link

@christianriley christianriley commented Mar 9, 2021

ACK - if it avoids contention and deadlock and nothing else is on the docket, it is worth a try.

@wangchun

This comment has been minimized.

Copy link

@wangchun wangchun commented Mar 9, 2021

ACK

@junderw

This comment has been minimized.

Copy link

@junderw junderw commented Mar 9, 2021

ACK

@PubPete

This comment has been minimized.

Copy link

@PubPete PubPete commented Mar 9, 2021

NACK

@prayank23

This comment has been minimized.

Copy link

@prayank23 prayank23 commented Mar 9, 2021

Would also ACK a lower threshold down to 2/3.

@LLFourn +1

@juestr

This comment has been minimized.

Copy link

@juestr juestr commented Mar 9, 2021

ACK

@TheBlueMatt

This comment has been minimized.

Copy link

@TheBlueMatt TheBlueMatt commented Mar 9, 2021

I still believe the timeline should likely be adjusted to reduce the overall risk as previously expressed, though presumably that conversation will continue given it only just started. In any case, the overall idea I'm a fan of - the solution of "just ship a miner activation and we'll figure it out later if it fails" has definitely always been a good way to avoid deadlock, at least insofar as its possible to do without threat of network split and to keep the community together. Given it seems like those are receding for a shortened timeline, a shortened timeline sounds great.

@nkohen

This comment has been minimized.

Copy link

@nkohen nkohen commented Mar 9, 2021

ACK!

@Rspigler

This comment has been minimized.

Copy link

@Rspigler Rspigler commented Mar 9, 2021

ACK, preferably with BIP8

Edit: Signed statement here

@duncandean

This comment has been minimized.

Copy link

@duncandean duncandean commented Mar 9, 2021

ACK

@fedsten

This comment has been minimized.

Copy link

@fedsten fedsten commented Mar 9, 2021

ACK

@6102bitcoin

This comment has been minimized.

Copy link

@6102bitcoin 6102bitcoin commented Mar 9, 2021

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK (Speedy Trial Support) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEESwChxB/GsIHq+NR8Hhu59EyPkbgFAmBHV4cACgkQHhu59EyP
kbhitQv/Qv/NSDVrkekQWhVF9obY0YClegZBs5bwiYbW66+FWP3oGX2rlfgPvuEB
iNNIy/M4HAOvupLFkUhOXy2dS5gw3SjXNNnXtNGCf//dZPeRDqMM3dvxXIaQgfk6
RsQR/0oOHxlU8lz6d26fFbZUSInDDk5vzrxxiSEJ5FQSnbwpLh/6Q6K4FolMGfwm
N/oMVznUj/KKV88/lAv/r6aQam6Hi6AkCsdNoVx8SPlVspJnUc2TjM19QFoNALlh
AdWPFWvBDefO4yS6b2nRF9NCSui4r5NPB1dKuq/aXoxPkQaT/w1GYEX7gDqBVXpa
wDF6D3/7WTNIWCz0R/F+SzYez6yoKMbxJ3gwy5GhUJthkfwA2hOzgOmCd2tXZSxd
2c1txQI8eAE5m6zKTfKkVvMai70NSEJa1bWJOH9TPDHtlIJHUcPu/sIFTZTazuGO
4GV+hafUlbUKgdXAfxww0fLxdbseRntpl+zJicMYblJEkG+iEQ9VVvVZplPdsKO5
TV8OQyn7
=+rO6
-----END PGP SIGNATURE-----

@zndtoshi

This comment has been minimized.

Copy link

@zndtoshi zndtoshi commented Mar 9, 2021

ACK

@elichai

This comment has been minimized.

Copy link

@elichai elichai commented Mar 9, 2021

ACK

@davterra

This comment has been minimized.

Copy link

@davterra davterra commented Mar 9, 2021

ACK

@maxdignan

This comment has been minimized.

Copy link

@maxdignan maxdignan commented Mar 9, 2021

ACK - thank you to all that worked on this!

@chill117

This comment has been minimized.

Copy link

@chill117 chill117 commented Mar 9, 2021

ACK

@JeremyRubin

This comment has been minimized.

Copy link

@JeremyRubin JeremyRubin commented Mar 9, 2021

@PubPete if possible you should include a justification with your NACK otherwise it's not possible for everyone else to discern what issue you may have (e.g., is it with activating Taproot at all? With ST as the mechanism? Etc).

@bruteforcecat

This comment has been minimized.

Copy link

@bruteforcecat bruteforcecat commented Mar 10, 2021

ACK

@hodlwave

This comment has been minimized.

Copy link

@hodlwave hodlwave commented Mar 10, 2021

ACK

@philipglazman

This comment has been minimized.

Copy link

@philipglazman philipglazman commented Mar 10, 2021

ACK

@Sjors

This comment has been minimized.

Copy link

@Sjors Sjors commented Mar 10, 2021

Also, don't forget to raise such objections on the mailinglist.

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 10, 2021

Thanks to those who have uploaded signatures. For those that did pre March 10th I've verified those signatures.

@mloop1

This comment has been minimized.

Copy link

@mloop1 mloop1 commented Mar 10, 2021

ACK

@wraithm

This comment has been minimized.

Copy link

@wraithm wraithm commented Mar 11, 2021

ACK

@GambolingPangolin

This comment has been minimized.

Copy link

@GambolingPangolin GambolingPangolin commented Mar 11, 2021

ACK
Seems to be a great reward/risk ratio.

@jaybny

This comment has been minimized.

Copy link

@jaybny jaybny commented Mar 15, 2021

ACK

@rustyrussell

This comment has been minimized.

Copy link

@rustyrussell rustyrussell commented Mar 16, 2021

NACK.

Taproot could be activated by a blind monkey, but that doesn't mean we should do it that way. Getting it right this time means forming a model on how future soft forks are done.

ST avoids the hard questions, since it will almost certainly pass; we've made it as easy as possible for miners to say "yes". They don't have to upgrade, just flip a bit and promise to do so later. Nobody has to answer the hard questions on what happens if they don't, because they will.

But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.

@luke-jr

This comment has been minimized.

Copy link

@luke-jr luke-jr commented Mar 16, 2021

@rustyrussell I share your concerns, but:

  1. I do not consider this to be a showstopper (ie, not a NACK).
  2. I disagree on the details of the precedent we should be setting, which is how we got here in the first place. (LOT=false isn't safe and shouldn't be a default)
  3. ST is a gamble; it could work, but it could also very well fail, and that would grow support for the followup, and further improve the strength of a precedent established
@evoskuil

This comment has been minimized.

Copy link

@evoskuil evoskuil commented Mar 16, 2021

@evoskuil

This comment has been minimized.

Copy link

@evoskuil evoskuil commented Mar 16, 2021

@bjarnemagnussen

This comment has been minimized.

Copy link

@bjarnemagnussen bjarnemagnussen commented Mar 16, 2021

@rustyrussel It does currently seem to be very difficult to achieve consensus around more involved activation methods, such as the one you suggest, especially without a former BIP proposal that is studied thoroughly? In that regard it is impossible to foresee the future and maybe network upgrades that a blind monkey can activate will be the only ones having a chance to activate at all.

@fresheneesz

This comment has been minimized.

Copy link

@fresheneesz fresheneesz commented Mar 17, 2021

ACK

In response to @rustyrussell, I agree its important to "get it right" as far as forming a model on how future soft forks should be done. However, I think the time to get it right is not when that discussion blocks a non-contentious bitcoin improvement. Getting it right takes a lot of time and deliberation, and it would be a shame to let taproot languish while we hash out a consensus on a soft fork model.

What we should do is start the discussion and work now for a soft fork model so that we can decide on it as soon as possible (probably will take over a year TBH). We should simply use the best / most-agreed-upon soft fork model that we have at the time an upgrade is available. Improving our model on how to make bitcoin protocol changes can be an ongoing process that's done completely in parallel with other efforts.

@hMsats

This comment has been minimized.

Copy link

@hMsats hMsats commented Mar 17, 2021

ACK

@eruruu

This comment has been minimized.

Copy link

@eruruu eruruu commented Mar 17, 2021

ACK

@hsjoberg

This comment has been minimized.

Copy link

@hsjoberg hsjoberg commented Mar 17, 2021

ACK

@ajtowns

This comment has been minimized.

Copy link

@ajtowns ajtowns commented Mar 17, 2021

Taproot could be activated by a blind monkey, [...] ST avoids the hard questions, since it will almost certainly pass; [...] But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.

I think this argument makes two major errors:

  • First, it tries to artificially tie two improvements together; "if you can't solve controversial activations, you shouldn't get taproot". That isn't the way we should do development: just as it was a mistake to try to tie segwit and a hard-fork to double the block size together, other improvements should also stand or fall on their own merits. If we're tying updates together there should be good reasons for why they're better together (eg segwit and the witness discount; and taproot, schnorr and tapscript).

  • Second, it assumes that you can usefully test a weapon when play fighting -- if taproot can be activated by a blind monkey, then having your bodyguards activate taproot only proves they're as good as a blind monkey, not that they're ready to protect you from a home invasion. In particular, bip8 isn't even as ready as bip148 for a real battle; it lacks even the limited safeguards that were included in that client (and it's also lost the element of surprise, which might've been bip148's biggest advantage).

I think it also probably assumes that the bip8 approach is more ready to go than it is -- there are (IMHO) serious unresolved objections to bip8 in every possible deployment mode (eg, just lot=true: developers are imposing decisions on miners and users; just lot=false: miners can object; lot=true and lot=false: unnecessary chain split risk, risk of downtime for those running lot=true, risk of reorgs/wipeout for those running lot=false). Maybe all those objections -- even the ones from one of the bip8 authors -- are mistaken, but personally I think it's more likely that significant improvements are needed.

Personally, I can think of about half a dozen soft-forks I would like/expect to see progress on once taproot is squared away (great consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, op_cat/covenants), so it's not like there aren't other opportunities to improve activation methodologies coming up.

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 17, 2021

@ajtowns: I think your challenge to @rustyrussell arguments is strong and I agree with it. Let me attempt to challenge yours.

So ideally you want an activation mechanism where developers aren't imposing decisions, miners can't object, no chain split risk, no risk of downtime, no risk of reorgs/wipeout (and presumably you'd prefer it be in a Core release rather than an alternative client). That is quite the ask. Certainly BIP 9 doesn't meet your criteria either (miners can object, there is chain split risk in the face of a competing incompatible activation mechanism and hence risk of reorgs/wipeout). So using your logic there are serious unresolved objections to BIP 9 too. Which doesn't leave with us anything other than no Taproot activation this year (or perhaps ever).

I'll summarize what I think you are actually thinking (to save some others time). You don't like the LOT parameter (as it can enforce signaling at the end of the deployment when set to TRUE) in BIP 8 and you don't like some of the what I would agree are erratic arguments against LOT=false on the mailing list. So despite Speedy Trial fitting neatly into a revised version of BIP 8 you don't want to say we're using BIP 8. There is old BIP 9 code in the codebase and so you hope to say Speedy Trial is a BIP 9 deployment. You want to keep references to BIP 9 in the codebase so future activations can't say BIP 8 was used for Taproot. The problem with this isn't code, the problem is revising an old BIP (BIP 9) to fit Speedy Trial into it which the BIP 9 authors seem to have little interest in revising.

If I have summarized correctly I'd recommend that you champion a new BIP number. At the moment valuable arguments on what code and what commits should be in a Speedy Trial deployment (basically an in depth review of how your Speedy Trial PR and Andrew's Speedy Trial PR are different and which should be used) are getting glossed over because of this BIP 8/9 nonsense. If that is solved by a new BIP number so be it.

edit: Alternatively I'm happy to work on a new Speedy Trial BIP and get a new BIP number if this means the most important stuff (what code is included in a Speedy Trial release) is focused on rather than this BIP 8/9 stuff. Just say that is what you want and I'll do it.

Additional edit: It has been pointed out that I may have misunderstood AJ's argument and if I did I apologize. I am still a touch confused by it but I will endeavor to address any personal confusion.

@jaybny

This comment has been minimized.

Copy link

@jaybny jaybny commented Mar 17, 2021

@michaelfolkson new BIP number for ST is a great idea. ack that

@earonesty

This comment has been minimized.

Copy link

@earonesty earonesty commented Mar 20, 2021

ACK. But let's just not forget to address the underlying issue with activation. I believe a flexible, standardized percentage-required-decay mechanism might be nice in the future. But we shouldn't tie that refactor to this change.

@AlejandroDeLaTorre

This comment has been minimized.

Copy link

@AlejandroDeLaTorre AlejandroDeLaTorre commented Mar 23, 2021

ACK

@rustyrussell

This comment has been minimized.

Copy link

@rustyrussell rustyrussell commented Mar 25, 2021

Taproot could be activated by a blind monkey, [...] ST avoids the hard questions, since it will almost certainly pass; [...] But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.

I think this argument makes two major errors:

* First, it tries to artificially tie two improvements together; "if you can't solve controversial activations, you shouldn't get taproot". That isn't the way we should do development: just as it was a mistake to try to tie segwit and a hard-fork to double the block size together, other improvements should also stand or fall on their own merits. If we're tying updates together there should be good reasons for why they're better together (eg segwit and the witness discount; and taproot, schnorr and tapscript).

No, this is a disagreement about how all changes should be activated. This is completely germane to the current debate. Remember, segwit wasn't "controversial" until it suddenly was, either. I believe this is not the case here, but then, I believed that last time as well.

* Second, it assumes that you can usefully test a weapon when play fighting -- if taproot can be activated by a blind monkey, then having your bodyguards activate taproot only proves they're as good as a blind monkey, not that they're ready to protect you from a home invasion. In particular, bip8 isn't even as ready as bip148 for a real battle; it lacks even the limited safeguards that were included in that client (and it's also lost the element of surprise, which might've been bip148's biggest advantage).

"BIP 8 isn't ready" is definitely a factor, but while I prefer existing code when there are no other major factors, there are IMHO major factors here.

I think it also probably assumes that the bip8 approach is more ready to go than it is -- there are (IMHO) serious unresolved objections to bip8 in every possible deployment mode (eg, just lot=true: developers are imposing decisions on miners and users; just lot=false: miners can object; lot=true and lot=false: unnecessary chain split risk, risk of downtime for those running lot=true, risk of reorgs/wipeout for those running lot=false). Maybe all those objections -- even the ones from one of the bip8 authors -- are mistaken, but personally I think it's more likely that significant improvements are needed.

"unnecessary chainsplit risk". No, that's exactly the point: if we end up with various significant factions fighting over the rules, there will be a chainsplit. There are no technical workarounds for this. BIP 8 has been revised to minimize the chance of an unnecessary chainsplit, and the entire BIP-8 lot=true mechanism was designed as an explicit mining forcing function.

I remember @pwuille saying explicitly about Segwit activation that users must decide. That has stuck with me, and my preference for a hidden lot=true option reflects this understanding. Without such an option, developers are saying "you can override, but you'll have to replace us." The result in practice that users are reduced to "beg the devs" or "beg the miners". That kinda worked last time but damn it was messy, and such uncertainty does not help the BItcoin ecosystem.

Personally, I can think of about half a dozen soft-forks I would like/expect to see progress on once taproot is squared away (great consensus cleanup, anyprevout, ctv, graftroot, annex-based block commitments, op_cat/covenants), so it's not like there aren't other opportunities to improve activation methodologies coming up.

If this approach is good enough until there's a crisis, then why would anyone approve anything until a crisis comes?

@fresheneesz

This comment has been minimized.

Copy link

@fresheneesz fresheneesz commented Mar 25, 2021

this is a disagreement about how all changes should be activated

@rustyrussel I hear you saying that you want to decide now on how all future changes should be activated. It sounds like what you're worried about is that if the community doesn't block this release to decide this question, that the community won't actually work towards an agreement on that front until next time we need to release something. Is that right? But what if that wasn't the case? What if the community commits to work towards a better activation mechanism as the next top-priority without blocking this upgrade? Would that be agreeable to you? For example, if there was a credible group of people who will commit to working towards a better solution and building consensus on it well before the next upgrade, would that assuage your worries?

why would anyone approve anything until a crisis comes?

I think many in the bitcoin community look forward to preventing attacks and issues well in advance of when they might actually happen. I get the feeling that a substantial fraction if not a majority do care about getting a consensus on improvements to things like bitcoin's upgrade activation process. Are there specific things that make you think otherwise?

One thing I don't have good context on is: what was the previous activation process we came to a consensus on? Is that process documented somewhere? Like, when evaluating Speedy Trial, what should I be evaluating it as an alternative to?

@Kixunil

This comment has been minimized.

Copy link

@Kixunil Kixunil commented Mar 25, 2021

Is this the best place for discussion? The topic was to ACK/NACK (and I think it's OK to give bit of details), maybe it'd be better to move the discussion to another place? I specifically refrained from saying anything beyond ACK/NACK until now to not cause noise.

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 25, 2021

@Kixunil: Yeah this gist was intended for mass participation of ACKs and NACKs with comments. If you want to do more than log a N(ACK) with comments and have a broader discussion I'd recommend the bitcoin-dev mailing list or the ##taproot-activation Freenode channel. Feel free to start a thread on either of those (linking to a particular comment on this gist if that is a starting point)

@ajtowns

This comment has been minimized.

Copy link

@ajtowns ajtowns commented Mar 29, 2021

@michaelfolkson

So ideally you want an activation mechanism where developers aren't imposing decisions, miners can't object, no chain split risk, no risk of downtime, no risk of reorgs/wipeout (and presumably you'd prefer it be in a Core release rather than an alternative client).

Well, yes; wouldn't you? (Well, "miners can't object" is too strong, and bitcoin is probabilistic at best, so "no risk" is also too strong, but assuming those are "minimal risk" and "a small number of miners can't block things" those seem like good goals)

I think https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018723.html meets those goals, in addition to Rusty's "devs propose, miners activate, users override" triumvirate.

You want to keep references to BIP 9 in the codebase so future activations can't say BIP 8 was used for Taproot.

I've spent a lot of time working on bip8, I don't know why you're imagining that I'm fundamentally opposed to it. I'd like an activation method that gets as optimal a balance between the various different goals as possible and I'd thought bip8 with lot=false followed by an update to lot=true later if/when it became necessary was a good mix for that. Doing lot=true from day 0 was not what I was expecting after Luke's updates to bip8, so seeing people wanting to do that has changed my opinion substantially -- it's a very different upgrade scenario if any significant number of users are running lot=true code. And seeing the proposed testnet activation height be already passed when I had a first look at the proposed parameters made me uncomfortable, so when I realised you could make time-based activation compatible with mandatory signalling I changed my opinion there too. In any event, the whole point of a speedy trial is that its over quickly, one way or the other -- if it fails there's no need to keep the code supporting it around after the signalling period ends (and there's sufficient work on top that a reorg is vanishingly unlikey -- even a week is probably enough).

There's a whole bunch of other mind reading ("You want", "You hope", "you don't like") in your comment. Please stop it; it's very annoying even if you weren't getting it so wrong.

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 30, 2021

@ajtowns: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018723.html does not meet those goals and it doesn't meet Rusty's triumvirate. A flag day in Core is Core developers imposing activation via a flag day.

There's a whole bunch of other mind reading ("You want", "You hope", "you don't like") in your comment. Please stop it; it's very annoying even if you weren't getting it so wrong.

I am honestly doing my absolute best to try to understand where you are coming from. While you say things like a flag day meets all those goals (when they clearly don't) you don't leave me much choice other than to speculate on things you are thinking but you aren't saying. It is as annoying for me to feel the need to do this as it is for you to read it.

@JeremyRubin

This comment has been minimized.

Copy link

@JeremyRubin JeremyRubin commented Mar 30, 2021

@michaelfolkson you should re-read the link @ajtowns shared; he's not saying a flag day meets Rusty's goal.

@TheBlueMatt

This comment has been minimized.

Copy link

@TheBlueMatt TheBlueMatt commented Mar 30, 2021

A flag day in Core is Core developers imposing activation via a flag day.

I'm not sure where this comes from? "imposing activation" is always a question about social norms, whether something is in Core, not in Core, or a flag. Doubly so for something like Taproot where 95% of users have no reason to care, should not care, and don't care about it - a UASF is just as much some small group "imposing activation" as the fork being in Core, if not more.

The only thing that can ever define Bitcoin's consensus rules is what people refer to as Bitcoin, whether Bitcoin Core is that or not. Based on past experience, it seems like many agree that the market should define that by either futures or active trading across chains. In order for a fork being in Core to "impose activation", we'd have to restrict the market from trading the other side, or redefine norms around what Bitcoin is to be "what is in Core", which would obviously be a terrible idea. If you want to ensure that Core "isn't deciding", about the only way to do that is to ensure that users, the market, and exchanges understand that switching to a release with fork activation parameters is switching Bitcoins, and that they should consider that carefully, everything else is just fluff.

Still, no matter what we think of it (and I think we all think its generally good), if the protocol (for however you define that) goes in a way which the market of Bitcoiners doesn't like, the market will let us know. If there's one conclusion that we can absolutely take away from the Segwit2x/BCH/etc drama, its that the market not only wins, but finds a way to make its voice heard even when the people promoting a fork explicitly wish to ensure that it "just happens".

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Mar 30, 2021

The act of a user running a UASF release rather than a Core release is the "users override" part of Rusty's triumvirate. It is a conscious decision of a normal Core user to say "No I won't run what is in Core. I want what this UASF release does instead."

Even if it is true that 95 percent of users don't care about the Taproot soft fork (I'm not sure that it is) they should care about changes in consensus rules. Their node will likely be imposing them for the rest of Bitcoin's existence.

@TheBlueMatt

This comment has been minimized.

Copy link

@TheBlueMatt TheBlueMatt commented Mar 30, 2021

I'm not sure what your point there, was? Was that in response to something specific I'd said, because it didn't seem like a response.

@x00x00

This comment has been minimized.

Copy link

@x00x00 x00x00 commented Mar 31, 2021

@TheBlueMatt

Doubly so for something like Taproot where 95% of users have no reason to care, should not care, and don't care about it

Why should 95% not care about Taproot?
Why do you think they have no reasons to care?
Was there any survey or poll in community to conclude only 5% care about Taproot?
Are you in 95% or 5%?

@prayank23

This comment has been minimized.

Copy link

@prayank23 prayank23 commented Apr 2, 2021

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

@TheBlueMatt

This comment has been minimized.

Copy link

@TheBlueMatt TheBlueMatt commented Apr 2, 2021

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

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Apr 3, 2021

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

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Apr 6, 2021

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.

@fresheneesz

This comment has been minimized.

Copy link

@fresheneesz fresheneesz commented Apr 11, 2021

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?

@luke-jr

This comment has been minimized.

Copy link

@luke-jr luke-jr commented Apr 11, 2021

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.

@evoskuil

This comment has been minimized.

Copy link

@evoskuil evoskuil commented Apr 11, 2021

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

This comment has been minimized.

Copy link

@JeremyRubin JeremyRubin commented Apr 11, 2021

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

@stefment

This comment has been minimized.

Copy link

@stefment stefment commented Apr 11, 2021

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.

@michaelfolkson

This comment has been minimized.

Copy link
Owner Author

@michaelfolkson michaelfolkson commented Apr 11, 2021

@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

@Rspigler

This comment has been minimized.

Copy link

@Rspigler Rspigler commented Apr 12, 2021

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

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link
Owner Author

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

This comment has been minimized.

Copy link

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