* [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes @ 2021-03-24 3:46 Jeremy 2021-03-25 7:02 ` Anthony Towns 2021-04-06 4:25 ` Rusty Russell 0 siblings, 2 replies; 13+ messages in thread From: Jeremy @ 2021-03-24 3:46 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 3539 bytes --] We had a very productive meeting today. Here is a summary of the meeting -- I've done my best to summarize in an unbiased way. Thank you to everyone who attended. 1. On the use of a speedy trial variant: - There are no new objections to speedy trial generally. - There is desire to know if Rusty retracts or reaffirms his NACK in light of the responses. - There is an open question of if Rusty's NACK remains if it is sufficiently addressed. - There is no desire to wait for Rusty's response if he does not respond (but please don't leave us in suspense). 2. Selecting between heights and MTP: - There is not robust consensus on either - There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against height. More on this in agenda item 5. - No one has an issue with the technical safety of MTP/heights on their own. - There is an open question of the additional review required to ensure height based activation is safe. 3. Parameter Selection - There is broad agreement that we should target something like a May 1st release, with 1 week from rc1 starttime/startheight, and 3 months + delta stoptime/stopheight (6 retargetting periods), and an activation time of around Nov 15th. - If we select heights, it looks like the first signalling period would be 683424, the stop height would be 695520. - If we select times, we should target a mid-period MTP. We can shift this closer to release, but currently it looks like a 1300 UTC May 7th start time and stop time would be 1300 UTC August 13th. - The activation height should be 707616 (about Nov 15th) for either proposal. (please check my math, if anyone is superstitious we can add a day to times...) 4. Parameter Flexibility - We may wish to adjust the schedule a little bit -- either back 1 signal, or up 1 signal. - There's concurrence that regardless of pushing the start or stop dates, we should hold the November 15th date steady as slipping past Thanksgiving turns to Christmas turns to New Years turns to Chinese New Year and we're looking at March as the next date people would want to schedule. - There's concurrence that as long as we're getting to a release sometime in May (with a very strong preference for Mid-May as opposed to End of May) that we don't need to re-evaluate. There's limited belief that we could stretch this into June if needed. - There's belief that we should be able to get a release with ST Taproot on the timeline suggested by topic 3. 5. Simultaneous UASF* - luke-jr believes that a UASF client must be able to release before the ST client releases in order for people to use it - no one else in attendance seemed to share this sentiment, a UASF can proceed independently of ST. - UASF is compatible with a MTP based ST by selecting whatever height the ST MTP started at (and a stop height farther in the future with LOT). - luke-jr NACK of ST MTP: ST with MTP means that UASF must release after ST releases, which limits UASF adoption. - jeremyrubin NACK of ST Height: if using height means that we'd see a marketed push to launch a UASF client before ST is given a chance, ST fails its goal for avoiding contentious forks. * For the avoidance of doubt, theUASF client would include logic to be compatible with ST's minimum activation height and may be variously called a "UASF", "BIP8 LOT=true w/ minactiveheight for ST compatibility", "ST + BIP8", or some other combination of phrases in different places Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> [-- Attachment #2: Type: text/html, Size: 4131 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-03-24 3:46 [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes Jeremy @ 2021-03-25 7:02 ` Anthony Towns 2021-03-25 14:30 ` Jeremy 2021-04-06 4:25 ` Rusty Russell 1 sibling, 1 reply; 13+ messages in thread From: Anthony Towns @ 2021-03-25 7:02 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote: > 3. Parameter Selection > - There is broad agreement that we should target something like a May 1st > release, with 1 week from rc1 starttime/startheight, > and 3 months + delta stoptime/stopheight (6 retargetting periods), and an > activation time of around Nov 15th. I'd thought the idea was to release mid-late April, targetting a starttime of May 1st. > - If we select heights, it looks like the first signalling period would be > 683424, the stop height would be 695520. > - If we select times, we should target a mid-period MTP. We can shift this > closer to release, but currently it looks like a 1300 UTC May 7th start time and stop time would be 1300 UTC August 13th. We've traditionally done starttime/timeout at midnight UTC, seems weird to change. Oh, or is it a Friday-the-13th, lets have 13s everywhere thing? Anyway, block 695520 is about 19440 blocks away, which we'd expect to be 135 days, but over the past two years, 19440 blocks prior to a retarget boundary has been between 127 (-8) days and 137 (+2) days, and in the last four years, it's been between 121 (-14) days and 139 (+4) days. [0] So given block 676080 had mediantime 1616578564, I think picking a mediantime no later than ~139 days later, ie 1628640000 (00:00 UTC 11 Aug) would be the most likely to result in MTP logic matching the height parameters above, and a day or two earlier still might be better. (It will match provided MTP passes the timeout at any block in the range [695520, 697535]) > (please check my math, if anyone is superstitious we can add a day to times...) It looks to me like blocks are more likely to arrive earlier than later (which is what we'd expect with increasing hashrate), fwiw, so adding days would be more likely to cause MTP to have more signalling periods than height-based, rather than avoid having fewer. Cheers, aj [0] $ for b in `seq 201600 2016 676000`; do a=$(($b-19440)); echo $(( $(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $b) | grep mediantime | cut -d\ -f4 | tr -d ,) - $(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $a) | grep mediantime | cut -d\ -f4 | tr -d ,) )); done ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-03-25 7:02 ` Anthony Towns @ 2021-03-25 14:30 ` Jeremy 0 siblings, 0 replies; 13+ messages in thread From: Jeremy @ 2021-03-25 14:30 UTC (permalink / raw) To: Anthony Towns; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2972 bytes --] I think it's fine to move the dates back two weeks in that case; it was unclear from the meeting transcript if people thought release would be may 1st or startheight, but via parameter flexibility we can shift everything back 2 weeks if we want. W.r.t. the selection of MTP there's no funny business I just estimated a mid period MTP. I don't think midnight utc is sacred, it's 5 o'clock somewhere. We can adjust the parameters at your preference -- a little more or less time shouldn't hurt, but that is also the point of picking mid period MTP that it makes drift not matter much. On Thu, Mar 25, 2021, 12:02 AM Anthony Towns <aj@erisian•com.au> wrote: > On Tue, Mar 23, 2021 at 08:46:54PM -0700, Jeremy via bitcoin-dev wrote: > > 3. Parameter Selection > > - There is broad agreement that we should target something like a May 1st > > release, with 1 week from rc1 starttime/startheight, > > and 3 months + delta stoptime/stopheight (6 retargetting periods), and > an > > activation time of around Nov 15th. > > I'd thought the idea was to release mid-late April, targetting a starttime > of May 1st. > > > - If we select heights, it looks like the first signalling period would > be > > 683424, the stop height would be 695520. > > > - If we select times, we should target a mid-period MTP. We can shift > this > > closer to release, but currently it looks like a 1300 UTC May 7th start > time and stop time would be 1300 UTC August 13th. > > We've traditionally done starttime/timeout at midnight UTC, seems weird > to change. Oh, or is it a Friday-the-13th, lets have 13s everywhere > thing? > > Anyway, block 695520 is about 19440 blocks away, which we'd expect to be > 135 days, but over the past two years, 19440 blocks prior to a retarget > boundary has been between 127 (-8) days and 137 (+2) days, and in the > last four years, it's been between 121 (-14) days and 139 (+4) days. [0] > > So given block 676080 had mediantime 1616578564, I think picking a > mediantime no later than ~139 days later, ie 1628640000 (00:00 UTC > 11 Aug) would be the most likely to result in MTP logic matching the > height parameters above, and a day or two earlier still might be better. > (It will match provided MTP passes the timeout at any block in the range > [695520, 697535]) > > > (please check my math, if anyone is superstitious we can add a day to > times...) > > It looks to me like blocks are more likely to arrive earlier than later > (which is what we'd expect with increasing hashrate), fwiw, so adding > days would be more likely to cause MTP to have more signalling periods > than height-based, rather than avoid having fewer. > > Cheers, > aj > > [0] $ for b in `seq 201600 2016 676000`; do a=$(($b-19440)); echo $(( > $(bitcoin-cli getblockheader $(bitcoin-cli getblockhash $b) | grep > mediantime | cut -d\ -f4 | tr -d ,) - $(bitcoin-cli getblockheader > $(bitcoin-cli getblockhash $a) | grep mediantime | cut -d\ -f4 | tr -d ,) > )); done > [-- Attachment #2: Type: text/html, Size: 3529 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-03-24 3:46 [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes Jeremy 2021-03-25 7:02 ` Anthony Towns @ 2021-04-06 4:25 ` Rusty Russell 2021-04-07 1:20 ` Ryan Grant 1 sibling, 1 reply; 13+ messages in thread From: Rusty Russell @ 2021-04-06 4:25 UTC (permalink / raw) To: Jeremy, Bitcoin Protocol Discussion, Bitcoin development mailing list Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes: > We had a very productive meeting today. Here is a summary of the meeting -- > I've done my best to > summarize in an unbiased way. Thank you to everyone who attended. > > 1. On the use of a speedy trial variant: > > - There are no new objections to speedy trial generally. > - There is desire to know if Rusty retracts or reaffirms his NACK in light > of the responses. I do not withdraw my NACK (and kudos: there have been few attempts to pressure me to do so!). The core question always was: what do we do if miners fail to activate? Luke-Jr takes the approach that "we (i.e developers) ensure it activates anyway". I take the approach that "the users must make a direct intervention". Speedy Trial takes the approach that "let's pretend we didn't *actually* ask them". It's totally a political approach, to avoid facing the awkward question. Since I believe that such prevaricating makes a future crisis less predictable, I am forced to conclude that it makes bitcoin less robust. Personally, I think the compromise position is using LOT=false and having those such as Luke and myself continue working on a LOT=true branch for future consideration. It's less than optimal, but I appreciate that people want Taproot activated more than they want the groundwork future upgrades. I hope that helps, Rusty. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-06 4:25 ` Rusty Russell @ 2021-04-07 1:20 ` Ryan Grant 2021-04-07 5:01 ` Rusty Russell 0 siblings, 1 reply; 13+ messages in thread From: Ryan Grant @ 2021-04-07 1:20 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Rusty Russell On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > The core question always was: what do we do if miners fail to activate? > > [...] Speedy Trial takes the approach that "let's pretend we didn't > *actually* ask [miners]". What ST is saying is that a strategy of avoiding unnecessary risk is stronger than a strategy of brinkmanship when brinkmanship wasn't our only option. Having deescalation in the strategy toolkit makes Bitcoin stronger. > It's totally a political approach, to avoid facing the awkward question. > Since I believe that such prevaricating makes a future crisis less > predictable, I am forced to conclude that it makes bitcoin less robust. LOT=true does face the awkward question, but there are downsides: - in the requirement to drop blocks from apathetic miners (although as Luke-Jr pointed out in a previous reply on this list they have no contract under which to raise a complaint); and - in the risk of a chain split, should gauging economic majority support - which there is zero intrinsic tooling for - go poorly. > Personally, I think the compromise position is using LOT=false and > having those such as Luke and myself continue working on a LOT=true > branch for future consideration. It's less than optimal, but I > appreciate that people want Taproot activated more than they want > the groundwork future upgrades. Another way of viewing the current situation is that should brinkmanship be necessary, then better tooling to resolve a situation that requires brinkmanship will be invaluable. But: - we do not need to normalize brinkmanship; - designing brinkmanship tooling well before the next crisis does not require selecting conveniently completed host features to strap the tooling onto for testing; and - it's already the case that a UASF branch can be prepared along with ST (ie. without requiring LOT=false), although the code is a bit more complex and the appropriate stopheight a few blocks later. Although your NACK is well explained, for the reasons above I am prepared to run code that overrides it. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-07 1:20 ` Ryan Grant @ 2021-04-07 5:01 ` Rusty Russell 2021-04-07 13:42 ` Claus Ehrenberg ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Rusty Russell @ 2021-04-07 5:01 UTC (permalink / raw) To: Ryan Grant, Bitcoin Protocol Discussion Ryan Grant <bitcoin-dev@rgrant•org> writes: > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> The core question always was: what do we do if miners fail to activate? >> >> [...] Speedy Trial takes the approach that "let's pretend we didn't >> *actually* ask [miners]". > > What ST is saying is that a strategy of avoiding unnecessary risk is > stronger than a strategy of brinkmanship when brinkmanship wasn't > our only option. Having deescalation in the strategy toolkit makes > Bitcoin stronger. I don't believe that having a plan is brinkmanship or an escalation. During the segwit debate, Pieter Wuille said that users should decide. I've been thinking about that a lot, especially about what that means in a practical sense where the normal developer / miner dynamic has failed. >> It's totally a political approach, to avoid facing the awkward question. >> Since I believe that such prevaricating makes a future crisis less >> predictable, I am forced to conclude that it makes bitcoin less robust. > > LOT=true does face the awkward question, but there are downsides: > > - in the requirement to drop blocks from apathetic miners (although > as Luke-Jr pointed out in a previous reply on this list they have > no contract under which to raise a complaint); and Surely, yes. If the users of bitcoin decide blocks are invalid, they're invalid. With a year's warning, and developer and user consensus against them, I think we've reached the limits of acceptable miner apathy. > - in the risk of a chain split, should gauging economic majority > support - which there is zero intrinsic tooling for - go poorly. Agreed that we should definitely do better here: in practice people would rely on third party explorers for information on the other side of the split. Tracking the cumulative work on invalid chains would be a good idea for bitcoind in general (AJ suggested this, IIRC). >> Personally, I think the compromise position is using LOT=false and >> having those such as Luke and myself continue working on a LOT=true >> branch for future consideration. It's less than optimal, but I >> appreciate that people want Taproot activated more than they want >> the groundwork future upgrades. > > Another way of viewing the current situation is that should > brinkmanship be necessary, then better tooling to resolve a situation > that requires brinkmanship will be invaluable. But: > > - we do not need to normalize brinkmanship; > > - designing brinkmanship tooling well before the next crisis does > not require selecting conveniently completed host features to > strap the tooling onto for testing; and Again, openly creating a contingency plan is not brinkmanship, it's normal. I know that considering these scenarios is uncomfortable; I avoid conflict myself! But I feel obliged to face this as a real possibility. I think we should be normalizing the understanding that bitcoin users are the ultimate decider. By offering *all* of them the tools to do so we show this isn't lip-service, but something that businesses and everyone else in the ecosystem should consider. > - it's already the case that a UASF branch can be prepared along > with ST (ie. without requiring LOT=false), although the code is a > bit more complex and the appropriate stopheight a few blocks later. I don't believe this is true, unless you UASF before ST expires? ST is explicitly designed *not* to give time to conclude that miners are stalling (unless something has changed from the initial 3 month proposal?). > Although your NACK is well explained, for the reasons above I am > prepared to run code that overrides it. Good. In the end, we're all at the whim of the economic majority. Cheers! Rusty. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-07 5:01 ` Rusty Russell @ 2021-04-07 13:42 ` Claus Ehrenberg 2021-04-07 15:25 ` eric 2021-04-07 17:13 ` Matt Corallo 2021-04-08 11:11 ` Anthony Towns 2 siblings, 1 reply; 13+ messages in thread From: Claus Ehrenberg @ 2021-04-07 13:42 UTC (permalink / raw) To: Rusty Russell, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4757 bytes --] As a user, I think it's very important for me to know if Taproot is eventually coming or not. So why not make it so that if _either_ miners _or_ users decide for Taproot, it will activate no matter what. Accepting a chain split is imo the fairest way to 'resolve the conflict' (it can't be resolved anyway). That would probably mean running ST and and UASF concurrently. The upside would be that we've got a safe date for Taproot, except neither users nor miners want it. Cheers, Claus On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Ryan Grant <bitcoin-dev@rgrant•org> writes: > > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> The core question always was: what do we do if miners fail to activate? > >> > >> [...] Speedy Trial takes the approach that "let's pretend we didn't > >> *actually* ask [miners]". > > > > What ST is saying is that a strategy of avoiding unnecessary risk is > > stronger than a strategy of brinkmanship when brinkmanship wasn't > > our only option. Having deescalation in the strategy toolkit makes > > Bitcoin stronger. > > I don't believe that having a plan is brinkmanship or an escalation. > > During the segwit debate, Pieter Wuille said that users should decide. > I've been thinking about that a lot, especially about what that means in > a practical sense where the normal developer / miner dynamic has failed. > > >> It's totally a political approach, to avoid facing the awkward question. > >> Since I believe that such prevaricating makes a future crisis less > >> predictable, I am forced to conclude that it makes bitcoin less robust. > > > > LOT=true does face the awkward question, but there are downsides: > > > > - in the requirement to drop blocks from apathetic miners (although > > as Luke-Jr pointed out in a previous reply on this list they have > > no contract under which to raise a complaint); and > > Surely, yes. If the users of bitcoin decide blocks are invalid, they're > invalid. With a year's warning, and developer and user consensus > against them, I think we've reached the limits of acceptable miner > apathy. > > > - in the risk of a chain split, should gauging economic majority > > support - which there is zero intrinsic tooling for - go poorly. > > Agreed that we should definitely do better here: in practice people > would rely on third party explorers for information on the other side of > the split. Tracking the cumulative work on invalid chains would be a > good idea for bitcoind in general (AJ suggested this, IIRC). > > >> Personally, I think the compromise position is using LOT=false and > >> having those such as Luke and myself continue working on a LOT=true > >> branch for future consideration. It's less than optimal, but I > >> appreciate that people want Taproot activated more than they want > >> the groundwork future upgrades. > > > > Another way of viewing the current situation is that should > > brinkmanship be necessary, then better tooling to resolve a situation > > that requires brinkmanship will be invaluable. But: > > > > - we do not need to normalize brinkmanship; > > > > - designing brinkmanship tooling well before the next crisis does > > not require selecting conveniently completed host features to > > strap the tooling onto for testing; and > > Again, openly creating a contingency plan is not brinkmanship, it's > normal. I know that considering these scenarios is uncomfortable; I > avoid conflict myself! But I feel obliged to face this as a real > possibility. > > I think we should be normalizing the understanding that bitcoin users > are the ultimate decider. By offering *all* of them the tools to do so > we show this isn't lip-service, but something that businesses and > everyone else in the ecosystem should consider. > > > - it's already the case that a UASF branch can be prepared along > > with ST (ie. without requiring LOT=false), although the code is a > > bit more complex and the appropriate stopheight a few blocks later. > > I don't believe this is true, unless you UASF before ST expires? ST is > explicitly designed *not* to give time to conclude that miners are > stalling (unless something has changed from the initial 3 month > proposal?). > > > Although your NACK is well explained, for the reasons above I am > > prepared to run code that overrides it. > > Good. In the end, we're all at the whim of the economic majority. > > Cheers! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6042 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-07 13:42 ` Claus Ehrenberg @ 2021-04-07 15:25 ` eric 0 siblings, 0 replies; 13+ messages in thread From: eric @ 2021-04-07 15:25 UTC (permalink / raw) To: 'Claus Ehrenberg', 'Bitcoin Protocol Discussion' [-- Attachment #1: Type: text/plain, Size: 918 bytes --] You may activate any time you want. e From: bitcoin-dev <bitcoin-dev-bounces@lists•linuxfoundation.org> On Behalf Of Claus Ehrenberg via bitcoin-dev Sent: Wednesday, April 7, 2021 6:42 AM To: Rusty Russell <rusty@rustcorp•com.au>; Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org> Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes As a user, I think it's very important for me to know if Taproot is eventually coming or not. So why not make it so that if _either_ miners _or_ users decide for Taproot, it will activate no matter what. Accepting a chain split is imo the fairest way to 'resolve the conflict' (it can't be resolved anyway). That would probably mean running ST and and UASF concurrently. The upside would be that we've got a safe date for Taproot, except neither users nor miners want it. Cheers, Claus [-- Attachment #2: Type: text/html, Size: 2987 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-07 5:01 ` Rusty Russell 2021-04-07 13:42 ` Claus Ehrenberg @ 2021-04-07 17:13 ` Matt Corallo 2021-04-08 11:11 ` Anthony Towns 2 siblings, 0 replies; 13+ messages in thread From: Matt Corallo @ 2021-04-07 17:13 UTC (permalink / raw) To: Rusty Russell, Bitcoin Protocol Discussion, Ryan Grant On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote: > Ryan Grant <bitcoin-dev@rgrant•org> writes: >> On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev >> What ST is saying is that a strategy of avoiding unnecessary risk is >> stronger than a strategy of brinkmanship when brinkmanship wasn't >> our only option. Having deescalation in the strategy toolkit makes >> Bitcoin stronger. > > I don't believe that having a plan is brinkmanship or an escalation. I strongly disagree with this characterization of ST, primarily because there just isn't the kind of agreement you seem to be assuming. ST isn't a "lets not decide because we don't want to formulate a specific grand plan" its more of a "lets not decide, because there are very strong, and very divergent viewpoints on what a specific grand plan can or should look like, and something most people are ok with is better than nothing at all". Ultimately, there are a number of possible directions a grand plan could go, and there appear to be at least several prominent (and likely many non-prominent) individuals who would strongly disagree with any such plan, you and I likely among them :). >> >> LOT=true does face the awkward question, but there are downsides: >> >> - in the requirement to drop blocks from apathetic miners (although >> as Luke-Jr pointed out in a previous reply on this list they have >> no contract under which to raise a complaint); and > > Surely, yes. If the users of bitcoin decide blocks are invalid, they're > invalid. With a year's warning, and developer and user consensus > against them, I think we've reached the limits of acceptable miner > apathy. You say "developer and user consensus against them" here, but then go on to argue that its perfectly acceptable for only a small subset of users to be required to do something below. >> - in the risk of a chain split, should gauging economic majority >> support - which there is zero intrinsic tooling for - go poorly. > > Agreed that we should definitely do better here: in practice people > would rely on third party explorers for information on the other side of > the split. Tracking the cumulative work on invalid chains would be a > good idea for bitcoind in general (AJ suggested this, IIRC). We already have a really, really great precedent for tracking economic majority, I'd argue we have great tooling here! During Segwit2x, we had multiple futures and chain-split-tokens available, including the BitMex futures with billions of dollars in daily volume! For the BCH split, ViaBTC issued similar chain split tokens. At the end of the day, economic value is going to determine the amount of hashrate on any chain, and there is a very, very strong incentive (trading fees!) for an exchange to list...more stuff, chainsplit tokens included. Why do we need to build in really janky ways to measure economic majority when there's already a great one that experience has shown us will prop up and provide reasonable signal, given any material demand. >>> Personally, I think the compromise position is using LOT=false and >>> having those such as Luke and myself continue working on a LOT=true >>> branch for future consideration. It's less than optimal, but I >>> appreciate that people want Taproot activated more than they want >>> the groundwork future upgrades. >> >> Another way of viewing the current situation is that should >> brinkmanship be necessary, then better tooling to resolve a situation >> that requires brinkmanship will be invaluable. But: >> >> - we do not need to normalize brinkmanship; >> >> - designing brinkmanship tooling well before the next crisis does >> not require selecting conveniently completed host features to >> strap the tooling onto for testing; and > > Again, openly creating a contingency plan is not brinkmanship, it's > normal. I know that considering these scenarios is uncomfortable; I > avoid conflict myself! But I feel obliged to face this as a real > possibility. > > I think we should be normalizing the understanding that bitcoin users > are the ultimate decider. By offering *all* of them the tools to do so > we show this isn't lip-service, but something that businesses and > everyone else in the ecosystem should consider. While I strongly agree with your principle, I strongly disagree with the practice of how you propose going about it. Ultimately, no matter what we decide here, elsewhere, or what the process for consensus changes is, the decider will be economic activity and users voting with their Bitcoin. We should start by acknowledging that, and acknowledging that the markets will (and have!) let us know what they think when there is any kind of material disagreement. Then, we should optimize for ensuring that the market never needs to "correct the situation", because if we end up there (or in any of these kinds of scenarios), we've basically screwed the pooch. Sure, some 10% minority group (and usually less as time goes on) forking themselves off has turned out to basically be irrelevant, but if we end up with multiple active chains as a normal course of business (which I'd strongly argue we'd be optimizing for with some kind of UASF/LOT option design out the gate), all we do is encourage strife, at the cost of users who just want to use a robust and reliable Bitcoin. >> - it's already the case that a UASF branch can be prepared along >> with ST (ie. without requiring LOT=false), although the code is a >> bit more complex and the appropriate stopheight a few blocks later. > > I don't believe this is true, unless you UASF before ST expires? ST is > explicitly designed *not* to give time to conclude that miners are > stalling (unless something has changed from the initial 3 month > proposal?). ST is not intended to be an end-all, be-all of the taproot activation story. I don't think anyone who is pushing for it thinks that ST is the only option if miners are not able to upgrade before its signaling window expires. Just because it isn't designed to ensure we can play brinksman ship fork games with a UASF doesn't mean there isn't a followup that could include such a thing. Matt ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-04-07 5:01 ` Rusty Russell 2021-04-07 13:42 ` Claus Ehrenberg 2021-04-07 17:13 ` Matt Corallo @ 2021-04-08 11:11 ` Anthony Towns 2 siblings, 0 replies; 13+ messages in thread From: Anthony Towns @ 2021-04-08 11:11 UTC (permalink / raw) To: Rusty Russell, Bitcoin Protocol Discussion On Wed, Apr 07, 2021 at 02:31:13PM +0930, Rusty Russell via bitcoin-dev wrote: > >> It's totally a political approach, to avoid facing the awkward question. > >> Since I believe that such prevaricating makes a future crisis less > >> predictable, I am forced to conclude that it makes bitcoin less robust. > > LOT=true does face the awkward question, but there are downsides: > > - in the requirement to drop blocks from apathetic miners (although > > as Luke-Jr pointed out in a previous reply on this list they have > > no contract under which to raise a complaint); and > Surely, yes. If the users of bitcoin decide blocks are invalid, they're > invalid. That's begging the question though -- yes, if _everyone_ decides bitcoin works such-n-such a way, then there's no debate. But that's trivial: who's left to debate, when everyone agrees? On the otherhand, if people disagree with you, who's to say they're in the minority and "the users" are on your side? > With a year's warning, and developer and user consensus > against them, I think we've reached the limits of acceptable miner > apathy. The question is "how do you establish developer and user consensus?" In particular, if you're running a business accepting payments via "bitcoin", how do you know what software to run to stay in consensus with everyone else running bitcoin, so you know the payments you receive are good? Ideally, we try to make the answer to that trivial: just download any version of bitcoind and run it with the default configuration. More recent (supported) versions are better due to potential security fixes and performance improvements, of course. > > - in the risk of a chain split, should gauging economic majority > > support - which there is zero intrinsic tooling for - go poorly. > Agreed that we should definitely do better here: in practice people > would rely on third party explorers for information on the other side of > the split. Tracking the cumulative work on invalid chains would be a > good idea for bitcoind in general (AJ suggested this, IIRC). Those measures are only useful *after* there's been a chain split. I'm certainly in favour of better protections like that -- adversarial thinking, prepper-ism, whatever -- but we should be trying really hard to avoid ending up in that situation; and even better to avoid even ending up *risking* that situation. > Again, openly creating a contingency plan is not brinkmanship, I think the word "brinkmanship" is being a bit overused in this thread... lockinontimeout is designed for a chain split -- its only action is to ignore one side of a split should it occur. That's not useless -- splitting the chain is a plausible scenario in the event of someone dedicating something like $200M+ per week to attacking bitcoin, and we should have contingencies in place for that sort of thing. But it's like carrying a gun around -- yeah, there are times when that might be helpful for self-protection or to put a tyrant into the ground; but putting it down on the table everytime you sit down for a coffee* and tapping it and saying "look, I'm sure you'll do the right thing and serve me properly and I'll leave happy and give you a big tip; this is just a contingency plan" isn't super great. And even then, lockinontimeout isn't really a very *good* contingency plan in the event of a chain split: if your side of the split isn't in the majority, you're relying on the other side -- the one with all the money -- being stupid and not having a dontlockinever=yes option to protect them from wipeout, and without a hardfork to change proof-of-work or the difficulty adjustment, you'll have enormous difficulties getting blocks at all. * The only thing worth spending bitcoin on. > I think we should be normalizing the understanding that bitcoin users > are the ultimate decider. Yes. What we shouldn't be normalising is that the way users decide is by risking their business by having their node reject blocks and hoping that everyone else will also reject the same set of blocks. (After all, businesses handling lots of bitcoin being willing to force the issue via running node software that rejects "invalid" blocks, was the whole plan for making s2x a fait accompli...) I've written up what I believe is a better approach to dealing with the possibility of miners not upgrading to enforce a soft-fork quickly here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018723.html I belive it would be straightforward to implement that after a failed speedy trial; technically anyway. Cheers, aj ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes @ 2021-03-24 11:23 Michael Folkson 2021-03-24 18:10 ` Jeremy 0 siblings, 1 reply; 13+ messages in thread From: Michael Folkson @ 2021-03-24 11:23 UTC (permalink / raw) To: jlrubin, Bitcoin Protocol Discussion Thanks for this Jeremy. I agree with the vast majority of this. For those that missed yesterday's meeting the meeting log is here: http://gnusha.org/taproot-activation/2021-03-23.log Jeremy also livestreamed the meeting on his Twitch channel: https://www.twitch.tv/videos/960346848 On the choice between using block heights consistently or using a weird mix of both block heights and MTP in the same activation mechanism you can put me down for a NACK for the latter also. In addition I documented here the preferences for a consistent use of block height: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 If it was a direct choice between entirely block height or entirely MTP then I probably wouldn't NACK either. But using a mix of both makes no sense to me. The two arguments in favor of using a weird mix of block heights and MTP appear to be: 1) "additional review required to ensure height based activation" 2) To prevent a "marketed push to launch a UASF client." On 1) I would argue that the additional review required is not excessive by any means and we have the time to review a consistent use of block height (especially if people spent their time reviewing a PR with a consistent use of block height rather than arguing for a mix). On 2) if we are making technical decisions based on speculating on the marketing strategies of other projects Bitcoin Core is a very different project to the project I thought it was. I personally would find it much easier to reason about timings and time intervals of the different activation phases if block heights are used consistently across the activation mechanism rather than a weird mix of both block heights and MTP. Other than that, I agree it was an excellent meeting and thanks for your efforts organizing and hosting the meeting. -- Michael Folkson Email: michaelfolkson@gmail•com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-03-24 11:23 Michael Folkson @ 2021-03-24 18:10 ` Jeremy 2021-03-24 19:14 ` Michael Folkson 0 siblings, 1 reply; 13+ messages in thread From: Jeremy @ 2021-03-24 18:10 UTC (permalink / raw) To: Michael Folkson; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3969 bytes --] Michael, Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. Your NACK on MTP based ST does not have any merit. The only argument you made for nacking MTP based ST is it is "weird". "Weird" is not a technical argument, it's a normative statement. As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle. AJ's note on this where it is technically justified to use MTP w/ min active height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221, as such it is not a weird choice at all. In fact, without further patching, if I understand correctly, you wouldn't want to use pure MTP without additional logic. I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height. Pushing for height based ST is causing additional review burden on contributors in service of enabling a fringe group's side project. That is actually making a technical decision on another project's marketing strategy, and is precisely why I NACK'd it. Even more outrageously, MTP based ST is easily compatible with a height based BIP8 LOT=true + minactiveheight client, so there really is not a good reason for the fuss. Note -- in general UASF is not the fringe group here -- it's the group trying to preempt the release of an ST client with a UASF client which is the fringe sentiment. For you to flip the exact argument that I made for rejecting ST Height onto ST MTP is no more than a "I know you are but what am I" argument, which I do not think holds water. Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Wed, Mar 24, 2021 at 4:24 AM Michael Folkson <michaelfolkson@gmail•com> wrote: > Thanks for this Jeremy. I agree with the vast majority of this. > > For those that missed yesterday's meeting the meeting log is here: > http://gnusha.org/taproot-activation/2021-03-23.log > > Jeremy also livestreamed the meeting on his Twitch channel: > https://www.twitch.tv/videos/960346848 > > On the choice between using block heights consistently or using a > weird mix of both block heights and MTP in the same activation > mechanism you can put me down for a NACK for the latter also. > > In addition I documented here the preferences for a consistent use of > block height: > https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 > > If it was a direct choice between entirely block height or entirely > MTP then I probably wouldn't NACK either. But using a mix of both > makes no sense to me. > > The two arguments in favor of using a weird mix of block heights and > MTP appear to be: > 1) "additional review required to ensure height based activation" > 2) To prevent a "marketed push to launch a UASF client." > > On 1) I would argue that the additional review required is not > excessive by any means and we have the time to review a consistent use > of block height (especially if people spent their time reviewing a PR > with a consistent use of block height rather than arguing for a mix). > On 2) if we are making technical decisions based on speculating on the > marketing strategies of other projects Bitcoin Core is a very > different project to the project I thought it was. > > I personally would find it much easier to reason about timings and > time intervals of the different activation phases if block heights are > used consistently across the activation mechanism rather than a weird > mix of both block heights and MTP. > > Other than that, I agree it was an excellent meeting and thanks for > your efforts organizing and hosting the meeting. > > -- > Michael Folkson > Email: michaelfolkson@gmail•com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > [-- Attachment #2: Type: text/html, Size: 8056 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 2021-03-24 18:10 ` Jeremy @ 2021-03-24 19:14 ` Michael Folkson 0 siblings, 0 replies; 13+ messages in thread From: Michael Folkson @ 2021-03-24 19:14 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin Protocol Discussion > Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. I support Taproot activation and any project that can help bring that about. As I have said many times I am 100 percent against an incompatible UASF release with a Core ST release. However a UASF project is well within its rights to work around finalized ST parameters in Core to prepare for a possible (but unlikely) failed ST deployment, *especially* in the case that Core is unable to. > As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle. I just prefer consistency. If you prefer inconsistency that is your right. Although "I have a preference for fully height based design, correct" is another of your direct quotes from 6 days ago. So NACKing that same approach 6 days later is a touch bizarre. https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191 > I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height. "marketed push to launch a UASF client" is a direct quote from your email. What marketing has to do with anything I have no idea. As I said in my original response I would prefer not to make technical decisions based on speculation for the marketing strategy of an alternative project. That leads down a very dark road of merging in PRs in response to "world computers" and "Turing completeness" marketing. Thanks Michael On Wed, Mar 24, 2021 at 6:10 PM Jeremy <jlrubin@mit•edu> wrote: > > Michael, > > Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response. > > Your NACK on MTP based ST does not have any merit. The only argument you made for nacking MTP based ST is it is "weird". "Weird" is not a technical argument, it's a normative statement. > > As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle. > > AJ's note on this where it is technically justified to use MTP w/ min active height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221, as such it is not a weird choice at all. In fact, without further patching, if I understand correctly, you wouldn't want to use pure MTP without additional logic. > > I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height. > > > Pushing for height based ST is causing additional review burden on contributors in service of enabling a fringe group's side project. That is actually making a technical decision on another project's marketing strategy, and is precisely why I NACK'd it. > > Even more outrageously, MTP based ST is easily compatible with a height based BIP8 LOT=true + minactiveheight client, so there really is not a good reason for the fuss. Note -- in general UASF is not the fringe group here -- it's the group trying to preempt the release of an ST client with a UASF client which is the fringe sentiment. > > For you to flip the exact argument that I made for rejecting ST Height onto ST MTP is no more than a "I know you are but what am I" argument, which I do not think holds water. > > Best, > > Jeremy > > > > -- > @JeremyRubin > > > On Wed, Mar 24, 2021 at 4:24 AM Michael Folkson <michaelfolkson@gmail•com> wrote: >> >> Thanks for this Jeremy. I agree with the vast majority of this. >> >> For those that missed yesterday's meeting the meeting log is here: >> http://gnusha.org/taproot-activation/2021-03-23.log >> >> Jeremy also livestreamed the meeting on his Twitch channel: >> https://www.twitch.tv/videos/960346848 >> >> On the choice between using block heights consistently or using a >> weird mix of both block heights and MTP in the same activation >> mechanism you can put me down for a NACK for the latter also. >> >> In addition I documented here the preferences for a consistent use of >> block height: >> https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 >> >> If it was a direct choice between entirely block height or entirely >> MTP then I probably wouldn't NACK either. But using a mix of both >> makes no sense to me. >> >> The two arguments in favor of using a weird mix of block heights and >> MTP appear to be: >> 1) "additional review required to ensure height based activation" >> 2) To prevent a "marketed push to launch a UASF client." >> >> On 1) I would argue that the additional review required is not >> excessive by any means and we have the time to review a consistent use >> of block height (especially if people spent their time reviewing a PR >> with a consistent use of block height rather than arguing for a mix). >> On 2) if we are making technical decisions based on speculating on the >> marketing strategies of other projects Bitcoin Core is a very >> different project to the project I thought it was. >> >> I personally would find it much easier to reason about timings and >> time intervals of the different activation phases if block heights are >> used consistently across the activation mechanism rather than a weird >> mix of both block heights and MTP. >> >> Other than that, I agree it was an excellent meeting and thanks for >> your efforts organizing and hosting the meeting. >> >> -- >> Michael Folkson >> Email: michaelfolkson@gmail•com >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: michaelfolkson@gmail•com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-04-08 11:11 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-24 3:46 [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes Jeremy 2021-03-25 7:02 ` Anthony Towns 2021-03-25 14:30 ` Jeremy 2021-04-06 4:25 ` Rusty Russell 2021-04-07 1:20 ` Ryan Grant 2021-04-07 5:01 ` Rusty Russell 2021-04-07 13:42 ` Claus Ehrenberg 2021-04-07 15:25 ` eric 2021-04-07 17:13 ` Matt Corallo 2021-04-08 11:11 ` Anthony Towns 2021-03-24 11:23 Michael Folkson 2021-03-24 18:10 ` Jeremy 2021-03-24 19:14 ` Michael Folkson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox