--- Log opened Tue Mar 02 00:00:45 2021 00:08 <@michaelfolkson> belcher nothingmuch: I get the "let's find the solution everyone is happy with" and "let's all be friends". That's why we've spent 8 months + on this. 00:08 <@michaelfolkson> You're falling into the philosopher's stone trap. You think if we just spend another 8 months we'll find that solution 00:11 <@michaelfolkson> There is a difference between listening and attempting to stay civil (which I think you should do) and going round in endless circles 00:12 <@michaelfolkson> "it'd be interesting to poll LOT=false supporters for what timeout value, if any, would make LOT=true acceptable to them" <- Then you bikeshed over the timeout value. A year isn't long enough for readiness/to get ready?! 00:14 <@michaelfolkson> You set it to 2 years, 3 years and everyone forgets about it for a year and a half 00:17 <@michaelfolkson> Pretty much everyone in the meeting was happy with a year. F7 just says Core devs shouldn't push a first release with true, it doesn't say they can push a first release with true if the timeout is obscenely long (2+ years) 00:17 < aj> "everyone in the meeting" worked well for NYA too 00:19 <@michaelfolkson> Perhaps we should ban all meetings then. Any attempt to organize on a particular date at a particular time (even if it is open to all, promoted to all, logged, with people's views covered who couldn't bother attending) 00:19 <@michaelfolkson> Every Core dev meeting on a Thursday is a NYA. Ban every meeting 00:20 < aj> maybe just don't assume that agreement at a meeting means everyone will agree with you, or that you don't need to continue convincing people? 00:20 <@michaelfolkson> I prefer banning every meeting tbh 00:20 < aj> that's not something within your power 00:21 < nothingmuch> michaelfolkson: i believe 1y meant different things to different people, but i'm more interested in trying to understand the dispute, not bikeshedding it 00:21 <@michaelfolkson> In Matt's podcast (that I transcribed and covered in this channel despite him not bothering to engage or join the meetings) he said he was happy with lot=false. Now he's blocking lot=false in Core 00:22 < aj> huh? he's stating an opinion on a mailing list, that's not blocking anything 00:23 <@michaelfolkson> It sounds like you want to get back into the questionnaire game aj. You are free to do more questionnaires 00:25 < aj> ... 00:25 <@michaelfolkson> He's blocking the PR in Core. Wants it to be put on ice rather than opening a PR himself or putting forward a route that he is happy with 00:25 < aj> how do you think people understand things and come to agreement if talking about them and stating their opinions is terrible? 00:25 <@michaelfolkson> "In Matt's podcast (that I transcribed and covered in this channel despite him not bothering to engage or join the meetings) he said he was happy with lot=false. Now he's blocking lot=false in Core" 00:26 < aj> he's suggesting it to lockinontimeout=true code be split into a separate PR that also ensures that lot=true is safe to use; that's not blocking a lot=false deployment 00:26 < aj> s/it to/the/ ? 00:27 <@michaelfolkson> Well open that PR then. Putting on a PR that it should be put on ice after 8 months is plainly ridiculous 00:27 <@michaelfolkson> "In Matt's podcast (that I transcribed and covered in this channel despite him not bothering to engage or join the meetings) he said he was happy with lot=false. Now he's blocking lot=false in Core" 00:28 <@michaelfolkson> If that's the behavior of someone who thinks talking about them and stating their opinions if terrible.... 00:28 < aj> if a PR isn't safe, reverting it after it had been merged for 5 years would be fine. nacking it -- which he didn't -- after 8 months is fine, especially given the PR had been trivially buggy and needed a rebase for most of that time 00:30 <@michaelfolkson> What you have described is fine. Putting something on ice because you want to engage in another 8 months of philosophical debate because you didn't join in the first time isn't 00:32 <@michaelfolkson> The PR should be reviewed to death. Nobody is going to bother reviewing it or an alternative if they know it won't get merged for another 8 months because Matt wants to start the philosophical debate again 00:33 < aj> "the PR should be reviewed to death", but also, anyone who disagrees with it or raises concerns that might take time to solve is is too late and should be ignored? 00:35 <@michaelfolkson> What might take time to solve aj? A solution that has perfect 100 percent consensus, not a single individual is unhappy with it? Or a solution that has absolutely zero chain split risk? 00:36 <@michaelfolkson> You think either of those is solved if we just spend another 8 months on it? 00:36 < aj> huh? 00:37 < aj> matt's saying the lot=true code should handle a chain split, because it's impossible to 100% avoid one 00:37 <@michaelfolkson> Core isn't releasing lot=true, that is obvious 00:39 <@michaelfolkson> (Nor should it with the effective NACKs from Core contributors) 00:39 < aj> i'm trying to avoid setting my "michaelfolkson doesn't know what he's talking about, that is obvious" flag to true, but you're making it super difficult 00:40 < ghost43> lot=false is perfectly capable of activating a soft fork; and even if it fails, it's better to attempt it sooner than continuing endless debates. I bet if it failed we would either learn something or get community consensus on try another method that forces activation (e.g. lot=true) 00:41 <@michaelfolkson> You are free to have another 8 months of philosophical debate aj if that's what you think is necessary and a good use of your time 00:41 < aj> the PR proposes including lot=true support in core; if we merge that, and don't revert it, core will eventually be releasing code that supports lot=true. if core decides not to do that, the PR won't get merged. it's received no NACKs, though it has an unfixed bug from yesterday 00:41 < ghost43> if you really think the debate might go on for another 8 months it really seems best to just try lot=false 00:42 < aj> michaelfolkson: well, if i were going solely on what i felt was a good use of my time, i'd not be in this conversation 00:42 <@michaelfolkson> So open a PR without the lot=true support aj. Surely that is a better use of your time than arguing for another 8 months of philosophical debate 00:44 <@michaelfolkson> I have got no problem with Core releasing lot=false with no lot=true code support. I know Luke would strongly disagree but maybe that has a chance of being merged 01:16 * michaelfolkson thinking how "This PR should be put on ice" would be received if people got in the habit of writing this on PRs. Or claiming any IRC meeting conclusion is invalid because it is the same as the NYA. This. is. painful. 01:24 -!- Alexandre_Chery [94668738@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.135.56] has joined ##taproot-activation 01:27 < ghost43> A public meeting that anyone can reasonably attend if they want and is announced reasonably in advance on the ML; and the NYA; are like night and day 01:28 -!- Alexandre_Chery [94668738@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.135.56] has quit [Client Quit] 01:42 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 01:43 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds] 02:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 02:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 04:16 < AaronvanW> https://medium.com/@sdaftuar/on-taproot-activation-and-consensus-changes-in-bitcoin-5b3453e91c4e 04:51 <@michaelfolkson> taprootactivation.com updated with F2Pool LOT preference stating they are happy with LOT=true or LOT=false https://taprootactivation.com/ 04:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds] 05:02 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 05:40 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection] 05:41 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 06:07 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has joined ##taproot-activation 06:16 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadm_] 06:17 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 06:22 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 06:41 -!- jonatack [~jon@37.164.30.247] has joined ##taproot-activation 07:02 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:04 -!- jonatack [~jon@37.164.30.247] has quit [Read error: Connection reset by peer] 07:10 -!- ComplyLast [~thrmo@unaffiliated/thrmo] has joined ##taproot-activation 07:12 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 07:13 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 07:14 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 07:14 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 07:16 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 07:16 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 07:29 < luke-jr> aj: LOT=true doesn't require anything more to make it safe than LOT=false does 07:30 < luke-jr> aj: is there a reason not to just do https://dpaste.com/CKE9TAJUB ? 07:30 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 07:31 < aj> luke-jr: stats doesn't count signalling for the current block 07:32 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 07:33 < luke-jr> i c 07:34 < luke-jr> is getblockchaininfo RPC broken then too? 07:38 < aj> luke-jr: getblockchaininfo tells you the stats up until the last block you received and the enforcement status for the next block that comes in 07:39 * aj judges not lest he be judged, or something 07:41 < aj> luke-jr: getblockchaininfo passes Tip() in to VersionBitsStatistics, the code above passes pindexPrev in, rather than "block" (because block is actually a header so doesn't typecheck) 07:42 < luke-jr> aj: I don't see how this could affect the end result; if LOT=F nodes don't activate, neither should LOT=T? 07:42 < luke-jr> wonder what the best way to test this specific edge condition is 07:43 < luke-jr> (as a permanent test) --- Log closed Tue Mar 02 07:44:27 2021 --- Log opened Tue Mar 02 07:44:27 2021 07:45 < aj> luke-jr: if LOT=T nodes don't reject a block for failing to signal, they'll activate because MUST_SIGNAL always transitions to LOCKED_IN https://github.com/bitcoin/bitcoin/pull/19573/commits/23c38ba51661ee240ef80b52895ab2312e6f7fe6#diff-51f2f6d85b4ea5495a71bde76b5b721a5b0d2871e0912e83ff9cbb3970a7e207R87 maybe 07:49 < luke-jr> ah right, that's special cased 08:07 < luke-jr> aj: the test seems to reliably fail with random.shuffle left in..? 08:10 -!- jonatack [~jon@37.164.30.247] has joined ##taproot-activation 08:14 < aj> luke-jr: yeah. could count the bits like in STARTED and transition from MUST_SIGNAL to INVALID and INVALID->INVALID ; that'd make it easier to realise you have to rewind on startup after switching from false/true or similar 08:16 < aj> luke-jr: weird; should fail only 25% of the time with the shuffle still there i think? 08:16 < luke-jr> well, I did only run it a few times 08:16 < luke-jr> it's a rather slow test 08:17 < aj> it is :( 08:24 -!- ComplyLast [~thrmo@unaffiliated/thrmo] has left ##taproot-activation ["Leaving"] 08:39 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 09:08 -!- jonatack [~jon@37.164.30.247] has quit [Ping timeout: 260 seconds] 09:10 -!- jonatack [~jon@37.164.30.247] has joined ##taproot-activation 09:12 < luke-jr> aj: what is the reason it would only fail 25%? 09:15 < aj> luke-jr: it fails if it was possible up until the last block, but the last block doesn't signal and causes it to fail. if there's precisely enough signalling blocks for that to happen (N=107 is one too few signalling blocks), the chance that the final block signalling is 107/144 and the chance of it not-signalling and thus hitting the failure mode is 37/144=25% 09:16 < aj> (it'd still wrongly accept the non-signalling block even if it wasn't the last block in the period; but the next block would get rejected, so i don't think the test would pick it... but hmm, maybe the python code to check which block it fails on would pick it up -- that would explain the test failing 100% of the time) 09:17 < aj> (though in that case it should have failed with other N values too? ... not sure) 09:18 < luke-jr> aj: https://dpaste.com/CYRCZJJZ4 ? 09:20 < aj> luke-jr: sure 09:54 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 09:56 -!- naribia [6bb5bd25@107.181.189.37] has joined ##taproot-activation 10:00 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed] 10:03 < RusAlex> sorry I might be stupidly sound with my question. But I heard that LOT=true is the most safe way to update for any user in any environment. Even when lots of people will run LOT=false , LOT=false chain will have a long reorg when one day (and it's seems inevitable) LOT=true become longer 10:03 -!- nvk_ [~nvk@89.36.78.150] has joined ##taproot-activation 10:04 < RusAlex> in other words who runs LOT=false must understand this risk 10:04 <@michaelfolkson> RusAlex: This podcast is good on the discussion of this https://diyhpl.us/wiki/transcripts/bitcoin-magazine/2021-02-26-taproot-activation-lockinontimeout/ 10:06 <@michaelfolkson> Basically both LOT=true and LOT=false are as safe as eachother if miners activate within a year. If miners fail to activate within a year it gets complicated and depends on the percentages of people running LOT=true and LOT=false 10:07 < RusAlex> yes. I got it that this LOT fork scenario is only actual for situation when miners do not signal enough. 10:08 <@michaelfolkson> You would expect that after 6-9 months more and more people will be running LOT=true (this is not guaranteed of course) 10:09 <@michaelfolkson> Many of the LOT=false proponents have said they'd probably run LOT=true after 6-9 months (assuming there was no rationale for the delay) 10:14 < RusAlex> OK. I just want to imaging a scenario when let's say 3-5% of hashpower started minging LOT=true chain. After several weeks (~40 maybe, im stupid here) LOT=true chain will recalculate difficulty, and this old 5% hashpower becomes 100% hashpower 10:15 <@michaelfolkson> If you are worried about this (unlikely) scenario at the end of the year where there are different proportions of LOT=true and LOT=false nodes on the network there are a couple of things you can do to sit it out. You can make sure you don't transact at the end of the year and wait to see which "wins" so to speak. Or you could not upgrade at all until it clear which has won (ie not run either LOT=true or LOT=false) 10:16 < belcher> RusAlex in the event of a chain split the LOT=true chain could become pretty slow 10:16 <@michaelfolkson> But yes in this worst case scenario where miners fail to activate for a year and there are different proportions of LOT=true and LOT=false nodes on the network there is the possibility of a chain split 10:16 < belcher> So for example, imagine trading bitcoin for cash in person, but instead of waiting on average 10 minutes for a confirmation you have to wait 2 hours. Imagine depositing coins to an exchange which requires 3 confirmation, then instead of waiting ~30 minutes you have to actually wait 6 hours. 10:16 < belcher> its a mirror image of the situation where LOT=false is vulnerable to reorgs 10:17 < belcher> a chain split harms both sides, its pretty important to avoid a chain split 10:18 < belcher> (those exact numbers are only examples, they depend on the hashrate split between the two chains.... and interestingly according to taprootactivation.com 90% of the hashrate would activate taproot with BIP8... so if we released any code with BIP8 regardless of the value of LOT we'd probably get taproot activated long before the value of LOT became relevant or there was a danger of a chain split) 10:20 <@michaelfolkson> Right 10:22 < naribia> ..excuse me... what is LOT ? 10:23 < belcher> naribia lockontimeout 10:27 < RusAlex> risk long reorgs also there for non updated nodes when MASF is not happened 10:27 < RusAlex> in other words only LOT=true wont have reorgs but might become a chain without miners 10:30 < belcher> yes 10:34 < RusAlex> If Im owner of a service which accepts bitcoins , I would think how to avoid a loss of coins, rather of slow transactions during a transition period 10:36 < luke-jr> RusAlex: if you're literally the only oen with LOT=True, you'll be forced into whatever everyone else does 10:37 < luke-jr> @belcher: LOT=False would become both slow and unreliable 10:38 < belcher> i agree it would, chain splits are bad 10:38 * luke-jr stabs slack for confusing him with @ 10:39 < belcher> RusAlex slow transactions implies high miner fees, so you'd lose money in that case too 10:40 < luke-jr> no, it doesn't imply that 10:40 < belcher> RusAlex: if you're literally the only oen with LOT=True, you'll be forced into whatever everyone else does <---- this is not true, if he is the only one running LOT=true then he gets no more blocks ever, and has to go back to LOT=false or something else 10:41 < belcher> luke-jr we've seen plenty of times when the hashrate drops then blocks become slow and miner fees go up, its simply supply and demand... the last time it happened that i remember was right after the halvening last year when the hashrate dropped and oscillated for a while 10:41 < luke-jr> belcher: that's the same thing 10:41 < brg444> thats exactly what luke-jr is saying though 10:42 < luke-jr> belcher: correlation is not causation 10:42 < RusAlex> I know that miners are greedy and want to earn alot of money. And even if I stuck on my chain for some time with LOT=true , one day a valuable part of miners starting LOT=true , and then HUGE HUGE reogrs may happen in the network. 10:42 < belcher> its not correlation luke-jr its the law of supply and demand 10:43 < belcher> RusAlex thats why many people are saying they fear the risk of a chain split, its not good for anyone really 10:43 < luke-jr> belcher: your claim is false because 1) the existence of an invalid chain implies there is some economic value occurring on that chain and therefore not on the LOT=True chain; and 2) the same reasons smaller blocks don't mean an increase in fees 10:43 < RusAlex> even if nobody will mine LOT=true on start , there is the risk somebody will after some time 10:44 < luke-jr> RusAlex: only if there's economic value in doing so 10:44 < luke-jr> one person is not that 10:45 < belcher> why would miners mine on the LOT=true chain if users are just ready to jump back to LOT=false ? 10:45 < belcher> the point of a UASF is you stick with the chain you want through thick and thin, you have to be an intolerant minority 10:45 < luke-jr> belcher: there is a difference between one user, and many users 10:46 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation 10:49 -!- Guest95662 [50390e8e@g14142.upc-g.chello.nl] has joined ##taproot-activation 10:51 -!- nvk_ [~nvk@89.36.78.150] has quit [Ping timeout: 276 seconds] 10:51 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 10:52 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 10:53 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 10:56 -!- occupier [~occupier@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation 10:58 -!- devrando1 is now known as devrandom 10:59 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed] 10:59 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 11:03 < occupier> What's the argument against doing a rather short LOT=false and if it fails to activate, deduce why it didn't activate and if it's not compelling reason, do another short activation period with LOT=true? 11:06 < AaronvanW> occupier: as jonny1000 pointed out in ##uasf, might as well just ship lot=false with longer period, and upgrade to lot=false halfway. 11:06 < AaronvanW> uhh upgrade to lot=true halfway 11:08 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: leaving] 11:08 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation 11:08 < occupier> AaronvanW IMO there is value in the market being able to tell whether or not Taproot activated by LOT=false or LOT=true, if the ecosystem switches midway, that's less clear 11:09 < roconnor> I hope Core just does that. With a plan of flipping from LOT=false to LOT=true after a 6 month upgrade cycle, it will bring core in line with the LOT=trueers. 11:09 < luke-jr> there is no point in flipping it after 6 months 11:09 < luke-jr> might as well be true from the start 11:10 < luke-jr> stuff like that just seems like stalling to later say "nah not gonna do it ever" tbh (as certain folks recently admitted) 11:10 < roconnor> And if there is an unexpected and unforseen refusal to upgrade Bitcoin Core, the ones who do start with LOT=false will be okay. 11:11 < AaronvanW> occupier: if false hasn't done the job in, say, six months (without good reason), I think it's pretty clear myself. 11:12 < luke-jr> roconnor: not really 11:12 < luke-jr> AaronvanW: false does nothing until the timeout 11:17 -!- bitentrepreneur [2578d1d4@37.120.209.212] has joined ##taproot-activation 11:17 < bitentrepreneur> hi 11:17 < belcher> hey 11:21 < AaronvanW> bitentrepeneur I think you want to be in ##uasf 11:22 < bitentrepreneur> thansk AaronvanW 11:22 < belcher> see the logs in the topic of ##uasf if you want to catch up, the meeting started a couple of minutes ago 11:22 < roconnor> luke-jr: you say not really because a short LOT=true chain might overtake causing a single reorg if the LOT=true chain is more valuable? 11:28 < roconnor> Anyhow, I expect that Core will eventually release a LOT=true client if taproot doesn't activate promptly, so it ultimately there isn't going to be a practical difference between a USAF client and (eventually) Core client. 11:30 < occupier> consensus is path dependent, so I disagree that if the end states are the same, it doesn't matter how the protocol arrives there 11:31 -!- bitentrepreneur [2578d1d4@37.120.209.212] has left ##taproot-activation [] 11:33 -!- bitentrepreneur [2578d1d4@37.120.209.212] has joined ##taproot-activation 11:33 -!- temp345903485 [9a15d844@154.21.216.68] has joined ##taproot-activation 11:38 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 265 seconds] 11:48 < roconnor> Core should probably relase a LOT=true client even if taproot actives. Just to be safe. :) 11:54 < roconnor> If core releases their LOT=false client, and usafers run their LOT=true client, and then taproot activates, not only will the end states be the same, but it won't even be possible to tell if the usafers were victorious or irrelevent. 11:56 < roconnor> AFAICT core is never going to start with LOT=true and usafers will never start with LOT=false, but if both camps just proceed, we will likely have taproot in 6 months. 11:56 < luke-jr> then Core should release nothing at all 11:59 < roconnor> It seems enough Core supporters find merit in starting with LOT=false, and since Core would then proceed to LOT=true in the subsequent release, it seems harmless to indulge the LOT=false support. 12:01 < bitentrepreneur> i am working on finding out the support for LOT=False 12:01 < bitentrepreneur> from mining pool operators 12:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 12:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 12:05 < occupier> ty bitentrepreneur 12:06 < bitentrepreneur> no problem, i will push these mining pool ops harder 12:11 < luke-jr> roconnor: the harm is that it results in people using LOT=False instead of LOT=True 12:11 < luke-jr> roconnor: a mixed network, plus confusion 12:11 < luke-jr> roconnor: I wrote a ML post addressing this.. 12:11 < luke-jr> bitentrepreneur: please don't bother with LOT=False; it is a dead end 12:12 < bitentrepreneur> i'll leave it to the mining pool operators to decide 12:13 < roconnor> when everyone migirates from LOT=False to LOT=true after 6 months it won't matter that they were running LOT=false for 6 months. 12:14 < luke-jr> bitentrepreneur: so we're gonna do 2017 all over? 12:15 < roconnor> luke-jr: I think bitentrepreneur is just making the tautological statement that miners will run whatever software they want to run. 12:15 < belcher> doing 2017 all over again requires some miners to try to block taproot, that seems pretty unlikely 12:16 < belcher> 2017 was in the middle of the block size drama... by contrast today everyone loves taproot 12:16 < luke-jr> roconnor: yeah, my point is why even bring up LOT 12:16 < belcher> i bet it would be more like 2016 activating OP_CSV 12:16 < luke-jr> should just show the plan at BitcoinActivation and ask if they're cool with being listed as a supporter ;) 12:29 -!- realname192 [~real@37.163.139.21] has joined ##taproot-activation 12:30 -!- realname192 [~real@37.163.139.21] has quit [Client Quit] 12:32 < occupier> belcher +1 12:43 < roconnor> Is there even a PR for LOT=false? 12:43 < luke-jr> please don't make one 12:44 < roconnor> why not? 12:45 < luke-jr> LOT=False is harmful 12:45 < luke-jr> best if it isn't released or used by anyone 12:45 < luke-jr> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html 12:45 < aj> there is a PR for bip8, which supports both lot=false or lot=true deployments. the author of both bip8 and the pr now claims lot=false is harmful however 12:46 < luke-jr> also sets a bad precedent 12:48 < roconnor> aj: Right I was looking at PR #19573. 12:50 -!- Guest95662 [50390e8e@g14142.upc-g.chello.nl] has quit [Quit: Connection closed] 12:53 < luke-jr> roconnor: I would consider your review thereof quite valuable if you can 12:54 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed] 12:57 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##taproot-activation 12:57 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit] 13:06 -!- justinmoon [~quassel@157.245.122.126] has quit [Read error: Connection reset by peer] 13:07 < roconnor> luke-jr: do I get to ask n00b PR #19573 questions? Why is ContextualCheckBlockHeaderVolatile new and not part of BIP 9? 13:07 -!- justinmoon [~quassel@157.245.122.126] has joined ##taproot-activation 13:11 < luke-jr> roconnor: because Core never merged BIP148 13:11 < luke-jr> sorry, I'll watch this tab more actively for interactive Q&A ;) 13:14 < roconnor> oh I see, it is specific to the MUST_SIGNAL state which didn't exist in BIP 9 13:14 < luke-jr> yes 13:23 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed] 13:24 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation 13:54 -!- b10c_ [~b10c@2a01:4f8:192:612a:216:3eff:fef3:dc6a] has quit [Quit: leaving] 13:54 -!- b10c [~b10c@2a01:4f8:192:612a:216:3eff:fef3:dc6a] has joined ##taproot-activation 13:54 -!- bitentrepreneur [2578d1d4@37.120.209.212] has quit [Quit: Connection closed] 14:10 -!- guest23024084 [ad441c94@pool-173-68-28-148.nycmny.fios.verizon.net] has joined ##taproot-activation 14:13 -!- bitentrepreneur [2578d1d4@37.120.209.212] has joined ##taproot-activation 14:16 -!- b10c [~b10c@2a01:4f8:192:612a:216:3eff:fef3:dc6a] has quit [Quit: leaving] 14:21 < belcher> I've been thinking about bluematt's flag day activation idea. Briefly making the case for it: a big concern with BIP8 regardless of the value of LOT is that there can be a social movement of people on twitter/reddit/other social media which encourages different people to adopt different consensus rules, and that leads to different parts of the economy using different consensus rules and therefore we get a chain split. The good thing 14:21 < belcher> about a flag day activation is theres no possibility of that happening, it just happens on one date and no twitter people (who are possibly bots) can disturb it. 14:22 < belcher> initially i didnt understand the difference between BIP8 LOT=true and flag day, but theres the difference, bip8 is vulnerable to social media drama (even if the drama is genuine and not driven by bots, its still hard for an outsider to figure out which software they should run) 14:27 < stortz> how does flag day avoid any 'social movement' 14:28 < stortz> ? 14:28 < belcher> it doesnt avoid any social movement, it avoids a social movement which attempts to speed up activation 14:29 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation 14:29 < belcher> the bad result of that attempted speedup is we might end up in a situation where some parts of the economy activate taproot on 1st january, other parts activate it on 1st june.... that would be bad because it would result in a chain split that isnt easily resolved 14:29 < stortz> I don't understand, where can I read more about the flag day idea 14:30 < belcher> theres a couple of posts on the mailing list, but tbh it took me a long time to really figure out the idea so im about to write my own email called something like "making the case for flag day activation" 14:30 < stortz> because that does sound a lot like LOT=true 14:30 < stortz> I'll look for it 14:31 < luke-jr> belcher: the problem you describe exists with Matt's flag day, but does not exist with BIP 8 14:31 < belcher> because? 14:31 < luke-jr> because without a signal, there's no coordination 14:32 < luke-jr> but with a signal, everyone activates concurrently 14:32 < luke-jr> no matter when it occurs 14:32 < luke-jr> (within a range) 14:32 < belcher> how did those old flag day soft forks from 2010 work then? they didnt signal 14:33 < stortz> didn't those risk a mixed network? 14:33 < belcher> signalling is only required for miner activation 14:33 < luke-jr> belcher: fiat 14:33 < luke-jr> benevolent dictator said change 14:33 < luke-jr> and everyone changed 14:33 < luke-jr> glwt if you want to try that now 14:33 < belcher> i disagree with that, they changed because they had an incentive to change 14:34 < belcher> even satoshi couldnt force anyone to upgrade 14:34 < luke-jr> also, there was no money back then 14:34 < luke-jr> and that's not the scenario you described anyway 14:34 < belcher> in either case, signalling is a meme, its useful for miner activation but not when activation depends on a simple block height 14:34 < luke-jr> it never does 14:34 < belcher> nodes know the new rule is active if their current block height >= flag day 14:35 < luke-jr> the only time it depends on a simple block height, is when you deny anyone a choice 14:35 < belcher> what choice is being denied? 14:35 < luke-jr> the choice to reject Taproot 14:35 < luke-jr> to have a block >= that height without it 14:35 < belcher> bip8 LOT=true also denies that choice? 14:35 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in] 14:35 < luke-jr> no, it doesn't. 14:35 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation 14:36 < stortz> -_- 14:37 < luke-jr> users who wish to reject Taproot can simply reject a chain activating it 14:37 < luke-jr> if 1800 blocks with bit 2 are set, the next one with it is invalid 14:37 -!- prayank [~Prayank@2409:4053:2e1b:69dd:ad75:b355:dcd:efff] has joined ##taproot-activation 14:37 < belcher> users who want to reject taproot-activated-with-flag-day could include one transaction which does an invalid-spend from a taproot output 14:38 < luke-jr> that's a magnitude more complex 14:38 < luke-jr> and very unclear 14:38 < luke-jr> unclean* 14:38 < belcher> no its not its easy and simple, its two transactions, one to create the output and the other to invalid-spend it 14:39 < belcher> clean or unclean is in the eye of the beholder, who cares honestly 14:39 < belcher> OP_CHECKMULTISIG has that bug where it pops one extra item off the stack, thats way more unclean but who cares now 14:40 < luke-jr> belcher: in most probability, both Taproot and anti-Taproot would end up on the same chain, just disagreeing over what rules are active 14:40 < belcher> thats impossible, because the flag-day-taproot chain would reject the chain with the invalid spend 14:41 < luke-jr> in fact, I already explained all this on the ML 14:41 < luke-jr> go read it 14:41 < belcher> i did, and i disagreed 14:41 < luke-jr> that just makes you wrong 14:41 < belcher> oh no 14:42 < belcher> anyway, any lurker here can hopefully agree that iv shown that flag day activations cant be used maliciously, because users can create their own counter-flag-day soft fork which intentionally breaks the rule 14:42 < belcher> in the taproot case, adding a invalid taproot spend 14:42 < luke-jr> you haven't shown that 14:43 < belcher> but i understand the concern of course, what if one day core is captured and makes a flag-day-activation soft fork where sending to certain blacklisted coins is not allowed, the community who wants to resist would easily create their own soft fork where the first block after the flag day must pay to one of those addresses 14:44 < maaku> belcher: that was handled poorly. the extra stack item should have been used to indicate which pubkeys were used 14:45 < belcher> TIL 14:47 < maaku> I mean it wasn't used for anything. It was a bug. But while segwit requires that this dummy value be zero, it *should* have been forced to be a bitmask indicating which pubkeys to skip during validation. 14:47 < maaku> Then multisig would be batch validation compatible. 14:50 < maaku> belcher: https://github.com/tradecraftio/tradecraft/pull/25 14:52 -!- bitentrepreneur [2578d1d4@37.120.209.212] has quit [Quit: Connection closed] 15:05 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed] 15:13 -!- jonatack [~jon@37.164.30.247] has quit [Ping timeout: 276 seconds] 15:41 -!- prayank [~Prayank@2409:4053:2e1b:69dd:ad75:b355:dcd:efff] has left ##taproot-activation [] 16:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:59 -!- bob333 [~bob@46.28.204.21] has quit [Ping timeout: 245 seconds] 17:01 -!- bob333 [~bob@46.28.204.21] has joined ##taproot-activation 17:10 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds] 17:10 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation 17:45 -!- guest23024084 [ad441c94@pool-173-68-28-148.nycmny.fios.verizon.net] has quit [Quit: Connection closed] 18:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 18:04 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds] 18:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 18:30 -!- Netsplit *.net <-> *.split quits: jigawatt 18:30 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 18:32 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 18:33 -!- Netsplit over, joins: jigawatt 18:34 -!- takinbo [~takinbo@unaffiliated/takinbo] has quit [Ping timeout: 260 seconds] 18:44 -!- takinbo [~takinbo@unaffiliated/takinbo] has joined ##taproot-activation 18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 19:33 -!- Guest47624 [~pigeons@androzani.sysevolve.com] has quit [Ping timeout: 245 seconds] 19:47 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined ##taproot-activation 19:48 -!- pigeons is now known as Guest74062 20:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 20:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 20:05 -!- Murch [murch@gateway/shell/hashbang/x-vmabeawmbexmblgo] has quit [Ping timeout: 272 seconds] 20:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 20:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds] 20:16 -!- Murch [~murch@gateway/shell/hashbang/x-wlcswajepjogalnc] has joined ##taproot-activation 20:23 -!- occupier [~occupier@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: occupier] 20:40 -!- naribia [6bb5bd25@107.181.189.37] has quit [Quit: Connection closed] 20:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 23:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] 23:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 23:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] --- Log closed Wed Mar 03 00:00:45 2021