--- Log opened Thu Jan 28 00:00:28 2021 00:11 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 00:11 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 01:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 01:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 01:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 02:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 02:45 < michaelfolkson> Personally I think you want it to be a last resort. And in that sense it should be hard to do as other activation methods should have been pursued first. 02:47 < michaelfolkson> But you shouldn't pursue technical difficulty/complexity to make it hard. If it is needed as a last resort it should be technically viable 02:53 < michaelfolkson> The only precedent we have is SegWit. I understand why some people thought there wasn't sufficient consensus for doing UASF at the time (so difficult to measure consensus obviously but some clear opposition) 02:55 < michaelfolkson> But if SegWit levels of chaos and prolonged delay (at a bare minimum) are needed before UASF is considered I think that is fine 02:56 < michaelfolkson> I don't think there is even a 0.1 percent chance of that happening with Taproot but it is never zero. You can't entirely rule things out 03:06 -!- belcher_ is now known as belcher 03:13 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer] 03:14 -!- darosior [~darosior@194.36.189.246] has joined ##taproot-activation 04:31 < michaelfolkson> From where I'm sitting it seems revised BIP 8 is best placed to be the activation method at the current time but it would be good to hear where Matt, BTC.com etc stand on it 04:40 < belcher> aside from the UASF stuff, using block height rather than timestamp seems more logical to me... imagine if the halvening happened at a certain timestamp instead of exactly every 210000 blocks, it would be weird, right? 04:45 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has joined ##taproot-activation 04:49 < michaelfolkson> Right block height seems the better option to me 04:57 -!- L3300 [51cc0e98@81-204-14-152.fixed.kpn.net] has joined ##taproot-activation 04:58 -!- L3300 [51cc0e98@81-204-14-152.fixed.kpn.net] has quit [Client Quit] 05:26 -!- rdymac_ [uid31665@gateway/web/irccloud.com/x-rtrvbrteldnwftvj] has joined ##taproot-activation 05:34 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: I'm out.] 05:35 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation 05:44 -!- darosior4 [~darosior@194.36.189.246] has joined ##taproot-activation 05:45 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer] 05:54 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 05:54 -!- jonatack [~jon@88.124.242.136] has quit [Client Quit] 06:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 06:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 06:26 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has quit [Quit: Ping timeout (120 seconds)] 06:37 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has joined ##taproot-activation 07:46 -!- darosior4 is now known as darosior 07:54 < nothingmuch> if timestamp is used, what is the potential for malice by under-utilizing hash power in order to cause activation to happen at a lower difficulty or block height? 07:54 < nothingmuch> i can't think of anything concrete, but intuitively it seems more gamable than desirable 08:02 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 08:07 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 246 seconds] 08:07 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation 08:10 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Client Quit] 08:13 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 08:19 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds] 08:19 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation 08:29 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 08:34 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed] 08:37 -!- fanquake_ [sid369002@gateway/web/irccloud.com/x-hooxevzeyzepxlxz] has quit [Read error: Connection reset by peer] 08:38 -!- fanquake_ [sid369002@gateway/web/irccloud.com/x-pllzngnlrrqggqyd] has joined ##taproot-activation 08:48 < luke-jr> michaelfolkson: actually, most softforks have been UASFs 08:49 < michaelfolkson> We are in the world of defining what a UASF is now I guess :) 08:49 < luke-jr> nothingmuch: not sure what you mean - the goal is activation 08:50 < luke-jr> michaelfolkson: not really 08:50 < luke-jr> michaelfolkson: BIP 9 was only used for one softfork (not counting Segwit since it failed) 08:51 < luke-jr> there were a few increment-version-number MASFs before that 08:51 < luke-jr> but prior to those, everything was UASF 08:51 < michaelfolkson> I guess I'm defining a UASF as BIP 148 08:52 < luke-jr> that's silly, since BIP148 was a specific one-time thing 08:52 < luke-jr> nothing would ever be a UASF before nor after with such a definition 08:54 < michaelfolkson> Ok I'm happy to go with your definitions. In that case BIP148 (or an equivalent) should only be used as a last resort. UASF doesn't necessarily have the same connotations or risks that people were worried about with BIP148 08:55 < michaelfolkson> BIP 148 is the riskiest option of multiple UASF options 08:56 < luke-jr> O.o 08:57 < michaelfolkson> What does that mean? :) 08:57 < belcher> there was a proposal bip149 which was riskier in many ways 08:57 < luke-jr> michaelfolkson: it's not clear what you're intending to say is risky 08:57 < luke-jr> BIP148's timeframe is probably the only risky part of it? 08:58 < michaelfolkson> The risk that I'm referring to is the risk of the network splitting. A percentage of the network rejecting blocks that the remaining percentage are accepting 08:59 < michaelfolkson> I know you will argue that this wasn't a risk in SegWit's case because there was consensus among users/full nodes 08:59 < luke-jr> michaelfolkson: that risk exists with or without any protocol change 08:59 < luke-jr> UASFs, including BIP148, do not increase that risk 09:00 < michaelfolkson> It is more pronounced in a BIP 148 case because there are a stark choice for nodes on the network to make 09:00 < michaelfolkson> *there is 09:00 < michaelfolkson> In normal times such a choice does not need to be made 09:01 < luke-jr> yes there is 09:01 < michaelfolkson> I know you will argue every time you upgrade your software to a new Core version that is a choice. But no urgency with this choice. You don't risk being on a split network 09:01 < luke-jr> and unawareness of that is a danger to Bitcoin 09:02 < luke-jr> miners can always produce invalid blocks 09:02 < luke-jr> users can always choose to use full node or light wallet 09:03 < michaelfolkson> I get your argument. But when I upgrade to a new Core version I have no worries, no sweat. If I had to choose between two versions where one is rejecting blocks and the other is accepting those blocks I sweat 09:03 < luke-jr> the result of that choice can always be catastrophic 09:03 < luke-jr> michaelfolkson: you're assuming Core is the only option 09:04 < michaelfolkson> Right, simplifying for sake of argument 09:04 < luke-jr> oversimplifying* ;P 09:04 < michaelfolkson> Haha 09:04 < luke-jr> the situation is the same with or without a UASF 09:04 < luke-jr> miners choose to make valid or invalid blocks 09:05 < luke-jr> users choose to use full nodes or light clients 09:05 < michaelfolkson> Certainly percentages of implementations on the network suggest vast majority are only dealing with Core versions (for better or worse) 09:05 < luke-jr> I don't have data on light clients, do you? 09:06 < michaelfolkson> Nope 09:07 < michaelfolkson> Even with different implementations the chances there will be a bug or intended change to put you in that position where you are sweating on accepting/rejecting blocks is low 09:07 < luke-jr> It is also low with a UASF 09:07 < michaelfolkson> A UASF ok but not a BIP 148 UASF 09:08 < luke-jr> BIP148 was not special in this regard 09:08 < michaelfolkson> When Matt got unhappy earlier was he defining UASF how you are? 09:08 < luke-jr> I would assume 09:09 < luke-jr> there isn't really another way to define it afaik 09:09 < michaelfolkson> Ok I need to revisit. I thought we were defining UASF as BIP 148/9. That's on me 09:10 < luke-jr> What BIP 148 & 149 have in common, all has been done many times prior 09:14 < luke-jr> eg, P2SH was a case of BIP 149 09:16 < luke-jr> BIP 34 and 65 were comparable to BIP 148 09:16 < luke-jr> most of the pre-BIP softforks were also BIP 149-like 09:16 < luke-jr> (well, I guess *all* of them..) 09:19 < luke-jr> correction, 34/65 were MASFs sorry 09:20 < luke-jr> just not versionbit MASFs 09:28 < luke-jr> (though they still have the part of BIP148 Matt especially hates) 09:36 < michaelfolkson> It is hard because those early soft forks were on a tiny network managed on IRC, Bitcointalk right with Satoshi, Gavin as effective benevolent dictators? I don't know how much we can read into them as historical precedents for today 09:37 < michaelfolkson> Yet SegWit was the most recent and was a mess (due to external factors). I guess that's how we landed in the position we are today 09:45 < luke-jr> BIP148 made a good historical precedent 09:45 < luke-jr> even though it was rushed, it still worked pretty much ideally 10:06 < michaelfolkson> "that's silly, since BIP148 was a specific one-time thing" and "BIP148 made a good historical precedent" 10:06 < michaelfolkson> ? 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 11:19 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds] 11:21 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 11:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 11:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 11:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 11:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 11:44 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 11:44 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 11:45 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 11:49 -!- CARO2 [~Cesar@2804:7f4:c298:45af:7c3a:c9c7:c1a3:9e77] has quit [Ping timeout: 272 seconds] 12:44 -!- CARO2 [~Cesar@2804:7f4:c298:45af:b5c8:1106:a25b:ed2c] has joined ##taproot-activation 12:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 12:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 15:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 15:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 15:35 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-dcgzhmutntdsthom] has quit [Ping timeout: 246 seconds] 15:37 -!- felixweis_ [sid154231@gateway/web/irccloud.com/x-xnoihktppjcorqez] has joined ##taproot-activation 15:37 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-djjbiuznzxhrxocp] has joined ##taproot-activation 15:38 -!- felixweis [sid154231@gateway/web/irccloud.com/x-smefinmvkaltzcwo] has quit [Ping timeout: 260 seconds] 15:38 -!- felixweis_ is now known as felixweis 15:41 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Remote host closed the connection] 15:41 -!- waxwing_ [~waxwing@193.29.57.116] has joined ##taproot-activation 15:53 -!- hebasto [sid449604@gateway/web/irccloud.com/x-wksdajxeaaviknor] has quit [Ping timeout: 264 seconds] 15:54 -!- hebasto [sid449604@gateway/web/irccloud.com/x-eahswtbwpdytwihi] has joined ##taproot-activation 16:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 16:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 16:53 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation 16:59 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Remote host closed the connection] 17:04 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 17:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:07 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 17:11 -!- Netsplit *.net <-> *.split quits: jrawsthorne 17:11 -!- Netsplit *.net <-> *.split quits: robert_spigler 17:12 -!- Netsplit over, joins: robert_spigler, jrawsthorne 17:14 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-jjtbjalneajouwbt] has quit [Ping timeout: 240 seconds] 17:14 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-xomamwszluhtokug] has quit [Ping timeout: 244 seconds] 17:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 17:39 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 17:47 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-lelrozeewsjoiifv] has joined ##taproot-activation 17:49 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-gglsqyawzvjnaaiv] has joined ##taproot-activation 18:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:03 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-lelrozeewsjoiifv] has quit [Ping timeout: 260 seconds] 18:04 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-gglsqyawzvjnaaiv] has quit [Ping timeout: 260 seconds] 18:33 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-pfgpoxykjfjtgpfk] has joined ##taproot-activation 19:04 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-xcxdexwlbmvuuhza] has joined ##taproot-activation 19:16 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds] 19:38 -!- Netsplit *.net <-> *.split quits: gambpang_, rodarmor 19:40 -!- gambpang [~gambpang@unaffiliated/gambpang] has joined ##taproot-activation 19:46 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-ecnevpgerhrrvsyo] has joined ##taproot-activation 20:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 20:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 21:37 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 21:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 22:02 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 22:03 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 22:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 22:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 22:57 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has quit [Quit: No Ping reply in 180 seconds.] 22:58 -!- raj_149 [~quassel@ec2-18-217-191-36.us-east-2.compute.amazonaws.com] has joined ##taproot-activation 23:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 23:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 23:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 23:22 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] --- Log closed Fri Jan 29 00:00:30 2021