--- Log opened Tue Mar 16 00:00:57 2021 05:51 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined ##taproot-activation 05:51 -!- Topic for ##taproot-activation: General discussion on Taproot activation Logs: http://gnusha.org/taproot-activation/ Development of the LOT=true implementation belongs in ##uasf. Discussion on Taproot itself belongs in ##taproot-bip-review. 05:51 -!- Topic set by michaelfolkson [~michaelfo@2a03:b0c0:1:e0::23d:d001] [Sun Feb 28 16:59:51 2021] 05:51 [Users ##taproot-activation] 05:51 [@michaelfolkson] [ kanzure ] 05:51 [@moneyball ] [ ksedgwic ] 05:51 [ _0x0ff ] [ luke-jr ] 05:51 [ AaronvanW ] [ maaku ] 05:51 [ Abelian ] [ matt2 ] 05:51 [ achow101 ] [ mdrollette ] 05:51 [ ajonas ] [ meshcollider ] 05:51 [ amiti ] [ midnight ] 05:51 [ andytoshi ] [ mitjavoll[m] ] 05:51 [ b10c ] [ mol ] 05:51 [ belcher ] [ Murch ] 05:51 [ bitconner ] [ nehan ] 05:51 [ bob333_ ] [ nickler ] 05:51 [ brg444 ] [ niftynei ] 05:51 [ bsm117532 ] [ nioc ] 05:51 [ CARO2 ] [ otoburb ] 05:51 [ cguida1 ] [ parazyd ] 05:51 [ common ] [ phantomcircuit ] 05:51 [ copumpkin ] [ pinheadmz ] 05:51 [ criley ] [ pox ] 05:51 [ CubicEarth ] [ provoostenator_] 05:51 [ darosior ] [ qubenix ] 05:51 [ DeanWeen ] [ queip ] 05:51 [ dergoegge ] [ rabidus ] 05:51 [ devrandom ] [ raj_149 ] 05:51 [ dr-orlovsky ] [ rich| ] 05:51 [ drolmer ] [ roasbeef ] 05:51 [ elichai2 ] [ robert_spigler ] 05:51 [ Emcy ] [ roconnor ] 05:51 [ emzy ] [ rodarmor ] 05:51 [ fanquake ] [ RubenSomsen ] 05:51 [ felixweis ] [ RusAlex_ ] 05:51 [ fjahr ] [ sanket1729 ] 05:51 [ gambpang ] [ sanketcell_ ] 05:51 [ ghost43_ ] [ schmidty ] 05:51 [ glozow ] [ sdaftuar ] 05:51 [ gnusha ] [ shesek` ] 05:51 [ GoldmanSats__ ] [ stortz ] 05:51 [ grubles ] [ sturles ] 05:51 [ Guest30742 ] [ takinbo ] 05:51 [ gwillen ] [ timeerrr[m] ] 05:51 [ harding ] [ uasf ] 05:51 [ hebasto ] [ Victorsueca ] 05:51 [ hugohn ] [ virtu ] 05:51 [ Jackielove4u ] [ wangchun_ ] 05:51 [ jakesyl ] [ warren ] 05:51 [ jamesob ] [ waxwing_ ] 05:51 [ jesseposner ] [ willcl_ark ] 05:51 [ jigawatt ] [ windsok ] 05:51 [ jkczyz ] [ wraithm ] 05:51 [ jonasschnelli ] [ wumpus ] 05:51 [ jrawsthorne ] [ yanmaani ] 05:51 [ justinmoon_ ] [ yevaud ] 05:51 [ kallewoof ] 05:51 -!- Irssi: ##taproot-activation: Total of 107 nicks [2 ops, 0 halfops, 0 voices, 105 normal] 05:51 -!- Channel ##taproot-activation created Sun Jul 12 07:53:03 2020 05:53 -!- Irssi: Join to ##taproot-activation was synced in 166 secs 06:02 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation 06:28 -!- jonatack_ [~jon@37.165.122.66] has joined ##taproot-activation 06:43 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 06:43 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation 07:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 264 seconds] 07:12 -!- jonatack_ [~jon@37.165.122.66] has quit [Quit: jonatack_] 07:12 -!- jonatack [~jon@37.165.122.66] has joined ##taproot-activation 07:20 -!- waxwing_ is now known as waxwing 07:20 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 07:20 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-activation 07:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 07:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 07:39 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has quit [Ping timeout: 256 seconds] 07:42 -!- elector [~elector@gateway/tor-sasl/elector] has joined ##taproot-activation 08:01 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 08:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 08:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 08:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 08:22 -!- parazyd [~parazyd@devuan/developer/parazyd] has quit [Quit: parazyd] 08:27 -!- TheDiktator [~TheDiktat@140.82.33.246] has joined ##taproot-activation 08:27 < TheDiktator> taproot simplified: https://pastebin.com/raw/DmaKGyBQ 08:29 -!- parazyd [~parazyd@devuan/developer/parazyd] has joined ##taproot-activation 08:34 -!- TheDiktator [~TheDiktat@140.82.33.246] has quit [Ping timeout: 256 seconds] 08:36 < copumpkin> sigh 09:10 -!- temp345903485 [bf60434a@191.96.67.74] has joined ##taproot-activation 09:12 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##taproot-activation 09:38 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 09:40 -!- temp345903485 [bf60434a@191.96.67.74] has quit [Quit: Connection closed] 09:41 -!- rich| [rich@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in] 09:41 -!- rich [rich@2600:3c00::f03c:92ff:fe8e:dce6] has joined ##taproot-activation 09:51 -!- OP_NOP [bf60434a@191.96.67.74] has joined ##taproot-activation 09:57 -!- OP_NOP [bf60434a@191.96.67.74] has quit [Quit: Connection closed] 09:57 -!- OP_NOP_ [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation 09:58 -!- OP_NOP_ is now known as OP_NOP 10:10 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has joined ##taproot-activation 10:13 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has quit [Client Quit] 10:13 -!- testing [c6368468@static-198-54-132-104.cust.tzulo.com] has joined ##taproot-activation 10:14 -!- testing is now known as Guest22772 10:14 -!- Guest22772 [c6368468@static-198-54-132-104.cust.tzulo.com] has left ##taproot-activation [] 10:19 -!- pleb42 [c6368468@static-198-54-132-104.cust.tzulo.com] has joined ##taproot-activation 10:21 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation 10:33 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has joined ##taproot-activation 10:37 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has quit [Client Quit] 10:37 -!- nioc is now known as BillyPilgrim 10:38 -!- BillyPilgrim is now known as nioc 10:49 -!- stortz [c8b9cbcf@200.185.203.207] has quit [Quit: Connection closed] 10:51 -!- Nicap [5d681bd7@ppp-93-104-27-215.dynamic.mnet-online.de] has joined ##taproot-activation 11:03 -!- lucasmoten [~lucasmote@136.144.35.169] has joined ##taproot-activation 11:16 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds] 11:16 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined ##taproot-activation 11:18 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 11:23 -!- AsILayHodling [d0402051@208.64.32.81] has joined ##taproot-activation 11:24 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has joined ##taproot-activation 11:27 -!- peterrizzo_1 [44c18924@ool-44c18924.dyn.optonline.net] has joined ##taproot-activation 11:40 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has joined ##taproot-activation 11:49 <@michaelfolkson> I think this is happening in 10 minutes https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018636.html 11:56 -!- fiach_dubh [ac532846@172.83.40.70] has joined ##taproot-activation 11:56 -!- bitentrepreneur [uid39920@gateway/web/irccloud.com/x-fjahzivhcnduxzrn] has joined ##taproot-activation 11:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 11:58 < luke-jr> Emil Pfeffer's email seems self-contradicting O.o 11:59 -!- r251d [~r251d@50.121.84.2] has joined ##taproot-activation 12:01 < rusty> Mentally still asleep, but physically at keyboard... Hope I got the time right? 12:01 < AaronvanW> rusty: you did 12:01 <@michaelfolkson> Yup I think so 12:01 <@michaelfolkson> Want to start luke-jr? 12:01 < copumpkin> rusty: best mind state for the hottest takes :) 12:02 < luke-jr> sure 12:02 <@michaelfolkson> #startmeeting 12:02 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has joined ##taproot-activation 12:02 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection] 12:03 <@michaelfolkson> Agenda: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018636.html 12:03 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 12:03 -!- dav [b9b7c350@185.183.195.80] has joined ##taproot-activation 12:03 <@michaelfolkson> I thought I was leaving this to you Luke :) 12:03 <@michaelfolkson> You want me to go? 12:04 < elector> is there no danger to quick upgrades? 12:04 < bitentrepreneur> hi 12:04 <@michaelfolkson> Yeah say hi if you're here for the meeting 12:04 < AsILayHodling> yo 12:04 <@michaelfolkson> Thanks bitentrepreneur 12:04 < r251d> hi 12:04 < rusty> hi 12:04 < AaronvanW> hi 12:04 < devrandom> hi 12:05 < luke-jr> #topic Speedy Trial proposal 12:05 < luke-jr> since the last meeting, a new idea has been put forward to explicitly preempt the activation plan with a fast 3 months of signalling attempts; if miners signal readiness during that time, activation would occur in November 12:05 < luke-jr> elector: that's what the activation delay is for 12:05 < belcher> hi 12:05 < luke-jr> signalling for Speedy Trial (ST) would begin around May 1st 12:05 < bitentrepreneur> cool 12:06 < luke-jr> if at any point during May, June, July 90% of hashrate signals, activation would occur in November 12:06 < luke-jr> (mid-November) 12:06 < AsILayHodling> What are the main difference between ST and "Let's see what happens"? 12:07 < devrandom> original proposal here - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html 12:07 <@michaelfolkson> Have you had a chance to see if mining pools are happy with ST bitentrepreneur? I saw wangchun ACKed it https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f 12:07 < ksedgwic> hi 12:07 < AaronvanW> AsILayHodling: longer gap between signaling period and actual taproot enforcement. 12:07 < AsILayHodling> AaronvanW thanks 12:08 < bitentrepreneur> i will begin asking them by tomorrow 12:08 <@michaelfolkson> AsILayHodling: Very similar. Major difference is that ST has a delay between successful signaling and actual activation. "Let's see what happens" would activate immediately after successful signalling 12:08 < luke-jr> also, the proposal is to treat this as a quick "see what happens" with failure as an acceptable or even expected outcome 12:08 -!- shesek` is now known as shesek 12:08 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 12:08 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation 12:08 < bitentrepreneur> wanted to understand it all today in this meeting, before i did. 12:08 <@michaelfolkson> Cool, thanks bitentrepreneur 12:08 < bitentrepreneur> no prob 12:08 < luke-jr> that is, users would be advised to expect a followup "real" deployment in the event this isn't signalled 12:09 < luke-jr> hopefully avoiding the confusion issue 12:09 <@michaelfolkson> It is 3 months of signaling from around May 1st onwards 12:09 <@michaelfolkson> If it fails it fails immediately after the 3 months 12:09 <@michaelfolkson> So then we're back where we were with the LOT discussion on a BIP 8(1 year) 12:09 <@michaelfolkson> If it succeeds there is a long delay (3 months?) before it actually activates 12:10 < luke-jr> potential downside: activation during this 3 months means waiting until November, whereas BIP8 would have made it possible in August. 12:10 < AsILayHodling> "...would be advised to expect a followup "real" deployment..." luke-jr "real" here meaning a LOT=ture typr of scenario? 12:10 < luke-jr> otoh, August was a bit uncomfortablely soon IMO, and with no release as planned, I'd prefer to see it moved later anyway 12:10 < bitentrepreneur> waiting a couple of months for signalling to occur is fine by me 12:11 < luke-jr> AsILayHodling: right, though consensus on ST does not imply consensus on what comes after 12:11 -!- dav [b9b7c350@185.183.195.80] has quit [Quit: Connection closed] 12:11 < luke-jr> bitentrepreneur: ST is the opposite 12:11 < AaronvanW> AsILayHodling: LOT=true or LOT=false or both or whatever peaople agree on... bascially unclear as of now. 12:11 <@michaelfolkson> bitentrepreneur: It is 3 months of signaling. So not a long period of signaling 12:11 < bitentrepreneur> that is what i meant, 3 months is OK. 12:12 -!- dav [b9b7c350@185.183.195.80] has joined ##taproot-activation 12:12 < devrandom> by "OK", do you mean "long enough"? 12:12 <@michaelfolkson> Cool, so 3 months of signaling is ok and a delay between successful signaling and actual activation 12:12 < elector> if theres no consensus mechanism within Core then how can you ever reach one? 12:12 < luke-jr> potential upside: if signalling doesn't occur during the 3 months, support for LOT=True will hopefully be higher 12:12 < luke-jr> elector: ? 12:13 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Ping timeout: 256 seconds] 12:13 <@michaelfolkson> The proposed timeline is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html 12:13 < elector> the LOT debate will appear with any upgrade method 12:13 < elector> seems not having a method to make a decision can stale you forever 12:13 < rgrant> hi 12:14 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined ##taproot-activation 12:14 < rusty> elector: we are the method :) 12:14 < luke-jr> elector: LOT=True can safely happen without consensus, but ST avoids the issue entirely hopefully\ 12:14 <@michaelfolkson> elector: This ST proposal is effectively close to a BIP 8(3 month, false) 12:14 < AaronvanW> elector: users can always uasf 12:14 < luke-jr> elector: also note that Core does not decide the protocol any more than miners do 12:14 < elector> rusty: how does it work? 12:14 < rusty> elector: I'll tell you when it's complete :) 12:14 < elector> :) 12:14 -!- dav [b9b7c350@185.183.195.80] has quit [Client Quit] 12:14 < luke-jr> anyway, does anyone have anything else to add on ST, or any objections to trying it? 12:15 < luke-jr> (trying it because ST is just a try) 12:15 <@michaelfolkson> We're looking at actual activation of around November 13th if miner signaling threshold is met 12:15 < luke-jr> should add here: ST currently conflicts with the prior parameter choice, but that's only an issue if someone objects to delaying it 12:16 < rusty> Note that I expect any method of activation will work (in the sense that this SF will activate). I don't think that means we should use any method, though. 12:16 < luke-jr> only for 1 period (ST's last period and BIP8's first) 12:16 < bitentrepreneur> no objections to trying it from my end 12:16 < elector> my objection is that it could waste time but also that changing things so often creates confusion 12:16 < rusty> It avoids the awkward question of what happens if it doesn't activate, which I consider a nasty misfeature. But I understand people are tired, and nobody wants conflict. 12:16 < luke-jr> elector: the point of ST's timeline (aside from the 2 weeks overlap) is that it is before anything else, so can't really waste time 12:17 -!- pleb42 is now known as odell 12:17 < luke-jr> (provided the BIP8/1y continues to make progress during ST) 12:17 < shesek> I'd be interested to hear if people consider any failure to signal activation as malicious behavior by the miners that should result in a UASF, or leave room for the possibility of the miners having a reasonable reason not to be ready within 3 months 12:17 < rusty> luke-jr: no, the point of ST is to avoid making a difficulty decision. 12:17 < luke-jr> rusty: otoh, resolving the conflict now would hopefully avoid having to repeat it every SF :P 12:17 <@michaelfolkson> shesek: I think there will definitely be a UASF release if ST fails 12:18 < rusty> luke-jr: I agree, but ST is punting. 12:18 <@michaelfolkson> shesek: Regardless of what the perception is for the reason of it failing 12:18 < rusty> michaelfolkson: not at all! "Oh we didn't quite get the upgrade in time!" "It was awkward timing" etc. The available excuses are endless. 12:18 < luke-jr> rusty: the timeline specifically 12:18 < roconnor> rusty: Not entirely true. Part of the goal of ST is to gather evidence of users proactively upgrading their nodes to a taproot supporting node. 12:18 < OP_NOP> hi 12:18 < shesek> michaelfolkson, would you personally definitely support UASF post ST failing, or does it depend on circumstances? 12:19 < rusty> roconnor: I think the version bits are completely indep of what software they're running, no? 12:19 < roconnor> If ST doesn't active, we won't acutally be where we are today. We will have new information. 12:19 < shesek> luke-jr, interested in your take too 12:19 < devrandom> ST may help move things forward by coalescing support for UASF 12:19 < rusty> roconnor: it's a more reliable poll, true. But since it will pass, we'll not have resolved anything about how we activate SF. 12:19 < luke-jr> shesek: again, I think the LOT=True release needs to progress even before/if ST succeeds 12:20 < roconnor> rusty: my understand was that some people want this information before supporting LOT=true. 12:20 < shesek> progress as in get developed, or as in get released and promoted? 12:20 <@michaelfolkson> shesek: If ST fails I think a UASF release (BIP 8,true) is inevitable. I hope it is in parallel with a Core BIP 8(false). But I'm less confident about the Core part 12:20 < AaronvanW> luke-jr: but you'd be ok with a delayes timeline if everyone else is ok with it? 12:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 12:21 < shesek> have any miners confirmed their ability to upgrade within the ST timeframe yet? 12:21 < AaronvanW> shesek: F2Pool did 12:21 < rusty> michaelfolkson: well, why not just have a core BIP 8(false), and let either an option, or if all else fails, a patch do BIP 8(true). It's simpler. It's potentially faster. It resolves the issue of what happens if the miners don't activate. 12:21 < AaronvanW> at least they acked the proposal shesek 12:21 < BlueMatt> shesek: isnt that the point of the ST timeframe? they dont have to - they can reconfigure their pool in an hour, and then can upgrade their bitcoind over a few months. 12:22 < elector> why not BIP 8(true) from the start 12:22 < AaronvanW> and bitentrepeneur says it's ok. (poolin) 12:22 < bitentrepreneur> i can get an answer from poolin by tomorrow or day after tomorrow 12:22 <@michaelfolkson> rusty: Because it is incredibly difficult to get consensus on anything. I am absolutely shocked there is so much consensus around ST 12:22 < bitentrepreneur> it's because we all want taproot :) 12:22 < shesek> BlueMatt, you mean signal within the 3 months timeframe without actually upgrading their nodes, then make sure to upgrade before activation in 6 months? 12:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 12:23 < rusty> michaelfolkson: well, I think it's a terrible idea 12:23 < BlueMatt> shesek: yes, thats how basically all version-bit-signaled soft forks have gone off anyway. 12:23 <@michaelfolkson> rusty: Please add your opinion to the gist. Very few NACKs (1 I think) so far https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f 12:24 <@michaelfolkson> With explanation ideally 12:24 < BlueMatt> there has also been incredibly little in-depth discussion of ST 12:24 < rgrant> rusty: Can you restate your objection in your own terms? I heard you say you want bip8, but I didn't hear why ST is terrible. 12:24 < BlueMatt> eg the mailing list thread had one material comment and no discussion 12:24 < BlueMatt> presumably it should get more 12:24 < shesek> BlueMatt, even if it was the case in practice, we shouldn't be encouraging this >_< 12:25 < BlueMatt> shesek: anything using the version field in the header has this problem. I dont think anyone is proposing to change that now (though we could) 12:25 <@michaelfolkson> BlueMatt: Because it is so close to "Let's see what happens". This is hardly a revolutionary proposal 12:25 < BlueMatt> michaelfolkson: there are tons of details and flags and numbers and implications 12:25 <@michaelfolkson> They're in the proposal BlueMatt 12:25 -!- nija [5410eb84@84.16.235.132] has joined ##taproot-activation 12:25 < rgrant> rusty: Oh, I see you mentioned it not resolving anything. 12:26 < BlueMatt> yes, my point is there are lots of *things* worth discussing in depth :) 12:26 < BlueMatt> not that they arent filled in 12:26 <@michaelfolkson> BlueMatt: Gotcha. We can do that now if you have views? 12:26 < BlueMatt> sadly I'm currently both in a meeting and about to leave for another. 12:26 -!- Swarleys [d5c371cc@213.195.113.204] has joined ##taproot-activation 12:26 < BlueMatt> but I tried to discuss stuff on the ml and got no material responses 12:27 <@michaelfolkson> BlueMatt: On specific parameters of ST? I saw your concern of an incompatible UASF 12:27 < luke-jr> AaronvanW: what do you mean? I'm not okay with delaying work on BIP8/1y, but I'm more than okay with shifting its timeline 12:27 < luke-jr> shesek: both 12:27 < luke-jr> shesek: ideally, people upgrading now will just upgrade to a single release with both ST+UASF 12:27 <@michaelfolkson> BlueMatt: I didn't see any problems you had with parameters apart from that 12:28 < luke-jr> elector: BIP8(true) doesn't need to go away, to add ST in front 12:28 <@michaelfolkson> Can you link to a mailing list post BlueMatt in case I missed it? 12:28 <@michaelfolkson> I saw your comment on the gist https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f 12:28 < AaronvanW> rgrant: this is how harding summarized rusty's concern in the optech mailing list: “Speedy Trial fully prepares for the (likely) case where miners activate taproot, but it does nothing to codify lessons learned from Segwit’s failure to activate in a timely manner. We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the roles and responsibilitie 12:28 < AaronvanW> s for developers, miners, merchants, investors, and end users in all the ways an activation can progress, not just the best-case outcomes; in particular enabling and enshrining the final arbiter role held by Bitcoin’s economic users. Defining this will only get more difficult in the future, both because we’ll only do so when we’re already in crisis, and because Bitcoin’s growth means future agreement will need 12:28 < AaronvanW> to be done at greater scale and so with greater difficulty.” 12:28 < shesek> BlueMatt, there's no way to enforce that miners don't false-signal their readiness, but I don't think we should be putting the miners into a corner where false signaling is their only realistic option (I don't think it should be the case in a 3 months timeframe, though) 12:28 < AaronvanW> luke-jr: thanks, that answers my question. 12:28 < luke-jr> BlueMatt: there will be more softforks in the future to improve the process for 12:29 < rgrant> AaronvanW: thx! 12:29 < shesek> (but I'm not a mining pool operator, so I could definitely be wrong...) 12:29 < BlueMatt> shesek: to clarify some - there is no technical way to accomplish that with the header version field, its done in the pool server, no the node. that's just how it is. we can move it, but lets not do it this time. 12:29 < rgrant> My immediate counter to that concern is that we should always do a ST. :) 12:29 < luke-jr> considering the ST topic has gone on so long, and BlueMatt needs to go, and jeremyrubin wanted another week anyway, I propose we shelve the topic until next week? 12:30 < BlueMatt> I think the discussion can also happen on the ML 12:30 < luke-jr> of course 12:30 < BlueMatt> there seems to be broad consensus in principle, just gotta hash out details 12:30 <@michaelfolkson> luke-jr: I do think concerns or reservations about ST are urgent given attempted startheight of May 1st 12:30 < shesek> BlueMatt, do you have an estimate of how much % of hashpower is mining via pools but with their own full nodes? I would assume its (unfortunately) a tiny fraction 12:30 < AaronvanW> I'm ok with shelving until next week/mailing list. 12:30 < luke-jr> michaelfolkson: 1 week is okay for that 12:30 < BlueMatt> michaelfolkson: lets just change the constnat, no need for artificial pressure just because the original date isnt realistic. 12:31 <@michaelfolkson> BlueMatt: I'm happy with that but I'm conscious that I've got a lot of ACKs and we should avoid invalidating them 12:31 < rgrant> I hear one objection: we're not setting enough precedent. I propose this as the major topic for next week: "Should we try to set precedent?" The ST solution is basically saying "no thanks, not now". 12:31 < rusty> OK, I've posted on the GH here: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311 12:32 < luke-jr> #topic BIP8/1y activation plan 12:32 < luke-jr> more time-sensitive is that the previous plan, for BIP8/1y expected a software release yesterday. That did not happen. It is not close to happening. 12:32 < luke-jr> IMO we should shift the startheight/timeoutheight until later, no matter what happens with ST 12:32 <@michaelfolkson> BlueMatt: I don't think a short delay does invalidate them btw. But lots of changes to the proposal and that question will be raised 12:32 < roconnor> I expect specific values for activation parameters will be in their own PR. 12:32 < luke-jr> roconnor: https://github.com/bitcoin/bitcoin/pull/21393/ 12:32 <@michaelfolkson> Thanks rusty 12:32 < BlueMatt> michaelfolkson: right, I highly doubt it "invalidates" it. the general principle is what a lot of people agreed with, actual constants and the specific dates are somewhat separate 12:33 <@michaelfolkson> BlueMatt: Agreed. I hope all the ACKers on the proposal agree with that view too 12:33 < luke-jr> does anyone have any objections to pushing the BIP8/1y start/timeout heights later, until a software release is made? 12:33 < rgrant> rusty: Note that if we "set precedent", then we need to do it in a way that gently messages that this is inpreparation for some future problem, rather than a problem we believe we have right now. Miners aren't all bad. ;) 12:33 <@michaelfolkson> So to be clear Luke is talking about the UASF plan. Which should possibly in a separate UASF meeting 12:34 <@michaelfolkson> I know a lot of people here won't support the UASF plan regardless of timetables 12:34 < rusty> rgrant: yes, the point about shipping with LOT=true option. 12:34 < rusty> luke-jr: seems a no-brainer to me. 12:34 < elector> luke-jr: in the event the upgrade ends up with a bang at least august is a slow month 12:34 < rgrant> luke-jr: okay with time move 12:35 < luke-jr> michaelfolkson: this is the primary topic for this meeting to address, as it is up against a failed "checkpoint" on its schedule 12:35 < luke-jr> elector: but to keep August, we're reducing the time between release and earliest activation 12:35 <@michaelfolkson> luke-jr: But certainly no objections from me either. Any UASF should not conflict with ST 12:36 <@michaelfolkson> luke-jr: That is the schedule of the UASF. You're fine to ask but be conscious there are people here who don't support UASF or LOT=true 12:36 < luke-jr> elector: for example, if we don't have a software release ready for another month, can we be sure enough of the economy will have updated by August? 12:36 <@michaelfolkson> luke-jr: I think we are all in agreement that a UASF should not conflict or be incompatible with whatever the finalized ST parameters are 12:36 < luke-jr> michaelfolkson: the part primarily at hand is the MASF part anyway 12:37 <@michaelfolkson> If anyone doesn't agree with what I've just said please say so 12:37 < rgrant> michaelfolkson: +1 for UASF compatible with ST/MASF 12:37 -!- Nicap52 [5d6819eb@ppp-93-104-25-235.dynamic.mnet-online.de] has joined ##taproot-activation 12:38 < BlueMatt> michaelfolkson: to clarify somewhat, it may not have come across in the email I sent to the ML in response to the original ST proposal - my concern is not that the parameters are "compatible" with a UASF, more that they are perfectly in line with *encouraging* a UASF. ultimately any signaling-based activation method is "compatible" with a UASF standoff, but if we're trying to "keep the community together" by pushing for ST and 12:38 < BlueMatt> hoping it goes through before we tear each other apart anymore, we probably shouldnt *also* leave the parameters roughly in line with the actual timeline that BIP 148 ran, ie imo encourage people to take up a UASF during the ST process, which is intended specifically to avoid it. 12:38 < luke-jr> michaelfolkson: I don't think it's reasonable to expect things to revolve around Core at this point. ST parameters should be finalized, maybe next week, but not subject to further changes even if Core doesn't release for another month.. 12:38 -!- Nicap [5d681bd7@ppp-93-104-27-215.dynamic.mnet-online.de] has quit [Ping timeout: 240 seconds] 12:38 <@michaelfolkson> luke-jr: I disagree. Code is ready and reviewed when it is ready and reviewed 12:38 < BlueMatt> but it sounds like people *do* intend to push for a UASF during the ST process, which saddens me greatly, given I thought the goal was specifically to avoid that, but maybe I'm misreading backlog here. 12:38 < BlueMatt> in any case, I do actually have to run now, see y'all on the ML 12:39 <@michaelfolkson> Ok thanks BlueMatt 12:39 < luke-jr> BlueMatt: push for a UASF *in a year* only 12:39 < luke-jr> well, 18+ months at this point 12:39 < BlueMatt> luke-jr: ok, phew, then I'm misreading the backlog here. 12:39 < luke-jr> BlueMatt: ST, followed by 1y BIP8 MASF, then the UASF in late 2022 12:39 < achow101> BlueMatt: I don't think anyone is pushing for a UASF during ST 12:39 < BlueMatt> rusty: I only read your first line, but I like it :) 12:39 < luke-jr> BlueMatt: if ST succeeds, none of the rest matters 12:39 <@michaelfolkson> BlueMatt: The talk has been of a BIP 8(1 year,true) starting after ST has failed 12:40 * BlueMatt -> gone 12:40 * michaelfolkson waves 12:40 < luke-jr> elector: anyway, what solution do you propose? 12:40 < devrandom> BTW, if ST is merged into Core, then BIP8 is effectively merged, which reduces the diff for further activation, right? 12:40 < luke-jr> if we want to keep August, IMO we should release at least a RC1 this week, or things get very dangerous. 12:41 < achow101> devrandom: only the lot=false portion of bip8 will be merged 12:41 < elector> follow the initial timeline, decide on LOT and release 12:41 < rgrant> (serious) Can someone draw the infographic for time parameters that include ST and UASF? Probably using luke-jr's proposed moved block heights. 12:41 < devrandom> achow101: lot=true is a small diff on top of lot=false, no? 12:41 < achow101> devrandom: not really 12:41 < luke-jr> rgrant: https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files is what roconnor (IIRC) proposed, and I think makes the most sense right now 12:41 < OP_NOP> Nothing is a small diff with consensus code 12:42 <@michaelfolkson> rgrant: Yes but ST completes and fails before the UASF BIP 8(1 year,true) would start. They don't overlap 12:42 <@michaelfolkson> Can I ask you about your view rusty? 12:42 <@michaelfolkson> You still here? 12:42 < rusty> michaelfolkson: sorry, was paged out. 12:43 < roconnor> for the record my proposal isn't an endorsement. 12:43 < luke-jr> devrandom: https://dpaste.com/9ETAL93XH 12:43 < rgrant> luke-jr: okay, that. Point is that people aren't doing the block height math and internalizing the dates and the amount of time for the community to adapt to various phases of locked_in. 12:43 <@michaelfolkson> rusty: Why doesn't "devs propose, miners activate, users override" apply with ST? 12:43 -!- prayank [~andr0irc@2401:4900:30d2:dd44:6d14:3f85:cf7d:24e9] has joined ##taproot-activation 12:44 < devrandom> luke-jr: thanks! 12:44 <@michaelfolkson> Devs are proposing, miners can activate 12:44 < luke-jr> rgrant: 681408 is ST's May 1st 12:44 <@michaelfolkson> Users can override with a UASF after ST has failed 12:44 < rusty> michaelfolkson: it's "devs propose tepidly, miners activate, nothing"? 12:44 <@michaelfolkson> I don't get why this doesn't align with your maxim rusty 12:44 < luke-jr> rgrant: so ST begins May 1st and ends July 30th or so 12:44 < elector> If theres strong oppossion against LOT=true then I'd rather release LOT=false now to get it going 12:44 < luke-jr> rgrant: with LOT=True added on, we can just extend the timeout to 2022 November 12:44 < rusty> michaelfolkson: I mean, people are talking about devs activating if miners don't ack. 12:45 <@michaelfolkson> rusty: Users get the chance to activate with a UASF if ST fails 12:45 -!- fiach_dubh [ac532846@172.83.40.70] has quit [Quit: Connection closed] 12:45 < achow101> rusty: by devs activating, you mean release LOT=true? 12:45 < rusty> michaelfolkson: sure, users *always* get a chance to activate! 12:45 < rusty> I mean, they could do so now@! 12:45 -!- fiach_dubh [ac532846@172.83.40.70] has joined ##taproot-activation 12:45 < luke-jr> elector: LOT=False is unsafe 12:45 <@michaelfolkson> rusty: I highly doubt Core will release LOT=true if ST fails anyway. I wonder if Core will *ever* release LOT=true 12:45 < rusty> So, technically, this is always a true statement. It's also not a useful one. 12:46 <@michaelfolkson> rusty: (for any soft fork ever) 12:46 < luke-jr> elector: what do you think of that adjusted plan? essentially May 1st - Nov 2022 MASF, activating no earlier than Nov 2021, and UASF after Nov 2022) 12:47 < rgrant> luke-jr: Right, but people need to see all the space for reconciliation between August and next November on a single picture. eg. Matt felt we were talking about different dates. 12:47 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds] 12:47 < rusty> If the developers genuinely believe that users should have the final say, they ensure that the tools are at hand. That provides both a practical means for UASF, and a Schelling point around which to do so. These are both vital infrastructure. 12:47 <@michaelfolkson> rgrant: The problem is that ST parameters need to be finalized before UASF can set a timetable. Yet ST parameters only get finalized on ST PR(s) getting merged into Core 12:48 < luke-jr> michaelfolkson: why? 12:48 < luke-jr> Core is not in charge 12:48 <@michaelfolkson> Because otherwise PRs get merged in a rush or UASF releases something incompatible with ST 12:48 <@michaelfolkson> (or both) 12:48 < luke-jr> michaelfolkson: you mean Core releases something incomaptible 12:48 <@michaelfolkson> Either/or should definitely be avoided 12:49 < rgrant> michaelfolkson: Yes, the infographic would memorialize "consensus of expected game theoretic responses as understood by people supporting this merge into Core". 12:49 <@michaelfolkson> luke-jf: Not if we are working around ST (which I strongly think we should) 12:49 <@michaelfolkson> luke-jr* 12:49 < luke-jr> michaelfolkson: we should, but not giving Core dictatorship 12:49 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 12:50 <@michaelfolkson> luke-jr: You seem to be arguing for Core to stick to the timetable even if the PRs aren't ready to be merged. That is an absurd position 12:50 < luke-jr> ST should be decided by the community, regardless of when or if Core merges it 12:50 < luke-jr> no, it isn't absurd. Core ethically must do what the community wants or nothing at all. 12:50 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has quit [Quit: Connection closed] 12:51 <@michaelfolkson> We have the community supporting ST. You seem to think that one small change to that proposal and all the ACKs are invalidated. Again I think is absurd 12:51 < luke-jr> I'm not saying the current PR must be kept as-is, but the criteria isn't "when Core decides to merge it" 12:51 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has joined ##taproot-activation 12:52 < rusty> michaelfolkson: sorry, I have another meeting. Thanks for running this, I think you're a legend :) 12:52 <@michaelfolkson> I think we are in good shape with Andrew's Core PR. But whether it gets merged in 2 weeks, 3 weeks, 4 weeks I have no idea 12:52 < luke-jr> michaelfolkson: my point is that shouldn't matter 12:52 <@michaelfolkson> Thanks rusty, see ya 12:52 <@michaelfolkson> luke-jr: It does if we care about incompatibility between ST and UASF 12:53 <@michaelfolkson> (which we should) 12:54 <@michaelfolkson> A delay of a few weeks is fine. UASF should work around that. If the delay becomes months instead then it is a different discussion 12:55 < rgrant> I also have to drop. I would like to propose that we have enough consensus on the topic to shift these meetings to only considering pull requests. I think that if people have vague concerns that they will not dissolve them without commenting on specific pull requests or proposing their own. 12:55 <@michaelfolkson> I'd prefer there was a focus on getting Andrew's Core PR(s) reviewed and merged. Then we are closer to getting parameters and dates finalized 12:56 <@michaelfolkson> That makes it much easier for UASF to work around it then 12:56 < luke-jr> more pressing issue, is that elector wants to keep the existing schedule 12:56 <@michaelfolkson> So is that two of you? 12:56 < luke-jr> everyone else seems okay with working around ST 12:56 < luke-jr> one afaict 12:57 <@michaelfolkson> Not you luke-jr? 12:57 < luke-jr> michaelfolkson: no, like I said from the start, I think unless we have a release this week, the 1y plan needs to shift 12:57 <@michaelfolkson> Ok cool 12:57 < luke-jr> michaelfolkson: I like roconnor's idea to enclose ST 12:58 <@michaelfolkson> elector's view is noted. As is Rusty's NACK for ST. At the moment they seem to be extreme minority opinions 12:58 < luke-jr> michaelfolkson: but I'm also not okay with Core dictating stuff 12:58 < luke-jr> michaelfolkson: I'd still like to hear from elector what he thinks about the enclosed-ST variant 12:58 < roconnor> I still don't get rusty's NACK. Saying that something else would be better isn't actually a NACK. 12:58 < luke-jr> was rusty's an actual NACK? or just a preference to do otherwise? 12:59 <@michaelfolkson> I mean "extreme" as in very small rather than excessively stubborn/wrong 12:59 -!- AsILayHodling [d0402051@208.64.32.81] has quit [Quit: Connection closed] 12:59 < rusty> It was an actual NACK. I even used that word, so that it would be clear (though I generally avoid it!) 12:59 -!- Swarleys [d5c371cc@213.195.113.204] has quit [Quit: Connection closed] 13:00 < roconnor> Noted. But saying something else is better isn't actually a NACK, though you are of course welcome to label things however you like. 13:00 < luke-jr> rusty: is the NACK sustained even if we do roconnor's idea in a BA release first? 13:00 < elector> if we're changing the timetable then we still have time to debate 13:00 < luke-jr> elector: yes, depending on how much time :p 13:00 < luke-jr> elector: are you okay with that then? 13:01 < elector> I assume you want to push it by 6 months? 13:01 < luke-jr> elector: August -> November is 3 months 13:01 <@michaelfolkson> For those that support ST and are happy with the plan/proposal/parameters I'd encourage you to look at, review, test achow101 PR https://github.com/bitcoin/bitcoin/pull/21392 13:01 < jeremyrubin> hi 13:01 < luke-jr> hi jeremyrubin 13:01 < rgrant> roconnor: "Saying that something else would be better" -> yeah that's why we should move to pull requests only. 13:01 < jeremyrubin> I think w.r.t. what rusty is saying it's hard to know a parachute will work till you are already out of the plane 13:02 <@michaelfolkson> With all respect to elector, it is a single individual within an extremely large community 13:02 < jeremyrubin> I think our hands are tied to actually pre-plan what should happen when we are in a circumstance we don't expect 13:02 < elector> this is not a democracy though 13:02 < luke-jr> michaelfolkson: we don't know that 13:02 < prayank> michaelfolkson: Thanks for the link. Sorry joined late. But just read we have few NACKs on ST now or is it just from Rusty? 13:03 <@michaelfolkson> Same goes for rusty (despite rusty being a very well informed long term contributor and community member) 13:03 < luke-jr> michaelfolkson: with only a N samples, 1 sample could just as well be 1/Nth of the community 13:03 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left ##taproot-activation [] 13:03 < jeremyrubin> I do think rusty's concern is legitimate, but I don't think we can actionably pack a chute in this circumstance -- maybe we can try doing a soft fork that intentionally fails to gain experience? 13:04 < luke-jr> I agree with rusty's concern, but I don't think it's NACK-level; it's a gamble, which could very well also result in a different outcome 13:04 < jeremyrubin> but that seems out of scope for taproot 13:04 <@michaelfolkson> prayank: Just from Rusty and an individual called PubPete who didn't give further context behind his NACK 13:05 < luke-jr> what I said to BlueMatt also applies: there will be more softforks in the future 13:05 < jeremyrubin> Also Rusty's nack is not a "this is broken" it's a "X would be better" 13:05 < jeremyrubin> if it were a "this a broken" it would be appropriate to freeze 13:05 <@michaelfolkson> prayank: We have a few non-committals. And a few provisional/tentative ACKs. But so far just Rusty and PubPete who have literally NACKed 13:06 <@michaelfolkson> prayank: Which is incredible (and surely will not stay that way for long) 13:06 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation [] 13:06 -!- dome [~e-mod@50-205-60-6-static.hfc.comcastbusiness.net] has joined ##taproot-activation 13:06 <@michaelfolkson> Gist is here (once again): https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f 13:07 <@michaelfolkson> I don't think I have anymore to say so I think I'll leave too. As I've said many times, please comment on the gist, please look at achow101 PR. 13:08 <@michaelfolkson> I think that PR stands best chance of being merged into Core at this point (though I've been wrong in the past and could be wrong again) 13:09 <@michaelfolkson> And if you prefer Twitch to GitHub I can strongly recommend achow101 Twitch session coding the PR up https://www.twitch.tv/videos/941955839 13:09 <@michaelfolkson> Truly excellent 13:09 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation 13:09 <@michaelfolkson> OK adieu from me. Feel free to continue discussion 13:09 < bitentrepreneur> ciao 13:09 < bitentrepreneur> thanks 13:09 < dome> Thanks Michael 13:10 <@michaelfolkson> #endmeeting 13:10 < prayank> michaelfolkson: Thanks 13:10 < proofofkeags> ...and I missed it 13:10 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has quit [Quit: Connection closed] 13:10 < proofofkeags> daylight savings time is a wretched construction 13:10 -!- r251d [~r251d@50.121.84.2] has quit [Quit: r251d] 13:11 < elector> you haven't missed much 13:11 < OP_NOP> Meeting time was specified in UTC... 13:11 < luke-jr> we didn't get to the 3rd agenda topic :< 13:11 < proofofkeags> OP_NOP: for sure, I'm just a dumbass 13:11 * luke-jr pokes elector for an answer <.< 13:11 < OP_NOP> proofofkeags: Story of my life 13:12 < elector> luke-jr: q? 13:12 < luke-jr> proofofkeags: there's still work to be done! :D 13:12 < luke-jr> [19:46:34] elector: what do you think of that adjusted plan? essentially May 1st - Nov 2022 MASF, activating no earlier than Nov 2021, and UASF after Nov 2022) 13:12 < luke-jr> eg https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/3/files#diff-e43ac101b32b6804209cfdf26da4d122e54b994eb7f1538d4378f6a508dab817L529 13:13 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has quit [Quit: Connection closed] 13:13 < elector> not delighted but I have to ok it 13:13 < proofofkeags> luke-jr am I to understand that theres essentially a LOT=true activation direct appended to the ST attempt? 13:14 < proofofkeags> *directly 13:14 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has joined ##taproot-activation 13:14 < luke-jr> elector: eh, you don't *have* to, but IMO it'd make things less dramatic 13:14 -!- Alexandre_Chery [9466a2bc@148.102.162.188] has quit [Client Quit] 13:14 < luke-jr> proofofkeags: yes; it's possible to have 2 activations, but ugly in various ways 13:14 < luke-jr> proofofkeags: just extending ST to 15 months and setting LOT seems cleaner 13:15 < elector> right, I kinda though, my objecting to it would not make a difference 13:15 < luke-jr> elector: depends on how many others agree with you 13:16 < luke-jr> elector: and how much effort you (plural) are willing to put into it 13:16 < luke-jr> elector: we would have already had a software release with the current plan by now, but nobody is willing to do the work.. :/ 13:16 < elector> the working meaning what? 13:17 < elector> work* 13:17 < elector> what caused the delay? 13:17 < proofofkeags> sorry for missing the meeting so let me know if my catch up questions are not appropriate for the forum, but iiuc there seems to be support within Core for an ST activation attempt, and most of them would consider a followup UASF, however, if a single deployment carries ST >> L=T deployment is that going to prevent consensus? 13:17 < luke-jr> elector: merging pull requests into the BitcoinActivation repo, making the decisions for it, deciding to release 13:17 < luke-jr> elector: I'm willing to hand-hold/teach, build, etc, but not to do everything 13:18 < luke-jr> proofofkeags: if it does, does it matter? 13:18 < luke-jr> proofofkeags: ST is unacceptable without the followup L=T… it only has near-consensus IF we do that 13:19 < elector> I actually stayed out of it to see if you guys can come to a consensus 13:19 < proofofkeags> I get that in principle, but a lot of people seem to be married to the charade of having some sort of cooldown period in between the hypothetical ST failure and a movement on L=T 13:20 < proofofkeags> and ST was supposed to be some sort of compromise attempt, and packaging an L=T deployment alongside it can be interpreted as bad faith and kill consensus even around ST 13:20 < luke-jr> proofofkeags: those people will probably run Core with just ST 13:20 < luke-jr> proofofkeags: but ST doesn't have consensus without that 13:21 < luke-jr> besides, it sounds like even Matt was okay with it 13:21 < proofofkeags> OK, so iiuc, this is like the same plan as before 13:21 < proofofkeags> but with ST first 13:21 < luke-jr> yes 13:21 < luke-jr> and we have to shift the timeline a bit 13:21 < proofofkeags> I can live with slipping of timelines 13:21 < luke-jr> elector: community support is separate from the work to release IMO 13:22 < prayank> luke-jr: I was assuming we don't need L=T anymore at least during ST according to https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09620.html 13:22 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation 13:23 < luke-jr> prayank: L=T only has any effect right before timeout 13:23 < luke-jr> prayank: in this case, 12 months after the ST part ends 13:24 < prayank> Okay 13:24 < elector> luke-jr: right, but theres something else going on 13:24 < luke-jr> elector: ? 13:25 < elector> luke-jr: anyway, isn't BitcoinActivation about UASF? 13:25 -!- lucasmoten_ [~lucasmote@136.144.35.169] has joined ##taproot-activation 13:26 < luke-jr> elector: it still is? 13:26 < luke-jr> and not really; it's BIP8 which is MASF+UASF 13:26 < elector> so LOT=true ? 13:26 < luke-jr> yes 13:27 < luke-jr> the 3 month delayed variant, just puts ST as the start of the MASF part 13:28 < luke-jr> so after 3 months, ST-only nodes will give up, while BA nodes will continue another year and end with a UASF 13:28 -!- lucasmoten [~lucasmote@136.144.35.169] has quit [Ping timeout: 265 seconds] 13:29 -!- fiach_dubh [ac532846@172.83.40.70] has quit [Quit: Connection closed] 13:29 < proofofkeags> the problem I foresee here, is that after a failed ST, core will likely genuinely support some sort of UASF, but the fact that BA already has one in flight at that time will make things quite messy 13:29 < luke-jr> if there are many people who dislike the delay, we *could* reasonably keep the timeoutheight unchanged I suppose 13:30 < luke-jr> proofofkeags: only if Core maliciously conflicts with it 13:30 < prayank> luke-jr: Why one year and not something less? 13:30 < luke-jr> prayank: because by the UASF deadline, it will be imporant for the *entire* economy to have upgraded 13:30 < luke-jr> another reason: it gives Core time to adapt and release the same params 13:31 < proofofkeags> in order for a UASF to have any chance of succeeding it needs to have campaign time 13:31 < luke-jr> proofofkeags: which should start now IMO 13:31 < luke-jr> Core can release ST-only, but we should encourage people to upgrade straight to Core+Taproot with the whole deal 13:32 < proofofkeags> luke-jr: assuming core does want to release compatible params after, is it safe to have the BA deployment immediately kick into an L=T deployment 13:33 < luke-jr> proofofkeags: yes 13:33 -!- friendly_arthrop [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has joined ##taproot-activation 13:34 < luke-jr> (if it wasn't, ST alone would be broken too :P) 13:35 < proofofkeags> yeah, I suppose 13:35 -!- prayank [~andr0irc@2401:4900:30d2:dd44:6d14:3f85:cf7d:24e9] has quit [Ping timeout: 244 seconds] 13:36 -!- prayank [~andr0irc@2401:4900:30df:4b1c:6d14:3f85:cf7d:24e9] has joined ##taproot-activation 13:38 < luke-jr> elector: in any case, it would be nice to have some resolution, so BA can move forward to release *something* :P 13:38 < proofofkeags> I suppose the concern I have is that if we don't include a "cooldown" period in between, Core might be actively discouraged from releasing a UASF variant at all due to a rushed schedule. Maybe someone might start working on the necessary changes during the ST period though and have a UASF client ready at ST expiration, though I'm not optimistic that is the case 13:38 -!- odell [c6368468@static-198-54-132-104.cust.tzulo.com] has quit [Quit: Connection closed] 13:38 < luke-jr> proofofkeags: there is an inherent cooldown already in the min activation height 13:39 < luke-jr> proofofkeags: also, again, the UASF client is what we should release this week or soon 13:39 < elector> I'm thinking... 13:39 < roconnor> proofofkeags: I totally agree with you I think Core will need upto 6 months to release a LOT=true client after an ST failure and will want a 1 year runway beyond that. 13:40 < luke-jr> elector: sorry to rush you; I just would prefer to avoid the conversation ending without some resolution 13:40 < proofofkeags> roconnor: that's what I was thinking 13:40 < luke-jr> roconnor: sigh 13:41 < luke-jr> at that point we're back to "Bitcoin does not revolve around Core" IMO 13:41 < luke-jr> if it needs 6 months, it should just release the whole thing upfront 13:41 < elector> luke-jr: I think the resolution is that we should move forward, and possibly release by the end of month 13:41 < luke-jr> elector: but is the 3 month delay okay for that? 13:42 < elector> luke-jr: what delay, the initial timetable was release 17-31March 13:43 < luke-jr> elector: ok, so you still want to do the initial timetable 13:43 < proofofkeags> luke-jr: I appreciate the level of effort you're putting in to make the issue move, I just don't think the *actual* timeline is as important as progress. If we don't give Core the opportunity to come to consensus, then you're essentially holding a referendum on what the new reference client is, which is a pretty serious campaign to run. One that really can't be done on a rushed schedule. 13:43 < luke-jr> proofofkeags: Core+Taproot is still Core at the end of the day 13:43 < luke-jr> proofofkeags: also, there is no reference client at this point 13:43 < elector> yea thats what I was toying with, I think we should fork and release lot=true 13:44 < luke-jr> proofofkeags: we're looking at less than 2 months for ST; 3 months should be enough for Core to get back on track after ST 13:45 < proofofkeags> maybe I mistook the diff here but I thought there was no delay between the timeout height of ST and the start of the L=T period 13:45 < luke-jr> proofofkeags: but there is still the min_activation_height from ST 13:45 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has quit [Ping timeout: 244 seconds] 13:45 < luke-jr> after ST timeoutheight, there's 3 months before it would activate (or not) 13:46 -!- nija [5410eb84@84.16.235.132] has quit [Quit: Connection closed] 13:46 < proofofkeags> ahh 13:46 < luke-jr> that doesn't go away after ST, even with a longer timeoutheight 13:46 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has joined ##taproot-activation 13:47 < luke-jr> (because if it did, that would encourage miners to wait until ST ends to signal) 13:47 < proofofkeags> I need to reread the terms of ST 13:48 < luke-jr> brb 13:50 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has quit [Client Quit] 13:52 -!- friendly_arthrop [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has quit [Quit: Connection closed] 13:55 < AsILayHodling> luke-jr do I understand correctly that, if ST is a go, you believe it'd be best to have code for a L=T scenario ready to go BEFORE the May start time just in case? 14:19 < elector> proofofkeys: I think thats exactly what needs to happen, I'm not thrilled by the politics 14:25 < luke-jr> AsILayHodling: ready to go, AND being adopted 14:25 < luke-jr> AsILayHodling: ie, the same code should be used for ST 14:25 < AsILayHodling> So packaged together? 14:25 < luke-jr> yes 14:25 < luke-jr> people want Taproot, they upgrade to Core+Taproot that supports both 14:27 < AsILayHodling> ok that makes logical sense to me. one bit of confusion, though: you believe that LOT=T should be included in the release of ST, but you believe that a true UASF should be developed outside of Core if users wish to deploy it correct? 14:27 < AsILayHodling> Do I also understand this correctly? 14:28 <@michaelfolkson> AsILayHodling: In an ideal world Luke would like a UASF release with ST and then BIP 8(true,1year) if ST fails packaged together. The ST part would be fully compatible with the Core ST 14:29 < luke-jr> AsILayHodling: LOT=True is a true UASF 14:29 <@michaelfolkson> The LOT=true is unlikely to get merged and released by Core too (imo and I think in Luke's opinion too) 14:29 < luke-jr> michaelfolkson: in an ideal world, Core would just release BIP8(1y,T) and we'd be done :P 14:29 <@michaelfolkson> Ha 14:29 < luke-jr> michaelfolkson: after ST fails, hopefully Core will follow up with a full release 14:29 <@michaelfolkson> Different levels of ideal 14:30 < AsILayHodling> Yeah I guess that's where I'm confused luke-jr because I thought you said you believe UASF should not be pushed by Core if users don't agree with it? 14:31 < luke-jr> AsILayHodling: if users didn't agree with Taproot 14:31 < AsILayHodling> Ahhhh ok got it 14:31 < AsILayHodling> Thanks, that clears it up 14:31 <@michaelfolkson> We're using "UASF" as "alternative to Core or community release" here 14:31 < AsILayHodling> got it 14:32 < luke-jr> I'm not. 14:32 <@michaelfolkson> I guess it wouldn't make much sense for UASF to release BIP 8(false) though 14:32 <@michaelfolkson> It could in theory if Core didn't release anything and that is what the community wanted 14:33 <@michaelfolkson> In theory the UASF could release a BIP 8(false). It wouldn't have community consensus though 14:33 < luke-jr> BIP8(False) is by definition not a UASF 14:34 <@michaelfolkson> Just an argument about semantics I think. In a theoretical world where the entire community wanted a BIP 8(false) and Core didn't deliver it, a community release could be BIP 8(false) 14:35 <@michaelfolkson> I get it probably shouldn't be called UASF in that case 14:45 < luke-jr> simplified summary of params: https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit?usp=sharing 14:50 -!- Nicap52 [5d6819eb@ppp-93-104-25-235.dynamic.mnet-online.de] has quit [Quit: Connection closed] 14:50 < AsILayHodling> luke-jr for clarity: the third column with the "ST compatible" parameter--this includes the UASF? And the first column for 2021-22 plan is BIP 8 with LOT=True? 14:50 < luke-jr> AsILayHodling: right 14:50 < AsILayHodling> Word, thank you 14:50 < luke-jr> both 2021-02 and 2021-03 are BIP8(LOT=True) 14:50 < luke-jr> but the latter is ST-compatible 14:51 < AsILayHodling> Are there any dangers with ST compatible UASF? Does it carry similar split risks as BIP8 False? 14:51 < luke-jr> not so long as ST-only is released with a proper explanation that it is a "try and see" and expected to have a followup 14:52 < AsILayHodling> Ok so one of the risks is the "wait I have to activate again?" confusion you mentioned a while back? 14:52 -!- jonatack_ [~jon@37.171.42.2] has joined ##taproot-activation 14:53 < luke-jr> right, except this time users are told to expect it (or just upgrade to Core+Taproot to begin with) 14:54 < AsILayHodling> (y) 14:56 -!- jonatack [~jon@37.165.122.66] has quit [Ping timeout: 264 seconds] 15:00 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed] 15:04 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection] 15:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 15:14 -!- bitentrepreneur [uid39920@gateway/web/irccloud.com/x-fjahzivhcnduxzrn] has quit [Quit: Connection closed for inactivity] 15:26 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 15:35 -!- Netsplit *.net <-> *.split quits: queip, AaronvanW 15:37 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 15:40 -!- prayank [~andr0irc@2401:4900:30df:4b1c:6d14:3f85:cf7d:24e9] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 15:44 -!- stortz [c8b9cbcf@200.185.203.207] has joined ##taproot-activation 16:08 -!- peterrizzo_1 [44c18924@ool-44c18924.dyn.optonline.net] has quit [Quit: Connection closed] 16:08 -!- dome [~e-mod@50-205-60-6-static.hfc.comcastbusiness.net] has quit [Ping timeout: 265 seconds] 16:14 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 16:15 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 16:24 -!- sdfsdfsdfssdf [ad1eb8d2@173-30-184-210.client.mchsi.com] has joined ##taproot-activation 16:27 -!- sdfsdfsdfssdf [ad1eb8d2@173-30-184-210.client.mchsi.com] has quit [Client Quit] 17:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:28 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 265 seconds] 18:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 18:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 19:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 19:56 -!- stortz [c8b9cbcf@200.185.203.207] has quit [Quit: Connection closed] 20:09 -!- mobintaneh [2ea6b894@46.166.184.148] has joined ##taproot-activation 20:10 -!- mobintaneh [2ea6b894@46.166.184.148] has quit [Client Quit] 20:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 21:08 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 21:11 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds] 21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 21:21 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 21:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds] 21:23 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds] 21:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 21:48 -!- shesek` [~shesek@164.90.217.137] has joined ##taproot-activation 21:52 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 264 seconds] 21:54 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-irngybgfmgpzypua] has quit [Quit: ZNC 1.8.2 - https://znc.in] 22:00 -!- jonatack_ [~jon@37.171.42.2] has quit [Ping timeout: 256 seconds] 22:09 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-qcfpgmsncdtvtiio] has joined ##taproot-activation 22:49 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 22:50 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation 23:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 23:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] 23:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 23:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] --- Log closed Wed Mar 17 00:00:58 2021