--- Log opened Wed Feb 10 00:00:25 2021 00:38 -!- jonatack [~jon@37.167.157.108] has joined ##taproot-activation 00:52 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 00:55 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 01:05 -!- jonatack_ [~jon@37.166.50.22] has joined ##taproot-activation 01:08 -!- jonatack_ [~jon@37.166.50.22] has quit [Client Quit] 01:08 -!- jonatack_ [~jon@37.166.50.22] has joined ##taproot-activation 01:08 -!- jonatack_ [~jon@37.166.50.22] has quit [Client Quit] 01:09 -!- jonatack [~jon@37.167.157.108] has quit [Ping timeout: 240 seconds] 01:09 -!- jonatack [~jon@37.166.50.22] has joined ##taproot-activation 01:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 01:33 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 01:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:46 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 02:01 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has joined ##taproot-activation 02:06 <@michaelfolkson> luke-jr: No I was thinking of setting the code review date after the meeting next week. And setting an Aus friendly time for AJ 02:07 -!- CARO2 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has joined ##taproot-activation 02:08 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has quit [Ping timeout: 272 seconds] 02:08 <@michaelfolkson> The number of attendees will be smaller I'm guessing. Though if we want nickler dr_orlovsky (both Europe I think) and other Europeans there that gets aj up at crazy hour again 02:20 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 02:24 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 02:38 -!- belcher_ is now known as belcher 02:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 03:01 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds] 03:38 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has joined ##taproot-activation 03:39 -!- CARO2 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has quit [Ping timeout: 265 seconds] 04:00 -!- jonatack [~jon@37.166.50.22] has quit [Quit: jonatack] 04:06 -!- jonatack [~jon@37.166.50.22] has joined ##taproot-activation 04:08 -!- jonatack [~jon@37.166.50.22] has quit [Read error: Connection reset by peer] 04:08 -!- jonatack [~jon@37.166.50.22] has joined ##taproot-activation 04:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 04:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 04:45 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 272 seconds] 04:46 -!- jonatack [~jon@37.166.50.22] has joined ##taproot-activation 04:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 05:05 <@michaelfolkson> I was thinking about 2017 and how crazy it got during the hype and it hardened my support a little for LOT=true 05:07 <@michaelfolkson> LOT=true feels unnecessary today but who knows what could happen in 6 months if bull market takes off and all the craziness kicks off again 05:07 <@michaelfolkson> We could have a new CSW coming out the woodwork 05:08 <@michaelfolkson> LOT=true avoids all that 05:11 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 272 seconds] 05:13 <@michaelfolkson> Damn you luke-jr. I hate it when I start off thinking you are totally wrong and then I come round :) (It doesn't always happen to be clear) 05:18 <@michaelfolkson> Going to be challenging to get consensus on it though 05:20 <@michaelfolkson> Much easier to do these things in bear markets than bull markets 05:26 <@michaelfolkson> I wish you'd be less antagonistic to miners though. Makes it harder to get consensus on LOT=true imo 05:58 -!- CARO2 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has joined ##taproot-activation 06:00 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has quit [Ping timeout: 265 seconds] 06:14 -!- jonatack [~jon@37.166.50.22] has joined ##taproot-activation 06:19 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 06:20 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 06:50 < luke-jr> michaelfolkson: simply admitting they ought not have a say, is not antagonistic ;) 07:15 <@michaelfolkson> Even with your CEO, security guard analogy. If my personal security depended on my security guards I'd like to hear what they have to say 07:15 <@michaelfolkson> And it isn't a perfect analogy obviously 07:18 < luke-jr> but it doesn't 07:19 < luke-jr> the miners either create valid blocks, or they don't and cease to be the miners 07:19 < luke-jr> it's the nodes that are enforcing the rules 07:19 <@michaelfolkson> Because the security guards can be replaced in your analogy 07:20 <@michaelfolkson> Even so I wouldn't want to get a bad reputation for mistreating security guards 07:20 <@michaelfolkson> Disrepecting them, not listening to them etc 07:21 < luke-jr> this is where the analogy breaks down completely :P 07:21 <@michaelfolkson> Lol 07:22 < luke-jr> besides, they are speaking and being heard - just not as if they are more than who they are 07:22 < luke-jr> after all most miners are users too 07:22 <@michaelfolkson> Right, that's the most important point I think 07:23 <@michaelfolkson> Users that are easily identified and contacted 07:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 08:11 -!- mhinimi[m] [mhinimimat@gateway/shell/matrix.org/x-qjtqpjrdqyjzcjqu] has joined ##taproot-activation 08:30 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 08:32 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 264 seconds] 08:34 -!- common [~common@unaffiliated/common] has joined ##taproot-activation 08:37 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 264 seconds] 08:37 < nothingmuch> michaelfolkson: FWIW i would personally set LOT=true on my node, that doesn't count for much because i'm not a meaningful economic node but i think i would even if i was, but i'm still not convinced core should ship that way, and the argument is completely non technical, purely perceptions based 08:39 <@michaelfolkson> Thanks for this nothingmuch. I agree. But I think before you evaluate whether there is consensus for something you should evaluate what is the optimal option 08:39 < nothingmuch> the nature of this particular soft fork (preserves UTXO set, etc) means the moral hazard of shipping LOT=true is nothing near e.g. the geth dao fork default 08:40 <@michaelfolkson> I think LOT=true is the optimal option but I have no idea whether miners, Core will be happy with it. I hope they will 08:40 < nothingmuch> i have heard no compelling argument for LOT=false other than that people might (technically incorrectly) perceive it as a unilateral move by devs 08:41 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 08:41 <@michaelfolkson> If they aren't happy with LOT=true I wouldn't want to try to force it through. But I'm hopeful they will be happy/comfortable with it 08:41 < nothingmuch> but unfortunately people are often not technically savvy and even if they are their reasoning/preferences are often motivated by tribal affiliations more than self interest, which is why applying the precautionary principle is not straight forward here 08:42 < nothingmuch> i hope so too, but it's a bit like a Keynsean beauty contest for them 08:42 < nothingmuch> Keynesian* 08:42 <@michaelfolkson> We'll see. No point second guessing it in advance 08:43 < nothingmuch> that wasn't meant to be a guess, just pointing out the self referential nature of the dilemma 08:43 <@michaelfolkson> Right, agreed 08:44 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 240 seconds] 08:45 < nothingmuch> FWIW i might be a bit of an oddball in thinking that the catastrophic bug argument for LOT=false is kind of moot, since that can always be addressed by another soft fork that invalidates taproot spends, all that is lost is a version number 08:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 08:47 <@michaelfolkson> F4 cover it in this? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html 08:48 <@michaelfolkson> Trying to refer to these arguments in case they can be improved or added to 08:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit] 08:48 < nothingmuch> yep, i should have referred to it by number sorry 08:48 <@michaelfolkson> No worries, just checking 08:49 < nothingmuch> what i'm saying is that to me is not a compelling reason for LOT=false, whereas the non-technical perceptions arguments i do find compelling (even though i wish they weren't) 08:49 < nothingmuch> so e.g. F5-6 08:50 <@michaelfolkson> I totally agree. We'll focus on the technical arguments to begin with in the meeting next week but towards the end we'll have to assess the non-technical perceptions and general consensus 08:54 < nothingmuch> btw thanks so much for all the cat herding, it makes it so much easier to read the logs after the fact 08:54 <@michaelfolkson> Haha, no problem 09:01 < luke-jr> LOT=false is just as unilateral as LOT=true 09:01 < luke-jr> (of course, that's "not really at all, but could be perceived as such") 09:02 < luke-jr> (and the "could be" is still weak, since FUD will say that even w/o any softfork) 09:05 < nothingmuch> agree 100% about the symmetry on technical grounds. i think i misspoke when i said "could be", the Keynesian beauty contest framing is more accurate, perceptions have a positive feedback loop 09:05 <@michaelfolkson> F6 09:05 <@michaelfolkson> "Plenty of people just don’t like 09:05 <@michaelfolkson> LOT=true very much absent evidence that miners are blocking deployment. To 09:05 <@michaelfolkson> some it just feels needlessly antagonistic and distrusting towards part of 09:05 <@michaelfolkson> our community." 09:06 < nothingmuch> well, it could go the other way too, e.g. that LOT=false is needlessly paying lip service to miners 09:06 <@michaelfolkson> I think that is the hard thing to dislodge 09:06 < nothingmuch> no sense in theorizing 09:06 < nothingmuch> i have to run, sorry, will catch up with backlog later tonight 09:06 <@michaelfolkson> Thanks for popping by 09:19 < luke-jr> michaelfolkson: Plenty of people just don't like LOT=false ;) 09:19 < luke-jr> michaelfolkson: LOT=true is not antagonistic, and "don't trust, verify" is a thing for a reason 09:20 < luke-jr> that argument is like saying we should re-add the inflation bug and just trust miners not to exploit it 09:40 -!- mhinimi[m] [mhinimimat@gateway/shell/matrix.org/x-qjtqpjrdqyjzcjqu] has left ##taproot-activation ["User left"] 09:47 < robert_spigler> michaelfolkson > Saying something didn't work during wartime so it shouldn't be used in peacetime seems to me flimsy 09:47 < robert_spigler> I think this is a lot of people's opinion of LOT=true, but the whole security position of bitcoin is we don't assume good behavior 09:48 < robert_spigler> like luke-jr said, that argument is like saying we should re-add the inflation bug and just trust miners not to exploit it 09:54 < emzy> robert_spigler: this comparison makes no sense to me. 09:56 < emzy> fwiw I'm still for LOT=false. 09:57 < luke-jr> emzy: LOT=false is a comparable bug 09:57 <@michaelfolkson> Can I try to persuade you emzy? I think luke-jr exaggerates his argument and it is offputting 09:58 < emzy> If we end up without an activation on LOT=false all nodes and miner still are on the same page. Where is the bug? 09:59 <@michaelfolkson> LOT=false opens the door to shenanigans, politics and another chaotic UASF later. During a year which is looking like a rerun of 2017 09:59 <@michaelfolkson> LOT = true locks it in. And we don't have to worry about any of that 09:59 < luke-jr> emzy: we also didn't end up with any inflation.. 10:00 < emzy> michaelfolkson: That is true. But could be or not. I think LOT=false is for the 1. try safer. 10:01 <@michaelfolkson> Safer because of F4? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html 10:01 < emzy> luke-jr: We ask for readiness and if they are not ready where is the trusting the miners in it? 10:02 <@michaelfolkson> We are giving them a year to get ready emzy 10:02 < luke-jr> emzy: LOT=false is less safe, not more 10:02 <@michaelfolkson> Why would a year not be enough? 10:02 < luke-jr> emzy: Miner activation is there to accelerate activation, not to slow it down 10:03 < luke-jr> Miners don't have a choice in the matter of the change, they just can help make it sooner 10:03 <@michaelfolkson> (I don't want to feel like this is us ganging up on you emzy. This is a useful exercise.) 10:03 <@michaelfolkson> (If we can't convince you we'll probably struggle next week) 10:03 < emzy> luke-jr: there will be an activation without miners ready. I think that is not a good way of activation. 10:03 <@michaelfolkson> Because miners will need more than a year? 10:03 < luke-jr> emzy: miners will be ready, or they won't be miners 10:04 < emzy> michaelfolkson: Yes F3 might be true. But I think we overthinking this here. 10:04 < emzy> luke-jr: I believe they will. So no need for LOT=true. 10:05 < luke-jr> emzy: you believe they won't inflate, so let's re-introduce the inflation bug? 10:05 < luke-jr> what is the need for LOT=false? LOT=true is status quo and default 10:05 <@michaelfolkson> What probability would you allocate to miners not activating emzy? If you had to guess 10:05 < luke-jr> why re-introduce a bug we already fixed? 10:05 < emzy> I'm not totaly against =true but I think =false is just more safe. 10:07 <@michaelfolkson> A year to get ready for something you have pledged support for seems more than enough to me 10:07 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation 10:07 <@michaelfolkson> A year is not rushing imo 10:07 < emzy> michaelfolkson: hard to tell. below 10% for sure. 10:08 <@michaelfolkson> emzy: I would agree. But with some imagination you could see that below 10 percent probability descending into chaos that could be avoided with LOT=true 10:09 < emzy> luke-jr: I think we need the option for =true afterwards but not on the first try. Try the safe version first. 10:09 < luke-jr> emzy: LOT=true IS the safe verison 10:09 < luke-jr> and LOT=false makes no sense if you're just going to do =true later 10:09 < emzy> luke-jr: the option might be enought pressure on the miners. 10:10 < luke-jr> the only reason to have =false is if you intend to allow miners to abort it 10:10 <@michaelfolkson> Please be clear on why you think LOT=false is the safe version emzy 10:10 <@michaelfolkson> F4 right? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html 10:11 < emzy> michaelfolkson: because there is more then 5% of the miners using the new consensus, if not we abort. 10:11 < maybehuman> just out of curiosity: Is it possible to find a middle ground by playing with the threshhold value? i.e. would lot=false with a low enough threshhold be closer to lot=true? Or does that increase technical risks too much? 10:11 < emzy> michaelfolkson: yes, also F4 10:12 < luke-jr> maybehuman: defeats the point of the MASF 10:12 <@michaelfolkson> emzy: We have done everything to ensure mining pools agree with Taproot as a soft fork change https://taprootactivation.com/ 10:13 < emzy> michaelfolkson: yes, but we don't know if they realy do what they say. 10:13 < maybehuman> luke-jr: I'm asking because I have the vague memory of reading that segwit needed a particularly high threshhold because of p2p changes (I think). So I was wondering if it could be lower this time around 10:13 <@michaelfolkson> emzy: Why would they say something and do the opposite unless they are acting maliciously? 10:14 < maybehuman> because the lower the threshhold the smaller the differences between lot true/false 10:14 < emzy> My concern is, that we are below 5% of miner support and activating because of LOT=true. I think this will be not so good for the network. 10:14 < luke-jr> maybehuman: perhaps it can be, but that's unrelated to LOT 10:15 < emzy> michaelfolkson: they are humans.. that's how it is sometimes. 10:15 < luke-jr> emzy: so you might suggest LOT should require a lowered threshold to trigger? 10:15 < emzy> michaelfolkson: you can't fully trust what someone says. 10:15 < maybehuman> btw, it just occured to me that with lot=true, can you even call it an MASF anymore? It's not like they have a choice 10:16 <@michaelfolkson> emzy: Right but I don't get the motivation for saying something and doing the opposite unless it is maliciousness or incompetence 10:16 < emzy> luke-jr: I think 5% is about right. 10:16 < luke-jr> maybehuman: yes; they were never supposed to have a choice :p 10:16 < robert_spigler> even if miners signal, nodes ultimately have to upgrade to safely enforce the fork 10:17 < emzy> michaelfolkson: just soething that must be considered. I also think they say what they will do. 10:17 < luke-jr> emzy: but why should even 95% of miners *yesterday* get to veto Bitcoin *today*? 10:17 < maybehuman> luke-jr choice, coordination, whatever. Point is with false, they activate it or they don't 10:17 <@michaelfolkson> I think we are ganging up on poor emzy ;) 10:17 < robert_spigler> consensus has already been achieved (or should be). Activation discussion is separate and distinct 10:18 < emzy> All good. 10:18 < maybehuman> with true, they get kicked off the network instead 10:18 <@michaelfolkson> I agree with the desire for safety. I just think this instinctive feeling that LOT=false is safer isn't right 10:18 < luke-jr> maybehuman: "miners" who make invalid blocks are ALWAYS "kicked off the network" no matter how it activates 10:18 < robert_spigler> LOT=true has less of a chance of a chain split (T6) 10:18 <@michaelfolkson> They both appear to me to be as safe or as risky as eachother 10:19 <@michaelfolkson> There is some (limited) risk with a soft fork change regardless. I think in this case it has been minimized as much as possible 10:20 < maybehuman> luke-jr by miners I don't mean machines hashing things, but the people whose livelihood depends on those machines 10:20 < robert_spigler> I think the reason why ppl see LOT=false as 'safe' is b/c they erroneously see it as 'no change' 10:20 <@michaelfolkson> And now we choose between leaving the door ajar to unlikely but possible shenanigans or we close that door 10:20 < luke-jr> maybehuman: same answer 10:20 < robert_spigler> But they will be a group of ppl running LOT=true no matter what Core sets, so default LOT=true IS the safer option 10:21 < maybehuman> luke-jr ok, but can you see why this might look scary to them? 10:22 < luke-jr> maybehuman: all they need to do is update within a year.. 10:22 < robert_spigler> maybehuman: which they've already promised to do 10:23 < luke-jr> in fact, this is why miners would want to run LOT=true themselves.. 10:23 < luke-jr> to ensure they stay on the valid chain 10:23 < maybehuman> someone should tell them that :-) 10:24 <@michaelfolkson> I do think both miners and Core won't want to be the ones who puts the pin in LOT=true. Which makes people who are willing to openly argue for LOT=false like emzy valuable 10:24 < emzy> I understand all the points for LOT=true. Makes sense. But still I think we should do LOT=false first. 10:25 < robert_spigler> emzy: why? 10:25 < maybehuman> robert_spigler: one could argue that they deserve the benefit of the doubt then? 10:25 < emzy> michaelfolkson: if miners do LOT=true they will also activate before the LOT time. So no problem for me (LOT=false) 10:25 <@michaelfolkson> You have to be prepared for (unlikely but possible) 2017 style shenanigans and politics etc in that case during a bull market 10:26 < luke-jr> maybehuman: do they deserve the benefit of the doubt on inflation too? 10:26 <@michaelfolkson> That is the cost of choosing LOT=false emzy 10:26 < maybehuman> luke-jr: ofc not 10:26 < emzy> robert_spigler: I don't like to activate without miner support first. Like 95%. I know LOT=true will pressure to activate first, but I think it is not the safe way. 10:26 < robert_spigler> maybehuman: Ok, so why just here? Let's remove other rules 10:26 < luke-jr> maybehuman: so why this? 10:26 < maybehuman> robert_spigler: what rules are being removed by lot=false? 10:26 < robert_spigler> emzy: So what happens if we never have miner support? 10:27 < emzy> robert_spigler: We will have no taproot or we will need a LOT=true afterwars. 10:27 < emzy> *afterwards ;) 10:28 < robert_spigler> emzy: Saying you want a MASF, and if not, a LOT=true afterwards, is the same thing as setting LOT=true first with a long time frame 10:28 < robert_spigler> B/c it allows a MASF if miners coordinate, but if they are malicious, it sets a UASF at the end... 10:28 < maybehuman> luke-jr: It's really mostly a question of perception imo: If you tell somebody, if you don't do what I (we, whatever) want, you'll be out of a job this time next year, it's just not a good look (and might even breed resentment) 10:28 < emzy> robert_spigler: no 10:28 < robert_spigler> emzy: yes 10:29 < robert_spigler> You're just giving miners power they don't have and then taking it away 10:29 < robert_spigler> And making it needlessly complicated 10:29 < emzy> robert_spigler: they only can delay. And they have no reason to delay. 10:30 < emzy> robert_spigler: I think the case will not happen. 10:30 < robert_spigler> emzy: exactly, the power to veto, when they really should only have the power to coordinate 10:30 < robert_spigler> LOT=true allows for both. A MASF when 85-95% signalling happens. If not, a UASF will occur at the end 10:31 < emzy> I just want to be sure that 95% are ready. I don't like to activate with less. 10:31 < maybehuman> luke-jr: also, I find the comparison to consensus bugs invalid. Nobody is going to steal or devalue my coins if taproot doesnt activate on the first try 10:31 <@michaelfolkson> But you will activate with less after a year emzy 10:31 < luke-jr> emzy: so you don't want Taproot to activate if miners decide to sabotage it? 10:32 < emzy> michaelfolkson: not with LOT=false 10:32 < robert_spigler> emzy: You just said you would run LOT=true if miners didn't coordinate 10:32 <@michaelfolkson> emzy: In the scenario where LOT=false is set and Taproot doesn't activate what would you do after a year? 10:32 < emzy> luke-jr: not on the first try. 10:32 < robert_spigler> There is no reason to run LOT=false and then run LOT=true; you might as well run LOT=true from the beginning 10:33 <@michaelfolkson> You'd set LOT=true on a second try after the LOT=false has failed 10:33 < emzy> emzy: on the second try maybe. 10:33 < emzy> robert_spigler: ^^ 10:33 < luke-jr> emzy: why have multiple "tries"? 10:33 < luke-jr> what's the point? 10:34 < emzy> luke-jr: I think we can assume that it will be activated, so we will need no second try. 10:34 < robert_spigler> Do people understand that LOT=true includes a MASF if miners aren't malicious? 10:34 < luke-jr> emzy: then no need to LOT=false at all 10:34 < emzy> luke-jr: just in case. 10:35 < luke-jr> … 10:35 < luke-jr> in case what? 10:35 <@michaelfolkson> I think just psychologically it feels safer to give a voluntary first try to miners. Which is unfortunate. Because I don't think it actually is any safer in reality 10:35 < robert_spigler> The only logical argument I see for LOT=false is if you /never/ want to run LOT=true only ever want MASF's 10:35 < luke-jr> there is literally *nothing* to gain from LOT=false 10:35 < emzy> luke-jr: It will not activate on 1. try. 10:35 < luke-jr> emzy: that's a reason for LOT=true 10:36 < luke-jr> michaelfolkson: LOT=true still gives them the first try 10:36 <@michaelfolkson> Voluntary from start to end 10:36 <@michaelfolkson> It is just an infuriating psychological thing I think 10:37 < emzy> Yes, the problem is that we talk more about psychologically and I am for the technical safe choice. And do the psychologically outside of the protocol. 10:37 <@michaelfolkson> If you are going to do LOT=true the second try it makes no sense to me to not do it at the end of the first try 10:38 <@michaelfolkson> If you never want LOT=true ever that is an argument I can understand 10:38 < emzy> We can screem at them if they not activate. ;) 10:38 <@michaelfolkson> What's the benefit though? 10:39 <@michaelfolkson> Entertainment? We could have just set LOT=true 10:39 < emzy> michaelfolkson: maybe saying you do LOT=true later is enough. 10:39 < robert_spigler> michaelfolkson: exactly 10:39 <@michaelfolkson> We can't guarantee that emzy 10:40 < emzy> Good talk, anyways. 10:40 < luke-jr> michaelfolkson: "voluntary" for miners means intentionally letting them veto it forever 10:40 <@michaelfolkson> Maybe after LOT=false has failed the first time, people want to do another try with LOT=false 10:40 <@michaelfolkson> So they can do some more screaming 10:40 < emzy> michaelfolkson: true. 10:40 < emzy> lol 10:41 < maybehuman> btw, not sure if anyone remembers this https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018046.html 10:41 <@michaelfolkson> Ok well I disagree with you emzy but I'm grateful for you putting yourself in the line of fire ;) 10:41 < maybehuman> it's the same points exchanges here, but maybe in a more readable form 10:42 <@michaelfolkson> Cool, thanks maybehuman 10:42 < emzy> michaelfolkson: Hope we find a good way to activate. I think we will. 10:47 < luke-jr> I wonder if any of those "no worries miners won't block Segwit" posts from 2016 are linkable <.< 10:51 < maybehuman> did the possibility of segwit not activating even occur to people back then? 10:51 < maybehuman> I had the impression that everyone seemed pretty surprised 10:52 <@michaelfolkson> Personally I don't think it is important. I think this time everyone knows it is possible with lot=false. We would just quibble on relatively low probabilities 10:52 <@michaelfolkson> emzy said below 10 percent which I would agree with 10:53 <@michaelfolkson> Of course that can raise the longer it goes without miner activation 10:54 <@michaelfolkson> A lot of this Matt post https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018046.html is on perception 10:54 <@michaelfolkson> If we make decisions based on perception rather than the facts it isn't optimal 10:56 < luke-jr> maybehuman: iirc some bigblockers were trolling it around once in a while 10:56 < maybehuman> not optimal in the technical sense, but there's people involved, too 10:56 < luke-jr> nobody on the good side thought it was a risk 10:57 < maybehuman> what I do remember from 2017 though is reading comments by sipa & gmaxwell saying it's no big deal if the first activation fails 10:57 <@michaelfolkson> There was the block size war happening at the same time 10:57 < maybehuman> although that ofc could also have been meant as deescalation 10:58 <@michaelfolkson> Wartime versus peacetime 10:59 <@michaelfolkson> Post block size war stress disorder 11:00 < maybehuman> It's interesting that blocks are starting to get full again just about now 11:00 < maybehuman> so better not quibble too long :-) 11:02 <@michaelfolkson> There will be definitely be more block size/weight wars imo. Just a matter of when 11:03 <@michaelfolkson> It makes no sense to try to get it wrapped up with Taproot for no reason though 11:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 11:10 < maybehuman> btw, regarding perception in the BlueMatt mail: This is just speculation on my part, but I always think that core devs picture themselves being on trial for facilitating child trafficking (or whatever) by creating this "anonymous money". And to establish the plaintiff's control over the software the prosecution would show that he in fact was 11:10 < maybehuman> responsible for activating feature xyz. 11:12 < maybehuman> (which plays a bit into what I posted the other day about lot=false giving the maintainers an out) 11:13 <@michaelfolkson> Satoshi created it. The act of creation isn't theirs. They worked on improving it. But I think we are going off topic 11:14 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined ##taproot-activation 11:14 <@michaelfolkson> Their "out" if LOT=true is chosen is that we had this painstaking discussion over many weeks and months involving anyone who would listen 11:17 < maybehuman> yes. In the end they will have to decide if they go along with true or not 11:17 < maybehuman> just trying to look at all the angles 11:17 <@michaelfolkson> If that is what we propose to them. I literally have no idea which way it will go 11:17 <@michaelfolkson> If it was up to purely me I'd go LOT=true 11:18 < maybehuman> if they say no, can we just fall back to false then? 11:18 < maybehuman> I don't think anyone would want still more months of discussion, right? 11:19 <@michaelfolkson> Personally I want to do the meeting next week, a code review and then propose something on the mailing list. That's where my involvement ends 11:20 < luke-jr> maybehuman: devs overruling the community would ACTUALLY be them taking control 11:20 < luke-jr> LOT=false is no different from LOT=true, in regard to this topic 11:21 < maybehuman> luke-jr: So they'll just have to do as they're told? Also, see my posts from a couple of days ago (the ones you called "not sane") 11:22 <@michaelfolkson> Personally I think Core can refuse to implement what we propose on the mailing list. And if I knew Core was opposed I personally wouldn't propose it 11:23 <@michaelfolkson> Core being a loosely defined group of voluntary contributors of course 11:37 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 12:46 < robert_spigler> I'll run LOT=true regardless, but the default in Core will ultimately be up to what the 'loosely defined group of voluntary contributors' decide :) 12:59 < nothingmuch> re the inflation argument, why is that a false equivalence? Taproot has no p2p or resource related changes, proportionaly more of the same total block weight will be cheaper to validate, the UTXO set is still auditable, so much like fixing an inflation bug i think one can argue from first principles that it is strictly an improvement as a change 13:00 < nothingmuch> well, not exactly first principles, but non controversial assumptions about what bitcoin is "supposed" to be 13:05 -!- jonatack_ [~jon@37.173.248.254] has joined ##taproot-activation 13:06 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit] 13:06 -!- jonatack_ [~jon@37.173.248.254] has joined ##taproot-activation 13:06 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit] 13:08 -!- jonatack_ [~jon@37.173.248.254] has joined ##taproot-activation 13:08 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit] 13:09 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 256 seconds] 13:10 -!- jonatack [~jon@37.173.248.254] has joined ##taproot-activation 13:14 < nothingmuch> to clarify the issue with perceptions / Keynesian beauty contest: suppose enough miners only support LOT=false in order to have veto power. large entities such as exchanges might disregard that argument that activating taproot should result in no harm to anyone simply because it seems like the politically pragmatic choice (to save face with miners' who seek veto power) 13:15 < nothingmuch> this is analogous to how oppressive regimes can stay in power even if a majority of their subjects would fare better if they were deposed or overthrown 13:28 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 264 seconds] 13:30 < nothingmuch> to be clear that could be argument for LOT=true (that explicitly states that nobody should have veto power over such strictly-no-harm soft forks, takes T5 or equialently that F5 is invalid as an assumption), or LOT=false (handicap principle => F3, and precautionary principle => F5, F6), but in either case there's a reinforcing effect where what large economic entities believe, regarldess 13:30 < nothingmuch> of whether it's logically consistent and rational, can change what an entity perceives as a Schelling point (see also Thomas theorem, informally that even unfounded beliefs can have real consequences) 13:37 < nothingmuch> the reason i personally think erring on the side of LOT=false is more conservative (albeit weakly so) is that LOT=true assumes everyone believes that Taproot activation does not harm any users. i strongly believe this but i can't prove it (unknown unknowns), and failure to activate clearly only imposes an opportunity cost, not a direct one. because defaults can make have a very big effect 13:37 < nothingmuch> on outcomes, defaulting to LOT=true can back fire even if there are really no harms, but only the belief that harm might be a possibility 13:40 -!- jonatack [~jon@37.173.248.254] has joined ##taproot-activation 14:19 -!- gwollon [~gwillen@unaffiliated/gwillen] has joined ##taproot-activation 14:19 -!- gwollon is now known as gwillen 14:49 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 272 seconds] 14:54 -!- jonatack [~jon@37.173.248.254] has joined ##taproot-activation 15:28 < luke-jr> what the 'loosely defined group of voluntary contributors' decide <-- in practice, most likely what a niche of developers force on everyone else; hopefully I'm proven wrong 15:44 < luke-jr> /pessimism 15:45 < robert_spigler> luke-jr: I hope not ☹️ 15:46 < robert_spigler> nothingmuch: LOT=false is not more conservative, because there is a greater risk of chainsplit 15:49 < luke-jr> robert_spigler: wut 15:50 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 264 seconds] 15:58 -!- jonatack [~jon@37.173.248.254] has joined ##taproot-activation 16:19 < robert_spigler> luke-jr: "in practice, most likely what a niche of developers force on everyone else"<-I hope not 16:23 -!- mol_ [~mol@unaffiliated/molly] has quit [Quit: Leaving] 17:06 < nothingmuch> robert_spigler: if the economic majority and hash rate majority is on LOT=false and MASF fails, then especially for users like exchanges the less risky choice is to just see which side is winning and follow that. LOT=true is the conservative choice if wipeout risk for LOT=false chain is significant 17:07 < nothingmuch> defaults matter, so if core ships with LOT=true that's likely to have a big effect on that risk, so it does reduce the risk of chainsplit 17:10 < nothingmuch> however a similar argument can be made in the other direction, defaulting to LOT=false, by changing nothing makes activation opt-in for users, and indecision can lead to the economic majority running LOT=false, and then the more conservative choice would be to not activate 17:14 < nothingmuch> i think it boils down to whether or not it's reasonable to expect significant fraction of users to opt out by setting LOT=false (seems unlikely to me if default is to ship LOT=true), or simply not upgrading at all (this is my main concern about T6) 17:14 < nothingmuch> s/default is to ship LOT=true/if core ships default LOT=true/ 17:19 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Ping timeout: 246 seconds] 17:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:26 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined ##taproot-activation 17:49 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds] 17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 18:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 19:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 20:23 < robert_spigler> nothingmuch: No matter what Core ships with, there is a portion of the community that will be sure to run with LOT=true. That means that there will be a chainsplit risk with LOT=false and malicious/incompetent miners 20:33 < aj> the only way there's a chainsplit between lot=true and lot=false is if a majority of hashrate mines a chain where taproot never activates. that's not a few malicious/incompetent miners. (a few malicious/incompetent miners could have caused a chain split prior to https://github.com/bitcoin/bips/pull/1021/ though) 20:55 < robert_spigler> aj: I will have to look at that more carefully, thank you 21:01 < robert_spigler> Yes, over 50% of the miners would have to mine the non-taproot chain to cause a split, as LOT=false nodes will just follow the greatest difficulty chain 21:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 22:09 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 23:33 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 23:34 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 23:35 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 23:36 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 23:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation --- Log closed Thu Feb 11 00:00:26 2021