--- Log opened Sun Feb 14 00:00:29 2021
00:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
00:47 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]
01:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
03:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
04:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:48 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:58 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
05:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
05:22 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
05:38 -!- jonatack [~jon@37.164.249.206] has quit [Ping timeout: 240 seconds]
05:42 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
05:50 -!- jonatack [~jon@37.164.249.206] has quit [Ping timeout: 256 seconds]
05:56 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
06:03 -!- jonatack [~jon@37.164.249.206] has quit [Ping timeout: 246 seconds]
06:18 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
07:16 -!- jonatack [~jon@37.164.249.206] has quit [Ping timeout: 272 seconds]
07:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
07:22 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
07:29 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Quit: WeeChat 2.7.1]
07:38 <@michaelfolkson> My thoughts on harding's mailing list post from yesterday https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
07:39 <@michaelfolkson> I still remain convinced that looking exclusively at a single soft fork (Taproot) LOT being true seems optimal. Leaving the door open for shenanigans unnecessarily (with no long term upside) seems lazy
07:42 <@michaelfolkson> However, harding's argument is that there *is* long term upside, namely providing precedent for a higher bar on LOT being set to true and hence providing an additional safeguard against both a rushed through future soft fork and developer moral hazard
07:45 <@michaelfolkson> It is definitely a valid argument. The challenge to it is whether this long term upside is worth the cost of leaving the door open for shenanigans (both miner and UASFs assuming LOT is set to false) on the Taproot soft fork.
07:46 <@michaelfolkson> It is a very hard (arguably impossible) question to answer. We don't know
07:55 <@michaelfolkson> But if harding and Greg are both leaning towards LOT being set to false, those are two people I would feel very uncomfortable trying to overrule :)
07:55 -!- jonatack [~jon@37.164.249.206] has quit [Read error: Connection reset by peer]
07:55 -!- jonatack [~jon@37.164.249.206] has joined ##taproot-activation
07:56 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
08:17 <@michaelfolkson> F6 = It is more important that no rules that harm users are deployed than it is that new useful rules are deployed quickly.
08:22 <@michaelfolkson> There is no concern with Taproot imo for F6. But there could be a concern for future soft forks
08:30 <@michaelfolkson> If LOT was set to false I wonder if there should be advice/guidance to users who are thinking of changing it to true either individually or in a coordinated fashion with other users
08:31 <@michaelfolkson> Obviously they are free to not follow this advice/guidance. But communication for those who don't really understand what they are doing and don't want to risk getting forked off the chain
08:35 <@michaelfolkson> Something like "We expect there to be a coordinated effort to release a software version with LOT = true if miners have failed to activate within 6 months (say). We recommend that you don't attempt to try to force activation earlier than this unless you understand the risks"
08:36 <@michaelfolkson> But that is trying to claim we represent uninformed users which is also problematic
08:46 < luke-jr> I think harding's is fundamentally still about perception. Whereas the LOT=false issues have a practical effect in theory and practice.
08:48 <@michaelfolkson> Precedent for future soft forks isn't merely perception. I really wanted to avoid the "precedent" conversation because I think then people's views then get even more entrenched :)
08:49 <@michaelfolkson> But it is getting hard to avoid it now
08:51 < luke-jr> well, LOT=true is already precedent, so at least it isn't a chance :P
08:51 < luke-jr> change*
08:52 <@michaelfolkson> SegWit's precedent was LOT=false initially as the first attempt
08:53 < luke-jr> and failed
08:53 <@michaelfolkson> F5
08:54 <@michaelfolkson> But that's the harding argument. You can do LOT=true (maybe) but only once you've tried and failed with LOT=false
08:54 <@michaelfolkson> That's the additional safeguard. A precedent that you must try LOT=false first before you contemplate LOT=true
08:55 < luke-jr> "you" being who?
08:55 <@michaelfolkson> Developers of Core (and other implementations)
08:56 < luke-jr> devs should not be deciding any of this
08:56 <@michaelfolkson> Obviously users can set whatever they like (but they bear the cost if they do something stupid and get forked off)
08:57 < luke-jr> but if the users decide on LOT=true, it's Core that is forking off
08:57 <@michaelfolkson> Someone (with the consent of the other maintainers) has to click merge on a PR in the Core repo (or other implementation)
08:57 <@michaelfolkson> That is a decision
08:58 <@michaelfolkson> The question becomes what needs to be presented to them so they can make that decision
08:58 <@michaelfolkson> harding's argument is that precedent of SegWit (and maybe Taproot) is that you should try LOT=false first before you contemplate LOT=true
08:59 <@michaelfolkson> You being the Core maintainers and contributors
09:02 <@michaelfolkson> The most say you and me can do (in the case that LOT is set to false in Core and other implementations) is to provide guidance to users who don't know what they are doing but might consider participating in a UASF
09:03 <@michaelfolkson> So they understand the risks
09:06 <@michaelfolkson> The problem with your exclusive orientation around users is that they are hard to identify, hard to contact, may be apathetic, may not know what they are doing. So it is very hard to know what they want in advance and they can (potentially) be encouraged to do things that aren't in their best interest (like risk being forked off the chain)
09:07 <@michaelfolkson> I agree that in a ideal world that orientation wouldn't be full of holes
09:15 <@michaelfolkson> That was another good point from the Matt Corallo podcast. A lot of users presumably aren't on IRC, Twitter etc etc and don't care about Taproot let alone the activation mechanism used for Taproot
09:24 <@michaelfolkson> So as a safeguard against a future malicious actor and a future rushed soft fork we establish a precedent that you need to try to get miners to activate with LOT set to false before Core (and other implementations) developers consider setting LOT to true
09:39 -!- jonatack [~jon@37.164.249.206] has quit [Read error: Connection reset by peer]
10:40 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
11:04 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
11:19 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
11:58 < nothingmuch> FWIW this is why i kept harping about perceptions, Thomas theorem, Keynesian beauty contests, and Schelling points. I suspect many users are undecided or apathetic, possibly more easily swayed by bad faith arguments since they don't necessarily have strong technical opinions, etc...
11:58 < nothingmuch> there is a performative aspect to LOT=false being the default, it's like steel manning an opponent's argument
11:59 < nothingmuch> i'm not convinced this is enough to justify that, since these are political arguments and have to do with less likely hypotheticals
12:01 < nothingmuch> but defaulting to LOT=false is kind of giving the pro LOT=true side a handicap, which is both a risk (chainsplit, lost time, etc - most of these are objective) but also a risk mitigation (feeding into perceptions that core development is politicized etc even if not actually true)
12:05 < nothingmuch> assuming such a handicap, if MASF works out, that feeds into perceptions that Segwit controversy was a one off, likely just due to covert asicboost, and could provide some closure. if MASF doesn't work but it's clearer that it's desired, that would strongly reinforce the legitimacy of LOT=true. if MASF doesn't work and there doesn't seem to be a clear consensus as a result of that,
12:05 < nothingmuch> perhaps that's a missed opportunity, but it avoids the moral hazard of legitimizing the narrative that LOT=true would have been "forced" in some way (eve nthough IMO the fact that soft fork upgrades are shipped minor releases with no other features and the code is FLOSS completely alleviates that moral hazard in principle)
12:08 < nothingmuch> that last parenthetical is why i personally prefer LOT=true, but it seems to me that the true meaning of running free software is unfortunately just not that obvious except to FLOSS devs
12:09 <@michaelfolkson> I don't care about the perception side. I understand why some people care about it but I'd rather go with a superior option with a bad perception than a weaker option with a good perception
12:10 <@michaelfolkson> The argument harding outlines is not (merely) on perception. It is setting precedent for what hoops future soft forks will likely to have to go through
12:10 < nothingmuch> maybe it's a language barrier, but that's exactly what i mean by perceptions
12:11 < nothingmuch> (sorry, ESL)
12:11 < nothingmuch> but basically, perceptions alter reality, and can make technically sound things politically imposible, or can cause a lot of time to be wasted
12:12 <@michaelfolkson> I understand perception as good optics. Doing something because it feels friendlier or less antagonistic or more appreciative of people etc
12:13 <@michaelfolkson> If you go down that route you let weaknesses into your software because you don't want to upset people
12:13 < nothingmuch> yes, and sacrificing technical merit or time for that is a harm, but maybe not a net harm from the point of view of promoting superior technical things
12:14 < nothingmuch> that argument goes both ways, if people perceive core devs as forcing changes or something in an unsubstantiated way, that can harm development too
12:14 < nothingmuch> i'm not saying it's clearly better, i'm on the fence, what i'm saying is that i'd be interested in hearing others' perspectives on how the relative risks hold up
12:15 < nothingmuch> and personally i'm rooting for LOT=true becoming less controversial as a result of such a discussion
12:15 <@michaelfolkson> Ok on the perception of the power or influence of developers, that was part of harding's argument, you're right
12:16 <@michaelfolkson> I don't like making decisions based on perceptions personally. There's a valid argument on precedents though that I wouldn't include under perceptions
12:16 < nothingmuch> agreed, i think i was just using "perceptions" as a bit of an umbrella term, i don't know of a more accurate word
12:17 < nothingmuch> Keynsian beauty contests or guess 2/3rds of the average is a much more precise way of capturing that
12:17 < nothingmuch> specifically it's the feedback mechanisms that perceptions feed into that can destabilize Schelling points
12:18 <@michaelfolkson> That's the "Is there consensus on whether there is consensus" question
12:18 < nothingmuch> in a more rational world LOT=true would be an obvious Schelling point for any soft fork which does not appear to cause harm due to its technical attributes
12:20 < nothingmuch> yes, and my strongest case for LOT=false is that it seems to have the potential to clear up some of those conundrums (e.g. F3)
12:20 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation
12:21 < nothingmuch> FML will i ever be able to spell Keynesian right on the 1st attempt =P
13:08 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ilnpppfafwrqpnib] has quit [Quit: Connection closed for inactivity]
13:41 <@michaelfolkson> nothingmuch: Ha got it right eventually
14:26 -!- belcher_ is now known as belcher
15:18 < aj> personally i think the argument that initially set lot=false enables shenanigans absurd: we've already demonstrated we can change lot=false to lot=true true successfully, even when the mechanism isn't designed for it; and bip8 is specifically designed to make that work smoothly.
15:25 < aj> michaelfolkson: "doing something because it feels friendlier or less antagonistic" -- a different way of looking at it is "i might be wrong in thinking X makes bitcoin better, and the fact other people disagree with me on X makes that more likely. therefore i should allow for options other than X, until we find out more information or there is a truly urgent unavoidable problem". being
15:25 < aj> antagonistic and unfriendly also makes it less likely for anyone to bother explaining to you the reasons you're wrong. imho, anyway.
15:31 <@michaelfolkson> There is no reason to communicate in an antagonistic and unfriendly manner. But that is not the same as choosing an option because it is perceived as less antagonistic and less friendly
15:35 < aj> it's a lot easier to be unfriendly and antagonistic than just choosing the wrong words; particularly on issues that are already highly charged. both greg and matt have quit this channel in exasperation, eg
15:37 <@michaelfolkson> I'm happy to look back at the logs to see where people have been unfriendly and antagonistic. I have personally tried very hard to stop that from happening
15:38 <@michaelfolkson> I get the highly charged point though, that's why I've been trying
15:40 <@michaelfolkson> On "we've already demonstrated we can change lot=false to lot=true true successfully" what is the plan then assuming lot is set to false? Community coordination after 6 months to release a lot=true or discussion resumes at the end of the year (assuming miners haven't activated)?
15:41 < luke-jr> "unfriendly and antagonistic" is just FUD IMO
15:41 < luke-jr> you don't need to give someone a backdoor in the code to be friendly
15:44 <@michaelfolkson> I can go through the logs too. Plenty of examples of me and others encouraging people with different views to put forward their arguments. I haven't seen any unfriendliness or antagonism towards Greg or Matt on this channel
15:48 < aj> "X is just FUD" is pretty antagonistic...
15:50 <@michaelfolkson> Claiming Greg and Matt left this channel in exasperation is also pretty antagonistic given people's efforts to foster debate on it
15:52 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
15:53 < aj> huh?
15:54 < aj> do you think they're still here, or that they weren't exasperated when they left?
15:55 < aj> failing doesn't mean you're not trying
16:20 < luke-jr> michaelfolkson: when is code review?
16:20 < luke-jr> I see something else was scheduled for this week :x
16:23 < aj> need to have questions prepared by friday to get into wednesday's pr club
16:27 <@michaelfolkson> I wasn't planning to use a Core PR review club slot. Follow the format of a Core PR review club but not take up a Wednesday slot
16:27 < aj> ?
16:28 < aj> if we're doing all the work, why wouldn't we do it at a pr review club time (as well)?
16:28 < aj> either way, prompts should be ready before the week we're aiming to collect reviews, i think?
16:28 <@michaelfolkson> We should aim to do that, yes
16:29 < aj> also argh, monday's are meant to be my day where everyone else is having a relaxing sunday and not talking :(
16:30 <@michaelfolkson> "What’s it for?  To help newer contributors learn about the Bitcoin Core review process. The review club is not primarily intended to help open PRs get merged (although that might be a nice side-effect)."
16:30 <@michaelfolkson> It is cleaner to do an independent session
16:31 <@michaelfolkson> Especially if there are strong views
16:34 < aj> sure; i just mean why wouldn't we have a pr review club session at the same time as well?
16:36 <@michaelfolkson> You mean the same time as the PR review club? Or same time as LOT = true, false meeting?
16:37 <@michaelfolkson> No point in deliberately clashing with the time slot of the PR review club
16:42 < aj> no, the same week
16:43 < aj> do the preparation for both at the same time
16:44 <@michaelfolkson> We can do the code review meeting next week if you want, sure
16:45 <@michaelfolkson> When?
16:45 < nothingmuch> michaelfolkson: it's not not mutually exclusive, but an argument for doing revuew club on it might to elicit response from people who are new or curious
16:46 < nothingmuch> specifically because that might be a useful proxy for broader audience receptiveness
16:50 <@michaelfolkson> Maybe, I don't think it matters either way
16:51 <@michaelfolkson> Time slot can be any time
16:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:31 <@michaelfolkson> Ok let's do 19:00 UTC on Tuesday 23rd for code review
17:32 <@michaelfolkson> If you can't make that time let me know
17:33 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-euyphuspntddllnf] has quit [Remote host closed the connection]
17:35  * luke-jr drops onto calendar, looks okay for me
17:36 <@michaelfolkson> Great, thanks
17:59 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
18:05 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vtakzzjunnrxyedh] has joined ##taproot-activation
18:23 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
18:24 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
18:49 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds]
20:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation
20:57 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-rrmlobyjwtavxihc] has quit [Read error: Connection reset by peer]
20:57 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-poobjgzopnrlujqs] has joined ##taproot-activation
23:26 -!- jonatack [~jon@37.167.240.187] has joined ##taproot-activation
--- Log closed Mon Feb 15 00:00:31 2021