--- Log opened Tue Feb 02 00:00:33 2021 00:24 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation 00:42 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 00:53 -!- fanquake_ [sid369002@gateway/web/irccloud.com/x-fabjqugvqpcyhsnz] has quit [Changing host] 00:53 -!- fanquake_ [sid369002@unaffiliated/fanquake] has joined ##taproot-activation 00:53 -!- fanquake_ [sid369002@unaffiliated/fanquake] has quit [Changing host] 00:53 -!- fanquake_ [sid369002@gateway/web/irccloud.com/x-fabjqugvqpcyhsnz] has joined ##taproot-activation 00:53 -!- fanquake_ is now known as fanquake 00:56 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 00:59 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined ##taproot-activation 01:17 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds] 01:19 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation 01:26 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 01:30 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 01:31 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 01:35 < robert_spigler> aj: thanks for the explanation! 02:19 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds] 02:20 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 02:51 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 264 seconds] 02:52 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 02:52 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: No Ping reply in 180 seconds.] 02:53 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation 03:01 < virtu> I was looking at the proposals in the wiki and noticed that the decreasing threshold variant didn't list a con to the effect of resulting in two forks with similar amounts of hashrate 03:14 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation 03:18 < michaelfolkson> This is the channel bobazY. If moneyball has the time to change the topic and then change the topic back again after the meeting he can but I don't think it is a big deal if he doesn't 03:21 < michaelfolkson> bobazY: Starts at 19:00 UTC so in around 8 hours 03:27 < bobazY> Great see you then michaelfolkson / rest! 03:37 -!- Ezis [Ezis@gateway/vpn/protonvpn/ezis] has quit [Quit: Leaving] 03:48 < michaelfolkson> virtu: Yeah I would agree with you from reading through the summary again though this is possible for other activation mechanisms too. 03:52 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has quit [Remote host closed the connection] 03:52 < michaelfolkson> It seems to me you effectively have this choice of either giving miners the ability to stop a soft fork potentially forever despite users and the rest of the community wanting it. Or you open this door to the (hopefully low) chance of a fork 03:54 < michaelfolkson> That's why ideally you get agreement from as what Andreas calls the different "constituents" of the ecosystem. If everyone is happy then there is no need for users, other constituents to force it through 03:54 < michaelfolkson> And no chance of a fork, chainsplit 03:55 < michaelfolkson> I think we're there with Taproot which is good 04:11 < virtu> michaelfolkson: "there" refering to agreement of all constituents? 04:13 < michaelfolkson> Right (my personal opinion obviously from what I have seen be made public) 04:14 < michaelfolkson> Certainly technical arguments expressed against Taproot have been close to non-existent 04:15 < virtu> michaelfolkson: I'm of the same opinion 04:16 < virtu> I'm eager to find out what the rest of the community thinks about this issue 04:17 < michaelfolkson> Well I think most also agree with that opinion. That's why activation mechanism is the topic of the meeting and not the merits of Taproot 04:23 < virtu> I wonder whether this agreement will influence the choice of activation mechanism; and if it should... 04:26 < michaelfolkson> Well again this discussion has been going on for months 04:26 < michaelfolkson> Thoughts of some developers http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin 04:26 < michaelfolkson> Thoughts of some mining pools https://taprootactivation.com/ 04:28 < michaelfolkson> But yeah in terms of there being agreement I think you want to let the agreement flow and hopefully get Taproot activated without too much fuss 04:35 < virtu> your first link is really informative, thanks 04:35 < virtu> how would one measure uptake of opt-in activation in case of flag day activation? 04:37 < virtu> It seems though that the consensus of the survey was to have opt-out rather than opt-in 04:44 < michaelfolkson> You referring to lockinontimeout = false? Or a flag day in a second or third phase after it fails to activate in the first phase? 04:46 < virtu> The survey included a question about how users should opt-in to flag day activation and I was wondering how to quantify nodes in favor and against flag day activation 04:51 < michaelfolkson> Nodes run a particular software version or set a configuration option. Nodes don't decide on what goes into blocks, miners do. A lot easier to quantify miners than nodes as nodes are sybillable. 04:51 < michaelfolkson> Of course nodes can reject a miner's blocks 04:54 < virtu> from your statement I deduce that measureing flag-day activation support of nodes is unpractical due to sybil attacks. is that correct? 04:56 < michaelfolkson> It is definitely harder but it depends on how nodes are signaling for a flag day activation. If it is running a particular version of the software you could observe which versions are being run on the network 04:56 < michaelfolkson> Still sybillable though 04:57 < michaelfolkson> (I wasn't involved in 2017 though and there are people with much more expertise on this subject than me.) 04:57 < virtu> I agree with that assesment. In addition, there's no "easy" way to measure node versions, in particular when it comes to non-listening nodes 04:58 < michaelfolkson> Right it would be listening nodes if you were to do this at all 04:59 < virtu> I hope it won't come to this 04:59 < virtu> seems very fragile 05:00 < michaelfolkson> Yeah I don't want to tempt fate but I think it is in everyone's interests (other than saboteurs) for this to go smoothly and quickly 05:00 < michaelfolkson> I don't think anyone has the appetite for another 2017 other than saboteurs 05:05 -!- kiwi_45 [946697ab@148.102.151.171] has joined ##taproot-activation 05:07 -!- kiwi_45 [946697ab@148.102.151.171] has quit [Client Quit] 05:08 -!- kiwi_45 [946697ab@148.102.151.171] has joined ##taproot-activation 05:08 -!- kiwi_45 is now known as AlexandreDC 05:08 -!- AlexandreDC [946697ab@148.102.151.171] has quit [Client Quit] 05:09 -!- AlexandreDC [946697ab@148.102.151.171] has joined ##taproot-activation 05:11 -!- AlexandreDC is now known as AlexandreChery 05:16 -!- AlexandreChery [946697ab@148.102.151.171] has quit [Quit: Connection closed] 05:27 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 05:28 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 05:34 -!- dralez [051dbff0@5.29.191.240] has joined ##taproot-activation 05:39 -!- dralez [051dbff0@5.29.191.240] has quit [Ping timeout: 248 seconds] 05:41 < belcher_> UASF in 2017 wasnt done by measuring nodes so much as measuring bitcoin businesses and merchants 05:41 < belcher_> bitrefill was a prominent bip148 supporter back then and their node had way way more influence than a node that nobody was using as a wallet 05:41 -!- belcher_ is now known as belcher 05:42 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds] 05:43 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 05:52 < michaelfolkson> But then all the businesses of the "New York Agreement" supported SegWit2x 05:53 * michaelfolkson shrugs 05:53 < michaelfolkson> It gets messy 05:53 < belcher> segwit2x is a hard fork 05:53 < belcher> thats the crucial difference 05:54 < michaelfolkson> But I can't imagine those businesses with SegWit2x failing suddenly became BIP 148 supporters 05:56 < belcher> there were plenty of businesses supporting bip148, at least enough to scare the miners into activating it a few days before 05:57 < belcher> i recommend this https://bitcoinmagazine.com/articles/op-ed-user-activated-soft-forks-and-intolerant-minority which should explain why a soft fork and hard fork are so different, because a soft fork is backwards-compatible 05:58 < michaelfolkson> Right but it was messy, that's my point. Sometimes mess is unavoidable but ideally you avoid mess 05:58 < belcher> in any case, taproot activation is so very different to how segwit was, because during segwit times there was asicboost and huge miner fees with nothing like LN to provide another way to transact 05:59 < belcher> we all focus on UASF because that was what happened last (generals always fight the last war), but we know that ~90% of mining pools say they'll signal for taproot and theres nothing like the politics and drama like there was in 2015-2017 06:00 < michaelfolkson> Yup 100 percent agree with that 06:17 -!- AlexandreChery [94669b7d@148.102.155.125] has joined ##taproot-activation 06:18 -!- AlexandreChery [94669b7d@148.102.155.125] has quit [Client Quit] 06:26 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined ##taproot-activation 06:32 -!- user1234567890 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has joined ##taproot-activation 06:33 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 06:33 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: Leaving] 06:34 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined ##taproot-activation 06:38 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Client Quit] 06:39 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined ##taproot-activation 06:52 -!- Jan [51cc0e98@81-204-14-152.fixed.kpn.net] has joined ##taproot-activation 06:52 -!- Jan [51cc0e98@81-204-14-152.fixed.kpn.net] has quit [Client Quit] 06:54 -!- JanB [51cc0e98@81-204-14-152.fixed.kpn.net] has joined ##taproot-activation 07:30 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 240 seconds] 07:46 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 07:47 -!- AlexandreChery [9466a323@148.102.163.35] has joined ##taproot-activation 07:48 -!- AlexandreChery [9466a323@148.102.163.35] has quit [Client Quit] 07:51 -!- JanB [51cc0e98@81-204-14-152.fixed.kpn.net] has quit [Quit: Connection closed] 07:52 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation 07:54 < virtu> me, too. I think all talk of UASF and flag days is detrimental to the relationship between what michaelfolkson called constituents. in case of taproot, all parties have economic incentives to adopt. given that agreement, UASF/flag day shouldn't even be needed as stick (in two-phase deployments) to speed up adoption 07:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 07:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 08:16 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has joined ##taproot-activation 08:20 -!- liberliver1 [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined ##taproot-activation 08:20 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has quit [Ping timeout: 256 seconds] 08:20 -!- liberliver1 is now known as liberliver 08:24 -!- btc_iota [2f9d7da2@47.157.125.162] has joined ##taproot-activation 08:24 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation 08:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 08:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 08:35 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has quit [Remote host closed the connection] 08:39 -!- AlexandreChery [9466a323@148.102.163.35] has joined ##taproot-activation 08:40 -!- AlexandreChery [9466a323@148.102.163.35] has quit [Client Quit] 08:45 < michaelfolkson> virtu: Firstly I'm taking Andreas Antonopoulos language from 2017. It is a simplistic model but I found it useful. Secondly, it is always good to have options if the worst happens however unexpected. I doubt they will be needed though in this case (I certainly hope that is the case anyway) 08:49 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation 08:53 -!- AlexandreChery [9466a323@148.102.163.35] has joined ##taproot-activation 08:56 -!- AlexandreChery [9466a323@148.102.163.35] has quit [Client Quit] 09:03 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 272 seconds] 09:13 -!- z7 [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has joined ##taproot-activation 09:32 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined ##taproot-activation 09:42 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 09:44 -!- AlexandreChery [9466964e@148.102.150.78] has quit [Client Quit] 09:45 -!- b77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has joined ##taproot-activation 09:47 -!- civboi [~civboi@153.33.34.102] has joined ##taproot-activation 09:58 -!- benthecarman [2883a985@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation 10:03 -!- benthecarman [2883a985@h133.169.131.40.static.ip.windstream.net] has quit [Quit: Connection closed] 10:03 -!- benthecarman [~ben@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation 10:05 < michaelfolkson> We'll get started in a hour. But feel free to chat or discuss anything Taproot activation related in the run up to it https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html 10:06 < michaelfolkson> Reminder to luke-jr and aj who will hopefully be attending 10:09 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds] 10:09 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 10:10 -!- pox [~pox@147.234.92.170] has joined ##taproot-activation 10:11 < benthecarman> Curious on people's thought on BIP 9, I know luke-jr is opposed. I feel like BIP 9 could be an okay solution instead of having to implement all new activation code in bitcoin core 10:12 < luke-jr> benthecarman: it's not "all new" - it's the BIP 9 code with the fixes made by BIP 8 10:13 < luke-jr> it'd be similar to saying let's not fix the inflation bug because it changes the code :P 10:14 < benthecarman> I think those are a bit different lol 10:14 < luke-jr> only slightly 10:14 < luke-jr> BIP 9's bugs are pretty catastrophic as we saw with Segwit 10:15 < michaelfolkson> aj also said a few days back if in the very unlikely scenario we needed to contemplate UASF revised BIP 8 is an improvement 10:15 < luke-jr> it incentivises sabotage and makes it dangerous to recover from it 10:16 < luke-jr> the only practical difference is the timespan (once a SF is activated, BIP 8/9 becomes irrelevant until the next one) 10:16 -!- MikeMarzig [6bf2750b@107.242.117.11] has joined ##taproot-activation 10:17 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 10:18 -!- AlexandreChery [9466964e@148.102.150.78] has quit [Client Quit] 10:18 -!- JanB [1fc9e0c9@201-224-201-31.ftth.glasoperator.nl] has joined ##taproot-activation 10:19 < benthecarman> Fair enough 10:20 -!- MikeMarzig [6bf2750b@107.242.117.11] has quit [Client Quit] 10:20 < michaelfolkson> I don't know who will show and what they want to talk about but I'm thinking we'll split the meeting into a two. High level discussion and Q&A on current state of Taproot activation in first part. And then focus on the PRs in the second half 10:20 < michaelfolkson> So for those who don't want to get into the detail of the PRs they can leave halfway through 10:21 < luke-jr> hmm 10:21 < michaelfolkson> No? Straight to the PRs? 10:21 < michaelfolkson> Open to suggestions :) 10:21 < luke-jr> depends on who shows I guess 10:22 < michaelfolkson> Yup I agree 10:22 < benthecarman> I feel like the high level discussion could quickly fall into discussion on AJs 2 PRs 10:23 < luke-jr> originally I was thinking review then high-level, but your order makes more sense 10:23 < luke-jr> since high-level could influence BIP/code 10:23 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 10:23 < michaelfolkson> Ok cool, we'll do that 10:23 < michaelfolkson> (my order) 10:24 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 10:25 -!- erijon [~erijon@2a0b:f4c2:2::1] has joined ##taproot-activation 10:25 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has joined ##taproot-activation 10:26 -!- AlexandreChery [9466964e@148.102.150.78] has quit [Client Quit] 10:27 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has quit [Client Quit] 10:27 -!- bitentrepreneur [uid39920@gateway/web/irccloud.com/x-zhybvvhwzpluynfq] has joined ##taproot-activation 10:27 < luke-jr> https://bitcoinhackers.org/@lukedashjr/105663065325685076 10:28 < michaelfolkson> Nice 10:28 < bitentrepreneur> hi 10:28 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation 10:28 < bitentrepreneur> alejandro here from taprootactivation.com 10:28 < bitentrepreneur> vp of poolin 10:28 < michaelfolkson> Hey bitentrepreneur! 10:29 < bitentrepreneur> glad to be here :) good iniative michael 10:29 -!- jimmy53 [589689c8@88.150.137.200] has joined ##taproot-activation 10:29 < michaelfolkson> Thanks for your work on the site 10:29 < bitentrepreneur> likewise thanks for this 10:29 < jimmy53> hi 10:29 < michaelfolkson> It was luke-jr and benthecarman's idea as I recall 10:29 -!- nikitis [~nikitis@67.197.67.235] has joined ##taproot-activation 10:29 -!- tonysanak [d847dcf5@216-71-220-245.dyn.novuscom.net] has joined ##taproot-activation 10:30 < bitentrepreneur> ah! thanks to them then! 10:30 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 10:30 < michaelfolkson> As I said earlier we'll get started in 30 minutes. But feel free to chat before then 10:30 -!- Calkob [52033acb@cpc78887-bele10-2-0-cust202.2-1.cable.virginm.net] has joined ##taproot-activation 10:33 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has joined ##taproot-activation 10:33 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has quit [Client Quit] 10:33 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has joined ##taproot-activation 10:33 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has quit [Client Quit] 10:34 -!- walletscrutiny [c9d78d27@pc-39-141-215-201.cm.vtr.net] has joined ##taproot-activation 10:34 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has joined ##taproot-activation 10:34 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has joined ##taproot-activation 10:34 -!- solairis [bdcb842e@fixed-189-203-132-46.totalplay.net] has joined ##taproot-activation 10:35 -!- MikeMarzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has joined ##taproot-activation 10:35 -!- Chimp [cf054c02@207.5.76.2] has joined ##taproot-activation 10:35 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has joined ##taproot-activation 10:36 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has quit [Client Quit] 10:36 -!- TechMiX [~techtux@2001:4649:61c8:0:da2c:c9fa:866f:1342] has joined ##taproot-activation 10:37 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has joined ##taproot-activation 10:38 -!- trooter [4a40f913@cpe-74-64-249-19.nj.res.rr.com] has joined ##taproot-activation 10:39 -!- andras [bc8ecbaa@catv-188-142-203-170.catv.broadband.hu] has joined ##taproot-activation 10:40 -!- yamaaan [6d2843ea@ip-109-40-67-234.web.vodafone.de] has joined ##taproot-activation 10:41 < pox> [noob q] are user-activation methods susceptible to sybil attacks? 10:42 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has quit [Client Quit] 10:42 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has joined ##taproot-activation 10:42 < luke-jr> no 10:43 -!- slade100 [aec590c4@196.sub-174-197-144.myvzw.com] has joined ##taproot-activation 10:43 < hsjoberg> I think BIP9 was clearly a mistake as we saw with SegWit. So right now I'm slightly in favor of BIP8 10:43 < belcher> if you get big businesses well-known brands saying they'd support it then how do you fake that? it takes a lot of time and energy to build up a well-known business.... but in either case it seems >90% of hash power says it will activate taproot so a UASF doesnt seem necessary 10:43 -!- research48 [51269cb7@183.red-81-38-156.dynamicip.rima-tde.net] has joined ##taproot-activation 10:44 -!- Isharo865 [b9d8210e@185.216.33.14] has joined ##taproot-activation 10:44 -!- AsILayHodling [d0402051@208.64.32.81] has joined ##taproot-activation 10:44 < luke-jr> belcher: there is no harm to scheduling the UASF, if miners activate sooner 10:44 < hsjoberg> Anyway most miners are saying they are onboard and many even want BIP8 (including AntPool ironically enough) 10:44 -!- Isharo865 [b9d8210e@185.216.33.14] has quit [Client Quit] 10:44 < michaelfolkson> pox: To the extent that anyone can spin up a large number of nodes that is true. But a lot of work has done by people to already assess that Taproot has a lot of community support 10:44 < michaelfolkson> *has been 10:45 < hsjoberg> @michaelfolkson splitting like you said sounds like a good idea 10:45 -!- yamaaan [6d2843ea@ip-109-40-67-234.web.vodafone.de] has quit [Ping timeout: 248 seconds] 10:45 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has quit [Client Quit] 10:45 -!- jimmy53 [589689c8@88.150.137.200] has quit [Quit: Connection closed] 10:45 < michaelfolkson> Thanks hsjoberg. I think so. We will lose people as we go more and more into the detail :) 10:45 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has joined ##taproot-activation 10:46 -!- orbuld [5c20f37e@c-7ef3205c.04-69-67626723.bbcust.telenor.se] has quit [Client Quit] 10:46 < michaelfolkson> We'll see how productive the conversation is to see when to move on to the PRs 10:47 < pox> michaelfolkson, actually I was thinking more of a scenario where miners are on board, but then a bug is found in the proposed fork near the end of the signaling period, and at that moment a malicious actor spins up N nodes that force miners to go along with the buggy fork. 10:47 < hsjoberg> pox: Not really no. But it would mess with statistics 10:47 < belcher> activation isnt the right place to find and fix bugs, that should happen during code review 10:48 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has joined ##taproot-activation 10:48 < michaelfolkson> pox: I think that (unlikely) scenario would be messy regardless 10:48 < luke-jr> pox:the only nodes that can force anything on miners, are nodes people are actually receiving payments with 10:48 < michaelfolkson> But right as belcher says code review should be frontloaded before activation 10:48 < luke-jr> and yes, before activation is set at all, we really want to be sure there are no bugs ☺ 10:49 < hsjoberg> Running fullnode only makes sense if you do transactions. So if you spin up a bunch of nodes that do nothing with the rest of the network, it's irrelevant 10:49 -!- satosaurian [b0c7d365@ip-176-199-211-101.hsi06.unitymediagroup.de] has joined ##taproot-activation 10:49 -!- btee [aecc42cd@205.sub-174-204-66.myvzw.com] has joined ##taproot-activation 10:49 -!- mick [b94187e6@185.65.135.230] has joined ##taproot-activation 10:49 -!- IT4Crypto [c9fb8518@host201-251-133-24.elbolson.com] has joined ##taproot-activation 10:49 -!- mick is now known as Guest69468 10:50 -!- IT4Crypto37 [b5d62811@181.214.40.17] has joined ##taproot-activation 10:51 < TechMiX> noob q: what's the difference between BIP9 and BIP8(false) ? 10:52 < luke-jr> TechMiX: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Contrasted_with_BIP_9 10:52 < luke-jr> the ability to set lockinontimeout=true later, and using block heights instead of clock time 10:52 < pox> what's the criterion for being considered an economic node? what if a sybil attacker is willing to spend just enough money to get txs into the blockchain in a manner that relies on the (hypothetically buggy) soft fork? 10:53 < hsjoberg> In short, it's BIP9 but you'll have a lock-in after a deadline, should miners not coorporate 10:53 < TechMiX> luke-jr: Thanks luke. 10:53 -!- IT4Crypto [c9fb8518@host201-251-133-24.elbolson.com] has quit [Client Quit] 10:53 -!- satosaurian [b0c7d365@ip-176-199-211-101.hsi06.unitymediagroup.de] has quit [Client Quit] 10:53 -!- niftynei [~niftynei@104.131.77.55] has joined ##taproot-activation 10:53 < luke-jr> pox: receiving payments for which you can penalise the payer for a bogus transaction 10:53 -!- tonysanak [d847dcf5@216-71-220-245.dyn.novuscom.net] has quit [Quit: Ping timeout (120 seconds)] 10:53 -!- research48 [51269cb7@183.red-81-38-156.dynamicip.rima-tde.net] has quit [Quit: Ping timeout (120 seconds)] 10:53 -!- Guest69468 [b94187e6@185.65.135.230] has quit [Client Quit] 10:53 -!- JanB [1fc9e0c9@201-224-201-31.ftth.glasoperator.nl] has quit [Quit: Ping timeout (120 seconds)] 10:53 -!- walletscrutiny [c9d78d27@pc-39-141-215-201.cm.vtr.net] has quit [Quit: Ping timeout (120 seconds)] 10:53 -!- Calkob [52033acb@cpc78887-bele10-2-0-cust202.2-1.cable.virginm.net] has quit [Quit: Ping timeout (120 seconds)] 10:53 -!- kanon [0e3f7859@14.63.120.89] has joined ##taproot-activation 10:53 -!- tonysanak [d847dcf5@216-71-220-245.dyn.novuscom.net] has joined ##taproot-activation 10:53 -!- JanB [1fc9e0c9@201-224-201-31.ftth.glasoperator.nl] has joined ##taproot-activation 10:54 -!- trooter [4a40f913@cpe-74-64-249-19.nj.res.rr.com] has quit [Quit: Ping timeout (120 seconds)] 10:54 < luke-jr> eg, by not shipping the product, cutting off service, etc 10:54 -!- IT4Crypto37 [b5d62811@181.214.40.17] has quit [Client Quit] 10:54 -!- MikeMarzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- user1234567890 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- Chimp [cf054c02@207.5.76.2] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- slade100 [aec590c4@196.sub-174-197-144.myvzw.com] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- schulzemic [~ada@193.27.14.104] has joined ##taproot-activation 10:54 -!- z7 [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- btee [aecc42cd@205.sub-174-204-66.myvzw.com] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- btc_iota [2f9d7da2@47.157.125.162] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- user1234567890 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has joined ##taproot-activation 10:54 < pox> luke-jr ah. thanks. I'll shut up and think about it more now. 10:54 -!- snash779 [9eb54db9@158.181.77.185] has joined ##taproot-activation 10:54 -!- Billy [86290e1a@hlfxns018gw-134-41-14-26.dhcp-dynamic.fibreop.ns.bellaliant.net] has joined ##taproot-activation 10:54 -!- research48 [51269cb7@183.red-81-38-156.dynamicip.rima-tde.net] has joined ##taproot-activation 10:54 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 10:54 < luke-jr> that's a lot of ping timeouts :/ 10:54 -!- freerk [5c74722d@i5C74722D.versanet.de] has joined ##taproot-activation 10:54 -!- CodeShark____ [sid126576@gateway/web/irccloud.com/x-lykhywlaecnkcjgo] has joined ##taproot-activation 10:54 -!- solairis [bdcb842e@fixed-189-203-132-46.totalplay.net] has quit [Quit: Ping timeout (120 seconds)] 10:54 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has joined ##taproot-activation 10:55 -!- IT4Crypto [83ff04ee@131.255.4.238] has joined ##taproot-activation 10:55 -!- btc_iota [2f9d7da2@47.157.125.162] has joined ##taproot-activation 10:55 -!- suntsu8 [~suntsu@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-activation 10:55 -!- gloved [8d6267fb@141.98.103.251] has joined ##taproot-activation 10:55 -!- solairis [bdcb842e@fixed-189-203-132-46.totalplay.net] has joined ##taproot-activation 10:55 -!- MikeMarzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has joined ##taproot-activation 10:55 < kanon> nice to meet you! (y) 10:55 -!- satosaurian [b0c7d365@ip-176-199-211-101.hsi06.unitymediagroup.de] has joined ##taproot-activation 10:55 -!- walletscrutiny [c9d78d27@pc-39-141-215-201.cm.vtr.net] has joined ##taproot-activation 10:55 -!- jonny100051 [58d4b41d@88.212.180.29] has joined ##taproot-activation 10:55 -!- research48 [51269cb7@183.red-81-38-156.dynamicip.rima-tde.net] has quit [Client Quit] 10:55 -!- Alistair_Mann [56ab68b9@host86-171-104-185.range86-171.btcentralplus.com] has joined ##taproot-activation 10:55 < bitentrepreneur> 5 min to go 10:56 < luke-jr> kinda late, but it may be beneficial to read over BIP 8 :p 10:56 * gloved plays taproot fanfare song 10:56 -!- squiffy20 [b9c3e896@185.195.232.150] has joined ##taproot-activation 10:56 < bobazY> this one is good: https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next (by AaronvanW ) 10:57 < aj> *yawn* 10:57 < michaelfolkson> Ha 10:57 < michaelfolkson> Sorry for the sleep torture aj 10:57 -!- btcbb [d5399d8e@213.57.157.142] has joined ##taproot-activation 10:57 -!- alius87 [534e47d0@208.71.78.83.dynamic.wline.res.cust.swisscom.ch] has joined ##taproot-activation 10:57 -!- roasbeef [~root@104.131.26.124] has joined ##taproot-activation 10:58 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 10:58 -!- Chimp [cf054c02@207.5.76.2] has joined ##taproot-activation 10:58 * gloved passes coffees to aussies 10:58 < luke-jr> good meeting, thanks for coming all 10:58 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has quit [Client Quit] 10:58 -!- edoneerf [6b837dbf@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has joined ##taproot-activation 10:58 -!- gr-g76 [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has joined ##taproot-activation 10:58 < luke-jr> jk ☺ 10:58 -!- squiffy20 [b9c3e896@185.195.232.150] has quit [Client Quit] 10:58 < bitentrepreneur> lol 10:58 -!- pY61FlIVov44lCnk [5cba724a@92.186.114.74] has joined ##taproot-activation 10:58 -!- bitconner [~root@138.68.244.82] has joined ##taproot-activation 10:59 -!- gr-g76 [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has quit [Client Quit] 10:59 -!- lucasmoten [~lucasmote@45.146.55.219] has joined ##taproot-activation 10:59 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has joined ##taproot-activation 10:59 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has joined ##taproot-activation 10:59 < luke-jr> hmm, do we have the meeting bot here? 10:59 < luke-jr> jonasschnelli: 10:59 < michaelfolkson> I don't think so 10:59 -!- ryanthegentry [8831d538@136.49.213.56] has joined ##taproot-activation 10:59 -!- norisgOG [~norisgOG@dslb-088-066-245-006.088.066.pools.vodafone-ip.de] has joined ##taproot-activation 11:00 -!- janoside [44eb2b54@68.235.43.84] has joined ##taproot-activation 11:00 < michaelfolkson> But regardless... 11:00 -!- z88 [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has joined ##taproot-activation 11:00 < michaelfolkson> #startmeeting 11:00 < emzy> hi 11:00 < schmidty> hi 11:00 < fjahr> hi 11:00 < benthecarman> hi 11:00 < belcher> hi 11:00 < btcbb> hi 11:00 < bobazY> hi 11:00 < darosior> hi 11:00 < AaronvanW> hi 11:00 < norisgOG> hi 11:00 < erijon> hi 11:00 < gloved> hi 11:00 -!- friendly_arthrop [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has joined ##taproot-activation 11:00 < luke-jr> hi 11:00 < michaelfolkson> OK welcome. This is an experimental meeting on Taproot activation 11:00 < CodeShark____> hi 11:00 < hsjoberg> hi 11:00 < solairis> hi 11:00 < TechMiX> hi 11:00 < AsILayHodling> hi 11:00 < lucasmoten> hi 11:00 < jonny100051> hi 11:00 -!- ajonas__ [sid385278@gateway/web/irccloud.com/x-hdjjphhkyxisxfqq] has quit [] 11:00 < moneyball> hi 11:00 < Billy> hi 11:00 < snash779> hi 11:00 < tonysanak> hi 11:00 < dr_orlovsky> hi 11:00 -!- Stijnbtc_ [~StijnBtc@77-165-254-59.fixed.kpn.net] has joined ##taproot-activation 11:00 < michaelfolkson> Seems a lot of people, welcome all 11:01 < bitentrepreneur> hi :) 11:01 < roconnor> hi 11:01 < ghost43> hi 11:01 < michaelfolkson> So the plan in this experimental meeting is to discuss Taproot activation 11:01 < aj> hey 11:01 < felixweis> hi! 11:01 -!- wangchun_ [uid444603@gateway/web/irccloud.com/x-clwiemgrswhavjfu] has joined ##taproot-activation 11:01 < kanzure> hi 11:01 < michaelfolkson> The first part will be higher level, the second part will be focused on the PRs that still need some work (and review) 11:01 -!- CriptoLuis [be9ba048@190.155.160.72] has joined ##taproot-activation 11:01 -!- btclove [51dd4037@81.221.64.55] has joined ##taproot-activation 11:01 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-activation 11:02 -!- gritcoin [43b989a4@c-67-185-137-164.hsd1.wa.comcast.net] has joined ##taproot-activation 11:02 -!- tommy1 [~tommy@13.84-234-189.customer.lyse.net] has joined ##taproot-activation 11:02 < michaelfolkson> I sent this to the mailing list with links to resources that I found very useful 11:02 < hebasto> hi 11:02 < michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html 11:02 < luke-jr> michaelfolkson: maybe we should start over in a few mins since people are still joining 11:02 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has joined ##taproot-activation 11:02 -!- ajonas [sid385278@gateway/web/irccloud.com/x-ywrjihwxueudgghe] has joined ##taproot-activation 11:02 < michaelfolkson> Sure, we can wait a couple of minutes 11:02 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has quit [Client Quit] 11:03 < wangchun_> Hello, everyone! 11:03 -!- user1234567890 [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has quit [Quit: Connection closed] 11:03 < michaelfolkson> In terms of general housekeeping please be civil. Presumably we all want the same thing, Taproot activation as soon as is viable 11:03 < nikitis> This Taproot is just the ability to add smart contracts to bitcoin? 11:03 -!- jbeddict [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has joined ##taproot-activation 11:03 < michaelfolkson> Not the right meeting sorry nikitis 11:03 < kanzure> bitcoin already has scripts 11:03 -!- tommy1 is now known as oxtr 11:03 -!- alexandrev [~alexandre@cpe-24-193-76-156.nyc.res.rr.com] has joined ##taproot-activation 11:03 < achow101> hi 11:04 < michaelfolkson> Focused on activation mechanism 11:04 -!- alius87 [534e47d0@208.71.78.83.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 248 seconds] 11:04 < proofofkeags> hi 11:04 < bitentrepreneur> hi Wangchun 11:04 < hsjoberg> nikitis: It helps with smart contracting, bitcoin already has it. But it also provides other goodies. 11:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 11:04 < AaronvanW> Here's my explainer for those who don't know what Taproot is: https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin 11:04 < michaelfolkson> Lots of good resources on the benefits of Taproot 11:04 < luke-jr> guess most everyone is here now 11:04 < AaronvanW> (There are probably others too, but that's the one I wrote.) 11:04 < michaelfolkson> Thanks AaronW 11:04 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 11:04 < luke-jr> AaronvanW: thanks 11:04 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has joined ##taproot-activation 11:04 < michaelfolkson> * AaronvanW 11:04 < luke-jr> inb4 another 50 join :P 11:04 < michaelfolkson> Ok haha 11:04 -!- r251d [~r251d@50.121.84.2] has joined ##taproot-activation 11:05 < andrewtoth> hi 11:05 < michaelfolkson> So as I said we'll start higher level by reviewing those resources I shared in that mailing list post 11:05 < nikitis> AaronvanW: yeah I read that already, just wanted to hear from here as well 11:05 < luke-jr> [19:02:11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html 11:05 < michaelfolkson> If you have basic questions the first half of the meeting is your time to ask these questions 11:05 -!- arfon [554ca4c1@85-76-164-193-nat.elisa-mobile.fi] has joined ##taproot-activation 11:05 < michaelfolkson> The second half will be PR discussion 11:05 -!- matthewblack [~matthewbl@ip-45-41-170-185.fibre.fibrestream.ca] has joined ##taproot-activation 11:05 -!- Chimp [cf054c02@207.5.76.2] has quit [Quit: Connection closed] 11:05 < kanzure> which PRs? 11:06 -!- arfon [554ca4c1@85-76-164-193-nat.elisa-mobile.fi] has quit [Client Quit] 11:06 < michaelfolkson> It is in that mailing list post kanzure 11:06 -!- darbsllim [63f253a4@gateway/web/cgi-irc/kiwiirc.com/ip.99.242.83.164] has joined ##taproot-activation 11:06 < michaelfolkson> At the bottom 11:06 < luke-jr> https://github.com/bitcoin/bips/pull/1020 https://github.com/bitcoin/bips/pull/1021 11:06 -!- gz77 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:06 < luke-jr> https://github.com/bitcoin/bitcoin/pull/19573 11:06 < darbsllim> hello 11:06 -!- Unlessheown [25a2276d@37.162.39.109] has joined ##taproot-activation 11:06 < hsjoberg> See here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html 11:06 < proofofkeags> Should we post questions now or wait? 11:06 -!- CriptoLuis [be9ba048@190.155.160.72] has quit [Quit: Connection closed] 11:06 < bitentrepreneur> questions now 11:06 < IT4Crypto> In case there is more than 1 activation mode it is possible to have a BIP91 approach, right? or there is some limitiation and it is mandatory to have only one method? 11:06 < michaelfolkson> Yeah shoot proofkeags 11:06 < proofofkeags> What is the primary reason *not* to do it via Bip8/9 11:06 < michaelfolkson> *proofofkeags 11:06 -!- narcelio [~nf@179.186.160.103] has joined ##taproot-activation 11:06 -!- Raincloud [ac532845@172.83.40.69] has joined ##taproot-activation 11:07 -!- Zeven74 [33afe11f@31.51-175-225.customer.lyse.net] has joined ##taproot-activation 11:07 -!- rand0m [53d14312@h83-209-67-18.cust.a3fiber.se] has joined ##taproot-activation 11:07 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-activation 11:07 < hsjoberg> IT4Crypto: If we keep current miner signaling yeah sure BIP91 would be possible 11:07 < luke-jr> IT4Crypto: BIP91 was essentially a miner attack that we tolerated for the outcome 11:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 11:07 -!- fodediop [~fode@41.214.90.237] has joined ##taproot-activation 11:07 -!- Unlessheown [25a2276d@37.162.39.109] has quit [Client Quit] 11:07 < hsjoberg> Indeed 11:07 < luke-jr> proofofkeags: what do you have in mind? 11:08 < MikeMarzig> are there any activation methods other than bip8 or bip9 that are being seriously considered?  or are we basically just debating bip8 vs bip9? 11:08 < luke-jr> BIP 9 isn't being seriously considered either IMO :P 11:08 < michaelfolkson> If you look at the wiki post David Harding did (first link in my mailing list post) the primary proposals are described there https://en.bitcoin.it/wiki/Taproot_activation_proposals 11:08 -!- Unlessheown [25a2276d@37.162.39.109] has joined ##taproot-activation 11:08 < IT4Crypto> I thought BIP91 was the way to avoid a eary split in BTC2X 11:08 < darbsllim> Is it true that people are afraid to hit the button due to UASF PTSD? Do we need to do something like: 11:08 < hsjoberg> IT4Crypto: If we go with BIP8 there's no need for BIP91 really, we would just have to wait until the deadline is reaches (in which nodes will lock in automatically) 11:08 < darbsllim> 1) create an anon account to push the button 11:08 < luke-jr> I see it as finishing the details of BIP 8 (which can still change) and deciding activation params 11:08 -!- rand0m [53d14312@h83-209-67-18.cust.a3fiber.se] has quit [Client Quit] 11:08 -!- Stijnbtc_ [~StijnBtc@77-165-254-59.fixed.kpn.net] has quit [Quit: Leaving] 11:08 -!- fly [acf817d6@cpe-172-248-23-214.socal.res.rr.com] has joined ##taproot-activation 11:08 < darbsllim> 2) get coincenter to backup the core devs/maintainer? 11:08 -!- v33r [622218ac@c-98-34-24-172.hsd1.il.comcast.net] has joined ##taproot-activation 11:09 < proofofkeags> got it, so we aren't debating y/n on Bip8 so much as just the params? 11:09 < AaronvanW> is anyone in favor of BIP9? 11:09 -!- Guest79 [c11b0d8e@193.27.13.142] has joined ##taproot-activation 11:09 < fjahr> It seems pretty uncontroversial that is should be done with an updated BIP8 11:09 -!- trooter [4a40f913@cpe-74-64-249-19.nj.res.rr.com] has joined ##taproot-activation 11:09 < MikeMarzig> @luke-jr agreed 11:09 -!- MN99 [~textual@cpe589630a45781-cm589630a4577f.cpe.net.cable.rogers.com] has joined ##taproot-activation 11:09 < luke-jr> hsjoberg: thanks to some changes aj made a year or so ago, BIP 8 can be moved forward in time too 11:09 < michaelfolkson> darbsllim: This is a discussion to advance towards a decision 11:09 < luke-jr> proofofkeags: there are still some proposed changes to BIP 8 itself 11:09 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 11:09 < proofofkeags> understood, thank you 11:09 -!- yunier2002 [~yunier200@c-73-85-126-91.hsd1.fl.comcast.net] has joined ##taproot-activation 11:09 < aj> MikeMarzig: "modern soft fork activation" is another approach being considered, but i think that's more or less implementable via bip8. "bip9" can be done via bip8 with careful param choice, with the only differences being ones that don't really matter 11:09 < rusty> (Worth noting that BIP-8 is basically a superset of BIP-9). As BIP-9 coauthor, I prefer BIP-8 for future activations (once the proposed PRs are merged which fix some corner cases). 11:10 -!- thatoneprivacygi [25782e93@37.120.46.147] has joined ##taproot-activation 11:10 < bitentrepreneur> poolin doesn't mind if it's either thru bip 9 or bip 8 11:10 < achow101> what's the holdup on the BIP 8 changes? 11:10 < roasbeef> rusty: iiuc, BIP-8 is just a "after this point it'll activate, with caveats" on top of bip 9 right? 11:10 -!- maximalismo [62f0b3dc@gateway/web/cgi-irc/kiwiirc.com/ip.98.240.179.220] has joined ##taproot-activation 11:10 -!- Unlessheown [25a2276d@37.162.39.109] has quit [Client Quit] 11:10 -!- StijnBtc [~StijnBtc@77-165-254-59.fixed.kpn.net] has joined ##taproot-activation 11:10 < benthecarman> Given that bip 8 is likely the activation method to be used, what starting params are people thinking. Imo it should start 1 month after the core release as bip 8 false with a 1 yaer timeout 11:11 < hsjoberg> darbsllim: Wladimir is usually the one who pushes the button. I would say the reason the the delay is probably because the activation should be an community effort. Which basically eventually led to this meeting. 11:11 < aj> roasbeef: not any more, there's a specific parameter (lockinontimeout = true/false) that triggers that behaviour 11:11 < wangchun_> Has Binance responded? 11:11 -!- prusnak [sid403625@gateway/web/irccloud.com/x-mzyynxklwhxatlbs] has joined ##taproot-activation 11:11 < luke-jr> the first proposed change to BIP 8 is to get rid of the mandatory miner signalling during the LOCKED_IN phase; this would mean miners only need to signal if they fail to activate via MASF 11:11 < bitentrepreneur> yes they did 11:11 < fjahr> bitentrepreneur: I assumed from your website that this was not taking into account updates to BIP8, is that correct? 11:11 < bitentrepreneur> they said "yes" but not activation method 11:11 < bitentrepreneur> specified 11:11 < bitentrepreneur> no* 11:11 < rusty> roasbeef: see aj's response (he's more awake than I am, kudos!) 11:11 < luke-jr> roasbeef: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Contrasted_with_BIP_9 11:11 < hsjoberg> luke-jr: Would you mind explaining briefly how that works? 11:11 -!- phantomcircuit [~phantomci@2604:a880:1:20::f2:c001] has joined ##taproot-activation 11:11 < michaelfolkson> bitentrepreneur's site with mining pool views: https://taprootactivation.com 11:11 < darbsllim> luke-jr miners are already 91%+ signalling in favor of activating taproot 11:11 < bitentrepreneur> taprootactivation.com 11:12 < luke-jr> darbsllim: there is zero signalling right now 11:12 < gloved> Has anyone heard any justification from miners why mining taproot blocks would be more costly for them to make? (how segwit destroyed asic boost ) 11:12 < roasbeef> aj: ah intesting, ok I think I'm caught up now, peeped the new state machine diagram on the PRs as well 11:12 < bitentrepreneur> i updated %'s today and added two smaller pools from the US (they still havent responded) 11:12 -!- alius83 [534e47d0@208.71.78.83.dynamic.wline.res.cust.swisscom.ch] has joined ##taproot-activation 11:12 < benthecarman> gloved: no, that shouldn't be an issue with taproot 11:12 < gz77> darbsllim I don’t think we want coincenter to be involved in bitcoin development issues 11:12 < CodeShark____> a quick reminder that signaling is merely about reducing fork risks and has nothing to do with political support 11:12 < hsjoberg> wangcun_: Respond to what? 11:12 < aj> globed: i haven't 11:13 < aj> gloved: i haven't 11:13 -!- mememe [494e69ac@c-73-78-105-172.hsd1.co.comcast.net] has joined ##taproot-activation 11:13 -!- anna754839 [b94187e6@185.65.135.230] has joined ##taproot-activation 11:13 < AaronvanW> if no one is in favor of BIP9 I suppose the question is indeed what parameters to pick for BIP8. Duration / hash power lock-in / forced activation true or false. (Right?) 11:13 < luke-jr> as BIP 8 is right now, miners can lock-in the softfork by signalling N%, or when we get to block height M, it will lock-in anyway (if lockinontimeout=true) 11:13 < nickler> it would help to distinguish between bip8(lockinontimeout=true) and bip8(lockinontimeout=false) when referring to bip 8 whenever possible 11:13 -!- mememe [494e69ac@c-73-78-105-172.hsd1.co.comcast.net] has quit [Client Quit] 11:13 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-cdljmnidcybkxqei] has joined ##taproot-activation 11:13 -!- drebbly [8ac7341e@138.199.52.30] has joined ##taproot-activation 11:13 < luke-jr> after locked in, miners must all signal they acknowledge and are enforcing the new rules (2 weeks before the new rules are actuially enforced) 11:14 < gloved> So the main impediment to activation is mining infrastructure software updates to ensure the market gets sufficient hash rate? 11:14 -!- smurfs [25c83b43@67.59.200.37.customer.cdi.no] has joined ##taproot-activation 11:14 < benthecarman> AaronvanW: I believe that'd be the most productive use of our time here 11:14 < fjahr> AaronvanW: That's my perception as well 11:14 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has joined ##taproot-activation 11:14 < luke-jr> with aj's first PR, this changes: miners no longer need to signal once it's locked in 11:14 < hsjoberg> gloved: As Taproot are still just bitocoin transactions, I don't see why that would be the case... Though I recall hearing the exact same FUD about SegWit 11:14 -!- carlakc [uid471474@gateway/web/irccloud.com/x-qisnqdlibmhvayzj] has joined ##taproot-activation 11:14 < michaelfolkson> AaronvanW: Right and aj got some views from developers here: http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin 11:14 < achow101> luke-jr: iiuc it's moved to a new MUST_SIGNAL phase 11:15 < achow101> not that there isn't any signaling, just a new phase added for it 11:15 < luke-jr> achow101: MUST_SIGNAL is already merged a long time ago 11:15 < achow101> ah ok 11:15 < luke-jr> it only occurs if we fallback on UASF mode 11:15 < luke-jr> with the MASF path, there is no forced signalling at all (with PR A) 11:15 < aj> achow101: MUST_SIGNAL only occurs if the timeout is reached with lockinontimeout=true; at present 100% signalling is required during LOCKEDIN as well 11:15 -!- richsmon [bca7a5aa@188-167-165-170.static.chello.sk] has joined ##taproot-activation 11:15 -!- richsmon [bca7a5aa@188-167-165-170.static.chello.sk] has quit [Client Quit] 11:15 -!- alius83 [534e47d0@208.71.78.83.dynamic.wline.res.cust.swisscom.ch] has quit [Client Quit] 11:15 < hsjoberg> Makes sense 11:15 -!- ryan87 [541127c9@84.17.39.201] has joined ##taproot-activation 11:16 < luke-jr> in the context of being clear that the de jure rules for the chain include Taproot, this is fine I think 11:16 < wangchun_> Do we have a BIP for UASF? 11:16 < luke-jr> but it means some subset of miners might fail to upgrade 11:16 -!- krakatoa69 [49cb5a1f@c-73-203-90-31.hsd1.co.comcast.net] has joined ##taproot-activation 11:16 < michaelfolkson> Ultimately one of these needs to be chosen as the activation mechanism but I'm not expecting that to happen today: https://en.bitcoin.it/wiki/Taproot_activation_proposals 11:16 < luke-jr> wangchun_: BIP 8 includes both MASF and UASF 11:17 -!- drebbly [8ac7341e@138.199.52.30] has quit [Client Quit] 11:17 < gloved> Given the signaling requirements, What type of stalling or griefing attack could a mining pool achieve if they value stalling taproot? Eg abusing the marginal hashrate required for activation 11:17 < luke-jr> wangchun_: MASF is the preferred path, with UASF as a fallback if miners fail to signal 11:17 -!- porra [569b0811@host86-155-8-17.range86-155.btcentralplus.com] has joined ##taproot-activation 11:17 < luke-jr> michaelfolkson: not necessarily one of those 11:17 < roasbeef> luke-jr: well put, prob the most succicnt way to summarize 11:17 < bitentrepreneur> i believe MASF can be achieved 11:17 < michaelfolkson> Oh ok, thanks for the correction luke-jr :) 11:17 -!- porra [569b0811@host86-155-8-17.range86-155.btcentralplus.com] has quit [Client Quit] 11:17 < belcher> gloved i dont know what would motivate any pool to do that, if a pool had objections to taproot we surely wouldve heard about it by now 11:17 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation 11:17 < benthecarman> Can we discuss potential bip 8 params (start time, timeout, & lockinontimeout)? 11:18 < luke-jr> gloved: the community could move the UASF sooner if it's clear someone is stalling it 11:18 -!- timeerr [028a071a@26.red-2-138-7.dynamicip.rima-tde.net] has joined ##taproot-activation 11:18 < luke-jr> benthecarman: IMO the PRs need to be sorted out first 11:18 < michaelfolkson> benthecarman: We can if there is nothing left to discuss on those high level proposals 11:18 < aj> gloved: without a bip-91 like miner attack, a miner who can maintain >5% (or >10% depending on 90%/95% threshold choice) can block activation until the UASF timeout occurs (assuming a UASF happens at all) 11:18 < gloved> belcher anti social or adversarial agent who wants to grief Bitcoin’s utility 11:18 -!- gz77 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Quit: Connection closed] 11:18 -!- wtr [31c7d190@pa49-199-209-144.pa.vic.optusnet.com.au] has joined ##taproot-activation 11:18 -!- timeerr [028a071a@26.red-2-138-7.dynamicip.rima-tde.net] has quit [Client Quit] 11:18 < JanB> bitentrepreneur has any mining pool expressed objections to taproot? 11:18 < bitentrepreneur> none 11:18 < luke-jr> JanB: it shouldn't matter 11:18 < luke-jr> miners do not decide protocol changes 11:18 -!- pwd [08095039@8.9.80.57] has joined ##taproot-activation 11:18 < bitentrepreneur> some didn't want to answer, but they were small 11:18 < michaelfolkson> At least from a mining pool perspective BIP 8 (false) seems to be the preferred option 11:18 -!- wtr [31c7d190@pa49-199-209-144.pa.vic.optusnet.com.au] has quit [Client Quit] 11:19 -!- guggero [50fd5efc@80.253.94.252] has joined ##taproot-activation 11:19 < willcl_ark> What are the arguments against using BIP8 (true, 1year) give that code review is complete and merged? As otherwise that seems to appease most people in one shot as far as I can see... 11:19 < wangchun_> Bitcoin has one of the worst onchain governance I have ever seen 11:19 < achow101> I think it's reasonable to start out with the BIP 9 equivalent, i.e. BIP8(false, 1y). This is a known activation pattern and generally the beginning of the existing proposals afaict 11:19 -!- wtr [31c7d190@pa49-199-209-144.pa.vic.optusnet.com.au] has joined ##taproot-activation 11:19 < bitentrepreneur> lol 11:19 < michaelfolkson> But as luke-jr says mining pools are only one constituent 11:19 < nickler> What's wrong with "Start now, improve later" (as defined on the wiki page, perhaps with some tweaks)? Seems to be something people could compromise on according to aj's survey. 11:19 < wangchun_> If mining pools are the only one, 11:19 < gloved> aj that threshold is why I favor lower activation thresholds (make it exceptionally costly to stall out activation by requiring significant hash rate) 11:19 < wangchun_> UASF shouldn’t be an option 11:19 < dr_orlovsky> what is the release date for Bitcoin Core with updated activation mechanism (let's say BIP-8 with all parameters community will decide on). May 2021? 11:19 < wangchun_> I’ve been thinking this way since segwit 11:19 < luke-jr> dr_orlovsky: whenever it's ready 11:19 < belcher> achow101 agreed with that 11:19 < luke-jr> dr_orlovsky: softforks are not part of the usual schedule 11:20 -!- Isharo865 [57a133be@p57a133be.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 11:20 -!- pwd [08095039@8.9.80.57] has quit [Client Quit] 11:20 -!- krvopije [~krvopije@mobiledyn-185-69-244-189.mrsn.at] has joined ##taproot-activation 11:20 < luke-jr> wangchun_: ? 11:20 < hsjoberg> willcl_ark: What does onchain governance mean? 11:20 -!- bitbug42 [b08da8bf@176-141-168-191.abo.bbox.fr] has joined ##taproot-activation 11:20 < willcl_ark> hsjoberg: no idea 11:20 < wangchun_> And consider this is less controversial 11:20 < michaelfolkson> wangchun_: UASF isn't one of the options on the harding doc https://en.bitcoin.it/wiki/Taproot_activation_proposals 11:20 < willcl_ark> ask wangchun_ :) 11:20 < rusty> The original logic of the BIP-9 protocol was to allow an escape hatch (failed activation) if we found some last-minute issue. I did not consider that this ability to prevent an upgrade would be abused, however, but it's still comforting to have, IMHO. 11:20 < hsjoberg> willcl_ark: Miner activated coordination mechanism is a more safe bet, with BIP8 and the deadline reached nodes will just force-through the activation, which is a bit scary. 11:20 < fjahr> nickler: I have heard arguments that a long period like 2y would lead to people procrastinating for a year 11:21 < CodeShark____> we should make sure there is overwhelming support for taproot from users (including mining pools) before proceeding. if there are any objections, even though miners do not determine the protocol, miners cooperating in the activation makes for a much smoother transition 11:21 < hsjoberg> That's why the deadline should probably be set far into the future 11:21 < wangchun_> Bitcoin needs better governance 11:21 < wangchun_> Not UASF, not VASF, not LukeJrASF 11:21 -!- valeriyageorg [4f195edd@host-79-25-94-221.retail.telecomitalia.it] has joined ##taproot-activation 11:21 < luke-jr> if miners activate sooner, lockinontimeout=false/true *does not matter at all* 11:21 < wangchun_> But a constitution like governance 11:21 < nickler> fjahr: yeah 1 year would be a fine option too 11:21 < bitentrepreneur> so what do you suggest wangchun 11:21 < michaelfolkson> wangchun_: Please don't make generalized statements that don't advance the discussion 11:21 < wangchun_> yay 11:21 < gloved> I have seen no reasonable objections to taproot 11:22 -!- gz79 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:22 < CodeShark____> wangchun_: we're not here to create a new nation-state. governance is a much harder problem than taproot activation 11:22 < virtu> luke-jr: Not concerning the outcome but it has other implications 11:22 < wangchun_> We can go BIP 8 11:22 < kanzure> wangchun_: tapproot activation can be achieved without governance; do you have any reason to think it will not? 11:22 < hsjoberg> willcl_ark: Haha sorry! 11:22 < luke-jr> virtu: ? 11:22 < michaelfolkson> REMINDER: The subject is activation mechanisms, the pros and cons 11:22 < ghost43> nickler, fjahr I think many downstream devs, e.g. wallets, will not write any code until it actually actives so whether it's a 1y param or 2y param does not matter at all 11:22 < bitentrepreneur> cool, there you go BIP8 from wangchun 11:22 < ghost43> activates* 11:22 < proofofkeags> ghost43: this is consistent with my experience 11:23 < rusty> FWIW, I propose BIP-8 1yr (well, that many blocks), lockinontimeout=false. That mirrors previous BIP-9 activations. 11:23 -!- gz79 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Client Quit] 11:23 < fjahr> ghost43: yeah, this was more meant towards pools and miners 11:23 < bitentrepreneur> create a PR when you have some time wangchun : https://github.com/taprootactivation/Taproot-Activation 11:23 < benthecarman> rusty: I agree 11:23 < wangchun_> sure 11:23 < bitentrepreneur> thanks 11:23 < AaronvanW> fjahr nickler:I tink that's where the "improve later" comes in. if there's procrastrination, a UASF client can be deployed. 11:23 < willcl_ark> rusty: I agree also 11:23 < michaelfolkson> rusty: I agree 11:23 < virtu> rusty: simple and uncontroversial 11:23 < lucasmoten> rusty: I'm also in agreement with BIP-8(false, 1yr) 11:23 < nickler> AaronvanW: exactly 11:23 < belcher> agreed rusty, 1 year is what other soft fork activations did and i dont see any reason to change it 11:23 < achow101> rusty: ack 11:23 -!- wtr [31c7d190@pa49-199-209-144.pa.vic.optusnet.com.au] has quit [Ping timeout: 248 seconds] 11:23 < luke-jr> rusty: there is no rationale for lockinontimeout=false IMO 11:24 < michaelfolkson> Though I think luke-jr wants lockinontimeout=true. Is that right luke-jr? 11:24 < hsjoberg> Agreeing with rusty, 1yr BIP8 seems sensible. 11:24 < virtu> and leaves the option to follow the "start now, improve later" approach 11:24 -!- gz23 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:24 < proofofkeags> question for clarification: what happens to taproot as an idea if we get to the end of the consideration period and activation does not occur 11:24 < darosior> What rusty said: +1 11:24 < rusty> luke-jr: I gave one above: "The original logic of the BIP-9 protocol was to allow an escape hatch (failed activation) if we found some last-minute issue. I did not consider that this ability to prevent an upgrade would be abused, however, but it's still comforting to have, IMHO." 11:24 < gloved> What’s the motivation for 1 yr versus shorter time? 11:24 < luke-jr> proofofkeags: consideration is already done before we get to our present point 11:24 -!- gz23 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Client Quit] 11:24 -!- CraigSW [~androirc@2a00:23c5:ed96:500:89ac:4966:a1a6:f38e] has joined ##taproot-activation 11:24 < hsjoberg> proofofkeags: With BIP8 the nodes will mandate activation. With BIP9 the activation will simply not happen 11:24 < CodeShark____> shorter time may be better 11:24 < willcl_ark> gloved: miners need time to upgrade 11:24 < Raincloud> can we just start out listing the activation methods each with a comment period where people can talk about the pros and cons of each separately instead of trying to talk about all the options at once? 11:24 -!- fiatjaf2 [~fiatjaf@2804:7f2:298a:709b:ea40:f2ff:fe85:d2dc] has joined ##taproot-activation 11:25 < achow101> gloved: it's a known activation pattern and one we've used before 11:25 -!- Rue [c1ef544b@193.239.84.75] has joined ##taproot-activation 11:25 < proofofkeags> sorry luke-jr I mean the "activation period" or whatever parameter is being discussed 11:25 -!- gz87 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:25 < luke-jr> rusty: if there is a risk of an issue, we have a problem regardless 11:25 < wangchun_> The upgrade is easy 11:25 < hsjoberg> proofofkeags: This could lead to chainsplits 11:25 -!- Rue [c1ef544b@193.239.84.75] has quit [Client Quit] 11:25 < rusty> luke-jr: true, but we could have a worse problem. 11:25 < wangchun_> one or two weeks more than enough 11:25 < friendly_arthrop> agree on 1y activation timeframe reasonableness 11:25 < michaelfolkson> Raincloud: This has been done. aj collected developer feedback http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin 11:25 < achow101> 1yr is just for the timeout, activation can occur sooner if miners signal 11:25 -!- jon79 [62cf5005@c-98-207-80-5.hsd1.ca.comcast.net] has joined ##taproot-activation 11:25 < willcl_ark> wangchun_: glad to hear you say that! The lower bound of BIP8 is unset, only upper bound 1 year 11:25 < bitentrepreneur> im confident we can signal pretty quickly 11:26 < hsjoberg> CodeShark___: what time do you suggest? 11:26 -!- Rue [c1ef544b@193.239.84.75] has joined ##taproot-activation 11:26 < aj> proofofkeags: if you start off with (timeout=T, lockinontimeout=false) there's three possibilities when T is hit: the activation fails, you try again with a new activation (timeout=T+1 year, lockinontimeout=true, eg); before then you tell everyone to switch their software to (timeout=T, lockinontimeout=true) at which point you've upgraded the MASF to a UASF 11:26 -!- trubadur [b2a44ffa@178-164-79.250.3p.ntebredband.no] has joined ##taproot-activation 11:26 < AaronvanW> I agree with Raincloud. Let's discuss one proposal at the time. And just use this list? https://en.bitcoin.it/wiki/Taproot_activation_proposals 11:26 -!- aasmakov [3edd52e4@228.82.221.62.dyn.idknet.com] has joined ##taproot-activation 11:26 < CodeShark____> if the decision to activate has already been made (and there is no politics), the activation time should be as long as necessary to make sure everyone can safely upgrade but no longer than that, IMO 11:26 < dr_orlovsky> correct me if I'm wrong, but is it true that (mostly) all agree on taproot, so the question is not wherer to activate it or not, but is *how* to activate, so (a) the risks of any kinds of splits are as small as possible, (b) the route is safe in terms of "if some bug was discovered down the road" and (c) it does not create negative precedent for the future poor governance on less commonly agreed stuff 11:26 < nickler> and if it's about to time out out after 1 year, the community can reconsider 11:26 < bitentrepreneur> yes it's about how 11:26 < hsjoberg> codeshark____: Exactly, and that would be ~1 year probably 11:26 -!- gz87 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Client Quit] 11:26 -!- AsILayHodling [d0402051@208.64.32.81] has quit [Quit: Connection closed] 11:26 -!- Rue [c1ef544b@193.239.84.75] has quit [Client Quit] 11:26 < hsjoberg> Maybe 6m could work but not sure 11:26 < luke-jr> nickler: what is there to reconsider? 11:27 -!- Rue [c1ef544b@193.239.84.75] has joined ##taproot-activation 11:27 < proofofkeags> anecdotal, but I'm presently unaware of anyone objecting to Taproot 11:27 < fjahr> Raincloud: hard to discuss these parameters in isolation 11:27 < CodeShark____> shorter timeframe may be better to motivate people to act sooner. we don't want a protracted activation 11:27 < gloved> I’m aware of some objections but I don’t consider them reasonable 11:27 < aj> proofofkeags: there's also the possibility of getting everyone to upgrade to software that specifes (timeout=T-6 months, lockinontimeout=true) in which case the people who've upgraded will start rejecting blocks at T-6months, and if the longest chain activates by that time, both old and new software will have the soft-fork activated 11:27 < hsjoberg> nickler: If the code has already been merged, any objection is far too late really... 11:27 < michaelfolkson> AaronvanW: I think the key topics at this point are 3 months versus 1 year and lockinontimeout is true or false 11:27 < proofofkeags> aj: thanks for the explanation 11:27 < dr_orlovsky> "activation time should be as long as necessary to make sure everyone can safely upgrade but no longer than that" - can we find any statistical measures to that to take an informed decision, not an arbitrary deadlines? 11:28 < hsjoberg> dr_orlovsky: Yes, with Bitcoin cash people out of the way this time around, I don't see any real objections across the community 11:28 < benthecarman> It seems most people are in agreement of 1 year & lockinontimeout = false 11:28 < gloved> Hsjoberg I disagree. Merged code is not actively running code 11:28 -!- gz35 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:28 < nickler> luke-jr: reconsider how to activate when bip8(false, 1y) failed due to miner veto 11:28 < belcher> any timeline we pick will be arbitrary, we may as well go with what was used before which is 1 year (or that number of blocks) 11:28 < CodeShark____> I think 1 year may be too long if everyone is ready to go 11:28 < Raincloud> fjahr it is just hard to keeep track with what it being said. Everyone is talking about everything and there is no conversation flow. 11:28 -!- okok [b52c3ca1@181.44.60.161] has joined ##taproot-activation 11:28 < proofofkeags> fwiw I'd prefer to lockinontimeout = true, but I'm open to arguments to the contrary 11:28 < michaelfolkson> Please focus on the topic: 3 months versus 1 year and lockinontimeout is true or false 11:28 -!- juice [47d3a509@71-211-165-9.hlrn.qwest.net] has joined ##taproot-activation 11:28 -!- asdf123 [d9d6932c@host-217-214-147-44.mobileonline.telia.com] has joined ##taproot-activation 11:28 < hsjoberg> gloved: You could have rasised any issues either in the mailing list or on the pull requests. 11:28 < andrewtoth> I agree with BIP8 1 year timeout lockin false 11:28 < luke-jr> nickler: why give them a veto at all? 11:29 < virtu> CodeShark____: if everyone is ready to go, it won't take one year 11:29 < fjahr> It seems that BIP8(false, 1year) seems the least controversial option at the moment and I would prefer to just get started with it rather than discussing lockin on timeout true for several months :) 11:29 < hsjoberg> belcher: agree 11:29 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has joined ##taproot-activation 11:29 -!- guggero [50fd5efc@80.253.94.252] has quit [Quit: Connection closed] 11:29 < virtu> fjahr: +1 11:29 -!- okok [b52c3ca1@181.44.60.161] has quit [Client Quit] 11:29 < waxwing> BIP8 (false, 1 year) +1 11:29 < achow101> fjahr: agrred 11:29 < aj> gloved: taproot code is active on -signet, so it's running there for what that's worth 11:29 < gloved> Yep 11:29 < benthecarman> fjahr + 1 11:29 < AaronvanW> luke-jr: the "veto" isn't really a veto since it can be overruled. (as we've seen.) 11:29 -!- juice [47d3a509@71-211-165-9.hlrn.qwest.net] has quit [Client Quit] 11:29 < CodeShark____> virtu: generally agreed, but shorter timeframe may get people to act even quicker 11:29 -!- btclove [51dd4037@81.221.64.55] has quit [Quit: Connection closed] 11:29 < lucasmoten> fjahr +1 11:29 < luke-jr> AaronvanW: no reason to give it to them at all :P 11:29 < michaelfolkson> From what I have seen 1 year and lockinontimeout = false are most common choices. But luke-jr strongly disagrees on lockinontimeout 11:30 < hsjoberg> What's a veto? 11:30 < nickler> luke-jr: under the assumption that we can't measure community support, bip8=false is safer bec. it doesn't lead to a permanent chainsplit in the worst case 11:30 < hsjoberg> In context 11:30 < emzy> I'm also for BIP8 (false, 1 year) 11:30 -!- Rue [c1ef544b@193.239.84.75] has quit [Client Quit] 11:30 < proofofkeags> I'm with luke-jr here 11:30 -!- Satoshi [b52c3ca1@181.44.60.161] has joined ##taproot-activation 11:30 -!- asdf123 [d9d6932c@host-217-214-147-44.mobileonline.telia.com] has quit [Client Quit] 11:30 < CodeShark____> signaling is not a vote. talk of veto is moot 11:30 < virtu> CodeShark____: might, but the downside is what do you do when the threshold is not reached in the shorter time frame? 11:30 < luke-jr> nickler: we can observe there is no community oppositio\ 11:30 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Quit: Connection closed] 11:30 < hsjoberg> Yeah signaling was never supposed to be a vote, it was supposed to be a coordination mechanism. 11:31 < hsjoberg> For that reason I am somewhat against BIP9 11:31 < AaronvanW> [1 year, false] sounds fine to me btw. 11:31 < proofofkeags> iiuc if the threshold is hit before the timeout we get it as soon as the threshold is met 11:31 < nickler> luke-jr: I have the same impression and I don't think bip8(true) is terrible 11:31 -!- gz35 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Client Quit] 11:31 < jonny100051> 1 year and false sounds good to me too 11:31 < luke-jr> wangchun_ and bitentrepreneur seem certain miners will activate anyway, so lot=true should be fine 11:31 < gloved> Imo signaling provides no game theory weight because it’s costless and there’s a free default option 11:31 < bitentrepreneur> signalling is only to gauge support 11:31 < gloved> But that’s off topic 11:31 < bitentrepreneur> but looks like most support 11:31 -!- gz12 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 11:31 -!- smurfs [25c83b43@67.59.200.37.customer.cdi.no] has quit [Quit: Connection closed] 11:31 < proofofkeags> 1yr true for me 11:31 -!- mrnothanks [c7a4a1dd@199.164.161.221] has joined ##taproot-activation 11:31 < luke-jr> lot=false creates an incentive to sabotage 11:32 < proofofkeags> ^ 11:32 < proofofkeags> or at least an opening 11:32 < dr_orlovsky> I'd like to point out importance of the precedent: one day after taproot we will be discussing some other softfork (like ANYPREVOUT) and it will be hard to stick to any other activation variant than was used for taproot. So I propose to consider a broader picture: are we happy with lockingtimeout = false in general? 11:32 -!- thatoneprivacygi [25782e93@37.120.46.147] has quit [Ping timeout: 248 seconds] 11:32 < belcher> how does it do that luke-jr ? 11:32 < michaelfolkson> On lockinontimeout = false how strong is your oposition luke-jr? 11:32 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation 11:32 < aj> ((2yr, false) becoming either (2yr, true) or (1yr, true) for me) 11:32 < benthecarman> I would not be opposed to lot=true but I still feel lot=false is safer because it could be trivial to change to lot=true 11:32 < virtu> luke-jr: what happened to miner's incentive to increase the value of bitcoin? 11:32 < CodeShark____> signaling is not to gauge political support. if we are not fairly certain that there is no opposition, we should address that first before deploying any code. if we are already sure there will be no politics, then it's just about coordinatrion 11:32 < luke-jr> belcher: by giving miners a de facto veto they can abuse 11:32 < virtu> if that's not paramount then the system will ultimately fail anyway 11:32 < rusty> dr_orlovsky: yes. We have a UASF hammer if we need it, but obv it's better not to use it. 11:33 < michaelfolkson> I think it is wildly ambitious at this stage dr_orlovsky to think further than Taproot 11:33 < luke-jr> michaelfolkson: I think it would be a mistake. 11:33 < luke-jr> rusty: lot=true doesn't mean we use it 11:33 < Satoshi> Given recent developments in regulation that go against privacy, Taproot activation seems urgent, so wallets can start adopting the tech and bitcoin stays fungible. So my question is, why delay the activation more than 3 months? 11:33 < belcher> luke-jr right they could, but where does the incentive come from? given that miners get paid in bitcoin they already have an incentive for bitcoin's utility to improve 11:33 < michaelfolkson> It is hard enough to get this Taproot activation mechanism sorted 11:33 < hsjoberg> benthecarman: As long as it doesn't require a UASF client it's fine IMO 11:33 < aj> dr_orlovsky: almost every soft-fork we've had has involved reinventing the activation method, so not sure willingness to change is that big a problem 11:33 < dr_orlovsky> Satoshi: +1 11:33 < lucasmoten> Has any miner indicated preference for lockinontimeout=true ? 11:33 < virtu> I agree. we never needed the UASF hammer except for segwet. so why make an unnecessary show of force based on this one bad incident? 11:33 < rusty> luke-jr: at that point, the clock is ticking and the intent is clear though. 11:34 < dr_orlovsky> virtu: reasonable 11:34 < hsjoberg> virtu: Because the system was gamed 11:34 < darbsllim> seems like consensus here is BIP 8 1 year and let signalling start 11:34 < luke-jr> lucasmoten: why would they? and why do you think it matters? 11:34 < michaelfolkson> virtu: We are not discussing UASF. It is not being discussed. Please stay on point 11:34 < CodeShark____> even if there are no politics now, if you give people more options, you can introduce politics later 11:34 < luke-jr> rusty: which is a good thing 11:34 < willcl_ark> Completely annecdotal but I've not seen *any* opposition to Taproot.... But still I think using the lowest common denominator of activation params (false, 1yr) seems like the sensible choice to avoid any purposeful or accidental chainsplits in the case miners don't signal 11:34 < belcher> Satoshi bitcoin can become fungible even if we dont get taproot 11:34 -!- trubadur [b2a44ffa@178-164-79.250.3p.ntebredband.no] has quit [Quit: Connection closed] 11:34 < rusty> luke-jr: I disagree. But I think we understand each other, which is good. 11:34 -!- NoDeal [aef6c776@118.sub-174-246-199.myvzw.com] has joined ##taproot-activation 11:34 < gz12> False, 6 months 11:34 < dr_orlovsky> I agree on the risks of anti-privacy governmental actions which may create problems for bitcoin ecosystem (at least try to). So probably we should consider <1yr from this perspective 11:34 < darbsllim> yeah I haven't seen *any* opposition to taproot either, seems like everyone is in consensus ... miners, node operators, businesses, users, etc 11:34 < luke-jr> rusty: the intent is to activate Taproot. 11:34 < CodeShark____> even if right now everyone states they are in favor of activation, as soon as the activation process begins there could be incentives for someone to try to sabotage 11:34 < jonny100051> Luke, if after say 6 months into the BIP8 (false) activation period, if it still has not actuvated, then the community may start to do thinkgs like a BIP 8 (true), but for now when things seem ok, we can do bip 8 (false) maybe 11:35 < belcher> Satoshi for example its possible to create multisigs that look just like a single-sig with ecdsa-2p, however its newer crypto and harder to review so taproot is much better 11:35 < luke-jr> rusty: lot=false means the intent is to let miners decide 11:35 < michaelfolkson> 1 year does not mean waiting 1 year. It can be activated much earlier than that 11:35 < walletscrutiny> I see an urgency in improving the fungibility and with a 2a timeout ... us waiting for it to expire appears crazy given the current support. 11:35 -!- fengyun [73cca4a9@115.204.164.169] has joined ##taproot-activation 11:35 < luke-jr> jonny100051: 6 months is rushed 11:35 < belcher> so dont worry about "people might oppose taproot because of privacy", privacy is coming or already here and taproot being stopped wont change that 11:35 < hsjoberg> BIP8 with mandatory lock-in is not an unnecessary show of force 11:35 < wangchun_> That’s the current Bitcoin law 11:35 < luke-jr> jonny100051: not to mention the confusion "I thought I already upgraded for Taproot" 11:35 < wangchun_> It’s a balance between miners and developers 11:35 < michaelfolkson> Please don't move off topic 11:35 < wangchun_> I mean lot=false 11:36 -!- tonysanak82 [d847dcf5@216-71-220-245.dyn.novuscom.net] has joined ##taproot-activation 11:36 < michaelfolkson> I think we should probably move on. I'm hearing support for BIP 8(false, 1 year) despite luke-jr thinking false is a mistake 11:36 < luke-jr> wangchun_: developers aren't relevant to this 11:36 < bobazY> michaelfolkson: ack 11:36 < ghost43> if we do BIP8(1y, false), and it times out, we can still do another BIP8(1y, true) 11:36 < devrandom> we could start with lot=false, and upgrade later to lot=true based on community feedback and need. seems more likely to get feedback once the activation is in progress and we see how miners behave 11:36 < proofofkeags> it's not just luke fwiw 11:36 < benthecarman> My assumption is with a lot=false is that a config option could change it to lot=true, this should make it safer & easy for users to enforce the UASF 11:36 < proofofkeags> I also think that lot=false is a mistake 11:36 < michaelfolkson> Sorry proofofkeags, I agree 11:36 < jonny100051> Luke, the point is BIP 8 (false) doenst mean miners are in control, we are just trying to activate this way, if it doesnt work, then we can do bip 8 (true) 11:37 < luke-jr> jonny100051: but it does 11:37 < michaelfolkson> This is hard :) Trying to summarize 11:37 < waxwing> agreed benthecarman if it's easy to toggle that's helpful 11:37 < hsjoberg> bencartheman: If that is the case then lot=false by default is fine. As long as we don't need another Bitcoin client like with UASF, it's fine 11:37 < belcher> lot=false is safer than lot=true, so its worth doing lot=false first given that we know hashpower is ~90% already pro-taproot 11:37 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation 11:37 < luke-jr> jonny100051: it makes no sense to say that 11:37 < luke-jr> belcher: no, lot=false is less safew 11:38 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Client Quit] 11:38 < proofofkeags> if users can easily change lot=false to lot=true at some point without requiring a new core release, I'd support leaving lot=false the default 11:38 < bitentrepreneur> bip8 false 1y 11:38 -!- N [5fdf4a9c@ip-95-223-74-156.hsi16.unitymediagroup.de] has joined ##taproot-activation 11:38 < wangchun_> If lot=false is a mistake, why Bitcoin source code is hosted on GitHub, a Microsoft subsidiary? 11:38 < CodeShark____> the more we delay decisions and leave parameters open, the more it opens the door to expoitation. if the decision to activate has already been made, the activation should be quick and aggressive. allowing further parameter changes opens the door to politics 11:38 -!- N is now known as Guest48844 11:38 < wangchun_> core release to GitHub too, a super centralized for-profit comapny 11:38 < michaelfolkson> wangchun_: You are consistently moving off topic, please stop it 11:38 < Satoshi> The problem is not if we can make it fungible at some point, but how fast we can do it without breaking the system, given these outsider threats. 11:38 < virtu> CodeShark____: agressive? really? I'm all for conservative to minimize problems? 11:39 < michaelfolkson> Also off topic Satoshi 11:39 < waxwing> CodeShark____, the more we *change* parameters the more it gets political, but bip8 (false, 1year) is the least change from status quo 11:39 < CodeShark____> sometimes being aggressive is safer 11:39 < luke-jr> waxwing: status quo is lot=true 11:39 < luke-jr> Segwit activated by UASF 11:39 < benthecarman> Seems like we are just repeating ourselves now, should we move to PR discussions? 11:39 -!- tonysanak [d847dcf5@216-71-220-245.dyn.novuscom.net] has quit [Ping timeout: 248 seconds] 11:39 < jonny100051> that was an exception and crisis situation 11:39 < bitentrepreneur> yes 11:39 < hsjoberg> Codeshark____: I agree somewhat. People still has to be given time to upgrade. But yes after the software is out is not the time to argue whether Taproot should be activated or not 11:39 < proofofkeags> was segwit always planned to go via UASF or did it evolve into that after other failed attempts 11:39 < michaelfolkson> As the BIP 8 co-author do you make the decision on whether true or false in BIP 8 luke-jr? 11:39 < robert_spigler> Why not modern soft fork activation? 11:39 < AaronvanW> CodeShark____: sometimes, but this seems like a very uncontroversial upgrade, miners already indicated they want it. 11:39 < dr_orlovsky> what if users will be given an option to set lot=true with their nodes so we can see the support for this option and we can failback if lot=false didn't work w/o new bitcoin core release? 11:39 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation 11:39 < luke-jr> BIP8(false) is a regression 11:39 < wangchun_> luke-jr: Segwit activated by our under table engineering 11:40 < achow101> proofofkeags: it evolved into that 11:40 -!- mariobyn [bc19a421@188.25.164.33] has joined ##taproot-activation 11:40 < luke-jr> michaelfolkson: no 11:40 < gloved> Time check 40 min past the hour 11:40 < fjahr> luke-jr: there are still lots of options if bip8 false fails for no good reason. It seems like at worst we lose a few months 11:40 < belcher> without segwit bitcoin would have died most likely, because of asicboost and huge miner fees with nothing like lightning in sight 11:40 < waxwing> luke-jr, the wiki page disagrees with you 11:40 < luke-jr> wangchun_: no 11:40 < belcher> so the risk of a UASF was seen as worth it 11:40 < luke-jr> waxwing: then it's wrong 11:40 -!- jhurtford [6b4de288@mobile-107-77-226-136.mobile.att.net] has joined ##taproot-activation 11:40 < hsjoberg> AaronvanW: I think it should be fine, but I don't think we should base decisions on what people say they will do. 11:40 < CodeShark____> AaronvanW: my concern is people attempting to wedge once activation is in process 11:40 < michaelfolkson> Ok do we want to discuss robert_spigler suggestion on modern soft fork activation? 11:40 < aj> michaelfolkson: activation params are set in the bip describing the soft-fork (taproot, segwit), or in an entirely separate bip (bip148, bip91) 11:40 < robert_spigler> BIP8(false, 1y), if miners don't cooperate, they know lot=true is coming 11:41 < hsjoberg> Yeah Eric's point basically 11:41 < bitentrepreneur> im sure miners will activate 11:41 < luke-jr> fjahr: we lose a year, AND the current better precedent 11:41 < fjahr> robert_spigler: essentially we discuss the first part of it and I don't think it makes sense to already discuss now what would come after 11:41 < rusty> robert_spigler: yes. 11:41 -!- IT4Crypto [83ff04ee@131.255.4.238] has quit [Quit: Connection closed] 11:41 < MikeMarzig> bip8 (true, 1year) 11:41 < aj> this feels like it's going round in circles; everyone agrees the code should be able to support both lockinontimeout=false and lockinontimeout=true, no? 11:41 < CodeShark____> the more that activation seems inevitable and the less time and parameters people are given to tinker with the activation, the more smoothly it is likely to go 11:41 < aj> (even if one or the other is never used in practice) 11:41 < michaelfolkson> I found this from Luke and Eric very convincing on not drawing the activation out over many years and multi phases https://diyhpl.us/wiki/transcripts/bitcoin-magazine/2020-08-03-eric-lombrozo-luke-dashjr-taproot-activation/ 11:41 < hsjoberg> michaelfolkson: Yes, what's that? 11:41 < AaronvanW> CodeShark____: they can also do that in context of aggressive activations I think. 11:41 < luke-jr> (FWIW no matter the outcome, I will be running lot=true) 11:41 < robert_spigler> Seems like a good compromise 11:42 < wangchun_> ridiculous, seems everyone hate miners here... 11:42 < waxwing> aj, yes i think so 11:42 < bitentrepreneur> i don't hate miners 11:42 < nickler> kbenthecarman: If it comes to a UASF as you describe, ideally someone would just fork Bitcoin Core, instead of having Core decide for the community. BIP8(false) will follow under the proposed BIP8 revisions. 11:42 < wangchun_> Why Bitcoin remains PoW 11:42 < nickler> not that I think that's likely 11:42 < virtu> wangchun_: no, not everyone 11:42 < luke-jr> who said anything about hating miners? 11:42 < michaelfolkson> Ok let's call 5 minute warning. We'll move onto PRs in 5 minutes 11:42 < bitentrepreneur> ok cool 11:42 -!- IT4Crypto [83ff04ee@131.255.4.238] has joined ##taproot-activation 11:42 < benthecarman> +1 11:42 < luke-jr> nickler: if Core can ship BIp8(false) it can ship BIP8(true) 11:42 < wangchun_> So long Bitcoin remains PoW, 11:42 < belcher> btw, wangchun_ is not identified with nickserv, i havent seen any evidence that that nick is the real wangchun 11:42 < wangchun_> miners as a major role in the ecosystem 11:42 < rusty> luke-jr: I feel that avoiding appearance of developer mandate over the protocol is important, and also I like having an escape hatch should problems be found before activation. Thus I prefer to start with lockin=false, and revisit at 6 months if it hasn't activated. 11:42 < wangchun_> they should be respected, 11:42 -!- Guest48844 [5fdf4a9c@ip-95-223-74-156.hsi16.unitymediagroup.de] has quit [Client Quit] 11:42 < michaelfolkson> No one hates miners and you are moving off topic continuously wangchun_ 11:43 < benthecarman> nickler: I just think core should leave it as a config option, with false as the default 11:43 < michaelfolkson> It is very annoying 11:43 < MikeMarzig> wangchun, no one "hates" miners here.  bitcoin is obviously remaining PoW 11:43 < wangchun_> or change how system works 11:43 -!- jetlag [uid485552@gateway/web/irccloud.com/x-bygsklpwjelzttoq] has joined ##taproot-activation 11:43 < luke-jr> rusty: there is no developer mandate.. 11:43 < erijon> If there is no opposition to activating, and lot=false is regressing, and if I understand it correctly, lot=true keeps checks and balances between node users and miners. Why wouldn't we want lot=true? 11:43 < darbsllim> Miners like Bixin are respected 11:43 < achow101> benthecarman: a config option that can result in a chainsplit is dangerous 11:43 < hsjoberg> wangchun_: PoW is used to coordinate blocks and txs, not to decide consensus rules 11:43 < wangchun_> michaelfolkson: nobody is moving off the topic 11:43 < darbsllim> miners like Bitmain are not respected 11:43 < proofofkeags> rusty: I like the idea of lot=false if we shorten to 6mo 11:43 < wangchun_> we can talking about lot=false or lot=true 11:43 < luke-jr> wangchun_: giving miners power they ought never to have had, is not necessary for respect 11:43 < fjahr> Maybe hashrate quickly: anyone seriously considering <90%? Preferences between 95% and 90%? Maybe 95% for 6M first then 90% for 6M? 11:43 < CodeShark____> wangchun_: the point here is not to establish a permanent governance process - it is merely to decide on technical parameters, assuming the decision to activate taproot is already widely supported by miners 11:43 -!- fodediop [~fode@41.214.90.237] has quit [Ping timeout: 246 seconds] 11:44 < MikeMarzig> wangchun, even if lot=true, miners can still activate on their own. 11:44 < wangchun_> luke-jr: I must clarify I have personally not been mining since 2013, 11:44 < wangchun_> I have nothing to do with miners, 11:44 < darbsllim> wangchun_ Miners who are in consensus with the rest of the network are respected. 11:44 < hsjoberg> dardsllim: They are ironically in favor of BIP8 now 11:44 < proofofkeags> fjahr: what is needed from a topology perspective for it to be successful? 11:44 < bitentrepreneur> it's the real wangchun 11:44 < wangchun_> but things shouldn’t be like this 11:44 < bitentrepreneur> he submitted the PR 11:44 < lucasmoten> Could start with the false, 3m and goto true, 1yr if necessary 11:44 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed] 11:44 < virtu> it appears everyone agrees on bip8, almost no objections to 1y, but some opposition to the majority's preference for false 11:44 < bitentrepreneur> https://github.com/taprootactivation/Taproot-Activation/pulls 11:44 < wangchun_> if we agree that PoW should remain, 11:44 < wangchun_> and miners should be respected 11:44 < CodeShark____> I support less than 1 year and true 11:44 < belcher> bitentrepreneur anyone could squat that nick on this IRC, its not registered with nickserv 11:44 < setpill> wangchun_: PoW is for selecting which block is chain tip, not for which chain is valid 11:44 < wangchun_> It’s easy to see we should go for lot=false 11:44 < devrandom> any opposition to 90% threshold? 11:45 < bobazY> ⏰ 19:45 11:45 < rusty> luke-jr: I disagree. Miners get coordination power because we can reliably measure them in a decentralized manner, unlike other groups. That implies the ability to *not* coordinate, yes. But we have a plan for that too, as BIP-8 makes a UASF much less likely to cause a split. That's as good as we can do. 11:45 -!- mariobyn [bc19a421@188.25.164.33] has quit [Ping timeout: 248 seconds] 11:45 -!- jetlag is now known as DMN737 11:45 < luke-jr> lucasmoten: makes more sense to do 1y,false then 1y,true for the same 1y period 11:45 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation 11:45 -!- bobby_mexico [48b624b6@072-182-036-182.res.spectrum.com] has joined ##taproot-activation 11:45 -!- fly [acf817d6@cpe-172-248-23-214.socal.res.rr.com] has quit [Quit: Connection closed] 11:45 < fjahr> proofofkeags: sorry, not sure if I understand your question 11:45 < belcher> bitentrepreneur though i see your point that the timing does line up 11:45 < darbsllim> wangchun_ it sounds like you misunderstand the role of miners and what we learned from S2X. 11:45 < michaelfolkson> Ok let's move onto the PRs 11:45 < luke-jr> rusty: lot=true IS planning for that 11:45 < darbsllim> Miners are well paid security guards, they don't control the Bitcoin rules. 11:45 < luke-jr> rusty: it doesn't stop miners from doing MASF 11:45 < bitentrepreneur> guys let's stay on topic please 11:45 < michaelfolkson> NO MORE DISCUSSION ON ANYTHING OTHER THAN PRs PLEASE FROM THIS POINT 11:46 < michaelfolkson> We can schedule another meeting if we need in future 11:46 < rusty> michaelfolkson: OK, untyping now :) 11:46 < michaelfolkson> Thanks :) 11:46 < wangchun_> michaelfolkson: go ahead my lord :) 11:46 < gloved> Current topic? 11:46 < proofofkeags> fjahr, you were asking about what the threshold should be, and I'd like to know if lowering it to 90% has a significant introduced risk. Intuitively something in the neighborhood of 70% would work, but I don't have a topological argument for it. 11:46 < luke-jr> ok, so PR A effectively means miners *don't* lose blocks if they fail to upgrade/signal during LOCKED_IN 11:46 < hsjoberg> lucasmoten: Let's release one software so people can just upgrade instead of requiring further coordination. That why I am in favor of BIP8 1year with mandatory lock-in after deadline 11:46 -!- IT4Crypto37 [83ff04ee@131.255.4.238] has joined ##taproot-activation 11:46 < luke-jr> let's talk about PR A for now 11:46 -!- fly [acf817d6@cpe-172-248-23-214.socal.res.rr.com] has joined ##taproot-activation 11:47 < benthecarman> Is this #1020? 11:47 -!- mrnothanks [c7a4a1dd@199.164.161.221] has quit [Quit: Connection closed] 11:47 < michaelfolkson> Yup 11:47 < luke-jr> yes 11:47 < bobazY> https://github.com/bitcoin/bips/pull/1020 11:47 < luke-jr> https://github.com/bitcoin/bips/pull/1020 11:47 < michaelfolkson> The three PRs are at the bottom of this https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html 11:47 < luke-jr> this affects what happens AFTER Taproot is locked in 11:47 -!- bitbug42 [b08da8bf@176-141-168-191.abo.bbox.fr] has quit [Quit: Connection closed] 11:47 < luke-jr> the 2 week period between lock-in and activated 11:47 -!- JanB [1fc9e0c9@201-224-201-31.ftth.glasoperator.nl] has quit [Quit: Connection closed] 11:47 < luke-jr> right now, BIP 8 says miners must signal to indicate they are upgraded 11:47 < luke-jr> this PR removes that requirement, making it optional 11:47 < achow101> ACK 1020 11:48 < luke-jr> either way, the chain indicates lockin 11:48 -!- AlexandreChery [9466964e@148.102.150.78] has quit [Quit: Connection closed] 11:48 < benthecarman> From my understanding it was originally like this so enforce the actiavtion for other clients 11:48 < luke-jr> this is only about miners losing blocks if they haven't upgraded 11:48 < luke-jr> yes 11:48 < belcher> PR 1020 makes sense to me, ack 11:48 < rusty> Agreed, it's a weird and unnecessary requirement. Ack 1020 11:48 < luke-jr> but that is no longer needed 11:48 < benthecarman> ACK 11:48 < luke-jr> any objections to PR 1020? 11:48 -!- maximalismo [62f0b3dc@gateway/web/cgi-irc/kiwiirc.com/ip.98.240.179.220] has quit [Ping timeout: 265 seconds] 11:48 < jonny100051> Ack 11:48 < lucasmoten> ACK 11:48 < hsjoberg> I don't fully understand it yet 11:48 < norisgOG> Ack 11:49 < rusty> (We had a similar debate with BIP-9, too: it's kinda cute to see all miners ack that they're locked in, but it's not necessary) 11:49 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 11:49 < virtu> luke-jr: so this essentially decides whether blocks from non-upgraded miners are dropped starting in the locked-in phase or the active phase? 11:49 -!- fly [acf817d6@cpe-172-248-23-214.socal.res.rr.com] has quit [Client Quit] 11:49 -!- IT4Crypto [83ff04ee@131.255.4.238] has quit [Ping timeout: 248 seconds] 11:49 < felixweis> Since softforks are usually being developed in the open over many months already before being merged, and releases ship ±6 months there is already much time to voice opposition. So i'd prefer Modern Soft Fork activation with 2x short 3month timeouts (in the same inital activation release). If the first does fail, we get this particular signal faster. It would make news and potential mitigate some people 11:49 < felixweis> who were just too lazy to upgrade their node to help make the second timeout. 11:49 < felixweis> So BIP8(false, 3m) then immeadiatly BIP8(false, 3m) then rediscuss weather to realease a change the proposal or go with BIP8(true, 2y) or abandon in the next software release. 11:49 < darosior> Ack 1020 11:49 < hsjoberg> ACK 1020 11:49 < setpill> ACK 9a119ce 11:49 < luke-jr> there is one con to 1020 11:49 < luke-jr> I think 11:49 -!- IT4Crypto37 [83ff04ee@131.255.4.238] has quit [Client Quit] 11:49 < fjahr> proofofkeags: Ah, I don't have a good answer for it, just wanted to raise the question. 70% seems very low though, there was some research on fluctuations but would need to look for it. 11:50 < michaelfolkson> Sorry felixweis: NO MORE DISCUSSION ON ANYTHING OTHER THAN PRs PLEASE FROM THIS POINT 11:50 < luke-jr> it increases the risk that a miner(s) fail to upgrade, and because of that, mine transactions stealing Taproot coins after activation 11:50 < luke-jr> that block would be invalid, but more subtly 11:50 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has quit [Quit: Connection closed] 11:50 < roasbeef> re #1020, so the diff is just that after locked_in, you don't need to signal at all? 11:50 < robert_spigler> is virtu correct in his summary? 11:50 < luke-jr> light wallets would likely be fooled by it 11:50 < hsjoberg> If I understand this correctly, MUST_SIGNAL is the phase after the deadline where miners must signal for the softfork. Afterwards when threshold is reached it moves to LOCKED_IN? 11:50 -!- ruben [b2a44ffa@178-164-79.250.3p.ntebredband.no] has joined ##taproot-activation 11:50 < aj> fjahr: fluctuations are pretty trivial (if x% hashpower supports signalling blocks will be x+/-2% with >99% certainty or so, iirc) 11:50 < robert_spigler> "so this essentially decides whether blocks from non-upgraded miners are dropped starting in the locked-in phase or the active phase?" 11:51 -!- jhurtford [6b4de288@mobile-107-77-226-136.mobile.att.net] has quit [Quit: Connection closed] 11:51 < felixweis> in that case ACK 1020 11:51 < luke-jr> virtu: post-LOCKED_IN, either way, blocks are valid until someone tries to steal coins 11:51 < setpill> virtu: no, non-upgraded miner blocks are not dropped after activation 11:51 -!- ruben is now known as Guest58708 11:51 < roasbeef> ah ok it just removes the old bip 9 "grace period" (#1020) 11:51 < wangchun_> ACK 1020 11:51 < proofofkeags> ACK 1020 11:51 < luke-jr> rejecting non-signalling blocks during LOCKED_IN is a kick in the butt of the not-upgraded miners to get it done so there's no risk of such an attack 11:51 < aj> luke-jr: not-upgraded miners who enforce the old standardness rules won't mine txs that steal taproot spends; they'll only risk building on top of (invalid) blocks that have stolen taproot spends 11:52 < fjahr> aj: ok, thanks 11:52 -!- jaime [92f183f3@146-241-131-243.dyn.eolo.it] has joined ##taproot-activation 11:52 < michaelfolkson> Ok we've got enough ACKs, thanks everyone. Let's just let this discussion play out 11:52 < luke-jr> aj: good point 11:52 < waxwing> ACK 1020 here after reading it :) 11:52 < luke-jr> ok, no NACKs, I'll merge it 11:52 -!- aasmakov [3edd52e4@228.82.221.62.dyn.idknet.com] has quit [Quit: Connection closed] 11:52 < rusty> Note: this is the fallow period between "we know it's coming" and "it's here". Designed to give any lagging miners time to upgrade (could be ~5% of hash power). No need to reject their blocks as well. 11:52 < aj> \o/ 11:52 < luke-jr> btw if you have github accounts, feel free to post the ACKs there too 11:52 < norisgOG> are taproot involved transaction also anyone can spend tx for older nodes? 11:52 < bobazY> https://github.com/bitcoin/bips/pull/1020 11:53 < roasbeef> shouldn't #1021 have been discussed concurrently? (fwiw I like 1020 since it's just simpler) 11:53 < setpill> roasbeef: I think it brings bip 8 more in line with bip 9 actually (no mandatory signalling period was bip 9 behaviour) 11:53 < luke-jr> I think we're done with 1020 11:53 < achow101> we should discuss 1021 11:53 < aj> norisgOG: non-standard anyone can spend, yes (that is, they'll be rejected if seen on the p2p network or proposed for the mempool due to standardness rules) 11:53 < roasbeef> norisgOG: it's a soft fork, it adds a new witness version 11:53 < luke-jr> now e can discuss 1021 :P 11:53 < bitentrepreneur> nice 11:53 < michaelfolkson> norisgOG: NO MORE DISCUSSION ON ANYTHING OTHER THAN PRs PLEASE FROM THIS POINT. Please wait until after meeting for general Taproot questions 11:54 < benthecarman> roasbeef: 1021 is built on top of 1020 11:54 -!- temmanuel [188b63c6@24.139.99.198] has joined ##taproot-activation 11:54 < luke-jr> https://github.com/bitcoin/bips/pull/1021/commits/afe97b2eeeeaf8cd1a0658bb191da15b36a4dd3a 11:54 < aj> norisgOG: ("they'll be rejected" -- txs spending taproot UTXOs will be rejected from the mempool because they can't be verified but accepted in a block without checking, hence "anyone can spend") 11:54 < achow101> as I understand it, 1021 just means that any non-upgraded miners won't be kicked off during MUST_SIGNAL so long as th signaling threshold is reached 11:54 < luke-jr> ok, so 1021 is only relevant when miners have NOT activated the fork 11:54 < luke-jr> 1021 is in the UASF scenario ONLY 11:54 < luke-jr> it allows up to 5% of blocks to be missing the required signal 11:55 < roasbeef> benthecarman: I see, but them it reverts the prior partially by saying still signal? 11:55 < dr_orlovsky> what is the benefit in making the logic more complicated? What is the expected win with 1021? 11:55 < luke-jr> IMO this is pointless and just increases complexity 11:55 < roasbeef> yeh seems unncessary 11:55 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has joined ##taproot-activation 11:55 < luke-jr> aj: care to explain your thoughts? 11:56 < ghost43> I agree that it's best to keep this code as simple as possible; not sure this is worth it 11:56 < aj> (1) the argument here is that during a UASF, requiring signalling creates a risk of chain splits -- if a block doesn't signal, a non-UASF miner will build upon that, but everyone knows both blocks will be rejected, so that's an opportunity for attackers to double spend. accepting as many non-signalling blocks as possible (ie, up to 5%) limits that attack 11:56 -!- MN99 [~textual@cpe589630a45781-cm589630a4577f.cpe.net.cable.rogers.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:56 < setpill> I like the concept but yeah overengineering 11:57 < michaelfolkson> Given 1021 is the UASF scenario only does it need to be merged until an unlikely point where it is needed? 11:57 < luke-jr> aj: but these miners will create a problem once we reach 5% anyway, right? 11:57 < proofofkeags> it seems that the value of this change is highly contingent upon threshold size 11:57 -!- topg12 [25782e93@37.120.46.147] has joined ##taproot-activation 11:57 < benthecarman> michaelfolkson I think this needs to be decided before bip 8 can be implemented 11:57 < aj> (2) the other consideration is if you start with a longer timeout (timeout=2 years, lockinontimeout=true/false) and then want to speed up the activation, because everyone's upgraded, markets say they want it, and there's 6% of miners who are trying to convince everyone bitcoin sucks and we should move to another chain, then we can set (timeout=1 year, lockinontimeout=true) [cont'd] 11:57 < ghost43> michaelfolkson: yes, it's only meaningful if "old" nodes run this code 11:57 < nickler> 1021 it makes sure that hat bip8(false) will be on the same chain as bip8(true) if the signalling chain is the majority chain 11:57 -!- Guest58708 [b2a44ffa@178-164-79.250.3p.ntebredband.no] has quit [Quit: Connection closed] 11:57 < luke-jr> michaelfolkson: even if Core doesn't release lot=true, I and probably others will be using it anyway 11:57 < hsjoberg> I think it adds unnecessary complexity 11:58 < michaelfolkson> Ok 11:58 < roasbeef> nickler: interesting, so promotes some stability 11:58 < luke-jr> aj: we can do that anyway? 11:58 < aj> if we do the shorter timeout with lockinontimeout=true, then if we hit the timeout, and get 98% of blocks signalling but not 100%, this ensures everyone remains in consensus, and even if it's the 98% chain that continues with the longest weight, the people who did the bip148-style speedy uasf don't have to downgrade their software 11:58 < luke-jr> nickler: how is 1021 needed for that? 11:59 < roasbeef> > This reduces the ways in which a consensus split can occur, and avoids a way in which miners could attempt to discourage users from setting lockinontimeout=true. 11:59 < roasbeef> ^ from 1021 11:59 < setpill> nickler: you mean if the chain with the non-signalling block is the majority chain? 11:59 -!- gz12 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Quit: Connection closed] 11:59 < benthecarman> imo 1021 makes sense, it makes it safer for the UASF option which is the most "dangerous" scenario 11:59 < proofofkeags> yeah 11:59 < nickler> luke-jr: without 1021 there can be a chain with 95% signalling which is followed by bip8(false) nodes and one with 100% signalling followed by bip8(true) nodes 11:59 < hsjoberg> nickler: Why wouldn't that be the case without this PR 12:00 -!- temmanuel [188b63c6@24.139.99.198] has quit [Quit: Connection closed] 12:00 -!- v33r [622218ac@c-98-34-24-172.hsd1.il.comcast.net] has quit [Quit: Connection closed] 12:00 < aj> luke-jr: "create a problem once we reach 5%" -- yes, if there's >threshold miners they can create a problem; if there's only 2% or so, this avoids there being a problem 12:00 < luke-jr> hmm, so your thought is 95+% of miners will comply when they have no choice 12:00 < luke-jr> I guess we assume that anyway 12:00 < setpill> uasf game theory says miners are incentivised to join 100% signal chain 12:00 < dr_orlovsky> doesn't 1021 creates a side-effect leading to controversial decreases in signaling that may be used for political reasons? 12:00 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined ##taproot-activation 12:01 < hsjoberg> Ah because a toc=false would still accept non-signaling block 12:01 < achow101> 1021 helps when >95% but <100% signal during MUST_SIGNAL, but I find that situation to be unlikely 12:01 < nickler> hsjoberg: exactly 12:01 < rusty> achow101: there's always someone asleep at the wheel :) 12:01 < benthecarman> dr_orlovsky: no because this is only during the UASF case 12:01 < luke-jr> rusty: but it's good if that someone loses their block? :P 12:01 < proofofkeags> achow101: doees it hurt in any other scenario? 12:01 < hsjoberg> But that subjected the be orphaned by the other miners (given that they run toc=true) 12:01 < luke-jr> dr_orlovsky has a point I think 12:02 -!- Satoshi [b52c3ca1@181.44.60.161] has quit [Quit: Connection closed] 12:02 < rusty> luke-jr: but will they? It becomes a test of how actually strong the UASF is at that point. 12:02 < aj> achow101: all you need to get <100% signal is for one node to mine a non-signalling block, and the other nodes not to be properly validating the blocks they mine on top of. then it's a question of "do we throw away those blocks, or try to convince uasf people that they should forgive us" 12:02 < luke-jr> if 5% can not-signal, it might lead to miners trying to max out non-signalling blocks? 12:02 < setpill> this change makes the game theory a lot more complex 12:02 < luke-jr> rusty: so it's better to just avoid the test? 12:02 < achow101> aj: past situations have shown we just throw them away 12:02 -!- prayank [~andr0irc@2402:8100:206c:5226:348b:b4b2:a2f5:ad48] has joined ##taproot-activation 12:03 < dr_orlovsky> added complexity may have some non-linear consequences and without the clear and strong need probably shouldn't be merged 12:03 < benthecarman> luke-jr wouldn't worst case senario be the first 5% of blocks don't signal and then we move to needing the next 100% of blocks to signal 12:03 < luke-jr> interestingly, it's in miners' interest to throw them away 12:03 < rusty> luke-jr: yes, always. If you actually want to test, you need to mine and propagate a post-fork-invalid block. There's no actual other way to do it. 12:03 < gloved> Setpill: nodes/users cannot know miners payoffs so reasoning about game theory is incomplete 12:03 -!- Hel [536320c1@ip-83-99-32-193.dyn.luxdsl.pt.lu] has joined ##taproot-activation 12:04 < setpill> gloved: we don't need perfect knowledge, but making the model more complex adds unknowns 12:04 -!- fodediop [~fode@41.214.90.237] has joined ##taproot-activation 12:04 < luke-jr> dipping into code a bit, can 1021 be implemented without checking the past 1000+ blocks every new block? 12:04 < rusty> luke-jr: yeah, this is always true. If you can convince the other miners to throw away someone else's block, you win. 12:04 < aj> luke-jr: for me, the point is "if you hit 5%, then any further non-signalling means no one will thing the fork activated" so throwing away is 100% the right answer if you're doing UASF; at <5%, it's ambiguous 12:04 < dr_orlovsky> nack 1021 after certain consideration. Imo complexity+overengineering not worth the win 12:04 < luke-jr> right now, we only check the full set of blocks on the 2 week window 12:04 < hsjoberg> NACK for the same reason as has already been raised 12:05 < ghost43> luke-jr: you can have a stateful counter but that makes the code even more complicated 12:05 -!- Hel is now known as LRHel 12:05 < luke-jr> aj: did you say you had an implementation? 12:05 < aj> luke-jr: it already only checks when the newly mined block doesn't signal iirc? i think you'd need another cache otherwise, though you could do that just on the tip 12:05 -!- bobby_mexico [48b624b6@072-182-036-182.res.spectrum.com] has quit [Quit: Connection closed] 12:06 < michaelfolkson> My understanding of the NACK is you want to make sure UASF can't happen or is more of a mess than it needs to be 12:06 -!- Bulminer [529bcb7c@bl6-203-124.dsl.telepac.pt] has joined ##taproot-activation 12:06 < michaelfolkson> I disagree with this 12:06 < aj> luke-jr: top commit on https://github.com/ajtowns/bitcoin/commits/202010-bip8-suggestions 12:06 < michaelfolkson> It is highly unlikely it is needed but you need to plan for unlikely eventualities 12:06 -!- bobby_mexico [48b624b6@072-182-036-182.res.spectrum.com] has joined ##taproot-activation 12:06 < bobazY> +1 michaelfolkson 12:07 < luke-jr> michaelfolkson: ? 12:07 < hsjoberg> I think it adds unnecessary complexity for little gain. Although I appreciate the concern. 12:07 < proofofkeags> not to mention 1021 simultaneously makes UASF's more viable without being outright hostile to miners 12:07 < michaelfolkson> I need to look at the code closer but I'm convinced on the Concept ACK from what I've heard on 1021 12:07 < dr_orlovsky> PR 2021 seems to save some revenues for non-careful miners at the expense of higher complexity-driven potential risks for broader community... 12:07 -!- krvopije [~krvopije@mobiledyn-185-69-244-189.mrsn.at] has quit [Read error: Connection reset by peer] 12:08 < benthecarman> dr_orlovsky what is the disaster scenario you see? 12:08 < proofofkeags> is there a concrete risk associated with this "expanded complexity" or is it just an opaque fear? 12:08 < jonny100051> ACK 1021, if it makes a consensus split less likley, seems worth while doing 12:08 < setpill> UASFs already force miners' hands. I think that this change is just giving a fake smile to them 12:08 < luke-jr> aj: I guess the complexity isn't too bad since the PoW still needs to match anyway 12:08 -!- bobby_mexico [48b624b6@072-182-036-182.res.spectrum.com] has quit [Client Quit] 12:09 < aj> luke-jr: s/complexity/lack-of-caching/ ? 12:09 < rusty> setpill: if you win, why not do so with grace? 12:09 < michaelfolkson> Generally the less complexity the better I get that. But if the added complexity has a purpose and you carefully review that added complexity 12:09 < nickler> dr_orlovsky: is there an actual incentive issue or is the problem only complexity? Otherwise, merging the PR seems less risky not more. 12:09 < bobazY> FYI seeing some [N]ACKS on https://github.com/bitcoin/bips/pull/1021 12:09 < dr_orlovsky> benthecarman: not the disaster, the higher complexity leads to non-linear risks that can't be analytically predicted. So it must be based on serious wins, which are not seen here. The change must be justified, not it's absence 12:09 < setpill> rusty: win condition would be miners and users wanting same thing 12:09 < luke-jr> aj: CPU time 12:09 -!- PinkElephant [~PinkEleph@87.118.155.136] has joined ##taproot-activation 12:09 < setpill> MASF is win condition imo, UASF is last resort 12:09 < aj> luke-jr: right, as opposed to code-complexity 12:09 < PinkElephant> hey 12:09 < bitentrepreneur> MASF FTW 12:10 < michaelfolkson> The win is that if we need UASF it isn't more of a mess than it needs to be dr_orlovsky 12:10 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has joined ##taproot-activation 12:10 < michaelfolkson> That is a clear win 12:10 < dr_orlovsky> michaelfolkson: good argument 12:10 < proofofkeags> dr_orlovsky, but making UASF's smoother does seem like a "serious win" 12:10 < dr_orlovsky> can the implementation be simplier? 12:10 < benthecarman> imo this isn't much more complex 12:10 < CodeShark____> UASF in principle is only there to strongly incentivize the MASF 12:10 -!- naribia [6bb5bd25@107.181.189.37] has joined ##taproot-activation 12:11 < rusty> setpill: Agreed. But there's never complete agreement, though, which TBH is a useful balwark against groupthink. 12:11 < hsjoberg> The code change looks to be pretty small. 12:11 < bobazY> So what is the risk in overengineering? Seems there needs to be engineering/(risk?) for covering the slight chance of UASF? 12:11 < hsjoberg> I assume similar code exists elsewhere? 12:11 < roasbeef> the code is in the diff y'all 12:11 < luke-jr> :p 12:11 < luke-jr> I agree with CodeShark____ 12:11 < luke-jr> so long as the lot=true is set, it's very unlikely we'd ever see a UASF 12:11 -!- CriptoLuis [be9ba048@190.155.160.72] has joined ##taproot-activation 12:12 < CodeShark____> if we actually get to UASF, I consider it a failure of the method. but the UASF possibility must exist to prevent the MASF from stalling 12:12 < luke-jr> so the minute details here doesn't matter much 12:12 < waxwing> i've been reading, but ultimately just to understand the paragraph that aj wrote at the top of the PR, I agree with it (i.e. ACK on #1021). 12:12 < aj> luke-jr: as long as lot=false, it's even more unlikely we'll see a UASF :) 12:12 < luke-jr> aj: no, it's significantly more likely 12:12 < michaelfolkson> At the moment it seems lot=false is the preferred choice though luke-jr. So either you convince people to change their view or you make the decision as the BIP author or we need to plan for false 12:12 < wangchun_> Hopefully we’ll never see a UASF. 12:13 < dr_orlovsky> will UASF need it's client? if yes, why not to keep this unmerged until we get into UASF? 12:13 < michaelfolkson> Agreed wangchun_ 12:13 < wangchun_> NACK 1021 12:13 < luke-jr> michaelfolkson: BIP author doesn't decide ;) 12:13 -!- jaime [92f183f3@146-241-131-243.dyn.eolo.it] has quit [Quit: Connection closed] 12:13 < luke-jr> michaelfolkson: every node will have to decide for himself ultimately 12:13 < achow101> dr_orlovsky: the bip needs to be finalized before any bip8 implementation is done 12:13 < michaelfolkson> So that leaves two options luke-jr on what Core ships ;) 12:14 < aj> dr_orlovsky: no point keeping it unmerged; if we want to do deployments with that policy later, it can be re-proposed then 12:14 < wangchun_> The entites who generate Bitcoin blocks are not layer 1 “miners” 12:14 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has joined ##taproot-activation 12:14 < wangchun_> But miners’ proxy or “mining pools” 12:14 -!- Bulminer [529bcb7c@bl6-203-124.dsl.telepac.pt] has quit [Quit: Connection closed] 12:14 < ghost43> I too agree now that #1021 is worth it; mainly due to reducing the chance of a split. the code complexity is not that bad at all on second inspection either 12:14 < hsjoberg> I think lot=true support was pretty clear 12:15 < wangchun_> Remember during last fork, we’ve seen a couple of invalid blocks 12:15 < virtu> hsjoberg: then I suggest you recount 12:15 < luke-jr> wangchun_: during the BIP148 period? 12:15 < TechMiX> to me, lot=false is BIP9 12:15 < aj> wangchun_: no we didn't? 12:15 < dr_orlovsky> aj: I don't like the non-triviality of the actual implementation; much more then the idea itself 12:15 < michaelfolkson> Yeah not in this meeting hsjoberg 12:15 < proofofkeags> hsjoberg while I personally thing lot=true is the right answer most people were on the side of lot=false 12:15 < wangchun_> I forgot the number, too old :) 12:15 < virtu> to me it seemed like 10:3 in favor of lot=false 12:15 < luke-jr> wangchun_: please inform us 12:15 < hsjoberg> I am in this meeting 12:15 < emzy> lot=true/false as an option is a bad thing. 12:16 < wangchun_> Immediately after locked-in 12:16 < felixweis> wangchun_: are you talking about BIP65? 12:16 < luke-jr> emzy: forcing users is worse 12:16 < wangchun_> Quite some time ago 12:16 < waxwing> let's vote on if we thought there were more votes for lot=true or false :) 12:16 < michaelfolkson> Sorry hsjoberg I mean in this meeting there was a majority on the side of false 12:16 < wangchun_> need to dig into old posts 12:16 < dr_orlovsky> int count = 1 + (block.nHeight % 2016); ... while (count > 0) { --count; ... if (..) ++singal ... } looks bad :( 12:16 < setpill> fwiw I prefer lot=true, didn't speak up because I didn't think we were counting votes 12:16 < hsjoberg> proofofkeags michaelfolkson: lot=false was discussed a lot, I agree. But not supported a lot 12:16 < hsjoberg> I might be wrong though ofc. 12:16 < aj> dr_orlovsky: oh, sure 12:16 < waxwing> i saw a ton of "votes" for BIP8(1yr, false) 12:17 < waxwing> a few dissents for sure 12:17 < michaelfolkson> At this point I need to remind people that simple vote counts are crude. I am only referring to it as it gives some weak signal when there is nothing else to go on 12:17 < hsjoberg> michaelfolkson: No sorry I misread actually 12:17 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has quit [Quit: Connection closed] 12:17 < luke-jr> point is we don't have a clear consensus on LOT yet 12:17 < dr_orlovsky> modulo division + reverse counting with the forward counting in the same block - what can go wrong with this here when we are in UASF? Really seems to me like a non-totally predictable thing 12:17 < michaelfolkson> Ok agreed luke-jf 12:17 < luke-jr> nor do we need to today 12:17 < ghost43> I think most people are trolling when talking about a vote here :P 12:17 < michaelfolkson> *luke-jf 12:17 < TechMiX> FWIW, I vote bip8(true, 1yr) 12:17 < luke-jr> let's focus on 1021 :P 12:17 < virtu> luke-jr: the good think is, there seemed to be clear consensus on bip8 and 1y 12:17 < michaelfolkson> *luke-jr can't type 12:17 < jonny100051> Luke, we will prob never have strong clear consensus on LOT 12:17 < luke-jr> virtu: yes 12:18 < wangchun_> agree with luke-jr is “consensus”, 12:18 < aj> dr_orlovsky: https://github.com/ajtowns/bitcoin/commit/7a9246e9788ccfd971e05543e8c7a3adb6234454 12:18 < wangchun_> disagree with luke-jr is no consensus 12:18 < CodeShark____> LOT is more an intolerant minority sort of thing than a consensus thing 12:18 < wangchun_> lol 12:18 < luke-jr> also, for the record only, a topic we haven't discussed yet:time between release and signalling-begins 12:18 < michaelfolkson> Please be civil wangchun_ :) 12:19 < michaelfolkson> I stated the opposite to luke-jr opinion was majority view 12:19 < hsjoberg> If we go for BIP8 lot=false, then we'll need further coordination should miners not cooporate. But perhaps it won't be as bad as last time as that required a software to be released whereas BIP8 allows lot to be configured by the user. 12:19 < dr_orlovsky> aj: much better 12:19 < wangchun_> I am not very strong prefer lot=false 12:19 < rusty> luke-jr: 2-4 weeks ? 12:19 < wangchun_> if you guys insist, i’m ok 12:19 < luke-jr> can we avoid LOT talk now; back to 1021 please 12:19 < aj> dr_orlovsky: "VersionBitsStatistics()" hides all the maths there 12:19 -!- NoDeal [aef6c776@118.sub-174-246-199.myvzw.com] has quit [Quit: Connection closed] 12:19 < hsjoberg> I think it's sound to just release one software and don't require anything else from people 12:19 < dr_orlovsky> aj: but I think PR must be improved in order to be a part of the standard. The logic there is really hard to understand for a formal spec 12:19 < wangchun_> 1021 is unnecessary and too much caution I think. 12:19 < aj> dr_orlovsky: sure, that makes sense 12:19 < michaelfolkson> Ok back to capital letters. ONLY 1021 FROM THIS POINT ON PLEASE 12:19 < jonny100051> if BIP8 (False) doesnt work, cant the end of that activation window be used as a coordination point for a UASF? 12:20 < setpill> I don't have anything else to say about 1021, already gave my NACK 12:20 < luke-jr> so how do we resolve the disagreement? ☺ 12:20 < gloved> A proof of work! 12:20 < wangchun_> that’s the problem 12:20 < luke-jr> is this enough of a corner case that we can just leave it be? 12:20 < ghost43> I think the implementation of 1021 aj linked is definitely not a complex change 12:20 < michaelfolkson> I would say so and hope so luke-jr 12:20 < wangchun_> that’s why governance is needed. sorry to repeat this 12:20 -!- koosies [b237d477@178-55-212-119.bb.dnainternet.fi] has joined ##taproot-activation 12:20 < proofofkeags> while I ACK 1021, I'm not hell bent on getting it in 12:20 < virtu> Given the 'controversy' I prefer the BIP8 to be clear over it addressing minor issues 12:20 < wangchun_> will back to 1021 12:21 < nickler> re #1021, if you decide run bip8(true) with most nodes still running bip8(false) you really wouldn't run code that doesn't implement #1021 because you might endup on the wrong chain otherwise 12:21 < achow101> IMO this is enough of a corner case that we can ignore it. small chain splits following soft forks are nothing new to us 12:21 < benthecarman> luke-jr I believe so, I acked 1021 but if it is not merged I will not be too worried 12:21 < aj> nickler: only if you also reduce the timeout 12:21 < dr_orlovsky> I propose to improve description of the algorithm and then re-review PR 1021 12:21 < luke-jr> nickler: hmm 12:21 < wangchun_> achow101: second to this 12:21 < aj> i think? no wait 12:21 < setpill> nickler: if you decide to run bip8(true) against the grain you can expect miners to try and fuck with you regardless, so dont do it if you are not ready for that 12:21 < CodeShark____> if we ever get to the point where 1021 is necessary, we probably already screwed up. the corner cases are important mainly to ensure there are little incentives to sabotage the MASF 12:21 < luke-jr> no, wait, nickler has a string point 12:22 < aj> yes, he does 12:22 < luke-jr> without 1021, you could run LOT=true and fail to follow the Taproot-activated chain! 12:22 < nickler> yeah 12:22 < gloved> Hmm 12:22 < wangchun_> lol 12:23 < achow101> luke-jr: wouldn't you be following the taproot not-activated chain? 12:23 < achow101> your node thinks it's active, but it isn't 12:23 < luke-jr> achow101: you'd be following nothing 12:23 < hsjoberg> Correct 12:23 < luke-jr> stuck for no reason 12:23 < achow101> I mean with 1021 12:23 < luke-jr> no 12:23 < luke-jr> with 1021, Taproot still must activate to follow it 12:24 -!- gz82 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 12:24 < felixweis> btc1 eventually shut down 12:24 < hsjoberg> loc=true nodes would be unnecessarily screwed. 12:24 < achow101> ah, nvm. threshold must be met during must_signal 12:24 < benthecarman> with 1021 you just get stuck after a ~100 blocks instead, right? 12:24 < felixweis> *nodes 12:24 < achow101> but you just chain split when the threshold is not being met 12:24 < luke-jr> benthecarman: you don't get stuck because miners would have to comply to get Taproot 12:25 < hsjoberg> Following the threshold instead of requiring all miners to signal is perhaps more sensible and is more akin to the loc=false mode 12:25 < wangchun_> not sure if it’s worth it 12:25 < luke-jr> wangchun_: it's needed because of what nickler points out 12:25 < wangchun_> if we’d give loc=true some tolerate 12:25 -!- fodediop [~fode@41.214.90.237] has quit [Ping timeout: 272 seconds] 12:26 < hsjoberg> Given that the code isn't that bad as I thought it would be I'm slightly in favor 12:26 < aj> yeah, if timeout=X+2016, then blocks X..X+2015 can have <95% signalling, 95%-99.9% signalling, or 100% signalling; lockinontimeout=true will currently reject the first two options, while lockinontimeout=false will accept all three and consider the last two to have the soft fork activated 12:26 < luke-jr> LOC=true is arguably broken without it 12:26 < hsjoberg> Agree 12:26 < wangchun_> yay that’s the point 12:26 < michaelfolkson> If what nickler says is true then yeah it is a definite ACK 12:26 < luke-jr> wangchun_: are you admitting to trying to sabotage Bitcoin? 12:26 < michaelfolkson> Haha please be civil 12:26 < bitentrepreneur> come on... 12:26 < hsjoberg> loc=true mode looks pretty broken without 2021 12:26 < michaelfolkson> I think we're going to need to wrap up soon 12:27 < luke-jr> nickler: what's your github username? 12:27 < nickler> luke-jr: jonasnick 12:27 < michaelfolkson> Is there anything else anyone wants to cover in last 5 minutes? 12:27 < wangchun_> I’ve removed my NACK on github 12:27 < nickler> michaelfolkson: as mentioned in my comment I checked this property with a haskell implementation of the PR and quickcheck 12:27 < dr_orlovsky> I also removed concept NACK on 1021 12:27 < proofofkeags> nickler where is that implementation? 12:27 < gloved> Ooo that sounds interesting 12:28 < michaelfolkson> Feel free to continue discussion after the meeting ends. But just to put a clean close on things 12:28 < michaelfolkson> Cool nickler 12:28 < nickler> it's too bad to publish, was only to help me review 12:28 < luke-jr> michaelfolkson: wait, we have a time limit? 12:28 < michaelfolkson> We don't. But I should close it right? 12:28 < nickler> but it should be easy for people to reimplement and test it 12:28 < luke-jr> XD 12:28 < michaelfolkson> Discussion can continue after 12:28 < hsjoberg> Yeah lets move on 12:28 < luke-jr> looking at http://luke.dashjr.org/programs/bitcoin/files/charts/security.html 12:28 -!- btcbb [d5399d8e@213.57.157.142] has quit [Quit: Connection closed] 12:29 < luke-jr> ~45% have upgraded in ~2 weeks 12:29 < bitentrepreneur> i think we should close it, we've progressed 12:29 < michaelfolkson> Ok I think luke-jr is playing with me. Let's wrap up the meeting. #endmeeting 12:29 < aj> could be good to ask if people are upgrading to 0.21 already? 12:29 < luke-jr> I think we need more data before deciding on signalling-begins timeframe, but 2 weeks is too soon IMO 12:29 < michaelfolkson> But feel free to continue discussion for however long you want 12:29 < michaelfolkson> This channel is open 24 hours 12:29 < achow101> wasn't segwit 2 months or something? 12:29 < benthecarman> aj: I am upgraded :) 12:29 < luke-jr> aj: I tweeted to encourage upgrades 12:29 < achow101> from releaset to start time 12:29 < hsjoberg> luke-jr: Wow that's pretty fast 12:29 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has quit [Quit: Ping timeout (120 seconds)] 12:30 < luke-jr> hsjoberg: indeed, but not enough yet 12:30 < hsjoberg> Yes 12:30 < waxwing> michaelfolkson, thanks for herding the cats (meow) 12:30 < luke-jr> achow101: I was worried 2 months might be too quick, but 45% is encouraging 12:30 < belcher> yes, ty michaelfolkson 12:30 < luke-jr> thanks michaelfolkson 12:30 < michaelfolkson> waxwing: Hopefully I didn't insult too many people 12:30 < gloved> Ty michael 12:30 < andrewtoth> thanks michaelfolkson 12:30 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has joined ##taproot-activation 12:30 < aj> luke-jr: does upgraded mean 21 not 20.whatever? 12:30 < hsjoberg> But 1 year deadline looks to be pretty conservative. Although more interesting would be a timeline graph 12:30 < achow101> luke-jr: that may also be due to the major release 12:30 < norisgOG> thanks michaelfolkson 12:30 < rusty> michaelfolkson: thanks! 12:30 < achow101> luke-jr: I expect minor releases have a longer uptake 12:30 < virtu> luke-jr: updates on your website means 0.21? 12:30 < luke-jr> achow101: IMO softfork is a bigger deal 12:30 < aj> luke-jr: i guess 20.whatever is fine for these purposes though 12:31 < luke-jr> virtu: or 0.19.3 12:31 < michaelfolkson> No worries. No need for anymore thanks! 12:31 -!- alibaba [563127e3@ip-86-49-39-227.net.upcbroadband.cz] has joined ##taproot-activation 12:31 < luke-jr> virtu: or 0.20.2 as soon as that's out 12:31 < luke-jr> oh, I wonder if it includes 0.20.1 12:31 < gloved> We should also consider that people may upgrade faster relative to other versions if the release has taproot 12:31 < luke-jr> it does -.- 12:31 -!- gz82 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Quit: Connection closed] 12:31 < lucasmoten> I think upgraded includes 0.20.1 12:31 < bitentrepreneur> thanks all 12:31 < luke-jr> 23452 /Satoshi:0.20.1/ updated 12:31 < luke-jr> so it's not even 45% :< 12:31 < luke-jr> gloved: that's why I encourage upgrading 0.21 / 0.20.2 as if it were Taproot 12:32 < luke-jr> merged 1021 12:32 < Raincloud>    23452 /Satoshi:0.20.1/ updated 12:32 < Raincloud>    13715 /Satoshi:0.21.0/ updated 12:32 < aj> luke-jr: i'll have a go at getting nicer wording for the 1021 changes 12:32 < hsjoberg> setting deadline to 6m seems reasonable 12:32 < luke-jr> only 16% then 12:32 < luke-jr> aj: ? 12:32 -!- CraigSW [~androirc@2a00:23c5:ed96:500:89ac:4966:a1a6:f38e] has quit [Ping timeout: 272 seconds] 12:32 < aj> luke-jr: dr_orlovsky's complaints about it being hard to follow the maths 12:32 < luke-jr> hsjoberg: I thought everyone was okay with 1y 12:33 < luke-jr> aj: ah 12:33 -!- krakatoa69 [49cb5a1f@c-73-203-90-31.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds] 12:33 < CodeShark____> the shorter the deadline (assuming it is still long enough to get everyone deployed) the easier it is to get the news to focus on it 12:33 < luke-jr> it might be good to make the % explicitly configurable too 12:33 < gloved> some people were in favor of shorter 12:33 < prayank> luke-jr: 33% vulnerable nodes in that pie chart 😳 12:33 < luke-jr> starting at 1y does'nt preclude making it shorter ;_) 12:33 < CodeShark____> shorter deadline may be preferable from a pure publicity standpoint 12:33 < hsjoberg> gloved: agree, if everyone knows 0.21.1 will be the taproot release, we can expect people to upgrade quicker 12:33 -!- AlexandreChery [9466964e@148.102.150.78] has left ##taproot-activation [] 12:33 < luke-jr> prayank: yeah.. and that's only publicly disclosed vulns :/ 12:34 -!- NoDeal [aec5028d@141.sub-174-197-2.myvzw.com] has joined ##taproot-activation 12:34 -!- AlexandreChery [9466964e@148.102.150.78] has joined ##taproot-activation 12:34 < luke-jr> shoot, we should have scheduled the next (2?) meetings before closing the meeting 12:34 < luke-jr> next one IMO should probably just be code review only 12:34 -!- AlexandreChery [9466964e@148.102.150.78] has left ##taproot-activation [] 12:34 < benthecarman> on your pr? ack 12:35 < Raincloud>   ~29% /Satoshi:0.20.1/ updated 12:35 < Raincloud>    ~16% /Satoshi:0.21.0/ updated 12:35 < michaelfolkson> When are you thinking luke-jr? In two weeks? 12:35 -!- alibaba [563127e3@ip-86-49-39-227.net.upcbroadband.cz] has quit [Client Quit] 12:35 -!- erijon [~erijon@2a0b:f4c2:2::1] has quit [Quit: Leaving] 12:35 -!- valeriyageorg [4f195edd@host-79-25-94-221.retail.telecomitalia.it] has quit [Quit: Connection closed] 12:35 < aj> luke-jr: next week's PR review club doesn't seemt o have a topic? https://bitcoincore.reviews/ 12:35 -!- fodediop [~fode@41.214.90.237] has joined ##taproot-activation 12:35 < gloved> Perfect opportunity 12:35 < michaelfolkson> I'll try (repeat try) to summarize today's meeting for the mailing list 12:35 < michaelfolkson> But will receive arrows 12:36 -!- fengyun [73cca4a9@115.204.164.169] has quit [Quit: Connection closed] 12:36 < proofofkeags> thank you, michaelfolkson, for helping moderate this meeting :) 12:36 < michaelfolkson> I can ask John about next week's PR review club 12:36 < michaelfolkson> Agreed I should? 12:36 < gloved> Please 12:36 < michaelfolkson> Ok 12:36 < proofofkeags> +1 12:36 < lucasmoten> +1 12:36 < aj> luke-jr: ^ ? 12:37 < michaelfolkson> Do you want a couple of weeks or is literally next week preferable? 12:37 < luke-jr> benthecarman: I need to merge in aj's changes to my PR first tho 12:37 -!- trooter [4a40f913@cpe-74-64-249-19.nj.res.rr.com] has quit [Quit: Connection closed] 12:37 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined ##taproot-activation 12:37 < luke-jr> michaelfolkson: sgtm 12:37 -!- Zeven74 [33afe11f@31.51-175-225.customer.lyse.net] has quit [Quit: Connection closed] 12:37 < michaelfolkson> Next week? Ok 12:37 -!- koosies [b237d477@178-55-212-119.bb.dnainternet.fi] has quit [Quit: Connection closed] 12:37 < luke-jr> aj: is your branch a straight merge? 12:37 < aj> luke-jr: do feel free to squash those in whatever way you see fit 12:38 -!- gz9 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 12:38 < aj> luke-jr: i think it'd be better squashed in places, and some sort of rebase is needed anyway, but i've forgotten the details :) 12:38 -!- r251d [~r251d@50.121.84.2] has quit [Quit: r251d] 12:38 < luke-jr> ok, I'll look at it in detail in a bit 12:38 < aj> luke-jr: oh, no it's not a straight merge, i did some fixes out of order so they were easier to squash i think 12:39 -!- oxtr [~tommy@13.84-234-189.customer.lyse.net] has quit [Quit: WeeChat 3.0] 12:40 < aj> afk for breakfast for a bit 12:40 -!- krakatoa69 [49cb5a1f@c-73-203-90-31.hsd1.co.comcast.net] has joined ##taproot-activation 12:40 < gloved> Great meeting, all 12:40 < bobazY> Useful meeting, thanks all, thanks michaelfolkson 12:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 12:40 < michaelfolkson> No problem bobazY proofofkeags 12:41 -!- gloved [8d6267fb@141.98.103.251] has quit [Quit: Connection closed] 12:41 < benthecarman> luke-jr: I meant ack on the idea, not the pr :P 12:41 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has quit [Quit: Connection closed] 12:41 < CodeShark____> thanks, michaelfolkson 12:41 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 12:41 < emzy> tnx michaelfolkson and all! 12:41 -!- alexandrev [~alexandre@cpe-24-193-76-156.nyc.res.rr.com] has quit [Ping timeout: 265 seconds] 12:41 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has joined ##taproot-activation 12:42 -!- solairis [bdcb842e@fixed-189-203-132-46.totalplay.net] has quit [Quit: Connection closed] 12:42 -!- andhans [5b3117b2@p5b3117b2.dip0.t-ipconnect.de] has quit [Client Quit] 12:42 < felixweis> thank you michaelfolkson for org, good inputs all! 12:42 -!- gz9 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Client Quit] 12:43 -!- NoDeal [aec5028d@141.sub-174-197-2.myvzw.com] has left ##taproot-activation [] 12:43 -!- gz77 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has joined ##taproot-activation 12:43 -!- lucasmoten [~lucasmote@45.146.55.219] has quit [Quit: Leaving] 12:43 < virtu> I did a quick timeline on node versions in case the data proves useful concerning choice of timeframe: http://virtu.llc/tmp/node_version_history.svg (note, however, it's just listening nodes) 12:44 -!- s3ton [02ec7591@2.236.117.145] has joined ##taproot-activation 12:44 -!- s3ton [02ec7591@2.236.117.145] has quit [Client Quit] 12:44 -!- Guest79 [c11b0d8e@193.27.13.142] has left ##taproot-activation [] 12:45 -!- naribia [6bb5bd25@107.181.189.37] has quit [Quit: Connection closed] 12:45 < michaelfolkson> Nice 12:45 < hsjoberg> Very nice, thanks virtu 12:45 -!- z88 [32f36641@50-243-102-65-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed] 12:46 -!- rovdi [~rovdi@host-5-58-235-16.bitternet.ua] has joined ##taproot-activation 12:46 -!- PinkElephant [~PinkEleph@87.118.155.136] has quit [Quit: leaving] 12:46 -!- CodeShark____ [sid126576@gateway/web/irccloud.com/x-lykhywlaecnkcjgo] has quit [] 12:48 -!- edoneerf [6b837dbf@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed] 12:48 -!- civboi [~civboi@153.33.34.102] has quit [Quit: Leaving] 12:50 -!- jonny100051 [58d4b41d@88.212.180.29] has quit [Quit: Connection closed] 12:50 -!- valeriyageorg [4f195edd@host-79-25-94-221.retail.telecomitalia.it] has joined ##taproot-activation 12:50 < rovdi> am i late? 12:50 < bobazY> rovdi: about 2 hours late 12:50 -!- friendly_arthrop [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has quit [Quit: Connection closed] 12:51 -!- Calkob [52033acb@cpc78887-bele10-2-0-cust202.2-1.cable.virginm.net] has joined ##taproot-activation 12:51 < bobazY> But michaelfolkson said: "I'll try (repeat try) to summarize today's meeting for the mailing list" :) 12:51 < felixweis> next meeting is wednesday in 1 week at 1700z 12:51 -!- LRHel [536320c1@ip-83-99-32-193.dyn.luxdsl.pt.lu] has quit [Quit: Connection closed] 12:51 -!- gz77 [1f0a8c94@31-10-140-148.cgn.dynamic.upc.ch] has quit [Quit: Connection closed] 12:52 -!- StijnBtc [~StijnBtc@77-165-254-59.fixed.kpn.net] has quit [Quit: Leaving] 12:52 -!- valeriyageorg [4f195edd@host-79-25-94-221.retail.telecomitalia.it] has quit [Client Quit] 12:52 -!- rovdi [~rovdi@host-5-58-235-16.bitternet.ua] has quit [Quit: leaving] 12:52 -!- Calkob [52033acb@cpc78887-bele10-2-0-cust202.2-1.cable.virginm.net] has quit [Client Quit] 12:52 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has joined ##taproot-activation 12:52 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 12:52 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation 12:52 -!- walletscrutiny [c9d78d27@pc-39-141-215-201.cm.vtr.net] has quit [Quit: Connection closed] 12:52 < hsjoberg> rovdi: yes meeting is over 12:53 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation [] 12:54 -!- pY61FlIVov44lCnk [5cba724a@92.186.114.74] has quit [Quit: Connection closed] 12:55 < bitentrepreneur> ill also help michael out with the summary 12:56 -!- satosaurian [b0c7d365@ip-176-199-211-101.hsi06.unitymediagroup.de] has quit [Quit: Connection closed] 12:58 -!- btc_iota [2f9d7da2@47.157.125.162] has quit [Quit: Connection closed] 12:58 -!- Raincloud [ac532845@172.83.40.69] has quit [Quit: Connection closed] 12:59 -!- Billy [86290e1a@hlfxns018gw-134-41-14-26.dhcp-dynamic.fibreop.ns.bellaliant.net] has quit [Ping timeout: 248 seconds] 12:59 -!- MikeMarzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has quit [Quit: Connection closed] 12:59 -!- zztop [622a7e87@98.42.126.135] has joined ##taproot-activation 12:59 -!- bobazY [~N_Ivarsso@120-111-178-143.ftth.glasoperator.nl] has quit [Quit: Leaving] 13:00 -!- hi [c6368369@static-198-54-131-105.cust.tzulo.com] has joined ##taproot-activation 13:00 -!- zztop [622a7e87@98.42.126.135] has quit [Client Quit] 13:00 -!- alexandrev [~alexandre@cpe-24-193-76-156.nyc.res.rr.com] has joined ##taproot-activation 13:00 -!- krakatoa69 [49cb5a1f@c-73-203-90-31.hsd1.co.comcast.net] has quit [Quit: Connection closed] 13:00 -!- ryanthegentry [8831d538@136.49.213.56] has quit [Quit: Connection closed] 13:01 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has joined ##taproot-activation 13:01 -!- Gman [5dacca1a@93-172-202-26.bb.netvision.net.il] has joined ##taproot-activation 13:02 -!- Gman [5dacca1a@93-172-202-26.bb.netvision.net.il] has quit [Client Quit] 13:02 -!- alexandrev [~alexandre@cpe-24-193-76-156.nyc.res.rr.com] has quit [Client Quit] 13:02 -!- gr-g [4dbd1fd2@x4dbd1fd2.dyn.telefonica.de] has quit [Ping timeout: 248 seconds] 13:04 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left ##taproot-activation [] 13:09 -!- hi [c6368369@static-198-54-131-105.cust.tzulo.com] has quit [Quit: Ping timeout (120 seconds)] 13:09 -!- andras [bc8ecbaa@catv-188-142-203-170.catv.broadband.hu] has quit [Quit: Connection closed] 13:09 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has quit [Ping timeout: 240 seconds] 13:09 -!- Johnkrak [2e22e408@ip-46.34.228.8.o2inet.sk] has joined ##taproot-activation 13:10 -!- Johnkrak [2e22e408@ip-46.34.228.8.o2inet.sk] has quit [Client Quit] 13:11 -!- fodediop [~fode@41.214.90.237] has quit [Quit: WeeChat 3.0] 13:14 -!- tonysanak82 [d847dcf5@216-71-220-245.dyn.novuscom.net] has left ##taproot-activation [] 13:17 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has quit [] 13:18 < luke-jr> aj: "VersionBitsStatistics expects pindex not pindexPrev" - but it doesn't? 13:19 < luke-jr> aj: rebased your branch and squashed some things (my bip8 branch); didn't investigate ^ yet 13:20 < aj> luke-jr: VersionBitsStatistics(const CBlockIndex* pindexPrev, calls ersionBitsConditionChecker(pos).GetStateStatisticsFor(pindexPrev, but AbstractThresholdConditionChecker::GetStateStatisticsFor(const CBlockIndex* pindex, 13:21 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has quit [Quit: Connection closed] 13:21 -!- Alistair_Mann [56ab68b9@host86-171-104-185.range86-171.btcentralplus.com] has quit [Quit: Connection closed] 13:22 -!- pescador [3efb0966@62-251-9-102.ip.xs4all.nl] has joined ##taproot-activation 13:22 -!- darbsllim [63f253a4@gateway/web/cgi-irc/kiwiirc.com/ip.99.242.83.164] has quit [Quit: darbsllim] 13:23 -!- pescador is now known as Guest26300 13:23 < aj> luke-jr: hmm ... i have no idea why that commit's in there though, it's just a no-op. 13:24 -!- matthewblack [~matthewbl@ip-45-41-170-185.fibre.fibrestream.ca] has quit [] 13:25 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has quit [Quit: Leaving] 13:27 -!- jbeddict [6408d596@pool-100-8-213-150.nwrknj.fios.verizon.net] has quit [Quit: Connection closed] 13:29 -!- prayank [~andr0irc@2402:8100:206c:5226:348b:b4b2:a2f5:ad48] has quit [Ping timeout: 258 seconds] 13:32 -!- snash779 [9eb54db9@158.181.77.185] has quit [Quit: Connection closed] 13:32 -!- Guest26300 [3efb0966@62-251-9-102.ip.xs4all.nl] has quit [Quit: Connection closed] 13:35 < luke-jr> aj: VersionBitsStatistics is called with pindexPrev, so.. need to figure this out :/ 13:36 -!- deen_ [65620f61@101.98.15.97] has joined ##taproot-activation 13:39 -!- anonuser547 [63b84fa3@99-184-79-163.lightspeed.jcvlfl.sbcglobal.net] has joined ##taproot-activation 13:39 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 13:44 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 13:46 < aj> luke-jr: the other VersionBits functions tell you what the state of the current block is by passing in its parent; VBStatistics tells you the stats including the block you passed in. current code passes in Tip() to all of them, telling you the stats including the tip block, and the state for whatever the next block to arrive 13:47 -!- Jason [8ff43287@143.244.50.135] has joined ##taproot-activation 13:48 -!- Jason is now known as Jason555 13:49 -!- Jason555 [8ff43287@143.244.50.135] has quit [Client Quit] 13:49 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed] 13:49 < luke-jr> aj: okay, I guess that mkaes sense 13:51 -!- sqaCrabdracula [b9c1e324@185.193.227.36] has joined ##taproot-activation 13:51 -!- BitCarrot [9084db5a@144.132.219.90] has joined ##taproot-activation 13:51 -!- mountainhodl [4504ea0d@69.4.234.13] has joined ##taproot-activation 13:52 -!- lurking [49faa072@c-73-250-160-114.hsd1.md.comcast.net] has joined ##taproot-activation 13:52 -!- BearishGay [b9c1e324@185.193.227.36] has joined ##taproot-activation 13:52 -!- sqaCrabdracula [b9c1e324@185.193.227.36] has quit [Client Quit] 13:52 -!- BitCarrot [9084db5a@144.132.219.90] has quit [Client Quit] 13:52 -!- BearishGay [b9c1e324@185.193.227.36] has quit [Client Quit] 13:54 -!- shawny [69bd3754@105.189.55.84] has joined ##taproot-activation 13:55 -!- zndtoshi [567cb7ee@86.124.183.238] has joined ##taproot-activation 13:55 -!- shawny [69bd3754@105.189.55.84] has quit [Changing host] 13:55 -!- shawny [69bd3754@unaffiliated/shawny] has joined ##taproot-activation 13:55 -!- anonuser547 [63b84fa3@99-184-79-163.lightspeed.jcvlfl.sbcglobal.net] has quit [Quit: Connection closed] 13:56 -!- mountainhodl [4504ea0d@69.4.234.13] has quit [Client Quit] 13:56 -!- shawny [69bd3754@unaffiliated/shawny] has quit [Client Quit] 13:57 -!- janoside [44eb2b54@68.235.43.84] has quit [Quit: Connection closed] 14:03 -!- jon79 [62cf5005@c-98-207-80-5.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 14:03 -!- carlakc [uid471474@gateway/web/irccloud.com/x-qisnqdlibmhvayzj] has quit [Quit: Connection closed for inactivity] 14:08 -!- anna754839 [b94187e6@185.65.135.230] has quit [Quit: Connection closed] 14:15 -!- gg30 [4641afdd@S0106d807b66f84ea.rd.shawcable.net] has joined ##taproot-activation 14:16 -!- gg30 [4641afdd@S0106d807b66f84ea.rd.shawcable.net] has quit [Client Quit] 14:18 -!- schulzemic [~ada@193.27.14.104] has quit [Quit: Konversation terminated!] 14:26 -!- ryan87 [541127c9@84.17.39.201] has quit [Quit: Connection closed] 14:26 -!- gritcoin [43b989a4@c-67-185-137-164.hsd1.wa.comcast.net] has quit [Ping timeout: 248 seconds] 14:40 -!- openoms54 [5b84884c@91.132.136.76] has joined ##taproot-activation 14:42 -!- openoms54 [5b84884c@91.132.136.76] has quit [Client Quit] 14:47 -!- prusnak [sid403625@gateway/web/irccloud.com/x-mzyynxklwhxatlbs] has left ##taproot-activation [] 14:49 -!- monokh [5cef15e9@92.239.21.233] has joined ##taproot-activation 14:55 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 14:56 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 14:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 14:58 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 15:03 -!- lukedashjr is now known as luke-jr 15:04 -!- bitentrepreneur [uid39920@gateway/web/irccloud.com/x-zhybvvhwzpluynfq] has quit [Quit: Connection closed for inactivity] 15:05 -!- zndtoshi [567cb7ee@86.124.183.238] has quit [Quit: Connection closed] 15:10 -!- SK999 [5c3bd3a1@92.59.211.161] has joined ##taproot-activation 15:11 -!- SK999 [5c3bd3a1@92.59.211.161] has quit [Client Quit] 15:11 -!- entropyhappens [d4662ca2@212.102.44.162] has joined ##taproot-activation 15:11 -!- egg87 [d57f519b@ip-213-127-81-155.ip.prioritytelecom.net] has joined ##taproot-activation 15:11 -!- egg87 [d57f519b@ip-213-127-81-155.ip.prioritytelecom.net] has quit [Client Quit] 15:12 -!- benthecarman [~ben@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 246 seconds] 15:15 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has left ##taproot-activation ["Leaving"] 15:18 -!- Satoshi [8ff42896@143.244.40.150] has joined ##taproot-activation 15:18 -!- Satoshi [8ff42896@143.244.40.150] has left ##taproot-activation [] 15:19 -!- Hodlonandon [8ff42896@143.244.40.150] has joined ##taproot-activation 15:21 -!- Hodlonandon [8ff42896@143.244.40.150] has quit [Client Quit] 15:23 -!- nympus [b94186f2@185.65.134.242] has joined ##taproot-activation 15:24 -!- nympus [b94186f2@185.65.134.242] has quit [Client Quit] 15:32 -!- monokh [5cef15e9@92.239.21.233] has quit [Quit: Ping timeout (120 seconds)] 15:32 -!- topg12 [25782e93@37.120.46.147] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- freerk [5c74722d@i5C74722D.versanet.de] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- lurking [49faa072@c-73-250-160-114.hsd1.md.comcast.net] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- deen_ [65620f61@101.98.15.97] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- CriptoLuis [be9ba048@190.155.160.72] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- entropyhappens [d4662ca2@212.102.44.162] has quit [Quit: Ping timeout (120 seconds)] 15:34 -!- Alistair_Mann [56ab68b9@host86-171-104-185.range86-171.btcentralplus.com] has joined ##taproot-activation 15:35 -!- Alistair_Mann [56ab68b9@host86-171-104-185.range86-171.btcentralplus.com] has quit [Client Quit] 15:38 -!- monokh [5cef15e9@92.239.21.233] has joined ##taproot-activation 15:38 -!- monokh [5cef15e9@92.239.21.233] has quit [Client Quit] 15:48 -!- tyler99 [49024a91@c-73-2-74-145.hsd1.ca.comcast.net] has joined ##taproot-activation 15:49 -!- tyler99 [49024a91@c-73-2-74-145.hsd1.ca.comcast.net] has quit [Client Quit] 16:11 -!- Netsplit *.net <-> *.split quits: kanon 16:14 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 16:15 -!- TechMiX [~techtux@2001:4649:61c8:0:da2c:c9fa:866f:1342] has left ##taproot-activation [] 16:18 -!- lurking [49faa072@c-73-250-160-114.hsd1.md.comcast.net] has joined ##taproot-activation 16:18 -!- lurking [49faa072@c-73-250-160-114.hsd1.md.comcast.net] has quit [Client Quit] 16:31 -!- common [~common@unaffiliated/common] has joined ##taproot-activation 16:31 -!- iduno8912 [~Devan@cpe-172-113-125-218.socal.res.rr.com] has joined ##taproot-activation 16:32 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has left ##taproot-activation ["Bye!"] 16:32 -!- common [~common@unaffiliated/common] has quit [Read error: Connection reset by peer] 16:33 -!- common [~common@unaffiliated/common] has joined ##taproot-activation 16:33 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 240 seconds] 16:36 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 16:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds] 16:40 -!- lukedashjr is now known as luke-jr 16:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 16:53 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 16:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 16:53 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 16:57 -!- lukedashjr is now known as luke-jr 17:01 -!- pox [~pox@147.234.92.170] has quit [Ping timeout: 240 seconds] 17:04 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 17:04 -!- zelgada [8eb1f5d6@142.177.245.214] has joined ##taproot-activation 17:05 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 17:14 -!- zelgada [8eb1f5d6@142.177.245.214] has quit [Ping timeout: 248 seconds] 17:16 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 17:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:53 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds] 18:43 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Remote host closed the connection] 18:44 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation 18:48 -!- dylan [ae588ff2@bras-base-otwaon0812w-grc-23-174-88-143-242.dsl.bell.ca] has joined ##taproot-activation 18:48 -!- dylan is now known as Guest64037 18:49 -!- Guest64037 [ae588ff2@bras-base-otwaon0812w-grc-23-174-88-143-242.dsl.bell.ca] has quit [Client Quit] 19:22 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 19:25 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 240 seconds] 20:25 -!- narcelio [~nf@179.186.160.103] has quit [Ping timeout: 240 seconds] 20:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 20:50 -!- b77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has quit [Quit: leaving] 21:09 -!- suntsu8 [~suntsu@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has left ##taproot-activation [] 21:12 -!- btee [49137fc5@c-73-19-127-197.hsd1.wa.comcast.net] has joined ##taproot-activation 21:13 -!- btee [49137fc5@c-73-19-127-197.hsd1.wa.comcast.net] has quit [Client Quit] 21:43 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 22:16 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has joined ##taproot-activation 22:33 -!- pox [~pox@82.114.45.173] has joined ##taproot-activation 23:08 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds] 23:52 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 258 seconds] 23:52 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation --- Log closed Wed Feb 03 00:00:34 2021