--- Log opened Sun Feb 21 00:00:35 2021 00:50 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 00:52 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 01:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:29 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit] 01:30 -!- qubenix [~qubenix@66.172.11.228] has joined ##taproot-activation 02:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 02:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 02:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 02:56 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 02:59 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 04:07 <@michaelfolkson> A reminder to aj luke-jr nickler dr_orlovsky and anybody else who wants to participate we have a code review of Bitcoin Core PR #19573 https://github.com/bitcoin/bitcoin/pull/19573 on Tuesday 19:00 UTC scheduled 04:08 <@michaelfolkson> I'm open to ideas on how to structure it. At the moment I'm thinking commit by commit starting with non-test commits 04:19 <@michaelfolkson> I'm also interested in guidance/ideas on how to test this beyond just running the unit tests, functional tests. There are edge case scenarios which I think are mainly P2P/network related ie handling naturally occurring re-orgs but with different signaling on each side of the re-org 04:20 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds] 04:21 <@michaelfolkson> And the scenarios of some nodes setting lot=true and some nodes setting lot=false is a whole different level of complexity 04:23 <@michaelfolkson> Presumably these types of scenarios would be tested by individuals on mini simulation projects rather than trying to incorporate into say functional tests 05:15 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 05:19 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation 05:20 < maybehuman> There's also the issue Matt mentioned on the mailing list: If you change your lot setting after must_signal has started, you would have to revalidate the blocks you already have because they might no longer be considered valid 05:25 -!- manj-gnome [~manjaro-g@37.162.2.237] has joined ##taproot-activation 05:29 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 05:54 -!- manj-gnome [~manjaro-g@37.162.2.237] has quit [Quit: Leaving] 06:08 <@michaelfolkson> I guess this approaches the question of what should Core protect the user against assuming the user is not using the default set in Core 06:08 <@michaelfolkson> I would argue not much. You should only change the default if you know what you are doing. Core can't protect you against edge cases if you start tampering with a Core release 06:10 <@michaelfolkson> But there are scenarios where the user is not tampering with a Core release (e.g. naturally occurring re-orgs) which the user should definitely protected against 06:15 < maybehuman> I don't know, it seems like a bad practice to release a setting and then basically say "If you change the default, you're on your own" 06:15 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation 06:17 <@michaelfolkson> There are an infinite number of edge cases and bugs you open up if you start tampering with software and you don't know what you are doing 06:17 < maybehuman> but it also depends how hard it is to switch I guess. If switching would involve modifying the source and recompiling then you could argue that it amounts to tampering 06:18 < maybehuman> if it's a config setting I would say changing it shouldn't break your system 06:19 <@michaelfolkson> Well there is a chain split risk regardless of what Core does 06:19 <@michaelfolkson> That is a given 06:19 < nothingmuch> also if you set it, vallidate some blocks, and then change it then you might be in an inconsistent state, IIRC that's the reasoning for making it a hidden config option 06:20 <@michaelfolkson> I just don't think encouraging the user to choose or change it is in any way viable 06:21 <@michaelfolkson> As I said in the mailing list post the best case scenario is there are two releases, say a Core release setting lot=false and a "community" release setting lot=true 06:21 < nothingmuch> in this particular case i think it only makes a difference after the timeout has expired, need to think about that more though 06:22 <@michaelfolkson> lot is only relevant at the end of the year right 06:23 < nothingmuch> i find the two releases approach appealing in its purity. if everyone believes a critical mass of economic nodes will enforce the rules, it should activate, and the critical mass is guaranteed not to experience a chain split if it has enough hash rate to survive 06:25 < nothingmuch> if it's not a critical mass, those users will see themselves on a minority chain that is unlikely to be accepted, as far as chainsplits go this seems like the least terrible type of chainsplit 06:26 < nothingmuch> if it's above a critical mass then LOT=false users are exposed to wipeout/reorg risk, and so have an incentive to set LOT=true, but arguably it's not a good idea to leave that as an option 06:28 < nothingmuch> iow the tradeoff seems to me like it's accepting objective risks in exchange for fewer bikeshedding moral hazards. unfortunately accepting objective risks is also a moral hazard, and i'm not sure how these stack up, i still find luke-jr's PoV most convincing (avoid the objective risk moral hazard, avoid objective chainsplit risk by defaulting to LOT=true) 06:31 < nothingmuch> to be clear, i'm kind of disagreeing with "best case" - i don't think it's clearly that because without a single default chainsplit risk is substantially higher 06:31 <@michaelfolkson> I'll be leaving swiftly if you just want to rehash the lot argument again :) 06:33 < maybehuman> It's still a strange proposition to say "here's two software releases. One of them might break horribly in a year, but we don't know which one" 06:33 <@michaelfolkson> Welcome to blockchains 06:34 < nothingmuch> michaelfolkson: no, only the two releases vs. one default question, but the details of that discussion are relevant to this question 06:34 <@michaelfolkson> maybehuman: This problem is avoided by going back to proprietary centralized databases. 06:35 < nothingmuch> if i'm not mistaken core releases tried to establish a precedent of avoiding such things, it's not my impression that most people take this risk as an inevitability 06:36 <@michaelfolkson> Core cannot stop others from releasing software with different defaults and cannot stop others from running it 06:37 < nothingmuch> agreed, the question is unavoidable on some level. but if you only use core and always upgrade - so far that has given some assurances 06:37 <@michaelfolkson> This risk has always been an inevitability and always will be 06:38 <@michaelfolkson> The system is antifragile, it is only individual users who can get in trouble and lose money if they transact during the time of the chain split 06:42 < stortz> also Core does not force users to upgrade 06:42 <@michaelfolkson> Of course not 06:42 < nothingmuch> i think so too, but just to acknowledge i'll paraphrase Matt's conter argument which is that e.g. a chainsplit followed by a 4 block reorg (much likelier when two competing chains are around) can still lose a lot of money, it really matters to users what exchanges are going to run 06:42 <@michaelfolkson> And the counter argument to that is never try an attempted soft fork again 06:43 < stortz> that scenario is very unlikely given the amount of time until LOT=true gets executed (1Y) 06:43 <@michaelfolkson> stortz: Right 06:43 < nothingmuch> i don't think it's so fatalist. like i said before, i think the contentious issue is actually the timeout, not LOT=true or LOTfalse 06:44 < nothingmuch> in upgrade vs. don't upgrade dilemmas, chainsplit risks can be avoided 06:45 < nothingmuch> that's qualitatively different than shipping two semi conflicting consensus rulesets concurrently 06:45 <@michaelfolkson> i think we're going off topic. Code review is priority for Tuesday 06:47 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 07:40 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed] 08:21 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal] 08:41 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation 09:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 10:28 -!- manj-gnome [~manjaro-g@37.162.2.237] has joined ##taproot-activation 10:50 -!- manj-gnome [~manjaro-g@37.162.2.237] has quit [Quit: Leaving] 11:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds] 11:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 12:50 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-kszhzxjqgjaaiytr] has quit [Read error: Connection reset by peer] 12:51 -!- felixweis [sid154231@gateway/web/irccloud.com/x-uxvkkvzinlkyxlvm] has quit [Ping timeout: 264 seconds] 12:51 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-wctqlxoztrxlnilq] has joined ##taproot-activation 12:51 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-zogsylksfifauupl] has quit [Ping timeout: 260 seconds] 12:51 -!- felixweis [sid154231@gateway/web/irccloud.com/x-nbngwvfrzzhlxemt] has joined ##taproot-activation 12:53 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-lopkrozptkoybihj] has joined ##taproot-activation 13:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 15:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 15:41 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation 16:45 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 16:48 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 18:27 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 18:51 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed] 19:27 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 19:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 21:30 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds] 21:40 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds] 23:14 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 23:15 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 23:34 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 23:34 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 23:42 -!- pox [~pox@141.226.243.49] has quit [Quit: pox] 23:43 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 23:49 < aj> luke-jr: i'd like to propose a rename of lockinontimeout -> https://en.wikipedia.org/wiki/Failure_Is_Not_an_Option 23:50 < aj> (i have not decided whether i'm being serious or not :) --- Log closed Mon Feb 22 00:00:37 2021