--- Log opened Tue Mar 23 00:00:04 2021
01:06 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:07 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
01:07 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
01:07 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
01:15 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
01:16 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
01:21 -!- jonatack_ [~jon@37.165.23.76] has joined ##taproot-activation
01:23 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
01:25 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:18 -!- jonatack_ [~jon@37.165.23.76] has quit [Quit: jonatack_]
02:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
02:53 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 256 seconds]
03:03 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
03:14 -!- pigeons [~pigeons@androzani.sysevolve.com] has quit [Ping timeout: 264 seconds]
03:17 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
03:24 -!- provoostenator_ [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
03:25 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
03:26 -!- jonatack [~jon@37.165.23.76] has joined ##taproot-activation
03:31 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
03:37 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
03:38 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Ping timeout: 272 seconds]
03:38 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
04:12 <@michaelfolkson> Re flexibility with the timetable. I think the proposed startheight and timeoutheight could be pushed back a couple of weeks whilst keeping the same min activation height. Thoughts?
04:12 <@michaelfolkson> This would just shrink the time between the timeoutheight and the min activation height
04:14 <@michaelfolkson> From 3 months to 2.5 months. I don't think that time between timeoutheight and min activation height is that critical.
04:32 -!- jonatack [~jon@37.165.23.76] has quit [Ping timeout: 240 seconds]
04:32 -!- jonatack [~jon@37.165.23.76] has joined ##taproot-activation
04:38 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds]
04:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:42 -!- jonatack_ [~jon@37.165.23.76] has joined ##taproot-activation
04:42 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
04:42 -!- jonatack_ [~jon@37.165.23.76] has quit [Read error: Connection reset by peer]
04:42 -!- jonatack [~jon@37.165.23.76] has quit [Read error: Connection reset by peer]
04:43 -!- jonatack_ [~jon@37.165.23.76] has joined ##taproot-activation
04:46 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-regukkmmqhmknzvr] has left ##taproot-activation ["User left"]
04:48 -!- jonatack_ [~jon@37.165.23.76] has quit [Read error: Connection reset by peer]
04:48 -!- jonatack__ [~jon@37.165.23.76] has joined ##taproot-activation
05:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
05:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
05:05 -!- stortz [c8b9cbcf@unaffiliated/stortz] has joined ##taproot-activation
05:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
05:18 -!- roconnor [~roconnor@host-45-58-230-226.dyn.295.ca] has joined ##taproot-activation
05:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
05:29 -!- jonatack__ [~jon@37.165.23.76] has quit [Ping timeout: 264 seconds]
05:45 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
05:45 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
05:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
05:58 -!- jonatack [~jon@37.165.23.76] has joined ##taproot-activation
06:05 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
06:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
06:52 -!- Alexandre_Chery [946692c4@148.102.146.196] has joined ##taproot-activation
06:54 -!- Alexandre_Chery [946692c4@148.102.146.196] has quit [Client Quit]
07:18 -!- adiabat_ [~adiabat@63.209.32.102] has quit [Ping timeout: 256 seconds]
07:30 -!- common [~common@unaffiliated/common] has quit [Remote host closed the connection]
07:30 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
07:32 -!- common [~common@unaffiliated/common] has quit [Read error: Connection reset by peer]
07:33 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
07:46 -!- jonatack [~jon@37.165.23.76] has quit [Ping timeout: 264 seconds]
07:48 -!- CARO1 [~Cesar@177.18.110.65] has quit [Read error: Connection reset by peer]
07:50 -!- jonatack [~jon@37.165.23.76] has joined ##taproot-activation
08:13 -!- adiabat_ [~adiabat@63.209.32.102] has joined ##taproot-activation
08:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:29 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
08:34 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 260 seconds]
08:35 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-reikaeljmctsmgsy] has quit [Ping timeout: 265 seconds]
08:35 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 248 seconds]
08:35 -!- bob333_ [~bob@46.28.204.21] has quit [Ping timeout: 245 seconds]
08:35 -!- sturles [~sturles@unaffiliated/sturles] has joined ##taproot-activation
08:36 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-ofhjocytdelbzosq] has quit [Ping timeout: 240 seconds]
08:37 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ynqouhvuqnikmhoj] has quit [Ping timeout: 240 seconds]
08:37 -!- bob333 [~bob@46.28.204.21] has joined ##taproot-activation
08:38 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has quit [Ping timeout: 265 seconds]
08:38 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has joined ##taproot-activation
08:47 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
08:52 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined ##taproot-activation
08:52 -!- pigeons is now known as Guest77909
08:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
08:55 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-ereijbatrlhojoxa] has joined ##taproot-activation
08:58 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-tdrnzokykoubckzx] has joined ##taproot-activation
08:58 -!- CARO2 [~Cesar@2804:7f4:c19f:cde8:e931:72dd:eafd:b9a] has joined ##taproot-activation
09:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
09:08 -!- stortz [c8b9cbcf@unaffiliated/stortz] has quit [Quit: Connection closed]
09:13 -!- stortz [c8b9cbcf@unaffiliated/stortz] has joined ##taproot-activation
09:14 < jeremyrubin> michaelfolkson: that sounds reasonable to me
09:15 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-wkeizfzjpcqneuho] has joined ##taproot-activation
09:20 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
09:25 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
09:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
09:46 -!- RelayCat [~relaycat@gateway/tor-sasl/relaycat] has joined ##taproot-activation
09:58 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
09:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
10:01 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
10:01 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
10:01 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
10:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:27 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
10:49 -!- belcher_ is now known as belcher
10:52 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation
11:01 -!- Alexandre_Chery [9466b34d@148.102.179.77] has joined ##taproot-activation
11:05 -!- Alexandre_Chery [9466b34d@148.102.179.77] has quit [Client Quit]
11:10 -!- aperson [b9c3e886@185.195.232.134] has joined ##taproot-activation
11:11 -!- aperson is now known as Guest99747
11:12 < Guest99747> Is this where the Speedy Trial activation discussion is being held at 19:00 UTC?
11:13 < luke-jr> yes
11:13 < Guest99747> Cheers
11:16 -!- Alistair_Mann [1f3396fd@host31-51-150-253.range31-51.btcentralplus.com] has joined ##taproot-activation
11:17 -!- prayank [~Prashant_@2401:4900:30de:f516:699a:b03e:1b3a:254f] has joined ##taproot-activation
11:18 -!- doitnow [ae17a858@174-23-168-88.slkc.qwest.net] has joined ##taproot-activation
11:19 -!- zeph [4e66b052@ip-78-102-176-82.net.upcbroadband.cz] has joined ##taproot-activation
11:20 -!- prayank1 [~Prashant_@2401:4900:30de:f516:849:5f6b:d99b:40d9] has joined ##taproot-activation
11:20 -!- bitcoinaire [5ad8ccbf@90.216.204.191] has joined ##taproot-activation
11:20 < bitcoinaire> Yo
11:21 -!- prayank [~Prashant_@2401:4900:30de:f516:699a:b03e:1b3a:254f] has quit [Ping timeout: 240 seconds]
11:22 -!- bitcoinaire [5ad8ccbf@90.216.204.191] has quit [Client Quit]
11:22 -!- Guest99747 [b9c3e886@185.195.232.134] has quit [Ping timeout: 240 seconds]
11:23 -!- xsat [621a4191@cpe-98-26-65-145.nc.res.rr.com] has joined ##taproot-activation
11:23 -!- brunog [bbb72f44@187.183.47.68] has joined ##taproot-activation
11:24 -!- livestream-jerm [18b0f7b6@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
11:25 -!- ryanthegentry [883195f5@136.49.149.245] has joined ##taproot-activation
11:25 -!- giaki3003 [b9b25ffe@185.178.95.254] has joined ##taproot-activation
11:26 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
11:26 -!- FreeeZy00 [5ff47b73@host-95-244-123-115.retail.telecomitalia.it] has joined ##taproot-activation
11:27 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
11:27 -!- raucao [~raucao@2a03:b0c0:2:f0::ff:e001] has joined ##taproot-activation
11:27 -!- adfffdddsaeevv [2f9d7da2@47.157.125.162] has joined ##taproot-activation
11:27 -!- lightlike [~lightlike@p200300c7ef1ca90089ae1ec809ac3f97.dip0.t-ipconnect.de] has joined ##taproot-activation
11:28 -!- oxtr [~tommy@13.84-234-189.customer.lyse.net] has joined ##taproot-activation
11:28 -!- prayank1 [~Prashant_@2401:4900:30de:f516:849:5f6b:d99b:40d9] has left ##taproot-activation []
11:29 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has joined ##taproot-activation
11:32 -!- Lester [aef85acf@207.sub-174-248-90.myvzw.com] has joined ##taproot-activation
11:33 -!- mememe [6b4dc606@mobile-107-77-198-6.mobile.att.net] has joined ##taproot-activation
11:35 -!- landeau [bbbd94a0@fixed-187-189-148-160.totalplay.net] has joined ##taproot-activation
11:36 -!- mojalai [47de2425@71-222-36-37.lsv2.qwest.net] has joined ##taproot-activation
11:36 -!- zeph [4e66b052@ip-78-102-176-82.net.upcbroadband.cz] has quit [Quit: Connection closed]
11:36 -!- makriath [acdae048@d172-218-224-72.bchsia.telus.net] has joined ##taproot-activation
11:37 -!- zeph [4e66b052@ip-78-102-176-82.net.upcbroadband.cz] has joined ##taproot-activation
11:38 -!- Zoltan [d460228f@catv-212-96-34-143.catv.broadband.hu] has joined ##taproot-activation
11:38 -!- Zoltan is now known as Guest24822
11:41 -!- Lester [aef85acf@207.sub-174-248-90.myvzw.com] has quit [Ping timeout: 240 seconds]
11:41 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has joined ##taproot-activation
11:42 -!- Lester [aef85acf@207.sub-174-248-90.myvzw.com] has joined ##taproot-activation
11:42 -!- entropyhappens [490e0a27@c-73-14-10-39.hsd1.co.comcast.net] has joined ##taproot-activation
11:42 -!- ere [b09902cb@176-153-2-203.abo.bbox.fr] has joined ##taproot-activation
11:43 -!- epson121 [d595335f@213.149.51.95] has joined ##taproot-activation
11:44 -!- rumm [c1bb5b1a@193.187.91.26] has joined ##taproot-activation
11:44 -!- thebitcoinrabbi [43f8563b@cpe-67-248-86-59.nycap.res.rr.com] has joined ##taproot-activation
11:44 -!- mememe [6b4dc606@mobile-107-77-198-6.mobile.att.net] has quit [Ping timeout: 240 seconds]
11:48 -!- ndalliard [b2c7e972@114.233.199.178.dynamic.wline.res.cust.swisscom.ch] has joined ##taproot-activation
11:49 -!- rumm [c1bb5b1a@193.187.91.26] has quit [Quit: Connection closed]
11:49 -!- gr-g [4dbd19eb@x4dbd19eb.dyn.telefonica.de] has joined ##taproot-activation
11:49 -!- Elkim [b9d59ba1@185.213.155.161] has joined ##taproot-activation
11:50 -!- thebitcoinrabbi [43f8563b@cpe-67-248-86-59.nycap.res.rr.com] has quit [Ping timeout: 240 seconds]
11:51 -!- pzi_onic89 [b230a2e3@catv-178-48-162-227.catv.broadband.hu] has joined ##taproot-activation
11:51 -!- Lester [aef85acf@207.sub-174-248-90.myvzw.com] has quit [Ping timeout: 240 seconds]
11:51 -!- HotWax [592de0dd@89.45.224.221] has joined ##taproot-activation
11:52 <@michaelfolkson> Meeting agenda is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html
11:52 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined ##taproot-activation
11:52 <@michaelfolkson> Starting in less than 10 minutes, jeremyrubin hosting
11:52 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has joined ##taproot-activation
11:52 -!- Memes [498b3b1b@c-73-139-59-27.hsd1.fl.comcast.net] has joined ##taproot-activation
11:53 -!- Memes [498b3b1b@c-73-139-59-27.hsd1.fl.comcast.net] has quit [Client Quit]
11:53 -!- Memesan [498b3b1b@c-73-139-59-27.hsd1.fl.comcast.net] has joined ##taproot-activation
11:54 -!- HotWax [592de0dd@89.45.224.221] has quit [Client Quit]
11:54 -!- Alexandre_Chery [9466b34d@148.102.179.77] has joined ##taproot-activation
11:55 -!- pzi_onic89 [b230a2e3@catv-178-48-162-227.catv.broadband.hu] has quit [Client Quit]
11:55 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has quit [Client Quit]
11:55 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has quit [Quit: Connection closed]
11:57 -!- Antoine50 [cfe48d5a@207.228.141.90] has joined ##taproot-activation
11:57 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has joined ##taproot-activation
11:58 -!- Guest3999 [2d8138c5@45.129.56.197] has joined ##taproot-activation
11:58 -!- Guest3999 [2d8138c5@45.129.56.197] has quit [Client Quit]
11:58 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has quit [Client Quit]
11:59 <@michaelfolkson> You here jeremyrubin?
11:59 < jeremyrubin> yep
11:59 <@michaelfolkson> Cool
11:59 < jeremyrubin> just setting up stream
11:59 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has joined ##taproot-activation
11:59 < stortz> stream?
11:59 -!- nicy [2d8138c5@45.129.56.197] has joined ##taproot-activation
12:00 -!- prepaid [~prepaid@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation
12:01 < jeremyrubin> #startmeeting
12:01 < prepaid> hi
12:01 < emzy> hi
12:01 < AaronvanW> hi
12:01 < rgrant> hi
12:01 <@michaelfolkson> hi
12:01 < OP_NOP> hi
12:01 < stortz> hi
12:01 < prayank> hi
12:01 < Alistair_Mann> hi
12:01 < amiti> hi
12:01 < luke-jr> hi
12:01 < kanzure> hi
12:01 < Memesan> hi
12:02 < jeremyrubin> Cool :)
12:02 < jeremyrubin> welcome all
12:02 <@michaelfolkson> Feel free to say hi even if you're just lurking
12:02 < jeremyrubin> So as noted by michaelfolkson, you can review the agenda here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html
12:02 < epson121> hi
12:02 < gr-g> hi
12:02 -!- Satya [b9c3e89e@185.195.232.158] has joined ##taproot-activation
12:02 < Guest24822> hi
12:02 < jeremyrubin> I'm also hosting a stream on twitch for anyone who prefers to consume that way
12:02 < cguida> hi
12:03 < jeremyrubin> I guess without further ado, let's start with topic 1
12:03 < landeau> hi
12:03 < achow101> hi
12:03 < jeremyrubin> #topic
12:03 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has joined ##taproot-activation
12:03 < jeremyrubin> Resolving any outstanding concerns around using a Speedy Trial to
12:03 < jeremyrubin> attempt to activate Taproot that must be addressed.
12:03 -!- Antoine50 [cfe48d5a@207.228.141.90] has quit [Quit: Connection closed]
12:03 -!- benthecarman [~benthecar@2600:1700:201:6e60:b985:235:37a:c677] has joined ##taproot-activation
12:03 -!- ndalliard [b2c7e972@114.233.199.178.dynamic.wline.res.cust.swisscom.ch] has quit [Quit: Connection closed]
12:03 -!- benthecarman [~benthecar@2600:1700:201:6e60:b985:235:37a:c677] has left ##taproot-activation []
12:03 < jeremyrubin> There are no pre-registered nacks for ST
12:04 < luke-jr> rusty NACK'd on the gist
12:04 < prepaid> did rusty NACK ST?
12:04 <@michaelfolkson> https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
12:04 -!- pzi_onic89 [b230a2e3@catv-178-48-162-227.catv.broadband.hu] has joined ##taproot-activation
12:04 -!- _6102bitcoin [59ee824d@89.238.130.77] has joined ##taproot-activation
12:04 < luke-jr> IMO ST is only okay so long as there is a plan for a regular BIP8 following it; but if that falls apart, I'm also a NACK
12:04 < luke-jr> plan and progress on*
12:04 -!- nicy [2d8138c5@45.129.56.197] has quit [Ping timeout: 240 seconds]
12:04 < luke-jr> but that's a crossover to topic 5
12:05 < BlueMatt> well i think outstanding concern needs to be against a concrete proposal, so far the proposal is "well, we may do height, or time, and here's some ideas for timeline, but also we haven't discussed it in detail, plus it depends on the code review timeline"
12:05 -!- benthecarman81 [6b8a186e@107-138-24-110.lightspeed.austtx.sbcglobal.net] has joined ##taproot-activation
12:05 < BlueMatt> but, concept wise there seems to be agreement outside of rusty, and, apparently luke-jr?
12:05 < jeremyrubin> BlueMatt: have you had a chance to review the agenda?
12:05 < achow101> BlueMatt: there is a proposal of specific block heights already
12:05 < luke-jr> BlueMatt: more of a conditional ACK from me
12:05 < BlueMatt> jeremyrubin: yes, I'm aware there is to be discussion on the parameter selection
12:06 < rgrant> I felt that ajtowns gave a good answer to rusty's concerns, and lacking further reasons, it settles the issue for me.  https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667989
12:06 < jeremyrubin> This is more if anyone is conceptual opposed to what harding proposed
12:06 < BlueMatt> achow101: and zero response to attempts to discuss it, at least from what I've seen, plus debate around height-vs-time, plus, last i heard, depends on the code review timeline
12:06 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
12:06 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has quit [Client Quit]
12:06 < prepaid> Is anyone opposed to harding's proposal?
12:06 -!- dirmyr [4b2901ae@75-41-1-174.lightspeed.austtx.sbcglobal.net] has joined ##taproot-activation
12:06 < devrandom> hi
12:06 < BlueMatt> otoh, it could be specified in terms of "time that release is ready + X blocks" instead of "block X"
12:06 < benthecarman81> hi
12:06 < luke-jr> I'm a hard NACK on time-based..
12:07 < BlueMatt> luke-jr: care to elaborate why?
12:07 < luke-jr> if there's a push for time-based, we should just go back to BIP8(True) without ST
12:07 < jeremyrubin> I think this is topic 2
12:07 <@michaelfolkson> Let's try to keep the agenda jeremyrubin has set
12:07 <@michaelfolkson> Time for these discussions later
12:07 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
12:07 <@michaelfolkson> (within this meeting)
12:07 < luke-jr> sorry
12:07 < jeremyrubin> Please keep to discussing general issues with ST (roughly, 3 months then +3 months fixed active time)
12:07 < BlueMatt> jeremyrubin: starting at bitcoin core release + X?
12:08 < BlueMatt> please define X
12:08 < luke-jr> BlueMatt: Bitcoin Core is not Bitcoin
12:08 < jeremyrubin> (topic 3)
12:08 < BlueMatt> jeremyrubin: my question was specific to your question, I'm not sure what the topic is, then...
12:08 < jeremyrubin> Ah -- well it's just sort of, afaict "as soon as the code is ready to go"
12:08 < prepaid> list of topics https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html
12:09 <@michaelfolkson> prepaid: There are two NACKs in that gist I linked to. Rusty and PubPete
12:09 < BlueMatt> anyway, it sounds like the one major disagreement for the *concept* is rusty, who isn't hear, which implies that discussion should continue offline
12:09 < jeremyrubin> I think that rusty's comment has been sufficiently addressed
12:09 < BlueMatt> does rusty think that?
12:09 < luke-jr> not last I checked
12:10 < BlueMatt> then that discussion should likely continue, it looks like rusty hasnt had a chance to respond to the responses from aj + michael.
12:10 < prepaid> michaelfolkson AFAICT pubpete didn't substantiate the NACK
12:10 < achow101> if we want rusty to join this meeting, we are probably going to have to move it later in the day
12:10 < jeremyrubin> It doesn't matter what rusty thinks, it matters whether or not it has been addressed sufficiently
12:10 -!- btcactivator [d98adbb7@217.138.219.183] has joined ##taproot-activation
12:10 < jeremyrubin> achow101: rusty had ample chance to pre-register a comment
12:10 < rgrant> BlueMatt: he didn't reply.  It's up to us to decide if his objection was handled well.
12:10 < BlueMatt> achow101: we dont have to hold meetings just to decide on things, he can respond offline....
12:10 <@michaelfolkson> I don't think we will ever have 100 percent agreement on an activation mechanism. I'm staggered we've got as much as we have with this proposal
12:10 < BlueMatt> rgrant: huh? he should get a chance to respond, its only been a few days
12:11 < cguida> Apologies if this is out of scope for the meeting: Is the activation height at 6 months after signaling up for debate? Could we instead do 3 months after lock-in?
12:11 < jeremyrubin> I'd also note that  rusty commented "Taproot could be activated by a blind monkey, but that doesn't mean we should do it that way. Getting it right this time means forming a model on how future soft forks are done."
12:11 < BlueMatt> michaelfolkson: yep! doesnt mean we shouldnt give people a chance to respon. that said, its not like we have to "wait" on him to respond, but certainly he can respond next week and it wont change anything
12:11 <@michaelfolkson> Next topic cguida
12:11 < rgrant> BlueMatt: a week?  That's pretty good.
12:11 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
12:11 < jeremyrubin> so he does not have an objection based around the safety of it
12:11 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
12:11 < BlueMatt> rgrant: lol, people are busy, yo
12:12 < btcactivator> What’s the consensus on activation right now?
12:12 -!- jbeddict [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has joined ##taproot-activation
12:12 < jeremyrubin> BlueMatt: well, he's neither at the meeting nor pre-reg'd a comment, nor a pre-reg'd comment to say he's too busy
12:12 < BlueMatt> btcactivator: well we dont have hard parameters, so lets see what happens on the next topics.
12:12 < jeremyrubin> ok
12:12 <@michaelfolkson> Until parameters are finalized (and perhaps even after) rusty has time to express his arguments
12:12 < jeremyrubin> ready to move on?
12:12 < BlueMatt> michaelfolkson: yes, thats what I said :)
12:13 < btcactivator> Sorry, just entered
12:13 < jeremyrubin> btcactivator: please review logs
12:13 < BlueMatt> rusty getting a chance to respond does not imply that a concrete proposal cant move forward towards implementation and concrete parameter selection.
12:13 < luke-jr> btcactivator: there seems to be common support for ST, provided [to part of the community] that it is followed by BIP8(true) should it fail
12:13 < jeremyrubin> There's never a hard cutoff for raising concerns
12:13 -!- thebitcoinrabbi3 [aecc8537@55.sub-174-204-133.myvzw.com] has joined ##taproot-activation
12:13 < BlueMatt> so, yes, lets move on, jeremyrubin
12:13 < jeremyrubin> I don't think at this juncture there are any concerns that should stop progress moving forward
12:14 < jeremyrubin> OK
12:14 -!- ClaudeNova [5204d218@cpc149476-cmbg20-2-0-cust535.5-4.cable.virginm.net] has joined ##taproot-activation
12:14 < jeremyrubin> #topic 2. Selecting between start/stop heights and times for a speedy trial.
12:14 -!- krs41 [53e91d3e@83-233-29-62.cust.bredband2.com] has joined ##taproot-activation
12:14 -!- Lester [aef85e9c@156.sub-174-248-94.myvzw.com] has joined ##taproot-activation
12:14 < jeremyrubin> Fortunately, no one is making the case for MTP for any technical reason with a pre-reg comment
12:14 < cguida> I thought we settled on heights
12:14 < jeremyrubin> We do not need to discuss the technical superiority of heights
12:14 <@michaelfolkson> jeremyrubin: This is specifically block heights versus MTP
12:15 < luke-jr> seems like achow101's Apr 30-Aug 6 activating Nov 12 is fin
12:15 < luke-jr> fine*
12:15 < jeremyrubin> Correct, we're discussing block vs MTP
12:15 < BlueMatt> MTP can be nice on a longer time horizon, but height isnt bad on a shorter time horizon
12:15 < achow101> at this point, either are reasonable imo. heights are technically better, but in terms of getting something through mtp may be
12:15 < jeremyrubin> The focus of this discussion should be focused on blocking reasons to not
12:15 < jeremyrubin> use time based parameters, the code review process, and timelines for being
12:15 < jeremyrubin> able to utilize either activation method.
12:15 < BlueMatt> it may be interesting to do *activation* on a MTP % x but signaling on a height
12:15 < prepaid> MTP = mediantimepast FYI
12:15 < luke-jr> achow101: MTP lacks community support, so is a non-starter
12:15 < BlueMatt> so that activation is guaranteed to happen during at least vaguely-reasonable human hours
12:15 <@michaelfolkson> The argument for MTP was it was slightly less code diff given that we don't have huge amounts of time to play with.
12:16 < jeremyrubin> Currently we're doing signaling on MTP and activation on height
12:16 < rgrant> luke-jr: does MTP interfere with bip8?
12:16 <@michaelfolkson> But I don't think the diff is that big at all. And we have enough time to play with to ensure preference is implemented and merged
12:16 < benthecarman81> Height seems objectively better than MTP, since the threshold is over a given difficulty adj period, it doesn't make sense to use MTP and have it potentially stop in the middle of a period
12:16 < BlueMatt> rgrant: the whole point of ST is to not deal with bip 8 debate yet
12:16 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
12:17 < jeremyrubin> With MTP and 3 months, using mid period MTPs the chance of changing from expected # of periods is pretty small
12:17 -!- Elkim [b9d59ba1@185.213.155.161] has quit [Quit: Connection closed]
12:17 < _6102bitcoin> > vaguely-reasonable human hours
12:17 < _6102bitcoin> bitcoiners are global
12:17 < achow101> benthecarman81: as jeremyrubin has pointed out, setting the mtp to the middle of a period is sufficient for very likely not losing any signaling periods
12:17 < jeremyrubin> Further, with a min active outside of the signal period, there is less accidental risk too
12:17 < prepaid> achow101 +1
12:17 -!- btcactivator [d98adbb7@217.138.219.183] has quit [Quit: Connection closed]
12:17 < BlueMatt> _6102bitcoin: that doesnt change the point, there are still more or less reasonable hours especially for devs and miners
12:17 < luke-jr> BlueMatt: interfering with it IS dealing with it (in a harmful way) - ST's near-consensus is based on it being neutral
12:17 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
12:17 < luke-jr> rgrant: yes, very much
12:18 -!- dirmyr [4b2901ae@75-41-1-174.lightspeed.austtx.sbcglobal.net] has quit [Quit: Connection closed]
12:18 < prepaid> achow101 that would follow barring any large change in hash rate (<-price swings), yes?
12:18 -!- misha93 [b0dd92ef@176.221.146.239] has joined ##taproot-activation
12:18 < BlueMatt> achow101: right, I dont see why not take the less-code option given its unlikely to change the technical details
12:18 < jeremyrubin> luke-jr: you've failed on numerous occasion to explain to me the actual issue. Besides saying it is an issue, can you descrive what the issue is?
12:18 < BlueMatt> i mean wasnt the whole point that people were in a rush?
12:18 < benthecarman81> achow: hmm that makes sense, however I still think height based is objectively better
12:18 < jeremyrubin> benthecarman81: see the agenda. no one disagress
12:19 < achow101> BlueMatt: in the previous discussions, there was consensus on activation being a height. 21377 changed from mtp activation to height activation as well
12:19 < BlueMatt> benthecarman81: sure, i think people mostly agree there, its a question of "but less code to review/less diff, to get it out the door quicker"
12:19 <@michaelfolkson> BlueMatt: A timetable that gets Taproot activated in November isn't relaxed. But it doesn't mean we can't ensure code is optimal and sufficiently well reviewed
12:19 < jeremyrubin> I'd rather take the smaller diff on known-good code personally unless there is a compelling reason.
12:19 < _6102bitcoin> >more or less reasonable hours
12:19 < _6102bitcoin> No such hours exist given miners are located everywhere.
12:19 < prepaid> agenda/topic https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html
12:19 < luke-jr> if people talking about MTP just spent that time reviewing achow101's PR I think we'd be done with the extra review time :P
12:19 < BlueMatt> michaelfolkson: huh? what comment of mine are you referring to?
12:19 < rgrant> jeremyrubin: you might mean that you've failed to understand it.  ;)  luke-jr: I don't get it either.
12:20 < BlueMatt> _6102bitcoin: pool ops are not. we live in the real world :)
12:20 -!- misha93 [b0dd92ef@176.221.146.239] has quit [Client Quit]
12:20 < prepaid> Is there anyone attending who runs a pool?
12:20 < jeremyrubin> no i meant i haven't been given an explanation at all
12:20 < luke-jr> pool ops (nor miners) are not all bitcoiners, no clue why that's even relevant
12:20 -!- James [c1207fda@193.32.127.218] has joined ##taproot-activation
12:20 < BlueMatt> achow101: wait, so what are the differences between the two prs now?
12:20 <@michaelfolkson> BlueMatt: "i mean wasnt the whole point that people were in a rush?" I wouldn't say we were in a rush. Just aiming for activation in November with Speedy Trial which means it isn't relaxed but it is not hectic rush either imo
12:20 < stortz> is there anyone who has a strict preference for MTP over height?
12:20 < achow101> BlueMatt: start and timeout is mtp in one, height in the other
12:21 -!- James is now known as James123
12:21 -!- ere [b09902cb@176-153-2-203.abo.bbox.fr] has quit [Quit: Connection closed]
12:21 < achow101> that's what we're discussing now
12:21 < BlueMatt> achow101: right, ok, then i misread your comment above
12:21 -!- Lester [aef85e9c@156.sub-174-248-94.myvzw.com] has quit [Quit: Connection closed]
12:21 < jeremyrubin> stortz: AFAIU no, they were asked to pre-reg a comment and none came in
12:21 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
12:22 < jeremyrubin> the only reason I could think of is that human times are a bit better, but only really matters if the signalling periods were like 100 blocks or something
12:22  * prepaid sees a second luke_jr
12:22 <@michaelfolkson> prepaid: I don't think so but Alejandro and Wangchun have ACKed the gist
12:22 < BlueMatt> michaelfolkson: definition of "rush" varies, but i guess the question is "does it make sense to *delay* taproot activation review in order to review more code to make activation height-based"
12:22 -!- mojalai [47de2425@71-222-36-37.lsv2.qwest.net] has quit [Quit: Connection closed]
12:22 < luke-jr_> jeremyrubin: rgrant: ST only works as an acceptable option because it can be shipped with the main "Bitcoin Core with Taproot" 2022-UASF client. But that only works if BIP8 is used for both.
12:22 < stortz> wait, why is there two lukes
12:22 < achow101> BlueMatt: since both mtp and height have almost the same parameters, does it really cause a delay?
12:22 -!- Elkim [2e87e4ea@cst-prg-228-234.cust.vodafone.cz] has joined ##taproot-activation
12:22 < jeremyrubin> luke-jr_: that's not actually an explanation though, it's a claim
12:23 < BlueMatt> but, frankly, flip a coin for all I care - as jeremyrubin pointed out multiple times, it doesn't matter in practice of how it would work in the real world.
12:23 -!- doitnow [ae17a858@174-23-168-88.slkc.qwest.net] has quit [Quit: Connection closed]
12:23 < jeremyrubin> an explanation would explain why it doesn't work
12:23 <@michaelfolkson> BlueMatt: I think there is enough slack in timetable to ensure a relatively small change (block heights) is sufficiently reviewed. Personal view
12:23 < luke-jr_> if ST were to be BIP9, doing both would require implementing both BIP9 and BIP8 in the same codebase instead of simply replacing/changing BIP9 to BIP8
12:23 -!- moi [05ada0ed@user-5-173-160-237.play-internet.pl] has quit [Ping timeout: 240 seconds]
12:23 < luke-jr_> which is much more complex and requires much more review; it probably wouldn't happen
12:23 < rgrant> luke-jr_: can the 2022-UASF client take a patch for MTP if needed?
12:23 < jeremyrubin> luke-jr_: BTCD took this approach
12:23 < _6102bitcoin> Has anyone verified the vocal well known bitcoiners in this chat?
12:23 < jeremyrubin> roasbeef:
12:23 < luke-jr_> rgrant: what?
12:24 < jeremyrubin> _6102bitcoin: off topic
12:24 <@michaelfolkson> BlueMatt: We aren't talking about delaying when it activates. We are talking about reducing the time between signaling and activation to give more time for review if needed (I think)
12:24 < jeremyrubin> luke-jr_: I also think that a height based UASF client cant be compatible with a time based ST client without needing both
12:24 -!- Lester [aef85e9c@156.sub-174-248-94.myvzw.com] has joined ##taproot-activation
12:24 < rgrant> luke-jr_: I think you covered this with "doing both would require implementing both BIP9 and BIP8 in the same codebase".
12:24 < jeremyrubin> Can you produce a condition where it fails to produce the intended outcome?
12:24 < BlueMatt> michaelfolkson: I sure hope not! but isnt that the next topic?
12:24 -!- Elkim [2e87e4ea@cst-prg-228-234.cust.vodafone.cz] has quit [Client Quit]
12:25 <@michaelfolkson> BlueMatt: Right :)
12:25 -!- valeriyageorg [4f10631d@host-79-16-99-29.retail.telecomitalia.it] has joined ##taproot-activation
12:25 < benthecarman81> Note: the diff to switch from MTP to block height is a 38 line diff of consensus code, shouldn't be a terrible review
12:25 < luke-jr_> ^
12:25 -!- thebitcoinrabbi3 [aecc8537@55.sub-174-204-133.myvzw.com] has quit [Ping timeout: 240 seconds]
12:25 < jeremyrubin> benthecarman81: it's consensus code though with a lot of tricky off by one things
12:25 -!- luke-jr_ [~luke-jr@unaffiliated/luke-jr] has quit [Client Quit]
12:26 -!- Elkim [2e87e4ea@cst-prg-228-234.cust.vodafone.cz] has joined ##taproot-activation
12:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
12:26 < jeremyrubin> aj's fuzzer helps with that a lot as a derisking
12:26 < benthecarman81> jeremyrubin: not wrong, just pointing out the size, and things like tests can help a lot
12:26 < benthecarman81> yeah exactly
12:26 < achow101> there are also tests for the height based stuff
12:26 -!- zeph [4e66b052@ip-78-102-176-82.net.upcbroadband.cz] has quit [Quit: Connection closed]
12:27 < luke-jr> it's much simpler than implementing BOTH MTP and heights
12:27 < benthecarman81> ^^
12:27 < BlueMatt> given the real-world outcome is the same, I'm not sure why we should bother changing the code to height, if i had to take a position.
12:27 < luke-jr> BlueMatt: the real-world outcome is not the same.
12:27 < BlueMatt> luke-jr: only if you're writing a patch to create a fork-coin, which I dont think is super relevant, tbh
12:28 < luke-jr> BlueMatt: false
12:28 < BlueMatt> ok
12:28 < rgrant> BlueMatt: The code change would resolve a fight.  It seems worthwhile.
12:28 < jeremyrubin> I think luke-jr needs to better break down the incompatibilities with a UASF client that he cares about. Because as long as the client is released afterwards, I see no issue
12:28 < luke-jr> jeremyrubin: the client needs to be released before
12:28 < jeremyrubin> But if the plan is to release a UASF client at the same time, then there is maybe an issue
12:28 < jeremyrubin> Oh?
12:28 < jeremyrubin> That seems to run counter to expectation. Perhaps you should explain this in topic 5
12:28 -!- nathanael [~nathanael@unaffiliated/nathanael] has joined ##taproot-activation
12:28 <@michaelfolkson> jeremyrubin: Regardless of Luke's position there is a general preference for block heights communicated in AJ's PR
12:29 < cguida> There was consensus on the technical superiority of height over MTP. So if we don't do it now, we're still going to need it eventually, correct?
12:29 <@michaelfolkson> jeremyrubin: With the caveat of wanting a little more time to review it
12:29 < _6102bitcoin> What are the arguments against block height?
12:29 < devrandom> is anybody actually opposed to paying the cost (in review time) that the switch to height-based requires, given that it is the preferred method in the longer term?
12:29 < jeremyrubin> yeah
12:29 -!- James123 [c1207fda@193.32.127.218] has quit [Ping timeout: 240 seconds]
12:29 < jeremyrubin> I think I'd want another month to seriously review heights. Times I could get on board with sooner.
12:29 < jeremyrubin> (Just speaking personally)
12:29 < cguida> devrandom: exactly
12:30 < BlueMatt> michaelfolkson: most of them seem to be based on people arguing that it makes creating a separate bitcoin-uasf fork-coin easier, which, again, I dont really understand why we should care.
12:30 < jeremyrubin> I'm not sure if that's time that we have, given peoples desire to ship.
12:30 <@michaelfolkson> jeremyrubin: Wow a whole month... Ok that surprises me
12:30 < BlueMatt> devrandom: I mean, would make sense. maybe we should come back to this after talking about timetable anyway, cause we can always just say "timetable is code-is-ready + X" and then it doesnt matter, just may delay it a few weeks, but so what.
12:30 < achow101> jeremyrubin: the current timeline is ~1.5 weeks
12:31 < devrandom> is that a delta month between the approaches or a month vs two weeks for the time-based? (i.e. two weeks delta)
12:31 -!- jbeddict23 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has joined ##taproot-activation
12:31 < AaronvanW> BlueMatt: It's not obvious to me that it would be a forkcoin. (That's ultimately up to users.)
12:31 -!- Yerzhan [1f0efa0b@31.14.250.11] has joined ##taproot-activation
12:31 -!- listener [d4b28e15@D4B28E15.static.ziggozakelijk.nl] has joined ##taproot-activation
12:31 -!- pzi_onic89 [b230a2e3@catv-178-48-162-227.catv.broadband.hu] has quit [Quit: Connection closed]
12:32 -!- jbeddict [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has quit [Ping timeout: 240 seconds]
12:32 -!- xsat [621a4191@cpe-98-26-65-145.nc.res.rr.com] has quit [Ping timeout: 240 seconds]
12:32 < rgrant> BlueMatt: There is a legitimate argument that UASF changes the game theory of the situation.
12:32 < BlueMatt> devrandom: i just mean that its whatever extra review time is needed, rounded to difficulty periods
12:32 < jeremyrubin> I think so? I'm much more concerned w.r.t. Matt's wanting rusty to have time to voice opposition that we actually have time to really review the code. I'd probably write some custom tests to ensure that the new activation logic works properly
12:32 < cguida> I know we haven't gotten to the next topic yet, but I think making the activation height dependent on lock-in height, rather than start height, would allow more time upfront to review heights
12:32 < achow101> note that some people not in this meeting have commented in 21377 preferring the time based approach because of the less review required
12:32 < jeremyrubin> I'd feel less compelled to do so with MTP, since that review has happened already
12:32 < devrandom> alternatively, we can shelve this discussion and continue on both PRs in parallel
12:33 < BlueMatt> AaronvanW: sure, maybe, find me some major holders who are gonna sell bitcoin and buy bitcoin-knots or bitcoin-uasf, though. point being, I dont think we should precisely optimize here for "lets make it easier to split bitcoin in two"
12:33 -!- James [c1207fda@193.32.127.218] has joined ##taproot-activation
12:33 < luke-jr> devrandom: no point, as MTP is a hard NACK
12:33 <@michaelfolkson> Here is the feedback on block height vs MTP https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038
12:33 -!- James is now known as Guest16924
12:33 < jeremyrubin> devrandom: nope, we should resolve it
12:33 < cguida> devrandom: not a bad idea
12:33 < jeremyrubin> parallel progress won't really help as we need to coordinate review effort
12:33 <@michaelfolkson> Mixing MTP and block height to save some review sounds dumb to me
12:34 < jeremyrubin> there are contribs who won't really look at either PR till there's more consensus
12:34 < BlueMatt> rgrant: how? "if you dont do it in way X, then I'm gonna create a fork of bitcoin and try to pull users/economic activity into it" is not a good reason to do X.
12:34 < rgrant> luke-jr: Don't forget, rough consensus overrides NACKs that aren't explained.
12:34 < luke-jr> BlueMatt: that is what you're tlaking about doing
12:34 < AaronvanW> BlueMatt: making it harder for users to follow (economic) incentives and their preferences makes the risk of splits greater.
12:34 < AaronvanW> imo
12:34 < rgrant> luke-jr: although we get it better now that you want to release before.
12:34 <@michaelfolkson> I didn't realize jeremyrubin would like a month to review a (relatively) small change
12:35 -!- makriath [acdae048@d172-218-224-72.bchsia.telus.net] has quit [Ping timeout: 240 seconds]
12:35 < BlueMatt> AaronvanW: I don't think there's really a lot that can be done to make it harder or easier to split the chain, if someone wants to, of course.
12:35 -!- bluehair [6c4b87cb@108-75-135-203.lightspeed.sndgca.sbcglobal.net] has joined ##taproot-activation
12:35 <@michaelfolkson> Can we avoid the what happens after ST discussion please? There clearly isn't agreement on that
12:35 < prepaid> We're on topic 3?
12:35 < achow101> BlueMatt: to be clear, you aren't opposed to heights, just that mtp is less change?
12:35 < jeremyrubin> I don't think so yet prepaid
12:36 < BlueMatt> michaelfolkson: agreed. I was just noting that "ST needs to be done in X way so taht what comes after can be Y" isnt a useful argument when Y is definitely not something that has any kind of consensus
12:36 < stortz> topic2
12:36 < prayank> BlueMatt: Nobody will buy bitcoin-knots as it's an implementation. Nobody buys bitcoin core.
12:36 < luke-jr> BlueMatt: ST has even less consensus without being compatible with Y
12:36 < cguida> Are there any comments on this? "I know we haven't gotten to the next topic yet, but I think making the activation height dependent on lock-in height, rather than start height, would allow more time upfront to review heights". More time to review, less time for a UASF, early activation, height-based activation. Everyone wins
12:36 < BlueMatt> prayank: s/bitcoin-knots/bitcoin-uasf/, same point
12:36 -!- bluehair [6c4b87cb@108-75-135-203.lightspeed.sndgca.sbcglobal.net] has quit [Client Quit]
12:36 < rgrant> BlueMatt: Game theory isn't about ethics, but consequences.  If UASF works, and is possible, it's part of the conversation.
12:36 <@michaelfolkson> I do think we're flirting with flame war here for no reason
12:37 < benthecarman81> ^
12:37 < jeremyrubin> We can shelve uasf till topic 5
12:37 < prepaid> agreed
12:37 < BlueMatt> achow101: correct. I'm fine with heights, I think we should set activation timeline to "software is available + X" anyway, so things that delay "software is available" dont bother me, we can just bump the parameters
12:37 <@michaelfolkson> Even people who don't like UASF prefer block height (it seems)
12:37 < luke-jr> the whole point of ST is to not conflict; that point is lost with MTP
12:37 < jeremyrubin> luke-jr: you really should have pre-regged a comment to have avoided this
12:37 < luke-jr> jeremyrubin: you made it sound like MTP wouldn't even be discussed unless someone pre-regged somethign
12:38 < jeremyrubin> I think I was quite clear in the agenda that both PRs would be discussed
12:38 < BlueMatt> rgrant: but I thought this conversation is about ST, not "how can we make sure that ST leads to UASF". I dont see how its relevant to *this* conversation.
12:38 <@michaelfolkson> I would like tomorrow to do better at summarizing why block heights is better than a weird mix of block height and MTP
12:38 -!- listener [d4b28e15@D4B28E15.static.ziggozakelijk.nl] has quit [Quit: Connection closed]
12:38 < achow101> Since there isn't strong opposition to heights, if people who do feel strongly opposed to mtp, just review the heights and we can get it merged
12:39 < BlueMatt> jeremyrubin: would you be ok with heights if we just said "well, if heights leads to a delay in code being ready, the parameters are changed by the amount of delay"?
12:39 <@michaelfolkson> It clearly is imo, and AJ doesn't want MTP for startheight. So it is either block heights or a weird mix of MTP and block height
12:39 -!- IntangibleCoins [4926f905@c-73-38-249-5.hsd1.ma.comcast.net] has joined ##taproot-activation
12:39 < jeremyrubin> Well TBH if having heights released is going to cause people to do a simul UASF client, then maybe nacking height is prudent
12:39 < luke-jr> jeremyrubin: then we just do UASF cleitn and no ST at all
12:39 < BlueMatt> jeremyrubin: heh, well cant disagree with that one...kinda defeats the whole point of ST, at least afaiu
12:40 < devrandom> there's no simultaneous UASF being discussed
12:40 < jeremyrubin> if you listen to what luke-jr is saying, he wants to release the UASF client ahead of ST client
12:40 -!- s3ton [5d228090@93-34-128-144.ip49.fastwebnet.it] has joined ##taproot-activation
12:40 < BlueMatt> devrandom: yea, luke just said he wants heights so that he can release a uasf fork coin client before st even starts
12:40 < achow101> and we're back to square one
12:40 < jeremyrubin> so if that's going to happen then I see no point in ST
12:40 < cguida> Am I shadowbanned or something? :(
12:40 <@michaelfolkson> cguida: No
12:40 < devrandom> he can release whatever, but the UASF he's discussing is for 2022
12:40 < luke-jr> 'simultaneous' may be a confusing term to use, sinc ethe UASF is in 2022
12:41 <@michaelfolkson> It is a BIP 8(LOT=true) that starts after ST
12:41 < stortz> cguida no
12:41 < jeremyrubin> cguida: your comment wasn't clear enough for anyone to know what you are talking about
12:41 < devrandom> so the ST doesn't interact with it at all
12:41 < achow101> jeremyrubin: I think we can count on a uasf client existing at some point in the near future regardless of ST
12:41 < BlueMatt> devrandom: right, but the point of ST was to "unify" the UASF crowd with the conservative-bitcoin crowd, so it seems that release would completely defeat the *point* of ST
12:41 < prepaid> achow101 +1
12:41 -!- Lester [aef85e9c@156.sub-174-248-94.myvzw.com] has quit [Quit: Connection closed]
12:41 < jeremyrubin> achow101: but using MTP doesn't matter if it is released after the start MTP time
12:41 < BlueMatt> achow101: then why bother with ST? Lets just do a more carefully-designed deployment
12:41 < stortz> uasf is topic5, is it not?
12:41 < cguida> jeremyrubin: Let's have activation height be 3 months after lock-in height. I'm not sure how I can make that any clearer
12:42 < jeremyrubin> cguida: it already is?
12:42 -!- s3ton [5d228090@93-34-128-144.ip49.fastwebnet.it] has quit [Client Quit]
12:42 < luke-jr> cguida: that seems pointless and just adds complexity?
12:42 <@michaelfolkson> stortz: Correct
12:42 < achow101> jeremyrubin: it can still overlap with the signaling periods and cause a chain split
12:42 < luke-jr> cguida: the point of the min activation delay, is to give everyone time to upgrade; that's independent of when signalling occurs
12:42 < jeremyrubin> how so?
12:42 <@michaelfolkson> Let's leave UASF to Topic 5 as stortz says
12:42 < cguida> Oh. I guess something changed then. Harding's proposal said activation would be 6 months after start height
12:43 < luke-jr> cguida: start, not lockin
12:43 < BlueMatt> michaelfolkson: it sounds like this is more of a "should we even bother with ST" discussion, not a uasf discussion
12:43 < cguida> luke-jr: More time to review, less time for a UASF, early activation, height-based activation. Everyone wins
12:43 <@michaelfolkson> If there is a preference for a weird mix of MTP and block height over purely block height (which I don't think there is) then it should be merged regardless of UASF plans
12:43 < jeremyrubin> I would love for someone who is trying to produce a UASF client to diagram out the actual time issues because I just don't see how there is a new chainsplit risk not already introduced by a UASF client
12:44 < jeremyrubin> Short of that, and having asked for it multiple times already, I think it is just grandstanding
12:44 < luke-jr> cguida: sounds like you want to just shift startheight and not the others
12:44 < luke-jr> michaelfolkson: no
12:44 -!- mhagelstrom [2d389c2f@45.56.156.47] has joined ##taproot-activation
12:45 < cguida> luke-jr: but why should it be independent? You yourself were arguing several days ago that activation in the current ST proposal takes too long, especially if lock-in occurs early
12:45 < luke-jr> michaelfolkson: that idea has less community support than BIP8(True), so if it comes down to that, we shoudl just merge BIP8(True)
12:45 < jeremyrubin> I think we should try to get through the next couple topics as they're less controversial and circle back at the 1 hour mark
12:45 < achow101> jeremyrubin: if ST and uasf are signaling at the same time on the same bit, and the threshold is reached, st would activate at min activation height while uasf would activate the next period
12:45 < jeremyrubin> I can stay in the meeting longer but I want to work through the other bits
12:45 -!- jonatack_ [~jon@37.165.85.219] has joined ##taproot-activation
12:45 < luke-jr> jeremyrubin: did you see https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit?usp=sharing
12:46 <@michaelfolkson> BlueMatt: ST is an opportunity for miners to activate on a BIP 8(LOT=false). If ST fails there will be a BIP 8(LOT=true). It is just whether Core releases something compatible or not with that BIP 8(LOT=true). Or indeed if it releases anything
12:46 < jeremyrubin> #topic 3. Parameter Selection for start/stop/active points.
12:46 < jeremyrubin> Short of resolving height or time based start/stop, a discussion of
12:46 < jeremyrubin> selecting acceptable parameters. We should get agreement on both sets of
12:46 < jeremyrubin> height or time parameters irrespective of the resolution to 2, so that this
12:46 < jeremyrubin> conversation can proceed independently.
12:47 < BlueMatt> istm that we should just pick Xs for "software is available" date offsets
12:47 < cguida> luke-jr: shifting the start-height would also work. But it seems like a better idea to have the delay between lock-in and activation be fixed, allowing for a fast activation in case of an early lock-in
12:47 < BlueMatt> selecting numbers in advance just means we argue all day about whether its enough headroom
12:47 -!- z [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has joined ##taproot-activation
12:47 -!- z [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has quit [Client Quit]
12:47 < achow101> I picked the timing for software + 1 week for start height
12:47 < achow101> in my proposal
12:47 < BlueMatt> vs just saying "well, we pick numbers that are an offset from when the software is available
12:47 < jeremyrubin> BlueMatt: the only difficulty is respecting e.g. btcd
12:47 < BlueMatt> jeremyrubin: I presume they'll be ready at a similar time?
12:48 < luke-jr> presumably offset needs to be from rc1
12:48 <@michaelfolkson> Right it would certainly be convenient to tell alternative implementations, miners and users when the startheight will be (to the extent we can)
12:48 -!- ClaudeNova [5204d218@cpc149476-cmbg20-2-0-cust535.5-4.cable.virginm.net] has quit [Quit: Connection closed]
12:48 < BlueMatt> achow101: 1 week seems relatively aggressive. I assume, at least, that upgrade post-lock-in still catches that and will enforce?
12:48 < BlueMatt> luke-jr: yes, presumably.
12:48 < achow101> BlueMatt: that's the point of the long min activation height
12:48 < luke-jr> BlueMatt: restarting the node clears the vbits cache
12:48 < BlueMatt> achow101: yes, thats my understanding, was just checking that the software supports it.
12:48 < jeremyrubin> sure -- maybe we can quantize that it can only be on the fist of the month or something just to provide more headroom for releases
12:49 < achow101> BlueMatt: it should. I can add a test for that
12:49 < luke-jr> technically, startheight could even be before a release
12:49 < BlueMatt> achow101: thank you.
12:49 -!- jonatack_ [~jon@37.165.85.219] has quit [Read error: Connection reset by peer]
12:49 -!- jonatack [~jon@37.165.23.76] has quit [Ping timeout: 272 seconds]
12:49 <@michaelfolkson> The proposed timetable is here for those following along https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
12:49 < jeremyrubin> So I think that michaelfolkson made a good point
12:49 -!- jonatack_ [~jon@37.165.85.219] has joined ##taproot-activation
12:50 < jeremyrubin> We can fix the minactivationheight to be e.g. november no matter what
12:50 < jeremyrubin> and as long as we get a release out relatively soon, not change that
12:50 < BlueMatt> achow101: so, then, the proposal would be, eg, "rc1 + 1 week start" "rc1 + 3 months stop" "rc1 + 6 months" activate?
12:50 < jeremyrubin> E.g., if it's +6, 5, or 4 doesn't matter that much
12:50 < BlueMatt> jeremyrubin: I dont see why we'd want to do that? The operative concern here is "how long people have to update before activation"
12:50 < achow101> BlueMatt: current proposal is based on final release date
12:51 < luke-jr> BlueMatt: add "within reason" :P
12:51 < BlueMatt> a few months makes a big difference when we're talking about a (relatively) compressed timetable.
12:51 <@michaelfolkson> jeremyrubin: Right, December and Western holidays would be a pain. At the moment it activates mid November which I think is optimal
12:51 < BlueMatt> achow101: eh, ok, swap it for final, doesn't matter much
12:51 < BlueMatt> michaelfolkson: thats a good point. I suppose if it slips into dec we should just do jan, then?
12:51 -!- giaki3003 [b9b25ffe@185.178.95.254] has quit [Ping timeout: 240 seconds]
12:51 < luke-jr> achow101: it needs to be set before rc1 tho
12:51 < jeremyrubin> and then if it slips further you hit chinese NY which is bad
12:52 < jeremyrubin> So just having a set date is actually good because people can start planning for engineering crap
12:52 < BlueMatt> luke-jr: I believe achow101 was referring to the "1 week" concept - ie "it shouldnt start signaling before release is even final"
12:52 < achow101> luke-jr: yes. I worked backwards from the final to get an estimate of when we need rc1
12:52 <@michaelfolkson> BlueMatt: Pushing it into 2022 for next to no reason seems wasteful
12:52 < jeremyrubin> "We have to be ready by this fixed date"
12:52 < BlueMatt> so you could say rc1 + 2 weeks or rc1 + 1.5 weeks or whatever
12:52 -!- bitcoinjuicy [4b453819@c-75-69-56-25.hsd1.ma.comcast.net] has joined ##taproot-activation
12:52 < luke-jr> rc1 + 1 week is hopefully approx the final release time
12:52 < BlueMatt> michaelfolkson: who cares? taproot isn't exactly something that people are going to be using/deploying using on mainnet in 2021
12:52 < jeremyrubin> I think it also removes urgency from MTP/height debate
12:52 -!- Memesan [498b3b1b@c-73-139-59-27.hsd1.fl.comcast.net] has quit [Quit: Connection closed]
12:52 -!- Yerzhan [1f0efa0b@31.14.250.11] has quit [Quit: Connection closed]
12:53 < jeremyrubin> BlueMatt: I care; it pushes every ecosystem thing out even more
12:53 < BlueMatt> jeremyrubin: then it sounds like we should just do mid jan 2022?
12:53 < BlueMatt> jeremyrubin: it shouldnt? no reason we cant build future things once its locked in?
12:53 -!- IntangibleCoins [4926f905@c-73-38-249-5.hsd1.ma.comcast.net] has quit [Quit: Connection closed]
12:53 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation
12:53 < BlueMatt> jeremyrubin: plus once you hit lock-in people can test on signet and build for it
12:53 < jeremyrubin> as long as we pick a fixed date, jan or nov doesn't matter
12:53 < luke-jr> signet already has it
12:53 < BlueMatt> jeremyrubin: I think the important metric for "does it delay other stuff" is lock-in, not activation.
12:53 < achow101> people can already test on signet, and regtest
12:53 < cguida> Isn't the current proposal to activate in November? Why can that not still happen?
12:54 <@michaelfolkson> BlueMatt: I just think there is no reason to push min activation height into December, January 2022 for no reason. We can adjust timeout height easily without moving min activation height
12:54 < achow101> I think it's reasonable to shorten the time between timeout and min activation
12:54 < jeremyrubin> but picking a fixed date for ST active is probably good because if we need to take another week or two for an unrelated RC issue
12:54 < jeremyrubin> I don't want people to feel it's a tradeoff
12:54 < BlueMatt> michaelfolkson: it sounds like we wouldn't have 6 months between activation and lock-in, no?
12:54 < stortz> achow101 +1
12:55 < jeremyrubin> achow101: especially because it's a worst case 1 month, average case stays longer
12:55 < BlueMatt> the original proposal was, roughly, 9 months from release-contining-activation-code to activation, assuming signaling occurs, correct?
12:55 < jeremyrubin> No? 6 months
12:55 <@michaelfolkson> BlueMatt: You mean between startheight and min activation height? No. But why is that 6 month figure important?
12:55 < luke-jr> michaelfolkson: to ensure the network has upgraded sufficiently
12:55 < BlueMatt> jeremyrubin: no, 6 months between end height and activation, no?
12:55 < jeremyrubin> no
12:55 < achow101> BlueMatt: no, that's 3 months
12:55 < benthecarman81> 3
12:55 < BlueMatt> oh, right.
12:55 -!- btcomnivore34 [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation
12:55 < luke-jr> it's more importnat people have time to upgrade for activation, than that we have a release for startheight
12:56 < BlueMatt> michaelfolkson: the number that matters is "time from release containing activation code to activation"
12:56 < BlueMatt> and, yea, like luke-jr says, its important that people have time to upgrade
12:56 -!- bitcoinjuicy [4b453819@c-75-69-56-25.hsd1.ma.comcast.net] has quit [Client Quit]
12:56 < achow101> The current proposal is about 6.5 months from start height to activation height
12:56 < BlueMatt> *especially* given the politicization of this and the fact that there's probably more pressure to false-signal than there was even for segwit :/
12:56 < jeremyrubin> I think that if we have a set date of  mid novemeber and release by july 1st latest we're ok
12:56 < luke-jr> so we have 2 weeks to slip for 6 mo
12:57 < achow101> we have 2 weeks to skip and still be 6 months from start to activation
12:57 < achow101> *slip
12:57 < jeremyrubin> Preferably May 1st
12:57 < luke-jr> (let's try not to slip tho)
12:57 < jeremyrubin> But if we communicate it *now* it's best
12:57 < roasbeef> mo params, mo problems
12:57 <@michaelfolkson> Right that kind of slippage seems fine to me (if needed)
12:57 < BlueMatt> roasbeef: lol yup
12:57 <@michaelfolkson> roasbeef: Lol
12:57 < prepaid> lol
12:57 < stortz> lol
12:57 < BlueMatt> fewer params good
12:57 < roasbeef> responding to a ping above: yeh I did a refactor in btcd recently to let it abstract over time/blocks, so it's just has the deployment started or ended
12:57 < roasbeef> few.
12:57 < roasbeef> lol
12:57 < cguida> jeremyrubin: that sounds reasonable
12:58 < jeremyrubin> So do I hear that everyone is OK with fixing min active to mid nov height?
12:58 < jeremyrubin> Any opposition?
12:58 < luke-jr> *subject to revision if things slip too far
12:58 < BlueMatt> achow101: correct me if I'm wrong, but that means release before mid-april?
12:58 < jeremyrubin> (if we don't release by july, we scuttle)
12:58 < BlueMatt> jeremyrubin: can you please restate what you're asking?
12:58 -!- btcomnivore34 [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Client Quit]
12:58 < achow101> BlueMatt: I planned for release April 24th
12:58 <@michaelfolkson> I strongly support mid November for min activation height
12:58 < jeremyrubin> We fix the minactiveheight to not be relative to release date
12:58 <@michaelfolkson> And working around that
12:58 < jeremyrubin> and as long as we get a release out soon(tm), we don't change it
12:59 < roasbeef> also can someone explain where these expectations w.r.t time frame have come from? ppl shouldn't fool themselves w.r.t the actual uptake that would happen if things were to activate _today_, there's really minimal wallet/hardware/library/tooling support as far as i've seen
12:59 < BlueMatt> jeremyrubin: I'd say if we dont cut a release by mid-may we need to scuttle any november timeline
12:59 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Ping timeout: 240 seconds]
12:59 < jeremyrubin> Can we settle on June 1st startheight?
12:59 < BlueMatt> jeremyrubin: it sounds like we can hit that, no problem, but that would give us a hard number of six months, which is nice
12:59 < benthecarman81> jeremyrubin: ack
12:59 < achow101> If we're ok with having just rc1 out by the start height, we can gain a week or two as well
12:59 < luke-jr> jeremyrubin: prefer sticking to May 1
12:59 < luke-jr> unless we slip
12:59 < jeremyrubin> luke-jr: that's what i meant
12:59 < BlueMatt> roasbeef: yea, that was my point - who cares if its novermber or january or whatever
12:59 < jeremyrubin> june 1 latest
13:00 < jeremyrubin> ideal may 1st
13:00 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has joined ##taproot-activation
13:00 < jeremyrubin> but if we need another RC or whatever we have some slack
13:00 < achow101> I think we can make may 1st. I put in a few weeks of slippage into my timeline because I'm not an optimist
13:00 < BlueMatt> but, sure jeremyrubin, so we'd be saying release + 1 week for start, end at + 3 months, activate mid-nov either way?
13:00 < jeremyrubin> roasbeef: I think it's a desire to communicate a known date earlier so that people can prepare to be ready.
13:00 < BlueMatt> achow101: add extra because its bitcoin core
13:00 <@michaelfolkson> BlueMatt roasbeef: For the businesses that want to be fully validating Taproot transactions I think they'd prefer not to do that during holidays
13:00 < jeremyrubin> otherwise we won't know the date until we actually release
13:00 < roasbeef> BlueMatt: yeh, and it'll take ppl even longer to fully impl than segwit, just given all the additional changes (new sig algo, new sig hashes, merkle path storage+crafting, diff key serialization)
13:01 < jeremyrubin> giving people less time overall to prepare
13:01 < luke-jr> michaelfolkson: upgrading *can* happen before activation :P
13:01 < jeremyrubin> roasbeef: segwit was worse
13:01 < roasbeef> jeremyrubin: naaah
13:01 < BlueMatt> jeremyrubin: but, unlike segwit, there is zero pressure to *use* taproot
13:01 -!- fiach_dubh [2578edb4@37.120.237.180] has joined ##taproot-activation
13:01 < jeremyrubin> Ok
13:01 < BlueMatt> only large multisigs care, really. plus whole new sig algorithm
13:01 < roasbeef> ^ yep, it's a bonus for mostly ppl doing contract stuff
13:01 < jeremyrubin> short of "x would be better"
13:02 < jeremyrubin> is there any *issue*
13:02 < jeremyrubin> Keep in mind we're trying to form consensus
13:02 < jeremyrubin> Mid nov minactiveheight
13:02 < BlueMatt> jeremyrubin: to confirm, we'd be saying release + 1 week for start, end at + 3 months, activate mid-nov either way?
13:02 < achow101> BlueMatt: yes
13:02 -!- jonyg3 [051d22fd@5.29.34.253] has joined ##taproot-activation
13:02 < jeremyrubin> yep
13:03 < BlueMatt> and, if release isnt by mid-may, scrap and do probably-mid-jan? sounds good.
13:03 -!- Satya [b9c3e89e@185.195.232.158] has quit [Quit: Connection closed]
13:03 < jeremyrubin> and if we can't get a release soon (TM) we have to push to either mid jan or mid feb
13:03 < jeremyrubin> err march?
13:03 < jeremyrubin> (need a china expert)
13:03 < cguida> jeremyrubin: ack to your proposal for keeping the min activation height where it is currently, and having it stay there regardless of when the code is available. We try to get a height-based ST client out by May 1, Jun 1 at the latest. If we miss Jun 1 we'll have to push it back, maybe 3 months.
13:03 < BlueMatt> well, whatever, lets hope we get it out by mid-may lol
13:03 < luke-jr> or abandon ST entirely at that point
13:03 <@michaelfolkson> I do think there would need to be an emergency for it not to be ready by mid May
13:03 < benthecarman81> > activate mid-nov either way?
13:03 < achow101> We can discuss that if we get to that point
13:03 < benthecarman81> meaning min activation height, not uasf correct?
13:03 -!- ryanthegentry [883195f5@136.49.149.245] has quit [Quit: Connection closed]
13:03 < achow101> min activation height
13:03 -!- jwow [ac3a1710@172.58.23.16] has joined ##taproot-activation
13:03 < benthecarman81> okay ty
13:04 < luke-jr> benthecarman81: yes
13:04 < jeremyrubin> Ok. So I think everyone agrees
13:04 < roasbeef> michaelfolkson: upgrading to a new client is very diff than actually having full support for being able to send/handle the new transactions
13:04 < jeremyrubin> And w.r.t converting times to heights if needed, I presume no one cares
13:04 -!- jwow [ac3a1710@172.58.23.16] has quit [Client Quit]
13:04 < prayank> BlueMatt: I don't think only large multisigs care and this point has been shared by lot of altcoiners recently or people sad about Taproot or any changes in Bitcoin protocol that improves things
13:04 < jeremyrubin> Everyone OK with, for times, targetting mid-period?
13:04 -!- harrym [b9f55740@185.245.87.64] has joined ##taproot-activation
13:04 < BlueMatt> sounds fine, yea
13:04 < luke-jr> jeremyrubin: what?
13:04 < jeremyrubin> (heights can be period aligned)
13:04 < achow101> if we use mtp, yes, mid period is safest
13:04 <@michaelfolkson> roasbeef: Gotcha, agreed. That won't happen for a while for most people
13:04 < luke-jr> jeremyrubin: no, again, times are a hard NACK period
13:04 < benthecarman81> if we do times, then ack
13:05 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation
13:05 < jeremyrubin> luke-jr: ex falso quod libet you don't need to care
13:05 < jeremyrubin> OK
13:05 < jeremyrubin> we did a thing!
13:05 < roasbeef> michaelfolkson: yeah....which is why the accelerated timelines puzzle me, I think only last month on one of the signets did someone actually do a taproot script spend for the first time
13:05 < jeremyrubin> \o/
13:05 < BlueMatt> jeremyrubin: heh, yay
13:05 < cguida> *applause*
13:05 < luke-jr> jeremyrubin: Core releasing ST with times would be very politically biased; BIP8(True) has more support
13:05 <@michaelfolkson> I would NACK a weird mix of MTP and block height because people don't want to review a slightly larger diff. That sounds dumb
13:05 < jeremyrubin> I think we covered topic 4 too
13:05 <@michaelfolkson> If people had a preference for a weird mix of MTP and block height, fine
13:05 < jeremyrubin> # 4. Parameter flexibility.
13:06 < jeremyrubin> #topic 4. Parameter flexibility.
13:06 < jeremyrubin> Nothing to add?
13:06 < luke-jr> you just said we finished it :P
13:06 <@michaelfolkson> Sorry
13:06 < BlueMatt> michaelfolkson: there's, generally, a *lot* of value in doing things "the way we know", so many fewer unknown. "dont want to review a bigger diff" is, like, generally quite good software engineering practice, yo.
13:06 < jeremyrubin> luke-jr: just checking in case someone does have something
13:06 < stortz> roasbeef to be fair, if you're making a product/service and the tapscript is not even with a min ETA, you wouldn't put much time/effort to push something out
13:06 -!- Elkim [2e87e4ea@cst-prg-228-234.cust.vodafone.cz] has quit [Quit: Connection closed]
13:06 < benthecarman81> think that's covered
13:07 < jeremyrubin> #topic 5. Simultaneous UASF.
13:07 <@michaelfolkson> BlueMatt: A massive diff on a short timetable fine :) A small diff on a short timetable... I'm not convinced
13:07 < achow101> NACK to a uasf having any overlap in signaling with ST
13:07 < jeremyrubin> I think here we can cover the luke-jr NACK on MTP too since it is related
13:07 < achow101> or literally any other activation method
13:07 < jeremyrubin> achow101: I'm OK with mid ST signalling I think
13:07 < luke-jr> achow101: the current idea isn't conflicting, even while overlapping
13:08 <@michaelfolkson> NACK to an incompatible UASF at same time as ST. That would be dumb too
13:08 < luke-jr> achow101: see Plan Y/Z of https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit?usp=sharing
13:08 < jeremyrubin> achow101: but generally, NACK on me doing any work until after ST fails
13:08 < BlueMatt> frankly, if half the uasf people want to do a uasf no matter the st stuff, I'm not sure what the point of st is.
13:08 < benthecarman81> imo It's good to have a UASF client ready if ST fails, they don't need to overlap however
13:08 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Client Quit]
13:08 < jeremyrubin> benthecarman81: agreed, and fair
13:08 < luke-jr> does anyone have any strong opinion of Y vs Z? only difference is the UASF date (Aug vs Nov 2022)
13:09 < jeremyrubin> I see no reason to e.g. hold up ST release because UASF isn't ready
13:09 < prayank> If ST is successful there won't be any UASF. It's plan B.
13:09 < jeremyrubin> luke-jr: what is YZ?
13:09 < benthecarman81> ^
13:09 < BlueMatt> but, yea, it seems like only luke-jr cares about debating uasf nonsense before st even happens, so we can safely ignore that
13:09 < luke-jr> jeremyrubin: see link
13:09 < jeremyrubin> I only see col A-E
13:09 < _6102bitcoin> > If half the uasf people want to do a uasf no matter the st stuff
13:09 < BlueMatt> ultimately, we need to focus on keeping the network together and having one bitcoin
13:09 < _6102bitcoin> I don't think this is accurate. Most people seem to be for ST in order to avoid the need for ST
13:09 < luke-jr> jeremyrubin: see headers; plan Y vs Z
13:09 < prayank> UASF or being prepared is not non sense
13:09 <@michaelfolkson> roasbeef: You referring to activation in November as accelerated? Or the 6 months being unnecessarily long?
13:09 < _6102bitcoin> * avoid the need for USAF
13:09 < BlueMatt> _6102bitcoin: right, see my second comment
13:10 < jeremyrubin> are Y and Z UASFs?
13:10 < luke-jr> jeremyrubin: yes
13:10 < roasbeef> michaelfolkson: I just mean general chatter of "it should activate by T", "no, T is too late"
13:10 < luke-jr> jeremyrubin: normal BIP8(True)
13:10 < _6102bitcoin> BlueMatt (y)
13:10 < cguida> I think pretty much all the UASF people would wait to see if ST succeeds. November is completely acceptable for activation.
13:10 < jeremyrubin> Why does it need to release at the same time?
13:11 < luke-jr> cguida: if ST doesn't succeed, a UASF can only have a chance in 2021 if it's deployed before ST fails
13:11 <@michaelfolkson> roasbeef: The activation conversation has been torturously long. Getting to a point where miners can activate it in 2021 seems like a win to me
13:11 < BlueMatt> cguida: the only timeline that matters is when the activation date is fixed, not when the activation *happens*, within reason. hell, even one-year-out or more proabbly wont change much in terms of how quickly taproot gets used
13:11 < benthecarman81> luke-jr: I disagree, if ST fails, people will still support UASF in the future
13:11 -!- ryanthegentry [883195f5@136.49.149.245] has joined ##taproot-activation
13:11 < luke-jr> cguida: otherwise the timeline doesn't even start until ST fails
13:11 < BlueMatt> michaelfolkson: isn't that about when the activation locks in
13:12 < BlueMatt> not when it *activates*?
13:12 < luke-jr> benthecarman81: hence "in 2021"\
13:12 < jeremyrubin> lukejr how about plan X: height at Apr 30th ealiest signal?
13:12 < luke-jr> jeremyrubin: ?
13:12 < jeremyrubin> Why not just,,, observe the actual height on the chain
13:12 < jeremyrubin> and release after
13:13 < prepaid> I don't follow you jeremyrubin
13:13 < luke-jr> jeremyrubin: both Y and Z are ST compatible
13:13 < jeremyrubin> Ok. so let's say ST launches with Apr 30th.
13:13 < jeremyrubin> then on May 7th, UASF client releases with whatever height was on Apr 30th startime
13:13 < jeremyrubin> what's wrong with that?
13:13 <@michaelfolkson> BlueMatt: Maybe we should be using the terminology here so we can be clear on exactly which height we're referring to https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
13:14 < prepaid> jeremyrubin "that" = what?
13:14 < BlueMatt> michaelfolkson: I'm not sure what that was in response to?
13:14 < luke-jr> jeremyrubin: that's before ST fails..
13:14 < jeremyrubin> it's not what I want
13:14 -!- soy_yo [ac5ca63e@172.92.166.62] has joined ##taproot-activation
13:14 < jeremyrubin> It's what you're saying you're doing anyways
13:14 < luke-jr> jeremyrubin: but with that approach, there is likely to be less adoption
13:14 <@michaelfolkson> BlueMatt: Forget it, it doesn't matter. I'm getting confused on what you and roasbeef are referring to exactly in terms of the time intervals
13:15 -!- soy_yo [ac5ca63e@172.92.166.62] has quit [Client Quit]
13:15 < BlueMatt> michaelfolkson: heh, ok
13:15 < jeremyrubin> luke-jr: burden on UASF
13:15 < prepaid> plan Y/Z appears to me, ST + UASF backstop
13:15 < jeremyrubin> if people don't want to actively choose it, whatever
13:15 -!- dulce [ac5ca63e@172.92.166.62] has joined ##taproot-activation
13:15 < jeremyrubin> and not like most users will upgrade in that 2 week period anyways
13:15 < luke-jr> prepaid: exactly
13:15 -!- dulce is now known as Guest47358
13:15 < jeremyrubin> I think it's a reasonable burden to bear for a UASF client, is it not?
13:15 < luke-jr> prepaid: also longer MASF after ST
13:16 < jeremyrubin> You just literally need to wait a day/week/whatever to set the startheight with bip8
13:16 < achow101> luke-jr: in the mtp case, as soon as we are past the mtp start time, you know the start height and can release before that height
13:16 < achow101> with the mtp start time being mid period, that gives you a week
13:16 < luke-jr> achow101: the goal is to release well before Core+STonly
13:16 < benthecarman81> luke-jr why?
13:17 < luke-jr> benthecarman81: to minimise people using STonly
13:17 < roasbeef> luke-jr: I think you might be over estimating the number of econmically relevant nodes that'll actually run that
13:17 < luke-jr> roasbeef: you are clearly underestimating
13:17 < roasbeef> this entire meeting is kind of a bubble in itself
13:17 -!- MyName15 [aecb0b60@96.sub-174-203-11.myvzw.com] has joined ##taproot-activation
13:17 < BlueMatt> luke-jr: so your explicit goal, here, is to completely avoid all of the advantage of ST, namely keeping the community and the network together?
13:18 < jeremyrubin> i will not run a UASF client until after ST fails
13:18 < devrandom> although I am interested in UASF as a backstop, I would not be running or recommending anybody run a UASF that conflicts with ST
13:18 < cguida> I thought the whole reason for ST was to avoid a UASF
13:18 < luke-jr> BlueMatt: no, this still keeps everything together
13:18 < jeremyrubin> I think that is probably consensus among people willing to do UASF as well
13:18 <@michaelfolkson> I think the UASF conversation is for ##uasf personally. I know some people don't think there should be a UASF at all at any point.
13:18 < BlueMatt> roasbeef: yea, that, this channel, hell even bitcoin-dev, is a very small bubble
13:18 < benthecarman81> devrandom: it doesn't conflict
13:18 < luke-jr> jeremyrubin: then we shouldn't do ST
13:18 < AaronvanW> BlueMatt: "ultimately, we need to focus on keeping the network together and having one bitcoin" <--- this is ultimately the responsibility of users and miners, not devs. imo devs should (if they want to keep one bitcoin) provide proper tools for users to best follow economic incentives. I believe pretty strongly that these could be UASF tools as well.
13:18 < jeremyrubin> michaelfolkson: it is relevent because luke-jr nacked MTP ST and i've nacked height ST if it means there's going to be a PR push to do a UASF before ST
13:19 < benthecarman81> AaronvanW: +1
13:19 < BlueMatt> AaronvanW: that is literally the Bitcoin Unlimited "emergent consensus" argument
13:19 < devrandom> benthecarman81: I would also not commit to a UASF before learning from the ST activation, so not until it fails
13:19 <@michaelfolkson> I do support luke-jr thinking ahead to if ST is released and fails to activate. We shouldn't be flatfooted if that happens
13:19 < BlueMatt> "we provide a few random config flags that lets you select your consensus, and you figure it out"
13:19 < BlueMatt> sure, I mean devs shouldnt (but also cant) block someone from forking themselves off, but thats separate from actively encouraging it
13:19 < prayank> AaronvanW: +1
13:19 < AaronvanW> BlueMatt: Bitcoin Unlimited never split off, because of economic incentives.
13:19  * rgrant AFK
13:19 <@michaelfolkson> jeremyrubin: You have NACKed height ST?! You'd prefer a mixture of block height and MTP is used?
13:19 < jeremyrubin> I don't think anyone beleives UASF must be released before ST, except luke-jr. Does anyone concur with luke on this?
13:19 < luke-jr> AaronvanW: they didn't?
13:20 < cguida> michaelfolkson: the ##uasf channel basically died once ST started gathering support. I think that's proof that people want to see how ST plays out
13:20 < _6102bitcoin> luke-jr is your concern that if SF+UASF code is released 2 weeks after SA code people will not run UASF?
13:20 < AaronvanW> luke-jr: not through these dumb tools that were embedded in their clients, no.
13:20 < BlueMatt> AaronvanW: I'm talking about how they wished to run their network *had* they split off - namely the "emergent consensus" nonsonse
13:20 < jeremyrubin> michaelfolkson: no pure-technical nack. just that I don't think it has consensus since it seems that it is incentivizing a UASF client
13:20 < luke-jr> _6102bitcoin: fewer will, because they will have already upgraded to ST-only
13:20 < benthecarman81> It's fine if a UASF client compatible with ST is released with ST, people will run what they want.
13:21 < _6102bitcoin> then the UASF will be a fork coin
13:21 < luke-jr> _6102bitcoin: no
13:21 < jeremyrubin> benthecarman81 +1 -- I just think given the above it is clear there is no technical reason to choose MTP or height for working with UASF
13:21 < jeremyrubin> it's purely to coerce people with picking UASF client before ST is released
13:21 < BlueMatt> AaronvanW: I said it before, but I think the most important thing to remember here is that 99% of users dont have time to be aware of any of this, and 95% of the remaining dont have time to build a well-informed and careful decision and understand all the tradeoffs. Our responsibility is to those 99.95% of users - others are smart enough to go download bitcoin-uasf or bitcoin-knots or whatever the hell fork client they want.
13:21 <@michaelfolkson> jeremyrubin: Going with a mix of MTP and block height to try to throw a wrench into UASF is terrible rationale imo
13:21 < AaronvanW> BlueMatt: BU was nonsense because they wanted to activate a hard fork without reorg protection. it was dumb, because economic incentives didn't align. UASF is the opposite. economic incentives align in favor of the upgrade.
13:21 < _6102bitcoin> if people don't care enough to run UASF code then it clearly doesn't have overwhelming consensus
13:22 < BlueMatt> AaronvanW: also relevant: Tyranny of Structurelessness
13:22 < benthecarman81> I also don't think we should pick MTP or height based off of if someone wants to release a UASF client, we should pick the one that is best
13:22 < prepaid> can we sideline historical debates about BU?
13:22 <@michaelfolkson> jeremyrubin: It is saying we'd rather go with the inferior option as to throw a wrench into UASF
13:22 < devrandom> jeremyrubin: I don't see how it's incentivizing a UASF client.  it has no effect at all AFAICT
13:22 < jeremyrubin> benthecarman81: +1, that's fair, but the only NACK on MTP is because of UASF
13:22 < prayank> _6102bitcoin: UASF will not happen before ST fails according to my understanding and even after ST fails there will be months time.
13:22 < BlueMatt> AaronvanW: suggesting its a a "neutral position" to make users pick which coin they want to run on is utter nonsense, frankly.
13:23 < luke-jr> jeremyrubin: the whole point of ST was to be neutral; MTP defeats that
13:23 < jeremyrubin> and anyone who actually writes/reviews the code has a mild preference for MTP based on review effort afaict
13:23 < benthecarman81> jeremyrubin: in the pr it seemed most people were in favor of height
13:23 < BlueMatt> AaronvanW: no, bu was *also* nonsense for "emergent consensus", at the time everyone i know literally used "emergent consensus" as a joke in any context.
13:23 < prayank> BlueMatt: Do you believe we should have just one implementation and one repository or you are in general okay with btcd, libbitcoin, knots, bcoin, gocoin etc.?
13:23 < _6102bitcoin> prayank I believe luke-jr is concerned that people will only upgrade once, and so there will be limited pressure on miners to activate during SA window due to threat of UASF
13:23 <@michaelfolkson> jeremyrubin: You haven't read the GitHub comment, let me link to it
13:23 < stortz> the PR is height based so far
13:23 < jeremyrubin> so while I've argued that height is better, we got excellent solutions that make MTP basically indistinguishable
13:24 < AaronvanW> BlueMatt: users *can* pick which coin they want to run. the question is: will they have good tools to do it with.
13:24 < BlueMatt> AaronvanW: hell, there was even an academic study on it, concluding that it would almost certainly fall apart
13:24 < luke-jr> _6102bitcoin: the point is the timeline; if we do nothing until after ST, everything shifts an extra 5 months
13:24 < benthecarman81> stortz: there are multiple prs
13:24 < BlueMatt> AaronvanW: of course they will! luke-jr just said he'd provide them.
13:24 < jeremyrubin> so really it only matters insofar as UASF needs parameters
13:24 -!- MyName15 [aecb0b60@96.sub-174-203-11.myvzw.com] has quit [Ping timeout: 240 seconds]
13:24 < luke-jr> BlueMatt: I didn't say that
13:24 < AaronvanW> BlueMatt: it would be great if it wasn't just luke.
13:24 < luke-jr> BlueMatt: in fact, I've said many times over the past several weeks I refuse to take a "lead" role in it
13:24 < BlueMatt> AaronvanW: I dont see why it should be *required* that developers build software for all possible outcomes
13:24 <@michaelfolkson> jeremyrubin: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038
13:24 < BlueMatt> AaronvanW: eh, sounds like benthecarman81 will too
13:24 < benthecarman81> it's not MTP makes UASF impossible, it can still be done
13:24 < luke-jr> BlueMatt: otherwise, there would already be a release done
13:25 < AaronvanW> BlueMatt: great, the more the better :)
13:25 < jeremyrubin> luke-jr: no one is saying you have to wait until it dies. just saying you have to wait until the MTP is crossed, then you have a whole week to release
13:25 -!- fiach_dubh [2578edb4@37.120.237.180] has quit [Quit: Connection closed]
13:25 < achow101> luke-jr: I don't understand why ST+UASF needs to release before ST begins
13:25 < jeremyrubin> because the 1st signaling period isn't until 7 days out
13:25 < prepaid> achow101 +1
13:25 < luke-jr> jeremyrubin: which is unreasonable
13:25 -!- brunog [bbb72f44@187.183.47.68] has quit [Quit: Connection closed]
13:25 <@michaelfolkson> jeremyrubin: Luke, Ben, Sjors, Russell, Harding (and even you at one point) expressed a preference for block height
13:25 < achow101> luke-jr: anyone who would run ST+UASF before ST will run it after ST
13:25 < prepaid> luke-jr the argument that people won't run which node software they want if other software exists is exceptionally weak IMO
13:25 < BlueMatt> AaronvanW: sure, but how does that imply that Bitcoin Core or some certain individuals should be somehow required to ship a "pleaseforkmeoffbitcoin" option?!
13:25 <@michaelfolkson> jeremyrubin: Marco too
13:26 < achow101> and if ST fails, then you'll be able to convince even more people too
13:26 < luke-jr> achow101: after ST is 3 months delay
13:26 < luke-jr> or longer
13:26 < _6102bitcoin> luke-jr 5 months is not very long imo. There won't be tools actually using taproot for some time
13:26 < achow101> luke-jr: after ST start time
13:26 < BlueMatt> AaronvanW: again, people who are well-informed enough to make a decision are *definitely* well-informed enough to go use a different client
13:26 < jeremyrubin> michaelfolkson: as noted, no one prefers MTP for a pure technical reason
13:26 < AaronvanW> BlueMatt: I agree BUs emergent consensus was dumb. For a number of reasons. But UASF is more like a on/off switch, and I believe the economic incentives align strongly in favor of "on".
13:26 < luke-jr> _6102bitcoin: tools to use is irrelevant
13:26 < AaronvanW> BlueMatt: I'm OK with a different client.
13:26 <@michaelfolkson> jeremyrubin: Only for throwing wrench into UASF or the minimal extra review
13:26 < BlueMatt> AaronvanW: that's highly unclear - we dont know that bip 148 uasf had almost any material impact. its an unknowable issue.
13:26 < luke-jr> _6102bitcoin: if anything, it goes against your argument
13:27 < jeremyrubin> michaelfolkson: but it's not even a wrench
13:27 < luke-jr> BlueMatt: yes we do
13:27 < jeremyrubin> michaelfolkson: it's still super easy to make a compatible client
13:27 -!- Satya [b9c3e89e@185.195.232.158] has joined ##taproot-activation
13:27 < roasbeef> BlueMatt: boom, ppl seems to overstate its' material impact, once again due to a sampling bias
13:27 -!- valeriyageorg [4f10631d@host-79-16-99-29.retail.telecomitalia.it] has quit [Quit: Connection closed]
13:27 <@michaelfolkson> jeremyrubin: So just the minimal extra review?
13:27 < achow101> roasbeef: confirmation bias more like
13:27 < prepaid> cracks open https://en.wikipedia.org/wiki/Revealed_preference
13:27 < roasbeef> achow101: yeh both
13:27 < BlueMatt> AaronvanW: didnt you just say that it should be the position of developers to not advocate for one position or another? inclusion or not in software precisely is that, there is no such thing as a neutral position here.
13:28 < luke-jr> if UASFs don't work, then we should just give up on Bitcoin because it's centralised
13:28 < prepaid> luke-jr OT IMO
13:28 < BlueMatt> luke-jr: no, it just means its hard to change, which is great!
13:28 < luke-jr> BlueMatt: easy for you, hard for anyone else*
13:28 < BlueMatt> if UASFs are as easy as you think, then its trivial to change bitcoin to be al kinds of arbitrary shit, which is almost certainly worse :)
13:28 < jeremyrubin> as noted, I prefer heights. AJ fixed the main height based request i had, and good choice of MTP address the other
13:28 < jeremyrubin> I don't actually care about height beyond that
13:28 < roasbeef> luke-jr: kek
13:29 < AaronvanW> BlueMatt: My preference is LOT=false in Core (bc of F7) and a parallel LOT-true UASF release, hopefully reviewed by experienced Core devs.
13:29 < jeremyrubin> And I think for ST, we probably never need to do height based as long as parameters stay similar
13:29 -!- puchu [~cryptoner@unaffiliated/puchu] has joined ##taproot-activation
13:29 < BlueMatt> but, I'm not really interested in debating if bitcoin should take on a ton of chain-split-risk for this kind of stuff. I've got work to do :)
13:29 <@michaelfolkson> 'll be leaving too. Thanks for hosting jeremyrubin, good job
13:29 < prepaid> What are some currently unaddressed or unsummarized points of the topic at hand that we would like to poll people about?
13:29 < jeremyrubin> Either code should be safe :)
13:29 <@michaelfolkson> Thanks everyone for attending
13:29 < jeremyrubin> But it does need to be the same as what other people run
13:29 < cguida> Yes, thanks jeremyrubin!
13:29 < BlueMatt> AaronvanW: yes! lets encourage users to split the chain, what a great outcome :( sure, we can't stop users from going off on a fork if they want, but man thats a terrible outcome if we all encourage it.
13:29 < _6102bitcoin> UASFs may work, but in an ideal scenario you never need to because miners do SA first
13:29 < benthecarman81> Good meeting jeremyrubin
13:29 -!- mhagelstrom [2d389c2f@45.56.156.47] has quit [Quit: Connection closed]
13:30 < jeremyrubin> Of course -- let's close in 1 minute -- any last points for the notes?
13:30  * BlueMatt -> actual work
13:30 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has left ##taproot-activation ["Ex-Chat"]
13:30 < achow101> oh, I was using this meeting to avoid doing actual work
13:30 < benthecarman81> lol
13:30 < AaronvanW> BlueMatt: I believe that optimalizing for a succesful UASF minimizes the risk of chain split.
13:30 < prepaid> <g>
13:30 < stortz> he's gone aaron
13:31 < jeremyrubin> #endmeeting
13:31 < AaronvanW> oh
13:31 < jeremyrubin> bye
13:31 < prepaid> ty jeremyrubin
13:31 < Alistair_Mann> tx jeremyrubin - much appreciated the 'prereg' format
13:31 -!- oxtr [~tommy@13.84-234-189.customer.lyse.net] has quit [Quit: WeeChat 3.0.1]
13:31 -!- gr-g [4dbd19eb@x4dbd19eb.dyn.telefonica.de] has quit [Quit: Connection closed]
13:31 < AaronvanW> Thanks jeremyrubin
13:31 < luke-jr> so do we have consensus that jeremyrubin leads all the meetings from now on?
13:31 < luke-jr> :P jk
13:31 < jeremyrubin> I'll try to post a summary of the meeting later today
13:32 -!- ryanthegentry [883195f5@136.49.149.245] has quit [Quit: Connection closed]
13:32 < jeremyrubin> luke-jr: glad you enjoyed
13:33 -!- poon [~poooon@unaffiliated/poon] has joined ##taproot-activation
13:33 -!- benthecarman81 [6b8a186e@107-138-24-110.lightspeed.austtx.sbcglobal.net] has quit [Quit: Connection closed]
13:33 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has joined ##taproot-activation
13:34 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has quit [Client Quit]
13:34 -!- Alexandre_Chery [9466b34d@148.102.179.77] has quit [Quit: Connection closed]
13:34 -!- jbeddict23 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has quit [Quit: Connection closed]
13:34 -!- Alexandre_Chery [9466b34d@148.102.179.77] has joined ##taproot-activation
13:35 -!- Alexandre_Chery [9466b34d@148.102.179.77] has quit [Client Quit]
13:36 < stortz> correct me if I'm wrong
13:36 -!- harrym [b9f55740@185.245.87.64] has quit [Quit: Connection closed]
13:37 -!- _6102bitcoin [59ee824d@89.238.130.77] has quit [Quit: Connection closed]
13:37 < stortz> but isn't the whole point of a 'soft fork' to be backwards compatible
13:37 < roasbeef> stortz: backwards+forwards yeh
13:37 < stortz> meaning any consensus rules introduced are not conflicting with the older ones
13:37 < stortz> if so, I don't understand Matt's point
13:37 < roasbeef> stortz: you can fork off tho
13:37 -!- entropyhappens [490e0a27@c-73-14-10-39.hsd1.co.comcast.net] has quit [Quit: Connection closed]
13:38 < luke-jr> stortz: Matt was trolling
13:38 < luke-jr> I guess ignoring the trolling means it doesn't get corrected :/
13:38 < roasbeef> stortz: if you start enforcing taproot today, then someone mines a block that doesn't recognize the new rules, you've forked off that chain
13:38 < roconnor> Even with a soft-fork, there are scenarios where some users could observe be massive reorgs and thus "double spending".
13:39 -!- livestream-jerm [18b0f7b6@024-176-247-182.res.spectrum.com] has quit [Quit: Connection closed]
13:39 < roasbeef> yeh there's always some chain split risk, ideally it's minimzed tho
13:39 < roasbeef> at times feels like ppl are forgetting the main benefits of soft forks vs hardforks
13:39 -!- Guest47358 [ac5ca63e@172.92.166.62] has quit [Quit: Connection closed]
13:39 <@michaelfolkson> stortz: You could have two competing incompatible alternative mechanisms being run on the network at the same time. Whichever loses could potentially be forked off
13:39 < stortz> meaning in a hardfork there's less chainsplit risk is what you're sayign roast
13:39 < stortz> saying*
13:39 <@michaelfolkson> *activation mechanisms
13:40 < luke-jr> provided miners follow the rules, chains don't split with a softfork
13:40 < roasbeef> would recommend ppl re read this if they haven't already: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
13:40 < roasbeef> stortz: no
13:40 < luke-jr> with a hardfork, old nodes can't follow the new chain at all
13:40 < stortz> yes I know
13:40 < roasbeef> there's an explicit chain split w/ a hardfork, a softfork avoids one by having things be forwards compatible for old clients (they ignore the stuff they don't understand essentially)
13:40 <@michaelfolkson> roasbeef: Nice, hadn't seen that mailing list post
13:42 -!- EkkaS [25dbe492@37-219-228-146.nat.bb.dnainternet.fi] has joined ##taproot-activation
13:43 -!- EkkaS [25dbe492@37-219-228-146.nat.bb.dnainternet.fi] has left ##taproot-activation []
13:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
13:43 < roasbeef> michaelfolkson: yeh it's really good
13:43 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
13:44 < roasbeef> > A) Softforks do not require the pervasive consensus that hardforks need. Soft forks can be deployed without knowing when all full nodes will adopt the rule, or even whether they will ever adopt it at all.
13:44 < jeremyrubin> keep in mind that it can be profitable (potentially) to mine a single bad block to attack miners not validating taproot
13:44 -!- jonyg3 [051d22fd@5.29.34.253] has quit [Quit: Connection closed]
13:44 < jeremyrubin> can amplify selfish mining type attacks
13:45 < roasbeef> yeh ppl talka about "activating" on w/e date, but would they move all their coins to the new output the very next block after?
13:45 < roasbeef> I guess w/ ST things are staged differently tho
13:45 < jeremyrubin> roasbeef: another benefit of fixed height
13:45 -!- doit [51523d71@d51523D71.access.telenet.be] has joined ##taproot-activation
13:45 < luke-jr> roasbeef: UASFs do need [almost] all to be safe tho
13:45 < jeremyrubin> safe to make bets now :p
13:45 < luke-jr> well, to be safe for ~everyone
13:46 < achow101> roasbeef: I would absolutely try to get the first taproot transaction on mainnet :)
13:46 < roasbeef> luke-jr: yeh that's the thing, you can't measure that
13:46 < roasbeef> > C) Hardfork coordination has a centralizing effect on development. As hardforks can only be deployed with sufficient node deployment, they can't just be triggered by miner votes. This requires central coordination to determine flag times, which is incompatible with having multiple independent consensus changes being proposed.
13:46 < luke-jr> and all softforks need an economic majority
13:46 -!- prepaid [~prepaid@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]
13:46 -!- gmegarlic [bc3f2ae3@227.42.63.188.dynamic.wline.res.cust.swisscom.ch] has joined ##taproot-activation
13:46 < luke-jr> roasbeef: you can't measure the future period
13:46 < roasbeef> the beauty of bip 9 as it was originally proposed was that it allowed multiuple in flight updates at once
13:47 < luke-jr> roasbeef: but you can make predictions based on social talk, and plan things with enough advance notice that everyone knows what is needed
13:47 < roasbeef> ofc that has never happend for various reasons, but that iself aides decentralization as you can be doing an upgrade and just _see_ that there's another one going on but not really have to worry about it due to soft forks
13:47 < roasbeef> luke-jr: not really, there's a lot of noise there, hard to sample, confirmation biases, etc, etc
13:47 < luke-jr> roasbeef: should get the NOINPUT or whatever it's called now in flight ;)
13:48 < luke-jr> roasbeef: if we can't, then we can't do softforks at all
13:48 < roasbeef> can't do what? measure who's gonna run it ahead of time?
13:48 < luke-jr> make predictions
13:48 < roasbeef> it's just a predication tho, a soft promise
13:49 < luke-jr> it's the same with a softfork vs a UASF - the only difference is degree
13:49 < roasbeef> luke-jr: oh yeh I'm kinda meh on base taproot, the excitement comes from what can follow
13:49 -!- prepaid [~prepaid@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation
13:49 < luke-jr> roasbeef: what's holding up the following?
13:49 < luke-jr> just waiting for Taproot?
13:49 < roasbeef> yeh mainly to not clog the airways
13:49 < jeremyrubin> luke-jr: people attacked me for suggesting that CTV proceed in parallel
13:49 -!- yamaaan [57a056bc@p57a056bc.dip0.t-ipconnect.de] has joined ##taproot-activation
13:49 < roasbeef> also if taproot h appens, then there's positive momentum for additional changes from there on
13:49 < luke-jr> jeremyrubin: wut
13:49 < jeremyrubin> :shrug:
13:50 < roasbeef> but because there's basically a single popular client, it's hard to do parallel changes
13:50 < prepaid> stortz consensus compatibility (soft vs hard forks) is orthogonal to if the node's consensus code is following what your peers are running
13:50 < jeremyrubin> that's why i've been waiting
13:50 < luke-jr> roasbeef: I would think easier tbh
13:50 -!- lightlike [~lightlike@p200300c7ef1ca90089ae1ec809ac3f97.dip0.t-ipconnect.de] has left ##taproot-activation ["Leaving"]
13:50 < prepaid> "mo params, mo problems"
13:51 < roasbeef> luke-jr: easier to multiuple changes at once?
13:51 < roasbeef> prepaid: preach
13:51 < roasbeef> that doesn't at all match the current social reality of bitcoin dev luke-jr
13:51 < prepaid> sensitive dependence on "initial parameters" 8P
13:52 < jeremyrubin> someone said they beleive review is like "an eye of sauron" -- it can look at anything, but not two things at once
13:52 < jeremyrubin> I disagree with that, but faced more resistance than support
13:52 < stortz> what's CTV
13:52 < roasbeef> jeremyrubin: in an ideal case I disagree, but in practice that's true
13:52 < prepaid> check template verify
13:52 < jeremyrubin> so at a certain point you can't place your own views above consensus
13:52 < jeremyrubin> https://utxos.org
13:52 < prepaid> roasbeef +1
13:53 < roasbeef> due to the overton window of discussions amongst devs and ppl naturally gravitating towards what others desire/think is cool
13:53 < jeremyrubin> see https://github.com/sapio-lang/sapio for what you can use it for
13:53 -!- gmegarlic [bc3f2ae3@227.42.63.188.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 240 seconds]
13:53 < jeremyrubin> roasbeef: I think we should set up better WG structure or something if we actually want to get more than one thing done
13:53 < jeremyrubin> but people are allergic to structure
13:53 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has quit [Quit: Connection closed]
13:54 < jeremyrubin> and so we're left with https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness
13:54 < prepaid> wg?
13:54 -!- platowight [580bceea@234.red-88-11-206.dynamicip.rima-tde.net] has joined ##taproot-activation
13:55 -!- Guest16924 [c1207fda@193.32.127.218] has quit [Quit: Connection closed]
13:55 < roasbeef> working group
13:55 < prepaid> ah
13:55 -!- yamaaan [57a056bc@p57a056bc.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
13:55 < roasbeef> jeremyrubin: yeh agreed, but once again re that link, there're certain unacknowledged structures that would need to be laid bare in order to let ppl move forward beyond them
13:56 < roasbeef> which is why I btcd ;)
13:56 < prepaid> a triumph of structurelessness
13:56 < jeremyrubin> city on a hill, pop 1
13:56 < roasbeef> i'll prob be able to start to implement taproot for btcwallet/btcd/lnd srsly in a month or two-ish
13:58 < luke-jr> wait, it doesn't support Taproot yet? how does it have any activation possible then
13:58 < luke-jr> or u mean using Taproot features?
14:00 < roasbeef> i never said it had activation possilbe
14:00 < roasbeef> what I've done so far is make it agnostic to using height or block for version bits based start/end times for deployments
14:01 < luke-jr> I see
14:01 < roasbeef> but along the way to implementing it, i'll end up generating a series of packages that can be used for independent stuff within the btcsuite project
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:02 < roasbeef> there're a few companies that use the set of libs now, so it may help to ease their utlimate integrations
14:03 < luke-jr> achow101: is this a false fail? https://cirrus-ci.com/task/4668473021300736
14:04 -!- proofofkeags_ [~proofofke@205.209.24.233] has joined ##taproot-activation
14:04 < achow101> luke-jr: I believe so
14:05 < luke-jr> I guess Cirrus only lets the PR author rerun
14:06 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 244 seconds]
14:07 -!- platowight [580bceea@234.red-88-11-206.dynamicip.rima-tde.net] has quit [Quit: Connection closed]
14:08 -!- FreeeZy00 [5ff47b73@host-95-244-123-115.retail.telecomitalia.it] has quit [Quit: Connection closed]
14:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
14:09 -!- Satya [b9c3e89e@185.195.232.158] has quit [Quit: Connection closed]
14:11 -!- krs41 [53e91d3e@83-233-29-62.cust.bredband2.com] has quit [Quit: Ping timeout (120 seconds)]
14:14 -!- doit [51523d71@d51523D71.access.telenet.be] has quit [Quit: Connection closed]
14:15 -!- wout32 [5bb11d50@80.29-177-91.adsl-dyn.isp.belgacom.be] has joined ##taproot-activation
14:15 -!- nathanael [~nathanael@unaffiliated/nathanael] has quit [Quit: nyaa~]
14:16 -!- wout32 [5bb11d50@80.29-177-91.adsl-dyn.isp.belgacom.be] has quit [Client Quit]
14:19 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
14:20 -!- adfffdddsaeevv [2f9d7da2@47.157.125.162] has quit [Quit: Connection closed]
14:20 -!- prayank [~andr0irc@2401:4900:30de:f516:f13c:594c:f3d0:3756] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
14:25 -!- prepaid [~prepaid@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: prepaid]
14:25 -!- Pompom [53532b9c@83-83-43-156.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation
14:26 -!- landeau [bbbd94a0@fixed-187-189-148-160.totalplay.net] has quit [Quit: Connection closed]
14:35 -!- Pompom [53532b9c@83-83-43-156.cable.dynamic.v4.ziggo.nl] has quit [Ping timeout: 240 seconds]
14:41 -!- psl123 [560804b3@finc-22-b2-v4wan-161039-cust178.vm7.cable.virginm.net] has joined ##taproot-activation
14:45 -!- stortz [c8b9cbcf@unaffiliated/stortz] has quit [Quit: Connection closed]
14:45 -!- psl123 [560804b3@finc-22-b2-v4wan-161039-cust178.vm7.cable.virginm.net] has quit [Client Quit]
14:55 -!- largecoffee [60201a0b@096-032-026-011.res.spectrum.com] has joined ##taproot-activation
14:56 -!- largecoffee [60201a0b@096-032-026-011.res.spectrum.com] has quit [Client Quit]
15:08 -!- epson121 [d595335f@213.149.51.95] has quit [Quit: Connection closed]
15:17 -!- pg [443817f9@c-68-56-23-249.hsd1.mi.comcast.net] has joined ##taproot-activation
15:17 -!- pg [443817f9@c-68-56-23-249.hsd1.mi.comcast.net] has quit [Client Quit]
15:20 -!- Guest24822 [d460228f@catv-212-96-34-143.catv.broadband.hu] has quit [Quit: Connection closed]
15:39 -!- proofofkeags__ [~proofofke@205.209.28.54] has joined ##taproot-activation
15:41 -!- proofofkeags_ [~proofofke@205.209.24.233] has quit [Ping timeout: 245 seconds]
15:46 -!- CARO1 [~Cesar@2804:7f4:c19f:cde8:e931:72dd:eafd:b9a] has joined ##taproot-activation
15:46 -!- CARO2 [~Cesar@2804:7f4:c19f:cde8:e931:72dd:eafd:b9a] has quit [Ping timeout: 258 seconds]
16:17 -!- poon [~poooon@unaffiliated/poon] has quit [Quit: Lost terminal]
16:40 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation []
16:48 -!- puchu [~cryptoner@unaffiliated/puchu] has quit [Quit: leaving]
17:08 -!- jonatack_ [~jon@37.165.85.219] has quit [Ping timeout: 256 seconds]
17:16 -!- proofofkeags__ [~proofofke@205.209.28.54] has quit [Ping timeout: 265 seconds]
18:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
18:59 < jeremyrubin> Anyone feel like reviewing meeting notes before I post to mailing list?
19:03 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
19:03 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
19:04 -!- CryptoEdge [2fc9a4e1@47.201.164.225] has joined ##taproot-activation
19:05 < luke-jr> jeremyrubin: sure
19:07 -!- CryptoEdge [2fc9a4e1@47.201.164.225] has quit [Client Quit]
19:11 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving]
19:48 -!- Guest77909 is now known as pigeons
19:58 < luke-jr> achow101: if you decide to bother with shedpainting, there's still start_height with underscores in the vbparams stuff - I just didn't want to cause any delay so avoided mentioning anything that wasn't a blocker :p
19:59 < achow101> luke-jr: where? I grepped for start_height and got more than what I wanted...
20:02 < luke-jr> chainparams
20:03 < achow101> oh i see
20:04 < achow101> imo the bip should've used underscores, much easier to read
20:05 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has joined ##taproot-activation
20:06 < jeremyrubin> https://gist.github.com/JeremyRubin/224d9380127006745e40b9c4bba4a544
20:06 < jeremyrubin> if anyone has any corrections before I send to mailing list tonight
20:07 < luke-jr> achow101: yeah, IMO we can change it later tho
20:07 < luke-jr> achow101: for minimising changes vs BIP 9 this is best
20:07 < luke-jr> actually, wait
20:07 < luke-jr> BIP 9 doesn't use heights at all
20:07 < luke-jr> nm, go ahead and use underscores XD
20:08 < achow101> lol
20:08 < luke-jr> jeremyrubin: ST+BIP8 might be clearer than "UASF"
20:09 < luke-jr> or ST + 1 year
20:10 < jeremyrubin> unclear?
20:10 < jeremyrubin> I think people know it's called UASF
20:10 < luke-jr> it's not
20:11 < roasbeef> luke-jr: so it's not a UASF?
20:11 < luke-jr> roasbeef: not just, no
20:11 < roasbeef> lol wat
20:11 < luke-jr> roasbeef: ST + 1 year MASF + UASF
20:11 < roasbeef> "we gon activate" isn't a uasf?
20:11 < luke-jr> roasbeef: no, that's just activation
20:11 < roasbeef> semantics
20:11 < luke-jr> not really
20:11 < luke-jr> it's simply not reintroducing an already-fixed bug
20:12 < roasbeef> do you agree if "activation" isn't based off some hash rate sampling threshold, then it's a uasf?
20:13 < luke-jr> I'm sure I could contrive a scenario where it isn't either, but I don't think that's relevant
20:13 < luke-jr> in any case, the full deal has hashrate sampling
20:13 < luke-jr> and will liekly activate using it
20:13 < roasbeef> what's a uasf then?
20:13 < luke-jr> roasbeef: the final fallback in Nov 2022 if miners neglect to coordinate an early activation
20:13 < roasbeef> oo, here's another one: has a uasf ever happened in the past?
20:14 < luke-jr> obviously
20:14 < jeremyrubin> I'm now more confused
20:14 < roasbeef> lol
20:14  * achow101 grabs popcorn
20:14 < luke-jr> -.-
20:14 < jeremyrubin> I can add a note saying what UASF is
20:14 < roasbeef> ok so we need a footnote? lmao
20:14 < luke-jr> jeremyrubin: why call it UASF?
20:14 < jeremyrubin> Maybe this is off topic here
20:14 < luke-jr> hardly
20:14 < jeremyrubin> Is there another channel to discuss this on?
20:18 < achow101> we could make mtp and height based be basically the same activation. I think the drift will be small enough that if we did starttime=April 24th and timeouttime=Aug 14th that the first and last real signaling period would match the height based one
20:19 < jeremyrubin> achow101: I put May 7th in the notes to be safe since it was unclear in the meeting when rc1 would come out
20:19 < jeremyrubin> but noted in parameter flexibility that we can move it back.
20:20 < achow101> with mtp, I would be fine with having the starttime be within a day of the release date because we still have the one week until the first real signaling period
20:21 < jeremyrubin> also starttime is less sensitive because the drift would have to be crazy
20:21 < jeremyrubin> v.s. the finish time could have more drift.
20:21 < roasbeef> does ST as "defined" actually use the MUST_SIGNAL state at all?
20:21 < achow101> roasbeef: no
20:21 < roasbeef> ok that's chill
20:22 < roasbeef> so bip 9, with maybe heights, and mo params (min activation height, etc)
20:23 < roasbeef> I haven't kept up w/ the bitcoind codebase as much these days, but I don't really follow the arguments that height vs time would somehow cause a massive overhaul or push things back
20:23 < roasbeef> since at the end of the day, you have a block header, and need to decide if things have started or ended
20:23 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Read error: Connection reset by peer]
20:24 < roasbeef> height number go up
20:24 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
20:25 < roasbeef> also iirc, the "buried deployments" is based on height
20:26 < roasbeef> I have some more tests to write, but afterwards btcd will be able to do either (and maybe even both at once *gasp*)
20:26 < jeremyrubin> roasbeef: then just to implement taproot :p
20:26 < roasbeef> yeh gotta draw the rest of the owl....
20:29 < achow101> roasbeef: the argument about code review is mostly just that mtp has been used before and it works, so there isn't a need for reviewers now to work out the possible mtp edge cases with start and timeout
20:30 < achow101> otoh height is conceptually similar, so reviewing that shouldn't be particularly difficult. and it's based on the existing mtp framework so the changes are super huge
20:30 < achow101> *aren't
20:32 < roasbeef> yeh you need to know the height in order to compute mtp lol
20:32 < jeremyrubin> roasbeef: you do actually
20:32 < jeremyrubin> we're targetting mid period MTPs to minimize drift
20:35 < jeremyrubin> here's the note I'm adding
20:35 < jeremyrubin> * For the avoidance of doubt, the UASF client would include logic to be compatible with ST's minimum
20:35 < jeremyrubin>   activation height and may be variously called a "UASF", "BIP8 LOT=true w/ minactiveheight for ST
20:35 < jeremyrubin>   compatibility", "ST + BIP8", or some other combination of phrases in different places
20:36 < roasbeef> jeremyrubin: height don't drift ;) -- only go up
20:37 < roasbeef> but i'm cool w/ w/e
20:37 < roasbeef> BIP8LTWMAHfSTC
20:37 < jeremyrubin> oh
20:37 < jeremyrubin> I think I injected a "don't"
20:37 < roasbeef> so is the plan to make ST a bip of its own since it doesn't have the MUST_SIGNAL state?
20:37 < jeremyrubin> we agree
20:37 < achow101> roasbeef: it is part of bip 8 now
20:38 < roasbeef> the bip that just keeps on giving
20:38 < jeremyrubin> I actually don't think a BIP is really required
20:38 < achow101> so my pr to core is actually 2/3 of bip 8
20:38 < jeremyrubin> technically ST is just BIP9 for a rule that doesn't activate till a fixed height
20:38 < jeremyrubin> could change 341 instead
20:38 < roasbeef> jeremyrubin: mhmm, would be nice if that's written down in one place tho
20:39 < achow101> bip 8 is like function: just keep adding more and more parameters to it
20:39 < roasbeef> lol right
20:39 < roasbeef> you can kinda ignore some of the params in practice I guess
20:40 < roasbeef> ok so I need to add one mo param, less params than expected
20:43 < roasbeef> we should mention a commit hash or something when we talk about bip 8 lol
20:43 < achow101> bip8 2021
20:44 < roasbeef> the text doesn't seem to match the example code, or maybe i'm not parsing this sentence correctly
20:45 < roasbeef> > Regardless of the value of lockinontimeout, if LOCKED_IN is reached, ACTIVE will be reached either one retarget period later, or at minimum_activation_height, whichever comes later.
20:45 < roasbeef> that should just be "active only happens after the min height" right?
20:46 < roasbeef> or I guess it's assuming you select the height w/ some additional criteria
20:48 < jeremyrubin> Also I think that we should spec for ST that minactivationheight SHOULD be expected to have to fall outside of the start/stop range.
20:50 < jeremyrubin> thanks for helping review my meeting notes
20:50 < achow101> roasbeef: that sentence is trying to account for when min activation height is during the signaling periods
20:50 < achow101> but english is hard
20:52 < jeremyrubin> achow101: I actually think it might be simpler to rebrand minactivationheight to fixedactivationheight for this?
20:52 < jeremyrubin> But I guess it's not technically true
20:52 < jeremyrubin> if we had absurd clock drift
20:53 < jeremyrubin> err
20:53 < jeremyrubin> it still is true
20:53 < jeremyrubin> err it's not
20:53 < jeremyrubin> if it doesn't activate
20:53 < achow101> jeremyrubin: min_actviation_heigt is generic enough to allow for it to be 0 for the usual method
20:53 < jeremyrubin> fair
20:53 < roasbeef> and the rationale for min actiation height is just something longer than a normal retarget period/
20:53 < achow101> and still be technically correct
20:53 < roasbeef> yeh that's what I was gonna do impl wise achow101
20:53 < jeremyrubin> it's just sorta confusing because we're using it as a fixed activation height
20:54 < jeremyrubin> and I don't think there's consensus on not having more periods of LOCKED_IN should min fall in the middle
20:54 < achow101> roasbeef: basically min_activation_height only effects the locked_in -> active transition. it's pretty much a one-liner in core
20:55 < jeremyrubin> so I think it's more a usage note than a requirement on the code
20:55 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
20:55 < achow101> if (height >= min_activation_height) { next = active; } else { next = locked_in; }
20:56 < achow101> articulating the effects in words is a bit harder which leads to the weird wording in the bip
20:57 < jeremyrubin> My suggestion is to update BIP8 to be ST compatible and make either a section or a new BIP which relies on BIP8 to define a "ST"
20:57 < jeremyrubin> BIP8 has a parameter space where it does diff things
20:57 < jeremyrubin> rather than try to rewrite or something else
20:58 < roasbeef> bip 7..."what happened to bip 9? well 7 ate.."
20:59 < roasbeef> what's the practical diff between ST and bip 9 (w/ maybe heights) that has a short period between start+end?
20:59 < roasbeef> jeremyrubin: I think it's already been updated: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#parameters
20:59 < roasbeef> function now has mo params
20:59 < achow101> roasbeef: wdym?
20:59 < roasbeef> I mean, what's the purpose of the min height? why is it better to have things lag instead of going to active after 2016 blocks
21:00 < roasbeef> lag as in go to active later
21:00 < achow101> the purpose is to allow ST to have a starttime/height be super close to software release. so the time for user nodes to upgrade is shifted to after lock in rather than before start
21:01 < achow101> there's a bit of a side effect of encouraging miners to false signal at the beginning because they'll have to upgrade after lock in
21:01 < achow101> *have time to upgrade
21:06 < roasbeef> has anyone here started to implement taproot wallet stuff? what purpose are ppl using for the keys generated for the top-level keyspend path?
21:07 < achow101> there's a proposal on the mailing list
21:09 < roasbeef> aight i'll just pick one for now
21:19 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 265 seconds]
21:42 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
21:46 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
22:03 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-qcfpgmsncdtvtiio] has quit [Ping timeout: 244 seconds]
22:34 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-kzwoeyrqdbyezhhf] has joined ##taproot-activation
23:13 -!- jonatack_ [~jon@37.165.85.219] has joined ##taproot-activation
23:14 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
23:15 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation
23:15 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Client Quit]
23:15 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation
--- Log closed Wed Mar 24 00:00:06 2021