--- Log opened Thu Feb 18 00:00:36 2021 00:06 -!- jonatack_ [~jon@37.167.103.144] has quit [Quit: jonatack_] 00:07 -!- jonatack [~jon@37.167.103.144] has joined ##taproot-activation 00:19 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer] 00:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 00:20 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 00:32 -!- realname19281 [~nizzle@37.160.143.103] has joined ##taproot-activation 01:01 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds] 01:04 -!- pox [~pox@141.226.243.49] has quit [Ping timeout: 264 seconds] 02:08 -!- realna [~nizzle@37.162.145.244] has joined ##taproot-activation 02:09 -!- realname19281 [~nizzle@37.160.143.103] has quit [Ping timeout: 272 seconds] 02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 02:30 -!- realna [~nizzle@37.162.145.244] has quit [Quit: Leaving] 02:49 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 03:51 <@michaelfolkson> maybehuman: This is useful from Andreas in the "Chain splits are not hard forks" section https://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2017-06-04-consensus-uasf-and-forks/ 03:52 <@michaelfolkson> There's (at least) two scenarios with a failed soft fork. If no miners activate it and no users set lot=true then the soft fork has failed to activate but caused zero disruption and certainly is nothing like a hard fork 03:54 <@michaelfolkson> If some miners activate it but other miners attempt to prevent it from activating, or some users set lot=true and others set lot=false and miners fail to activate then you have the possibility of a chain split. 03:54 -!- jonatack [~jon@37.167.103.144] has quit [Read error: Connection reset by peer] 03:55 <@michaelfolkson> A hard fork is generally defined as a deliberate attempt to remove consensus rules that can result in a chain split if there isn't overwhelming consensus on the hard fork 03:57 <@michaelfolkson> Hope that makes sense 05:23 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:7c3a:c9c7:c1a3:9e77] has joined ##taproot-activation 06:33 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 07:13 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 07:19 -!- jonatack [~jon@37.169.13.22] has joined ##taproot-activation 07:24 -!- duringo [4a779229@74.119.146.41] has joined ##taproot-activation 07:33 -!- jonatack [~jon@37.169.13.22] has quit [Quit: jonatack] 07:41 < luke-jr> michaelfolkson: the distinction there is "other miners attempt to prevent it from activating", not LOT 07:48 -!- duringo [4a779229@74.119.146.41] has quit [Ping timeout: 240 seconds] 08:02 -!- belcher_ is now known as belcher 08:50 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 09:16 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 09:18 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds] 09:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 09:50 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving] 10:19 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation 10:21 < maybehuman> I was wondering: btcd seems to have decided what they'll do, Knots will most probably do something different. So it seems to be an implementation-level decision now. Would it make sense then to raise this as a topic for a core meeting (when everybody has had the chance to read up on the mailing list)? 10:24 < darosior> See Bluematt point on the ML, it should not be an implementation-level decision. We keep rehashing it while we could just go with LOT=false and most probably have it activated.. 10:28 < maybehuman> dariosor: well, it _should_ not be that, but it looks like it de facto is already 10:30 < maybehuman> or you think that would be the most likely response? If we can't agree on this setting, we don't do it at all? 10:31 < maybehuman> *respose from core 10:35 < darosior> I don't know. But i agree with Matt here 10:41 < maybehuman> hm, so (someone like) btcd actually has (sort of) a veto power, similar to what lot=true is trying to take away from the miners? 10:52 < maybehuman> fwiw I agree more with michaelfolkson's view in that thread, but if we follow the Matt position, then the LOT parameter really needs to be abolished 10:52 < maybehuman> because as long as the option exists, someone will always set it to a different value than the others 10:52 <@michaelfolkson> maybehuman: We are doing code review of the Core PR next week (Tuesday). Once that is ready to be merged then perhaps that is right point to raise it as a topic for a core meeting 10:53 < maybehuman> michaelfolkson yeah, something like that 10:53 <@michaelfolkson> maybehuman: If there is no clear consensus on it then the option should continue to exist 10:54 < maybehuman> but at the same time, as long as there's no clear consensus, nothing at all should be done (according to Matt) 10:56 <@michaelfolkson> Ultimately you can't force everyone to do the same thing if they don't want to. You can't force everyone to delay either if they don't want to 10:59 < maybehuman> well put 11:00 <@michaelfolkson> If btcd sets lot=false and Knots sets true, we roll with that 11:03 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 11:03 <@michaelfolkson> Obviously it will be up to the btcd and Knots maintainers/contributors to communicate to their users the impact of that choice in the scenario where miners don't activate for a year 11:03 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation 11:05 <@michaelfolkson> If miners activate within the year it makes no difference that btcd and Knots differ in a parameter 11:06 <@michaelfolkson> (And I should be clear last time I heard from Luke he hadn't decided re Knots) 11:13 < luke-jr> darosior: we keep rehashing it while we could just go with LOT=true and most probably have it activated.. 11:15 -!- hebasto [sid449604@gateway/web/irccloud.com/x-diwgzwdyfnohchvk] has quit [Remote host closed the connection] 11:15 -!- fjahr [sid374480@gateway/web/irccloud.com/x-fnsvciziwascrtax] has quit [Remote host closed the connection] 11:16 <@michaelfolkson> luke-jr darosior: Right that argument works for both 11:36 -!- warren [~warren@fedora/wombat/warren] has joined ##taproot-activation 11:37 < jeremyrubin> My point was just that reading the meetings last couple weeks as being total is not proper; people have voiced thoughts over the last few years and didn't feel that participating in a big IRC all hands as being particularly more informative or important. Given the failure to reach consensus, perhaps I was wrong in choosing non-involvement 11:37 < provoostenator> Since some people are tallying "votes", I'll just briefly say that my default take is LOT=false. I might change my mind if someone a very clear prososal for LOT=true on the mailinglist. 11:38 <@michaelfolkson> I tried to bring people's views into the meeting where I knew them. I didn't know yours jeremyrubin 11:38 <@michaelfolkson> You were very involved early and then I didn't hear your view after the harding wiki was put up laying out the options 11:38 < provoostenator> Also: if said prososal contains 30 pages of game theory, it probalby won't convince me :-) 11:39 <@michaelfolkson> (But I could have just missed it jeremyrubin) 11:39 < luke-jr> provoostenator: so a one-liner saying "let's do LOT=true" ? :P 11:39 <@michaelfolkson> No effective NACK though I'm presuming on either provoostenator. Just a light preference? 11:40 < provoostenator> No, that's a NACK for LOT=true unless convinced otherwise. 11:40 <@michaelfolkson> A literal NACK? Ok, good to know 11:40 < provoostenator> It sounds reckless. 11:40 < jeremyrubin> I think the conversation on July 16th with me, luke, zmn, aj, etc is good 11:41 < provoostenator> Which is also how I felt about UASF. If people want to try that with their own patch of Bitcoin Core, be my guest of course. 11:41 < luke-jr> provoostenator: what is reckless? we're talking 1 year 11:42 <@michaelfolkson> You mean on this channel jeremyrubin. July 16th. I can go find that 11:42 < luke-jr> LOT=true is the safer option 11:42 < jeremyrubin> michaelfolkson: correct 11:42 < luke-jr> BIP148 was only reckless because it was ~4 months 11:42 < jeremyrubin> I almost think LOT=false is nack worthy; but I would need to do a lot more thinking before comitting to that 11:43 < luke-jr> and even then, and despite being heated, it STILL worked fine 11:43 < luke-jr> jeremyrubin: that's probably about where I am 11:43 < provoostenator> If miners and exchanges don't uprgade to enforce taproot rules, for whatever reason, then it makes no sense for casual downloaders of Bitcoin Core to assume Taproot is safe to use 11:43 <@michaelfolkson> Thanks jeremyrubin, that's useful 11:43 < jeremyrubin> nacking LOT=false might engender the outcome that I think LOT=false creates 11:43 < luke-jr> provoostenator: LOT has nothing to do with *usage* of Taproot 11:43 < jeremyrubin> so I am not going to cut my nose to spite my face on it 11:43 < luke-jr> provoostenator: nor relevant to the question of whether exchanges (or more importantly, businesses) use it 11:43 < jeremyrubin> but it has a bad long term implication for future work 11:43 < provoostenator> luke-jr: true, their entire node would be unsafe, because it would no longer see any blocks 11:44 < provoostenator> And then they have to go on Google and Twitter to find out what the heck is going on 11:44 < luke-jr> jeremyrubin: well, Core w/o any activation, means nobody will blindly follow LOT=false 11:44 < provoostenator> Where they will be treated to wonderful phising links. 11:44 < luke-jr> provoostenator: it would see the valid blocks 11:45 < provoostenator> luke-jr: which wouldn't exist if miners don't produce them 11:45 < luke-jr> provoostenator: indeed, since miners won't be making invalid blocks, likely *everyone* would be on the Taproot chain 11:45 < luke-jr> they will 11:45 -!- bluudix [~bluudz@103.108.94.45] has joined ##taproot-activation 11:45 < luke-jr> miners have no reason to make invalid blocks 11:45 < provoostenator> They can just keep making blocks on the current rules 11:45 < luke-jr> which will be worthless since nobody will accept them 11:46 < luke-jr> except light clients which are also okay with inflation etc 11:46 < provoostenator> By "nobody" you mean the people who run the latest Bitcoin Core release 11:46 < provoostenator> Because everyone with old Bitcoin Core releases will accept them 11:46 < luke-jr> provoostenator: that's why it's 1 year out - so everyone has time to upgrade 11:46 < provoostenator> So it's a forced upgrade? 11:46 < provoostenator> For users 11:46 < luke-jr> no, users already want it 11:47 < provoostenator> Some users *want* it, most users simply don't object to it. 11:47 < luke-jr> same thing 11:47 < jeremyrubin> I think what we're missing is a differentiation between "developers want taproot to activate" and "LOT=true best captures what is safe for ecosystem/users want" 11:47 < luke-jr> if users didn't want it, we shouldn't deploy ANY activation 11:48 < jeremyrubin> I think that devs are preferring LOT=false to demonstrate lack of control 11:48 -!- bluudz [~bluudz@103.108.94.40] has quit [Ping timeout: 265 seconds] 11:48 < jeremyrubin> but that, paradoxically by going against what is the safest option, means that there is a show of dev control 11:48 < provoostenator> Users should be able to keep using their own old node software wihout having to worry about multiple months of "invalid" blocks 11:48 < luke-jr> jeremyrubin: yet LOT=false is de facto imposing control when there is no community support for it 11:48 < jeremyrubin> yep that's my point 11:49 < luke-jr> provoostenator: which is most likely with LOT=true 11:49 < luke-jr> (and never zero risk for any softfork) 11:50 < provoostenator> Where "likely" depends on a bunch of game theory of how miners and exchanges will behave if core developers bluff. 11:50 < luke-jr> developers have nothing to do with it 11:50 < provoostenator> Developers are the ones setting LOT and proposing that as a release. 11:50 < luke-jr> no 11:51 < luke-jr> the community decides on LOT, and developers must do what the communtiy wants 11:51 < provoostenator> Not how it works. 11:51 < luke-jr> yes it is 11:51 < maybehuman> luke-jr: like sdaftuar said in the other channel: no one here is obligated to accept decisions from anyone else 11:51 < provoostenator> Developers are volunteers so they can choose not to implement something they think is unsafe. 11:51 < warren> The "community" was confused as heck mid-2015 and seemed to want Big Blocks. Developers must do what the community wants. 11:51 < luke-jr> maybehuman: but if you don't, you're just jgarzik with 2X 11:52 < provoostenator> They way things stand, I would not sign off on a release with LOT=true, I would tell people not to run it (until the smoke clears). 11:52 < provoostenator> Of course people are totally welcome to ignore me. 11:53 < luke-jr> provoostenator: by not running it, they are at greater risk 11:53 < provoostenator> We're not going to agree this, because it's same discussion as with UASF. 11:53 < luke-jr> ugh, this has all been explained many times in 2017 and after 11:53 < luke-jr> yes, UASF was proven successful and correct 11:53 < provoostenator> In your opinion 11:54 < warren> The best developers can and should do is demonstrate that a proposed softfork brings beneficial improvements and it has undergone extensive review to the point that developers believe it is safe and the correct thing to do. Developers can then recommend that it is ready. Then the "community" make an informed decision that they want it. 11:54 -!- hebasto [sid449604@gateway/web/irccloud.com/x-rvhmjnspapofjlfh] has joined ##taproot-activation 11:54 < luke-jr> warren: that's all already happened 11:54 < maybehuman> I found it helpful to always mentally add "IMO" to everything luke-jr writes her :-) 11:54 < maybehuman> *here 11:54 < provoostenator> When Russian Roulette doesn't kill you it wasn't "succesfull and correct" 11:55 * luke-jr goes to find something more productive to do 11:55 < warren> luke-jr: UASF was a failure because the miners decided to activate sooner thus they decided, not the community. 11:56 < provoostenator> "the community" is ill defined by the way 11:56 < warren> +1 11:56 < provoostenator> A bunch of people on Redit and Twitter 11:57 < warren> Not all voices should be weighed equally, especially when some people are literally against the goals of the project. 11:57 < warren> well, against what is prudent for the project 11:57 < provoostenator> I'm not a huge fan of relying on miners for activation signalling either to be clear. But it sounds like the safest thing to try first. 11:58 < luke-jr> BIP8 always tries that first 11:58 < provoostenator> Afaik you can always ship a LOT=true release after a LOT=false release. Not that I would want to probably. But the option exists. 11:58 -!- fjahr [sid374480@gateway/web/irccloud.com/x-hhqouwnzitxxomzo] has joined ##taproot-activation 11:58 < luke-jr> the only question is, if that fails, does it give up, or activate anyway since there's been plenty of time for everyone to upgrade who cares 11:59 < jeremyrubin> That is A) probably what will happen B) much less safe for everyone 11:59 < jeremyrubin> At least fixing the signalling period stuff makes this less bad 12:00 < luke-jr> if 1 year isn't long enough for the latter, then better to change that to 2y than give up 12:01 < provoostenator> The problem is that you don't know and don't control who runs which version of Bitcoin Core. 12:01 < maybehuman> I don't think giving up is the only choice there is if a lot=false activation fails 12:02 < maybehuman> in fact, I don't think anyone proposed that here even 12:02 < provoostenator> It's not, maybe people can come with a different signaling mechanism 12:02 < luke-jr> provoostenator: don't have to 12:02 < luke-jr> maybehuman: that's what LOT=false is 12:02 < maybehuman> luke-jr: lot=false doesn't mean you're forbidden from ever trying again with the same or different parameters 12:02 < provoostenator> LOT=false lets us try the same thing again, or something completely different 12:02 < luke-jr> maybehuman: it's still giving up 12:03 < maybehuman> I don't see how 12:03 < maybehuman> and giving up what exactly? 12:04 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 12:04 < luke-jr> so you're thinking of trying the same thing over and over and expecting different results…eh? 12:06 < maybehuman> doesn't have to be exactly the same 12:06 < provoostenator> This assumes there's no other mechanism people can come up with in a year. 12:06 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 12:06 < maybehuman> also, this is not a physics experiment. The "political climate" in the community will change over the course of that one year 12:06 < luke-jr> provoostenator: they're all fundamentally the same 12:07 < darosior> It's not giving up, just not using a hammer when it is not needed. If it is demonstrated to be needed then it can be used (somewhat safely, or at least way more than last time). The way things stand imo having the option is a big enough deterrent and that bluntly imposing LOT=true would likely create discord and thus not be enforced by big 12:07 < darosior> economical players whereas it would be for normies, who would get forked off. All in all, LOT=true is way more risky in the worst case (obviously) 12:07 < provoostenator> Nothing in the blockchain reveals which version people are running (at least not in recent updates) 12:07 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has left ##taproot-activation [] 12:07 -!- criley_ is now known as criley 12:08 < provoostenator> darosior: that reveals another risk, that big players might recompile with LOT=false and decide (much) later what they'll do. 12:08 < luke-jr> darosior: completely false 12:09 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation 12:09 < darosior> provoostenator: yep or not upgrade out of cautiousness, some of us already said they would do that if LOT=true was released (as a first try) 12:09 < provoostenator> I'd rather not give them a reason to collude on that parameter. 12:10 < provoostenator> Was there any discussion about a reasonable minimum time period for activation, e.g. a 6 month window rather than a year? 12:10 < luke-jr> far more likely people (incl businesses) changing LOT=false to true 12:10 < luke-jr> in fact, I have businesses asking to fund a LOT=true release already 12:10 < provoostenator> Because the shorter the window, the less downside to shipping with LOT=false 12:11 < luke-jr> provoostenator: that makes no sense either 12:11 < provoostenator> luke-jr: there's probably some selection bias in which businesses tend to contact yoyu for that :-) 12:11 < warren> June 13th 2017 warren wrote, "People should not defer to core or wait for the project to decide by the merging of BIP148 right now. Doing so means the project makes decisions when it really must not be their role. In some recent IRC dev meeting it was mentioned that merging BIP148 should not happen now, even disabled by default, because it would put users at risk. The top priority of the peer review process is safety. You will note that 12:11 < warren> Bitcoin is terribly boring when compared to the repetitive disasters of unrealistic-design-gone-wrong or emergency hardforks like what you see over in ETH-land. At the moment it is the correct decision from a safety point of view to not merge things that put users at risk." 12:11 < warren> My opinion now: Core made the right decision back in 2017. It was good to demonstrate it is not the role of developers to make unilateral decisions. I think merging LOT=false while giving the option for the user to set true seems OK but only if the risks of opting-in are widely understood due to an education campaign (community resources are better able to handle this these days). LOT=true by default would probably happen as published 12:11 < warren> by somebody else but it should not be Core. 12:12 < stortz> when are we deciding the LOT parameter 12:12 < luke-jr> stortz: never apparently 12:12 < darosior> provoostenator: see past meetings, the result of the first one was to with 1y. The second one agreed on the start and timeout and 90%. I personally believe that should miners try to (completly recklessly) prevent Taproot activation, we can do a BIP8(true, 6mo) after 6mo to get it activated for both clients. 12:13 < darosior> (assuming we'd go with BIP8(false, 1y) to start) 12:14 < stortz> I'm still trying to wrap my head around why should LOT=true pose a security risk if most miners are signaling for activation anyway 12:15 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [] 12:15 < provoostenator> darosior: I suppose it's fine is the deadline for a LOT=false release is 1 year out, since you don't have to wait for that to try something else. As long as "something else" involves the same signal. 12:15 -!- criley [~textual@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation 12:15 < provoostenator> In fact, having it expire and then doing another release is clumbsy, because not everyone would upgrade to that second release and meh. 12:16 < darosior> yep 12:16 < darosior> i believe it's cleaner to force signaling early should they be malicious (highly unlikely imho) 12:16 < maybehuman> and realistically speaking, people probably wouldn't sit on their hands for one entire year anyway 12:16 < provoostenator> luke-jr: so if Bitcoin Core release a LOT=false release and you do a LOT=true patch the next day, what's the downside? 12:17 < darosior> stortz: take the worst case. Both economic majority and miners don't accept Taproot (the formers don't upgrade, the latters don't signal). If the release was shipped with LOT=false, Taproot activation just don't happen yet. If it was with LOT=true, a *lot* of users get forked off the network 12:17 < warren> Were most people in favor of build-time configurable LOT= rather than runtime config because they are afraid the latter is too easy? 12:18 < provoostenator> stortz: if 95% is already signalling for activation, then there is no need for LOT=true 12:18 < darosior> stortz: because the ones running the software with default (and often without even reading release notes would likely not be big economical players but randos) 12:18 < provoostenator> But if it drops below that percentage, then there is a risk. 12:20 < stortz> can't the same be said for LOT=true? if 90%+ is already singaling, the risk of fork is below 10% (?) 12:20 < luke-jr> provoostenator: a mixed network is riskier than a universal LOT=true 12:20 < darosior> To try to make progress: luke-jr: what big downside do you see to do LOT=true after having released (and thus tried with) LOT=false ? 12:20 < darosior> (ok you just answered) 12:20 < maybehuman> luke-jr: or a universal LOT=false 12:20 < luke-jr> maybehuman: that is an impossible outcome 12:21 < luke-jr> and no, I think a universal LOT=false would be the riskiest outcome 12:21 < darosior> luke-jr: what if the second LOT=true has the same timeout block height than the first LOT=false ? 12:21 < maybehuman> universal lot true seems equally impossible 12:21 < luke-jr> darosior: still 12:22 < darosior> luke-jr: what big downside is there to go with this approach ? 12:22 < luke-jr> maybehuman: if Core releases LOT=true, very few (to the point of irrelevance) are likely to use LOT=false 12:22 < luke-jr> darosior: it's a mixed network; that means confusion for users, extra code to write/test, danger of a chain split 12:22 < maybehuman> I don't see why I can't just flip the trues and the falses in your statement 12:22 < belcher> not necessarily luke-jr, people may just not update 12:23 < luke-jr> maybehuman: because it doesn't hold for false 12:23 < belcher> its actually a three way choice, LOT=true, LOT=false or dont update 12:23 < luke-jr> belcher: ? 12:23 < stortz> isn't it backwards compatible ? 12:23 < maybehuman> luke-jr: Can you elaborate? 12:23 < darosior> belcher: i would argue that not updating ~= LOT=false 12:23 < luke-jr> belcher: the people who set LOT=false or don't update, are likely a smaller number than those who already run light wallets, if Core releases LOT=true 12:24 < provoostenator> Any controversy around LOT will probably reduce the number of people who upgrade. 12:24 < luke-jr> maybehuman: many people will use LOT=true no matter what Core releases 12:24 < belcher> darosior the big difference there is that a none-updating node doesnt enforce the new rules even if the miners signal 12:25 < belcher> luke-jr IMO your phrase "if Core releases LOT=true" is doing a lot of work 12:25 < darosior> belcher: yep that's why "~" but at least they don't get forked off should the opposite happen 12:25 < luke-jr> maybehuman: and again, a mixed network is STILL superior to universal LOT=false 12:25 < belcher> if you think about it, LOT=true is a UASF, LOT=false is a MAST 12:25 < luke-jr> belcher: LOT=true is MASF too 12:25 < belcher> we know users support taproot or at least dont oppose it, but we dont know whether users support a UASF 12:25 < luke-jr> just without a backdoor 12:26 < belcher> luke-jr right but all this discussion is about the backstop case of what happens if miners dont signal 12:26 < luke-jr> LOT=true simply removes that option 12:26 < luke-jr> miners MUST signal 12:26 < belcher> not if they think that the economic majority doesnt support the UASF 12:26 < darosior> IF economic majority runs it 12:27 < luke-jr> which is a given with universal LOT=true 12:27 < belcher> nope, because users might not upgrade to the latest core 12:27 < nickler> It's not at all clear that a mixed network is less risky as the assumption that everyone actually upgraded when lot=true activates. 12:27 < stortz> this is going in circles 12:27 < belcher> in 2017 many many people supported the segwit UASF because of issues like high fees and asicboost, today we dont have those conditions, bitcoin is perceived to be working absolutely fine 12:27 < darosior> nickler: +1 12:27 < stortz> we are for real doing circles around the argument 12:28 < provoostenator> Looks like we invented a perpetual motion machine after all 12:28 < luke-jr> nickler: what part is unclear to you? 12:28 < belcher> (i just read the recent mailing list emails about this, thats why i just joined in) 12:29 < nickler> luke-jr: there's only one part, it's impossible to know how many will _actually_ update 12:29 < darosior> stortz: yes but we need to get somewhere, hence my specific questions (i'm not opposed to get convinced either) 12:30 < provoostenator> Maybe someone can write a regtest test suite with 3 versions of Bitcoin Core (v0.21.0, v021.1 LOT=false, v021.1 LOT=true) and then simulate some scenarios 12:30 < luke-jr> nickler: with a published and consensus deadline of 1 year, it's only logical to assume most will 12:30 < luke-jr> almost all even 12:30 < stortz> it will just showcase what we know in relation to worse case scenarios 12:30 < provoostenator> I have no idea how you would simulate all the actors, but it should be good therapy 12:30 < stortz> we disagree in which one is the worse one 12:32 < nickler> uke-jr: sure, that's an assumption. Another assumption is that if people really want the softfork, they are able to do coordinate on a parallel lot=true that's minimally messy. And if not, that's fine too. 12:34 < stortz> I still think it should be LOT=true just to create a strong precedent for BIP8 12:35 < belcher> LOT=false would also create a precedent for BIP8? the lockontimeout parameter is part of BIP8 12:35 < maybehuman> luke-jr one thing I find interesting that a couple of days ago you were always arguing that the community is the ultimate sovereign in all this, today you seem to argue that because "many people" will surely do one particular thing, all the community has be to made to follow them 12:35 < belcher> LOT=true is a UASF, that has been done many times before by satoshi and with bip148, so its unclear to me what the value is in setting even more of a precedent 12:35 < luke-jr> maybehuman: why are you misrepresenting me now? 12:36 < maybehuman> luke-jr: That's how I understood what you wrote 12:36 < maybehuman> I can look up some links, but that would probably be boring for the rest of the channel 12:36 < luke-jr> literally nobody is being forced 12:36 < belcher> theres also value in setting a precedent that bitcoin core is always careful and conservative with a network that's worth so much today 12:36 < maybehuman> I mean you do seem kind of pushy about this universal LOT=true thing 12:37 < maybehuman> or am I misreading? 12:38 < luke-jr> apparently 12:38 < maybehuman> ok, so you wouldn't want to force universal lot true and at some point accept a mixed network as an outcome 12:41 < stortz> wouldn't it be fun if we had a vote and it ended in a tie 12:43 < luke-jr> maybehuman: LOT=true is the only thing that should be recommended or released. But nobody should be literally forced to release or run it. 12:43 < luke-jr> stortz: we did last meeting 12:43 < luke-jr> more or less 12:45 < nickler> luke-jr: looking at your version data again (https://luke.dashjr.org/programs/bitcoin/files/charts/branches.html), isn't 1 year timeout (for any lot) too short given that 30% are running 0.18 or older? 12:45 < nickler> 0.19.0 was released Nov 2019 12:45 < stortz> I think regardless of what is decided, we're probably getting the best case scenario for the final outcome 12:46 < luke-jr> nickler: IMO with 30% running 0.18, startheight should be the focus ;P 12:46 < nickler> yeah, that too for sure 12:46 < luke-jr> nickler: 0.18 was supported beyond 0.19.0 tho 12:46 < luke-jr> https://bitcoincore.org/en/lifecycle/ 12:47 < luke-jr> 0.18 Maint end wasn't until 2020-06-03 12:47 < luke-jr> 24% run <=0.17 tho 12:48 < luke-jr> nickler: I also made this to help inform https://luke.dashjr.org/programs/bitcoin/files/charts/historical-pretaproot.html 12:48 < luke-jr> in days-since-release, what % has upgraded to 0.21/0.20.2/0.19.2 12:50 < nickler> I guess the hope is that the announcements will draw enough attention to get people to update before startheight. I don't remember how well that worked with past softforks. 12:50 < luke-jr> me either 12:50 < luke-jr> that's why I suggested 0.21 should include a "please treat the same" announce 12:50 < luke-jr> but other devs wouldn't have it 12:51 < nickler> luke-jr: sorry, what exactly does the historical-pretaproot chart indicate? 12:51 < luke-jr> regardless, the situation with BIP148 was a *lot* riskier and controversial, and it worked out 12:52 < luke-jr> nickler: X is days since release, Y is % of network 12:52 < luke-jr> nickler: so day 0 is the day each version was released 12:52 < luke-jr> (a different day for each version) 12:53 < luke-jr> the first release this tracks is 0.19.2, so only it has data for day 41 12:53 < luke-jr> older versions would be nice, but generating it going back that far would be .. annoying 12:55 < nickler> looks surprisingly linear, after 180 days everyone should be on 0.21.0 heh 12:56 < luke-jr> I doubt it keeps up that long :P 12:58 * luke-jr ponders how long it would take to go back to at least 0.19 13:00 < nickler> yeah not really sure what conclusions to draw except that people update slowly 13:05 -!- fjahr [sid374480@gateway/web/irccloud.com/x-hhqouwnzitxxomzo] has quit [Remote host closed the connection] 13:05 -!- hebasto [sid449604@gateway/web/irccloud.com/x-rvhmjnspapofjlfh] has quit [Remote host closed the connection] 13:08 -!- criley [~textual@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Ping timeout: 246 seconds] 13:21 -!- hebasto [sid449604@gateway/web/irccloud.com/x-qkropcniubxwuafs] has joined ##taproot-activation 13:26 < jeremyrubin> people also update more slowly when there are no consensus critical changes most likely... 13:28 -!- fjahr [sid374480@gateway/web/irccloud.com/x-wtgxofjmyomzqblb] has joined ##taproot-activation 13:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 13:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 13:56 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed] 14:16 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 14:18 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds] 14:26 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 15:12 < luke-jr> nickler: it looks like 0.21 is actually seeing record adoption rates: https://luke.dashjr.org/programs/bitcoin/files/charts/historical-pretaproot2.html 15:12 < luke-jr> admittedly, only going back to 0.18 15:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 16:23 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 16:25 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 16:26 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 16:52 < robert_spigler> I will be running LOT=true. I don't see a logically valid reason for running LOT=false, especially if people are saying they will run LOT=true later if miners don't cooperate (you are giving them the ability to be malicious by running LOT=false, and if you want a MASF, LOT=true allows this) 16:54 < robert_spigler> LOT=false is not 'more conservative', as it creates a mixed network with a greater chance of network splits 17:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:25 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Ping timeout: 256 seconds] 17:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 17:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 17:58 -!- belcher_ is now known as belcher 18:13 -!- makriath [acdae048@d172-218-224-72.bchsia.telus.net] has joined ##taproot-activation 18:27 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 18:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 18:30 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation 18:51 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 18:51 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation 18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds] 19:01 -!- queip [~queip@unaffiliated/rezurus] has quit [Read error: Connection reset by peer] 19:06 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 19:16 -!- makriath [acdae048@d172-218-224-72.bchsia.telus.net] has quit [Quit: Connection closed] 19:16 -!- qubenix [~qubenix@66.172.11.228] has joined ##taproot-activation 20:01 -!- rdymac [uid31665@gateway/web/irccloud.com/x-wdrcfkkgnifmvmby] has quit [Ping timeout: 265 seconds] 20:01 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-kndjfmofvkutwjbp] has quit [Ping timeout: 264 seconds] 20:02 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ztsaembyqgmaqhzd] has joined ##taproot-activation 20:03 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-ijxwyxgobnnnxfzx] has joined ##taproot-activation 20:10 < CubicEarth_> robert_spigler: I read your logic as this: Some people are going to do something to try to force a change, and the most conservative thing would just be for everyone to go along with it so there is no split 20:12 < CubicEarth_> So basically, anytime some people want to make a change, everyone should just follow so there is no split 20:13 < CubicEarth_> Perhaps there would be no split, but Bitcoin would quickly morph into an unknown and unrecognizable form 20:13 < CubicEarth_> So it is conservative to avoid a split, but not conservative of Bitcoin's properties 20:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds] 20:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:10 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 21:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 21:15 -!- lukedashjr is now known as luke-jr 21:27 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed] 21:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 21:37 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-activation 21:39 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 21:54 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 21:54 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 22:36 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 22:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 22:39 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:40 -!- lukedashjr is now known as luke-jr 23:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 23:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 23:49 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation 23:50 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 23:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 23:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] --- Log closed Fri Feb 19 00:00:37 2021