Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-04-06 Thread Rusty Russell via bitcoin-dev
Ryan Grant writes: > On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev > 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

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-04-06 Thread Ryan Grant via bitcoin-dev
On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev 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

Re: [bitcoin-dev] Response to Rusty Russell from Github

2021-04-06 Thread Matt Corallo via bitcoin-dev
I'm somewhat gobsmacked that this entire conversation hasn't included the word "market" in it at all. If there's one thing we can all agree we learned from Segwit2x, BCH, BSV, BU, etc, its that, ultimately, the market decides. Not only does the market decide, but there's lots of money to be made

Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

2021-04-06 Thread Rusty Russell via bitcoin-dev
Jeremy via bitcoin-dev 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

Re: [bitcoin-dev] Response to Rusty Russell from Github

2021-04-06 Thread Rusty Russell via bitcoin-dev
Jeremy via bitcoin-dev writes: > Where I disagree is that I do not believe that BIP8 with LOT configuration > is the improved long term option we should ossify around either. I > understand the triumvirate model you desire to achieve, but BIP8 with an > individually set LOT configuration does not

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread David A. Harding via bitcoin-dev
(Replies to multiple emails) On Tue, Apr 06, 2021 at 12:27:34PM -0400, Russell O'Connor wrote: > It isn't "$MIN_LOCKIN_TIME + $((10 * 2016)) minutes". It's > "$MIN_LOCKIN_TIME + time until next retargeting period + $((10 * 2016)) > minutes". Ah, drat, I forgot about that. Thank you for

[bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip

2021-04-06 Thread Jeremy via bitcoin-dev
Bitcoin Developers, The second fortnightly taproot activation meeting has just concluded. Below are my notes: 1) On AJ's mods to MTP - luke-jr is still NACK any MTP related thing - It is generally uncontested that the Mods are fine; that it should be LOT (via LAST_CHANCE) compatible -

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Anthony Towns via bitcoin-dev
On Tue, Apr 06, 2021 at 01:17:58PM -0400, Russell O'Connor via bitcoin-dev wrote: > Not only that, but the "time_until_next_retargeting_period" is a variable > whose > distribution could straddle between 0 days and 14 days should the > MIN_LOCKIN_TIME end up close to a retargeting boundary. As

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
On Tue, Apr 6, 2021 at 12:27 PM Russell O'Connor wrote: > On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) >> >> Ten minute estimators can say: >> >> You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 *

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
On Tue, Apr 6, 2021 at 12:23 PM David A. Harding wrote: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + 11 days" ) > > Ten minute estimators can say: > > You need to upgrade by $( date -d "$MIN_LOCKIN_TIME + $((10 * 2016)) > minutes" ) > > And nine minute estimators can say: > >

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread David A. Harding via bitcoin-dev
On Tue, Apr 06, 2021 at 10:34:57AM -0400, Russell O'Connor via bitcoin-dev wrote: > The other relevant value of giving enough time for users to upgrade is not > very sensitive. It's not like 180 days is magic number that going over is > safe and going below is unsafe. I don't think it's the 180

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Adam Back via bitcoin-dev
As I understand Andrew Chow has a patchset for height based activation of Speedy Trial, so that it would be great if people could review that to help increase the review-cycles. Personally I also somewhat prefer block-height based activation, and for myself it seems like a mild step backwards to

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

2021-04-06 Thread Russell O'Connor via bitcoin-dev
I'm pretty sure that the question of "is signalling still possible by the time enough miners have upgraded and are ready to start signalling?" Strongly benefits from a guaranteed number of signaling periods that height based activation offers. Especially for the short activation period of Speedy

[bitcoin-dev] Update on "Speedy" Trial

2021-04-06 Thread Michael Folkson via bitcoin-dev
(The email last week was an April Fools. I did my best to make light of the situation...) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018724.html I'd like to give the list an update on where we are with Speedy Trial because it is just as absurd as it looks to an outside