--- 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] <michaelfolkson> 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