--- Log opened Wed Mar 03 00:00:45 2021
00:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation
00:22 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]
00:22 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation
00:42 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
00:43 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:33 -!- Mitantar [59226263@89.34.98.99] has joined ##taproot-activation
01:35 -!- Mitantar [59226263@89.34.98.99] has left ##taproot-activation []
01:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:10 -!- belcher_ is now known as belcher
02:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
04:10 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 256 seconds]
04:12 -!- DigDug [~toshiba@ool-44c6b39a.dyn.optonline.net] has quit [Remote host closed the connection]
04:32 -!- hsjoberg [~hsjoberg@c-0ec672d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation
04:36 -!- hsjoberg [~hsjoberg@c-0ec672d5.445-1-64736c11.bbcust.telenor.se] has quit [Remote host closed the connection]
04:39 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
04:48 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
04:53 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
04:56 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
05:19 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
05:22 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
05:22 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
05:24 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
05:35 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
05:35 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
05:38 < roconnor> michaelfolkson: Regarding PR 19573, isn't it important for Core to follow up a LOT=false with a LOT=true 6 months later (after the LOT=false upgrade proceeds normally).
05:38 < roconnor> s/./?
05:39 < roconnor> Basically I'm reiterating Rubin's comments.
05:40 <@michaelfolkson> I guess two things. Firstly Core could release LOT=true 6 months later despite there being no LOT=true code in the LOT=false release 6 months previous
05:41 <@michaelfolkson> And secondly I just don't think they will :)
05:41 < roconnor> Really?
05:41 <@michaelfolkson> I think any LOT=true release will need to be non-Core
05:42 <@michaelfolkson> We get in the same situation as SegWit if miners fail to activate
05:42 <@michaelfolkson> Core doesn't release LOT=true and UASF people are described as reckless and encouraged to wait out the year
05:42 < roconnor> I was under the impression that LOT=true after LOT=false was generally considered okay by developers, but I haven't been paying as much attention as you have been.
05:42 -!- realname192 [~real@37.160.29.171] has joined ##taproot-activation
05:43 <@michaelfolkson> I don't want to keep putting pressure on individuals because everyone can have their own view without being hounded. But Matt for one would be against. It sounds like Suhas would be too
05:44 <@michaelfolkson> I think part of the F7 argument is that Core maybe shouldn't ever release something that will definitely activate
05:45 < roconnor> Well, a separate PR adding Core support for LOT=true can be in the works.  Core will have like 6 months to reconsider.
05:45 <@michaelfolkson> It can. I expect it won't be merged but I could be wrong
05:46 < roconnor> I kinda think that Core should support LOT=true in the following release even if Taproot is activated. :D
05:49 <@michaelfolkson> It is hard because I agree with Luke in that getting consensus on this potentially means the code in releases is inferior. But there's no getting round that. The bar for consensus on Core is high
05:52 < roconnor> Anyhow, splitting 19573 into two PRs doesn't seem terrible, and I guess it seems helpful for some people, so it is probably a good idea.
05:53 <@michaelfolkson> Right, agreed
05:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
06:05 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:07 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
06:11 -!- realname192 [~real@37.160.29.171] has quit [Quit: Leaving]
06:15 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
06:16 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Client Quit]
06:16 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
06:17 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
06:19 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Client Quit]
06:19 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
06:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
06:27 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 246 seconds]
06:28 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
06:42 -!- jonatack_ [~jon@37.172.59.183] has joined ##taproot-activation
06:42 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
06:44 -!- jonatack_ [~jon@37.172.59.183] has quit [Client Quit]
06:46 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
06:46 < belcher> Making the case for flag day activation of taproot - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018538.html
06:48 < belcher> bip8 is clearly dead, luke doesnt like compares LOT=false and compares it to having an inflation bug that we trust miners not exploit, many core devs and others dont like LOT=true... we need something else and i think flag day activation will be the proposal many can get behind
06:48 < belcher> the "users first", permissionless types who prefer LOT=true will like that flag day activation takes activation out of the hands of miners
06:49 < belcher> the "safe, secure and conservative" crowd who like LOT=false will like that flag day activation can be made safe without being vulnerable to social media blitz
06:49 < belcher> also on reddit https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/
06:50 < nickler> belcher: in what way can it be made safe?
06:51 < belcher> nickler its not vulnerable to social media drama which ends up in brinksmanship and a game of chicken... if someone doesnt blink in that game then we get a chain split which puts the $1 trillion value that the network protects at risk
06:52 < belcher> i write in the email, the bitcoin reddits were targetted by bots, sockpuppets and brigading back during the block size drama, so its not just a theoretical concern
06:52 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
06:52 < nickler> oh seeing your email just now
06:53 < belcher> for actually getting it adopted, its made safe in the same way as other soft forks, we ask bitcoin users if they agree same as we did for segwit
06:53 < belcher> also the flag day can be enough in the future
06:54 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
06:58 < nickler> what makes it safer than lot=true except longer timeout?
07:00 < belcher> much more resistant to social media drama. Twitter and reddit drama provide a perfect cover for social attacks on bitcoin.
07:00 < belcher> with any kind of miner activation including LOT=true its possible to try to speed up activation, and to an observer of the drama (like a big exchange or mining pool) they dont know when the new rules are actually activating, and if they get it wrong we get a damaging chain split
07:01 < belcher> nothing like that is possible with flag day, you cant use drama to make regular nodes out there follow you, if someone wants to follow you they have to actually download and run your alternative node software
07:02 < aj> belcher: i think social media drama can target anything, personally. we had all the Classic, Unlimited, ABC/etc forks for a while; we'll just get them again if someone wants to play silly games and win stupid prizes
07:02 < belcher> right but they failed
07:02 < belcher> we cant wish them away, we can only design our systems to be resistant to them
07:03 < aj> belcher: they caused a bunch of stress at the time; Unlimited got to the point where chain split tokens were made, i think
07:03 < belcher> people who disagreed with bip148 saw that as a social media attack which succeeded, it put the network at a greater risk than they were comfortable with, sure it all turned out okay... this time
07:04 < aj> belcher: (i'm just saying, i don't think there's an anti-(social media drama) silver-bullet)
07:04 < belcher> for sure
07:05 < belcher> in the case of BU and the other forks, once we got lightning and other ways of making cheap transactions the social forces underlying the forks mostly disappeared... if someone was mad at high fees now we can just tell them to use LN
07:05 < aj> also, (as i just posted to the list) running the numbers, matt's proposed flag day seems like it's the same as the proposed bip8 lot=true forced activation height
07:06 < belcher> cool, though i wouldnt bank on that, a few months longer or shorter wont make a difference in the long term... taproot has already taken ages
07:07 < nickler> I don't see how in a lot=true/false world encouraging nodes to upgrade would be drama. You need to do the same for a flag day release.
07:07 < belcher> aj interesting way of derisking, having miner signalling which has no consensus effect
07:09 < belcher> nickler the argument is much weaker for a flag day: "Taproot would activate in ~18 months, so why are you so impatient that you need it in 6 months?"
07:10 < belcher> the big difference with bip148 is that people *had to* run some other node, otherwise they'd get no soft fork at all... and bitcoin core 0.13.1 was already deployed and was being run by loads of big exchanges, so trying to force signalling had a strong effect because the economy would follow you, even though that economy didnt sign up for forced signalling
07:11 < belcher> this effect of making nodes follow you even though they didnt sign up for a UASF is what makes any kind of MASF really controversial right now (im not saying i agree or disagree, but we need the agreement of people like that if we're to get taproot activated)
07:12 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
07:12 < nickler> belcher: to what action is "so why are you so impatient" a response?
07:12 < aj> 85% of hashpower (in a 2.3 day period; 87% over a 4.6 day period) signed up for forced-signalling via bip-91 though
07:12 < belcher> nickler i dont understand your question?
07:15 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
07:16 < aj> nickler: "encouraging other people to run uasf code that doesn't meet some high standard of quality"
07:17 < belcher> oh right
07:17 < nickler> ah
07:17 < aj> nickler: eg, "hey lot=true code hasn't been merged, here's a python script that simulates it by calling invalidateblock, haven't tested it, but probably works!" eg
07:17 < aj> too many egs, but hey that's how you make an omelette
07:18 < belcher> if theres social media drama trying to convince people to run some alt-client which activates the flag day in 6 months instead of 18 months, then the counter-argument could easily be "why are you so impatient" and i think a lot of people would find that convincing... they'll get taproot either way and this way has better code review / lower risk
07:21 < nickler> but with lot=true by default there wouldn't be an alt-client to run, and the same argument about "it'll activate in 18 months anyway" can be made
07:21 < roconnor> Seems premature to declare BIP8 dead.
07:22 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
07:23 < belcher> nickler many people disagree with lot=true though
07:23 < belcher> roconnor luke and a few others really dont like LOT=false, and many others dont like LOT=true... to me it looks like bip8 is dead then because LOT needs to be something
07:23 < roconnor> wait what?
07:24 < nickler> belcher: sorry for maybe going in circles, but wouldn't they disagree with flag day for the same reasons?
07:24 < roconnor> Too be clear I'm in favour of anything that activates taproot, including LOT=false and even a flag day.
07:24 < belcher> who would disagree nickler ?
07:24 < roconnor> The most compelling arguments against LOT=true apply to the flag day activation too.
07:24 < nickler> belcher: the people who disagree with lot=true
07:25 < roconnor> AFAICT flag day activation is strictly worse that a LOT=true on the same timeline.
07:25 < belcher> no i dont think they will, in fact flag day activation was proposed by bluematt who expressed some of the strongest disagreement with lot=true
07:26 < belcher> their problem isnt with a UASF, but with the miner activated part that ends up vulnerable to social media drama
07:27 < roconnor> I'm not convinced that is a fair attribution. Most of the arguments around LOT=true that I've heard have been around the optics of developer control and chainsplit risks due to not having miner support.
07:27 < aj> so the flag-day-and-not-before thing has an interesting property: lightning guys (and the like) could be ready to deploy wallets on the day it activates -- there's no uncertainty about it, they've got plenty of time to implement stuff, and there's a deadline they can plan publicity for...
07:27 < nickler> lot=true by default wouldn't have the social media drama you describe above either. The only difference seems to be the "lost hashpower" argument which isn't convincing to me because what is hashpower worth if it doesn't enforce the rules.
07:28 < roconnor> aj: again, a property that LOT=true has.
07:28 < roconnor> (sort of)
07:29 < aj> roconnor: no, lot=true would likely have activation happen at some unpredictable time well before then
07:29 < roconnor> but they would still have a deadline they can plan around it being known to be activated afterwards.
07:29 < belcher> roconnor to be fair, LOT=false creates optics that the miners control bitcoin... and we can derisk the miner support problem by asking pools (90% of hash rate has already said it supports taproot so this part seems easy)
07:30 < aj> roconnor: sorry, i meant more as a "let's hold a conference on the day it activates and do coordinated launches" publicity event style things
07:30 < belcher> aj like the reward halvening, i used that analogy in the email
07:30 < aj> roconnor: not as a "i can start work without worrying i'll be wasting my time" which is also an issue and one that lot=true solves
07:30 < roconnor> look, I'm not convinced by the arguments against LOT=true, but I am mostly convinced that we could rally enough support around LOT=false to get taproot activated.
07:31 < aj> roconnor: (i 85% agree)
07:31 < belcher> roconnor i initially prefered LOT=false too, but its obvious enough people disagree with it, did you read luke's email
07:31 <@michaelfolkson> I'm going to sit this out as I think it is just degenerating into egos game by now in search of the philosopher's stone.
07:31 < belcher> "LOT=False is dangerous and shouldn't be used" he says, he compares it to adding an inflation bug into bitcoin
07:31 <@michaelfolkson> But F7 applies to flag day https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
07:32 < belcher> michaelfolkson fair enough but LOT=false creates the impression that miners control bitcoin
07:32 < belcher> whoever does the final step can be accused of "really" controlling bitcoin
07:32 < belcher> in reality we all know the economy which uses full nodes controls the protocol
07:33 < roconnor> [02-16 02:46:58 pm] <luke-jr> anything other than LOT=true would be a mistake IMO, but probably not fatal; I'm not up for repeating 2017 though, so if we do LOT=false and it turns into a mess, LOT=false people can fix it <.<
07:33 < darosior> belcher: how so ? I don't think it's a fair attribution
07:33 < belcher> dated 16th feburary, then on 28th feburary he posted his "LOT=False is dangerous and shouldn't be used", seems like he changed his mind
07:33 < roconnor> I can work with a "probaly not fatal mistake"
07:33 < aj>                      06:45 <luke-jr> LOT=False is harmful                                            06:45 <luke-jr> best if it isn't released or used by anyone
07:33 < darosior> Miner can't control the implementation of the activation logic on clients..
07:34 < belcher> darosior of course i know, but the worry is about the *perception* even if its wrong
07:34 < roconnor> "best if"
07:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
07:34 < aj> ohoh someone's ears were burning
07:35 -!- pinheadmz [~pinheadmz@hns-contributor.dev] has joined ##taproot-activation
07:35 <@michaelfolkson> It is more than that. It is like a game of pass the parcel or pass the hot potato. F7 encourages another pass or two rather than Core pushing a release that definitely activates
07:36 < belcher> michaelfolkson yep
07:36 < roconnor> Notwithstanding luke-jr objections, and to be clear I'm not dismissing them, I'm just not convinced, I still think LOT=false can get support for Core merging.
07:37 < darosior> belcher: i'm not sure it's wise to worry about perceptions as there are many of them, but arguably one reality: having the activation logic in the hand of developers and the trigger in the hand of miners seems a better separation of control than everything in the hand of developers, in addition to being more appropriated (developers are more able
07:37 < darosior> to review the activation logic and miners to trigger it)
07:37 < nickler> belcher: I don't like arguing about perception but the perception that devs control bitcoin is a lot worse than miners control bitcoin.
07:38 < belcher> nickler what do you think of this? "Getting mining pools, businesses and users to look at the code and ask if they (a) think its either neutral or good for their business or use case and (b) they believe others view it similarly and that the consensus changes proposed have a good social consensus around them."
07:38 < belcher> back in 2017 for segwit we had this: https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
07:38 < belcher> a big list of businesses and wallets which supported segwit
07:38 < belcher> really big names in there: bitgo, bitstamp, kraken, localbitcoins... so it easy to refute the idea that core devs on their own were pushing segwit
07:39 < roconnor> even if the concerns of perception around developer control are misguided, that doesn't make LOT=false unacceptable.
07:40 < belcher> have you read luke-jr's email roconnor ?
07:41 < roconnor> yes.  I'm not convinced.
07:41 < nickler> cough cough "rough consensus"
07:42 < roconnor> AFAICT luke-jr's comments apply perpetually to any group interested in doing any soft-fork at anytime, which can happen whenever and isn't specific to BIP8 or taproot.
07:43 < roconnor> And to be clear, I think LOT=false should be followed up with LOT=true after a normal upgrade has happened.
07:43 < nickler> belcher: I do think it would be interesting to explore a process proving overwhelming support etc. for future softforks that'd allow Core to release lot=true
07:44 < roconnor> which further mitgates concerns about LOT=false.
07:44 < belcher> if you can get him to change his mind then fine, but if you're implying "just ignore luke" then theres also other people who disagree with deploying BIP8 LOT=false right now
07:44 < luke-jr> roconnor: the reaction is different with and witohut community support
07:44 < belcher> for example bluematt https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html "If the eventual outcome is that different implementations (that have material *transaction processing* userbases, and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not activate Taproot. Seriously."
07:44 < belcher> sdaftuar also has some words on it https://medium.com/@sdaftuar/on-taproot-activation-and-consensus-changes-in-bitcoin-5b3453e91c4e
07:45 < belcher> the "users first, miners shouldnt have control" dont like LOT=false for one set of reasons, the "safety first, lets stay in consensus" people dont like LOT=false for another set of reasons
07:45 < roconnor> Core not deploying taproot won't prevent different implementations.  If anything it is likely to encourage them.
07:45 < luke-jr> roconnor: which is fine
07:45 < luke-jr> other implementations are a good thing
07:46 < roconnor> Yes it is fine, but it isn't a reason not for core to drop taproot.
07:46 < luke-jr> Core should do LOT=True or nothing
07:46 < belcher> ok well you can give that a go in ##uasf if you like, i watched the meeting yesterday and from my point of view i dont think they'll succeed.... if im right and after they fail (~18 months from now), the flag day activation will be available too
07:46 < roconnor> I'm also not a fan of LOT=false, but there is a difference between not being a fan of LOT=false and finding it unacceptable.
07:47 < luke-jr> roconnor: if Core does LOT=False, people will run it thinking they're fine, and it sets a bad precedent
07:47 < belcher> the problem with deploying an alternative implementation is you need to get people to run it... lets say you dont, then when your alt-client activates taproot someone could steal coins in a taproot address and send them to bitstamp or coinbase, they would accept that deposit because they didnt implement your alt-client
07:47 < belcher> this was not true in 2017, because all those exchanges were running bitcoin core 0.13.1
07:47 < luke-jr> if Core does nothing, people will be more likely to run LOT=True, we get several good precedents, a safer network, etc
07:47 < belcher> (core 0.13.1 had miner activation)
07:48 < aj> belcher: (hopefully they were running 0.14 by that time)
07:48 < luke-jr> claims devs control the protocol die off too
07:48 < brg444> if people dont run it how does it even activate belcher that makes no sense
07:48 < belcher> brg444 lot=true activates even if nobody runs it :p
07:48 < brg444> !?
07:49 < aj> belcher: lot=true only activates if >2016 blocks are mined after the lot=true rules kick in
07:49 < belcher> as long as it gets to the timeout block height, as far as the code is concerned it is activated... but if nobody uses that code as their wallet then its not worth anything
07:49 < belcher> i could set up an alt-client which soft forks something that bans payments to certain address blacklists, it will "activate" according to my code, but if nobody runs it then it wont have an effect on the real world
07:49 < luke-jr> timeout + 2016 blocks
07:50 < roconnor> luke-jr: yes, LOT=false is worse, but is it unacceptable?  Or is it just a terrible mistake that probably won't be fatal that the LOT=false people can clean up if it turns into a mess?
07:50 < brg444> precisely so why fud about stolen bitcoins “not in real world”
07:51 < belcher> brg444 you guys spread fud about miner control
07:53 < belcher> fud = facts you dislike, fact is if bitstamp or coinbase dont run your UASF alt-client, and i put coins in a taproot address, a miner could steal my coins and send them to bitstamp or coinbase and they would accept the deposit
07:53 < belcher> or if you dont like bitstamp/coinbase pick anything, bitrefill, localbitcoins, etc
07:53 < belcher> or local OTC trader, anyone who accepts bitcoins
07:53 < belcher> and notice how this didnt apply in 2017, because in 2017 all those people were already runing bitcoin core 0.13.1
07:54 < brg444> belcher: I never said anything about miner control in fact I've argued with luke repeatedly.
07:56 < belcher> fine
07:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
07:58 < brg444> I've chosen to put efforts towards a different implementation because if it is really the case that a single person alone can stonewall rough consensus over an activation decision at Core then the process is broken
07:58 < brg444> And a release valve is needed
07:59 < brg444> I reject considering outcomes in a bubble and the notion that the network requires absolute code consensus on the lot value
08:00 < brg444> Everything indicates miners will activate and in the even that they don't I have no reason to believe the economic majority won't rally around lot=true
08:00 < brg444> s/bubble/vacuum
08:00 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
08:01 < belcher> do you think coinbase.com will adopt your alt-client? because if they dont, anyone who puts money into a taproot address can get it stolen and sold on coinbase
08:01 < belcher> theres your reason why the economic majority wont adopt it
08:02 < belcher> the conditions are different from 2017
08:02 < belcher> i mean you're welcome to try, and flag day activation can maybe be attempted after that, but it would be a shame to lose another year
08:03 < belcher> as for the argument "one person blocking stuff", this is a feature not a bug, bitcoin is resistant to change and thats what protects stuff like the 21 million limit, being hard to change is a good thing
08:03 < roconnor> I don't think one person can block stuff.
08:04 < brg444> roconnor: I certainly hope that's not the case either
08:05 < brg444> see Tao of developement based on IETF rough consensus guidelines I wrote before. Rough consensus is equipped to deal with such disagreement and still move forward
08:06 < brg444> belcher: as for your wife beating question, we did not need coinbase to run bip148 to get our stuff through last time around. And I expect the outcome to be the same, miners will enforce the rules. That does not require network level consensus around lot=true either
08:07 < belcher> brg444 however coinbase enforced segwit, because coinbase was running bitcoin core 0.13.1 which would enforce segwit if miners signalled
08:07 < belcher> this time round coinbase.com will not be enforcing taproot
08:07 < brg444> coinbase will run lot=false
08:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
08:08 < belcher> are you saying they'll be a third alt-client which implements lot=false?
08:08 < belcher> or do you think core will release lot=false?
08:08 < brg444> i'm saying core will implement lot=false. I know luke-jr disagrees but I personally see that as the best outcome.
08:09 < belcher> funny since yesterday you were saying in ##uasf something like "we cant expect core to do anything, we do this without core"
08:09 < belcher> now it turns out your entire plan depends on core releasing lot=false (?)
08:12 < brg444> Don't pull quotes out of context please. I said the project should focus on reviewing the code it's concerned with and not wait for Core to do so because indeed I believe luke's PR to be a dead end. No one wants to touch it.
08:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:14 < brg444> If it is the case though that Core sits on their hand releasing nothing then yes, I am pretty confident that users will run the release and other economic players will have no choice but to do so. Anything else would be a terrible precedent for Bitcoin
08:15 < brg444> You keep harping on an unlikely worst case scenario and don't appreciate the incentives alignment that come with people running LOT+
08:15 < brg444> lot=true
08:16 < brg444> The whole point of this isn't to have it activate through forced signaling. It's a deterrent against malicious behaviour.
08:16 < belcher> it doesnt matter that its unlikely, we have to think in an adversarial way... attacks dont come from dice rolls where likely or unlikely matters
08:17 < belcher> theres nothing that promises that bitcoin must update, remember many people actually welcome ossification so "setting a terrible precedent" doesnt scare them
08:18 < brg444> Well your flag day is its own can of adversarial matter. Anyways, I will copy michaelfolkson and just don't entertain philosophical wax anymore
08:19 < brg444> I'm not gonna be crying over ossification myself
08:19 < brg444> If that's what you want you are doing great stirring the pot right now
08:19 < belcher> earlier you were saying features being blocked is bad, now it turns out you dont care about ossification either? what am i missing
08:20 < belcher> theres nothing bad about philosophy, indeed philosophy of money was required before anyone even thought up creating bitcoin
08:21 < belcher> saying "philosophizing is bad" is basically saying "lets not think"
08:21 < brg444> Here's my take: I think the BIP8 PR @ Core should be withdrawn.
08:21 < brg444> Another PR with code solely focused on lot=false should be made and notwithstanding the inevitable luke NACK, everyone will be better advised by the response to this PR and we'll all get a better sense of where we stand
08:22 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
08:22 < AaronvanW> why not MASF + this flag day at the end? instead of "forcing" miners to signal?
08:22 < brg444> It's bad because in the context where everyone agrees on the outcome, endless bikeshed painting is a massive drain on contributors time
08:23 < belcher> bluematt and sdaftuar will NACK as well you know
08:23 < belcher> probably others, core devs take consensus pretty seriously
08:23 < belcher> bikeshedding is when you debate over useless stuff, this isnt useless its pretty damn important
08:23 < brg444> So all someone has to to do stonewall any future core release is to create an alternate implementation that randomly forks of at some point. Noted
08:24 < belcher> we knew ossification was coming one day
08:24 < belcher> not a future core release, just a soft fork... core can still release stuff as long as it doesnt change the consensus rules
08:25 < brg444> Well, I should point out you are enabling this, for what it's worth. So, I guess let's just focus on our own little venture. You try to get consensus for flag day and I'll see where my effort lead me.
08:27 < belcher> it takes two to tango, disagreement is never one sided
08:28 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
08:29 < aj> belcher: pfft, you've never been in my head
08:29 < belcher> :p
08:30 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
08:30 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
08:31 < brg444> I just prefer to not treat disagreement like vetos
08:31 < brg444> "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated"
08:31 -!- jonatack [~jon@37.172.59.183] has quit [Read error: Connection reset by peer]
08:31 -!- jonatack_ [~jon@37.172.59.183] has joined ##taproot-activation
08:33 < luke-jr> AaronvanW: I already explained the problems iwth that on the ML twice.
08:33 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
08:37 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
08:38 -!- jonatack_ [~jon@37.172.59.183] has quit [Quit: jonatack_]
08:39 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
08:44 -!- jonatack [~jon@37.172.59.183] has joined ##taproot-activation
08:48 < harding> If we're talking about alternative ideas (like a non-signaled flag day), I would like to remind people of one of the proposals we discussed early on: https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see_what_happens.2C_BIP8.28false.2C_3m.29
08:48 < AaronvanW> luke-jr: the argument being that it's not clear if the rules are being enforced or not, right? I don't think that argument holds up for reasons I think were explained by belcher: my node knows which rules its enforcing and that's the important part.
08:50 < AaronvanW> luke-jr: if the argument is that it could lead to unstable situations and reorgs, that's true, but that's also the case for LOT=true. And why miner enforcement is highly preferable. Which MASF+flag day would also facilitate, just like BIP8.
08:58 < waxwing> belcher, "We seem to be at a deadlock now. This will take less time than any other method, because other methods might never happen. BIP8 is dead and from what I see there's no other credible plan." <- really?!
08:58 < waxwing> i mean "really?!" isn't too helpful, i just want to say i strongly disagree with that.
09:01 -!- Netsplit *.net <-> *.split quits: roconnor, nehan, AaronvanW, Murch, criley, raj_149
09:07 -!- Netsplit over, joins: raj_149, AaronvanW, Murch, roconnor, criley, nehan
09:08 -!- generic [~generic@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation
09:08 -!- generic [~generic@195.181.160.175.adsl.inet-telecom.org] has left ##taproot-activation []
09:38 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
09:42 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation
09:45 -!- temp345903485 [9a15d844@154.21.216.68] has quit [Quit: Connection closed]
10:07 < belcher> waxwing from the "safe, conservative" side we've got people NACKing lot=false, they also NACK lot=true.... and from the "users rule, lets be permissionless" side we've got luke saying that LOT=false is dangerous and comparing it to an inflation bug, thats why my reading of the situation is that bip8 is dead
10:08 < belcher> to be clear, the reason the "safe/conservative" NACK lot=false is because they believe it will actually end up as a mixture of false and true because many will be actually running true
10:12 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has joined ##taproot-activation
10:12 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has quit [Client Quit]
10:12 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has joined ##taproot-activation
10:15 -!- mol_ [~mol@unaffiliated/molly] has quit [Remote host closed the connection]
10:15 < stortz> belcher is a mixture of flag day + LOT=true the best "mixed scenario" ? meaning the least amount of possible problems (as far as we know)
10:16 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
10:16 < belcher> stortz what do you mean by a mixture of flag day and lot=true? lot=true is a flag day if MASF didnt activate
10:17 < stortz> meaning core releases a flag day and the UASF releases a core+taproot with lot=true
10:18 < roconnor> How about we actually get a PR before we start counting LOT=false nacks.
10:18 < stortz> I need to read the flag day proposal again -_-
10:19 < roconnor> The idea that we shouldn't run LOT=false because some people might run LOT=true doesn't make any sense.
10:19 < stortz> someone said a PR is in the works, I think it was achow101
10:19 < roconnor> Yep I've heard the same thing.
10:20 < belcher> roconnor i disagree with that, the bitcoin community using a mixture of different consensus rules means there is an unnecessary risk of a chain split
10:21 < roconnor> people who want to run alternative clients are going to do so whether it is LOT=false, LOT=true, segwit or flag day.
10:21 < roconnor> or nothing at all even.
10:22 < stortz> belcher so a flag day client does not conflict with a lot=true release, correct?
10:22 < belcher> roconnor but they'll only harm themselves, they wont be able to harm other people who use LOT=false because it wont be deployed
10:22 < belcher> stortz i hadnt thought of it before but i guess it doesnt conflict
10:23 < belcher> if they had the same dates
10:23 < stortz> alright
10:23 < roconnor> people running alternative clients only harm other users when they are on a minority chain that later reorgs the majority chain.  Running LOT=false vs flag day doesn't change this fact.
10:23 < belcher> i wonder if that could be a solution... core releases flag day and UASF enthusiasts run LOT=true which has the same lock in date as the flag day
10:24 < aj> if that happened, and lot=true activated early, would you trust taproot utxos prior to the flag day?
10:25 < belcher> i wouldnt :p
10:25 < belcher> though i guess i would if most of the economy adopted the alt-client
10:25 < belcher> but thats all ok, if people dont trust it they can just wait until the flag day and use taproot then
10:25 < aj> and what happens if core picks a different signalling method prior to the flag day (eg witness nonce as matt suggests to reduce false signalling), and the main chain doesn't satisfy lot=true's signalling requirements?
10:26 -!- name [49e12c18@c-73-225-44-24.hsd1.wa.comcast.net] has quit [Quit: Connection closed]
10:26 < aj> the whole point of lot=true/lot=false was to make them agree that the rules are active or not for any given chain
10:27 < belcher> aj if the main doesnt doesnt satify the BIP8 signalling requirements but LOT=true then taproot will activate anyway from the point of view of people using the alt-client
10:27 < belcher> main chain*
10:27 < aj> belcher: if the chain doesn't satisfy the signalling requirements lot=true will stall or follow a lower work alternative chain
10:28 < belcher> oh i see what you mean
10:28 < belcher> because lot=true forces signalling
10:28 < belcher> right so they are not compatible right now
10:29 < belcher> if lot=true was modified to not require signalling after the timeout then they would be compatible (but then lot=true clients couldnt make lot=false clients follow them... however thats a moot point since lot=false clients wont exist)
10:34 < luke-jr> the witness nonce idea is interesting, but IMO will have to wait for the SF after Taproot
10:35 < luke-jr> and ultimately it's less important that miners are for sure upgraded, than it is to coordinate users
10:39 < stortz> what is the witness nonce idea?
10:42 < AaronvanW> belcher: "if lot=true was modified to not require signalling after the timeout" <- does it require signaling after the timeout? (why?)
10:43 < AaronvanW> because yes, LOT=true and flag day would be compatible if LOT=true triggers at the beginning of the last signaling period, and flagday triggers right after the last signaling period.
10:43 < AaronvanW> actually no. scrap that.
10:43 < belcher> AaronvanW it does, it seems the aim was that if the ecosystem is mixed between lot=false and lot=true then the consensus rules of lot=true force nodes running lot=false to follow them, and then nodes running lot=false will have the soft fork activated too
10:43 < AaronvanW> belcher: that is still during the signaling period. not after.
10:44 < AaronvanW> iiuc
10:44 < AaronvanW> last two-week difficulty period of the year-long signaling period. (again, iiuc.) (that's how it should work at least, imo.)
10:44 < belcher> hmm yes, theres something fiddly there.... i wonder if you can make them compatible by having the LOT=true timeout be 2016 blocks earlier than the flag day height
10:45 < belcher> then you wouldnt need to modify the LOT=true bip at all
10:45 < AaronvanW> I think that's correct, however, LOT=true might still activate taproot months before flag day.
10:45 < AaronvanW> that would be resolved with MASF+flag day, which I suggested earlier.
10:46 < belcher> thats ok, people who dont trust putting their money into taproot addresses just wouldnt do that until after flag day activation which economic nodes are running
10:47 < belcher> MASF is NACK'd looks like
10:47 < AaronvanW> I still see no benefit in not combining a flag day with MASF first though. (versus only a flag day)
10:47 < belcher> luke is against it and bluematt too (https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpk7772/?context=3)
10:47 < luke-jr> belcher: LOT=true already has MUST_SIGNAL *before* the timeout
10:47 < AaronvanW> well everything is nacked at this point.
10:47 < AaronvanW> so we'd have to convince some nacks to become acks.
10:47 < luke-jr> belcher: I am not against MASF. BIP8(true) is MASF
10:47 < luke-jr> AaronvanW: or ignore some NACKs
10:48 < AaronvanW> sure
10:48 < luke-jr> perhaps Core can't, but the community can
10:48 < belcher> luke-jr what do you think of having BIP8 lot=true with the lock-in date being exactly 2016 blocks (or whatever the right number is) earlier than the flag day activation height
10:48 < belcher> then people running bip8 LOT=true and people running flag day would actually agree
10:48 < belcher> (provided enough of the economy ran either one)
10:50 < luke-jr> belcher: an unsignalled flag day is an attack and very harmful
10:51 < AaronvanW> belcher: my point is that IF you support a flag day, I see no rational reason to not support MASF+flag day.
10:51 < AaronvanW> It has the same benefits, with the added benefit of a much saver MASF option first.
10:52 < belcher> AaronvanW MASF+flag day allows for brinksmanship which puts the network at risk, and people in ##uasf are getting ready to start that kind of brinksmanship so its a credible concern
10:52  * luke-jr looks up wtf "brinksmanship" means
10:53 < belcher> the entire network even people who dont care about taproot have to worry about if they'll be a chain split or not, and someone gets it wrong or doesnt blink in this game of chicken, then the $1 trillion that the bitcoin network protects is at risk
10:53 < luke-jr> that's just FUD
10:53 < aj> i still love that i learned that word after it was said to someone whose last name was Brinkman
10:53 < AaronvanW> belcher: but that's my point, people in ##uasf are *already* doing that, regardless of MASF attempts. The risks don't change. (roconoor also correctly pointed this out imo.)
10:53 < belcher> AaronvanW right but if MASF is not deployed then the ##uasf people cant make other people's nodes who didnt sign up for it follow them
10:54 < AaronvanW> belcher: yes they can. longest chain is all they need, in either case.
10:54 < belcher> no, longest chain means only the miners enforce taproot
10:54 < belcher> so in such an event, if the % enforcing taproot drops below 50% then money stored in taproot addresses could be stolen
10:54 < AaronvanW> longest chain would be followed by both MASF nodes and nothing nodes.
10:55 < belcher> but nothing nodes wouldnt enforce taproot
10:55 < roconnor> AaronvanW's point is that they can cause a disruptive reorg, which appearly is what the safe-and-coservative folks are worried about.
10:56 < roconnor> Not deploying BIP8 LOT=false won't stop this from happening.
10:56 < belcher> miners can always do reorgs if they want
10:57 < roconnor> then the safe-and-convervative folks have nothing new to worry about by doing a LOT=false deployment.
10:57 < belcher> they'll lose money if they disagree with the economy.... the miners serve the economy, and the problem with mixed consensus rules out there is miners wont know how they're best meant to serve
10:57 < luke-jr> roconnor: not deploying anything increases the amount of folks enforcing overall
10:57 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
10:57 < belcher> roconnor they do, in normal situations miners dont attempt reorgs, but in this brinksmanship situation they might do it accidently
10:58 < roconnor> yes but a LOT=false depolyment doesn't change "the situation".
10:58 < belcher> yes it does
10:58 < belcher> LOT=false deployment means a mixture of LOT=true and LOT=false
10:58 < belcher> i.e. mixed consensus rules being enforced out there
10:58 < roconnor> Agian, a mixture of LOT=true and status quo also has a mixture of consusus rules.
10:59 < AaronvanW> belcher: no LOT=false deployment means a mixture between nothing nodes and LOT=true nodes.
10:59 < maybehuman> as someone recently said, false is the "natural" condition in the network, i.e what unupgraded nodes run
10:59 < luke-jr> roconnor: a LOT=false deployment creates confusion among those who do want Taproot
10:59 < maybehuman> so you can't get it completely out of the picture
10:59 < luke-jr> people will upgrade to LOT=False thinking they're getting Taproot
11:00 < maybehuman> and they most probably will
11:00 < luke-jr> without LOT=False in the picture, everyone who wants Taproot will upgrade to LOT=True
11:00 < belcher> roconnor in a mixture of LOT=true and status quo, theres no incentive to engage in brinksmanship, because even if the ##uasf people win they dont actually get taproot.... sure they could force miners to follow them for now but if the hashrate % which enforces it drops below 50% then taproot coins could be stolen
11:00 < AaronvanW> belcher there is a mixture either way. Either 1) LOT=true & LOT=false & nothing, or 2) LOT=true & nothing. Reorg risks are the same.
11:00 < roconnor> everyone who wants to upgrade to LOT=true is going to do so regardless.
11:01 < luke-jr> roconnor: the point is that Taproot implying LOT=true gets higher levels of enforcement
11:01 < luke-jr> because you don't have people who don't know better deciding between LOT based on FUD
11:01 < belcher> <maybehuman> as someone recently said, false is the "natural" condition in the network, i.e what unupgraded nodes run <---- disagree, lot=false means that those nodes will *enforce* taproot if the miner signalling gets high enough, unupgraded nodes dont do this
11:01 < roconnor> which is why Core should follow up LOT=false with LOT=true.
11:01 < luke-jr> it shouldn't
11:01 < luke-jr> people who want Taproot should run LOT=True
11:01 < belcher> roconnor LOT=false has no consensus, as you see luke-jr doesnt want it and also bluematt doesnt want it
11:02 < roconnor> Sorry, I mean I mean "if" Core deploys LOT=false it should folow up with LOT=true.
11:02 < belcher> thats a big if
11:02 < luke-jr> roconnor: that's pointless
11:02 < belcher> its basically saying "if everyone agreed then core would deploy and it would all be fine".... yeah if everyone agreed
11:02 < luke-jr> can just release LOT=True from the start to reduce confusion, peering issues, etc
11:03 < maybehuman> luke-jr "people who want Taproot should run LOT=True" <= maybe people who don't want it but don't mind it either can run lot false?
11:03 < luke-jr> there's no value in a LOT=False that gets superceded before LOT matters
11:03 < roconnor> belcher: I still think you are making too big of a deal about Matt and Luke-jr's disagreements.
11:03 < luke-jr> maybehuman: even if they don't care about Taproot, presumably they care about being secure, which LOT=False isn't
11:03 < luke-jr> if they didn't care about being secure, they would run a light wallet
11:04 < belcher> roconnor maybe, i guess we'll see if/when the PRs appear on github if they ever do.... but i can only take them at face value by what they write on the ML or other places
11:04 < belcher> <AaronvanW> belcher there is a mixture either way. Either 1) LOT=true & LOT=false & nothing, or 2) LOT=true & nothing. Reorg risks are the same. <----- the reorg risk is not the same because in the LOT=true & nothing case there is no incentive for brinksmanship
11:05 < belcher> brinksmanship = holding a hand granade saying "do what i want or ill blow us all up"
11:05 < AaronvanW> belcher: why wouldn't there be an incentive for brinkmanship?
11:05 < luke-jr> belcher: there's no brinksmanship in LOT=True at all; that's LOT=False
11:05 < belcher> AaronvanW because even if the LOT=true people succeed in making miners signal, they dont actually get taproot because theres no LOT=false nodes to take notice of the miner signalling
11:06 < belcher> luke-jr so lets avoid LOT=false?
11:06 < luke-jr> belcher: except everyone is running LOT=True ;)
11:06 < AaronvanW> belcher: they do get Taproot... at least on their own nodes.
11:06 < luke-jr> belcher: yes, I agree with the conclusion that LOT=False should not be deployed
11:06 < belcher> if everyone really was running it i would be happy
11:06 < belcher> AaronvanW i mean i can recode my own node to show me that i own 21 billion bitcoins... its pointless if its only my node
11:07 < AaronvanW> belcher: but wasn't that your argument for flag day in the first place? *your node* knows that it activated and will treat it as such.
11:07 < belcher> AaronvanW my node _and_ people i trade with, so there'd be list of taproot adoptors like there was for segwit adoptors
11:08 < AaronvanW> belcher: but is that really an argument against brinkmanship? ##uasf doesn't seem to think so.
11:09 < belcher> sorry i dont understand your question
11:12 < AaronvanW> I think your argument is that a LOT=true UASF would only be effective if it would cause disruption if miners don't comply. Is this correct?
11:15 < belcher> thats right i think, the point of LOT=true is that they will not accept blocks unless miners signal
11:17 < AaronvanW> do you agree that a LOT=true UASF could cause disruption now? without LOT=false clients on the network at all?
11:18 < luke-jr> nah, the point of LOT=true is that miners don't get a choice whether to comply or not
11:18 < belcher> yes, i think a LOT=true UASF wont do much disruption now
11:19 < AaronvanW> belcher: why?
11:19 < belcher> because it wont be adopted much
11:19 < AaronvanW> luke-jr: miners can be too late to upgrade, and then switch to cause a reorg, causing reorgs and disruption for non-upgraded nodes.
11:20 < AaronvanW> belcher: and you think LOT=true UASF will be adopted more if there are also LOT=false clients?
11:21 < belcher> yes, because theres more of an incentive to adopt them, because if you win then the whole of bitcoin gets taproot
11:22 < AaronvanW> ok then I see your point now.
11:22 < luke-jr> AaronvanW: if miners are too late, they can false signal. it's not like they actually use the real signal ever anyway
11:22 < belcher> if LOT=false doesnt exist then if you win you only get taproot for yourself
11:23 < luke-jr> unless the majority upgrades to LOT=True/Taproot, which is the point
11:23 < AaronvanW> belcher: yourself and other LOT=true users, and LOT=false+flagday users when the flag day is there.
11:23 < luke-jr> I suppose a compatible point
11:23 < AaronvanW> but yeah I see your point and will think about it a bit.
11:23 < belcher> AaronvanW yep, but thats the same as saying "flag day will activate taproot"
11:23 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
11:23 < luke-jr> so LOT=False takes away from LOT=True usage, and also encourages LOT=True usage paradoxically
11:25 < luke-jr> anyway..
11:25 < luke-jr> I just posted on reddit to Matt, suggesting the idea of inverted signal during MUST_SIGNAL
11:25 < luke-jr> what do you think?
11:25 < luke-jr> that is, during the last period before timeout, the signal is bit2=0 instead of bit2=1
11:26 < luke-jr> thus, ignorant miners will mine signalling blocks automatically
11:26 < luke-jr> I think this might satisfy anti-LOT=True folks
11:26 < luke-jr> the tradeoff is there cannot be a UASF to move the date forward
11:27 < luke-jr> but IMO that loss is worth it if we can get consensus
11:27 < belcher> that could be good, because i think some of the disagreement about lot=true was a fear of a "social media drama" moving the date forward
11:30 < luke-jr> belcher: so it might not even be a tradeoff you're saying XD
11:31 < belcher> ill have to think some more
11:31 < belcher> so it would work that in the period before timeout, even LOT=false nodes would start to enforce taproot if bip2 was zeros?
11:34 < luke-jr> if LOT=False existed, which it still shouldn't
11:34 < belcher> right
11:35 < luke-jr> an anti-Taproot SF would then simply say at least 10%+1 blocks must set bit2=1 for that period
11:40 < belcher> <luke-jr> the tradeoff is there cannot be a UASF to move the date forward <---- how does this work? i just realized i dont understand it, whats to stop a UASF requiring that miners signal in (say) the second signalling period
11:40 < luke-jr> hmm
11:40 < belcher> i mean a bip148-style UASF, which just requires that miners signal bits in the block version
11:40 < luke-jr> ok, so an early UASF simply wouldn't invert it
11:40 < luke-jr> ok, so it's not really lost
11:41 < luke-jr> if we do it, we just lose the inversion benefit
11:45 < yanmaani> why hardcode LOT=true/false? Why couldn't you make it user-configurable, and let LOT=xxxx just be a default?
11:45 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
11:45 < luke-jr> yanmaani: because LOT=False is dangerous and should never be used..
11:46 < belcher> yanmaani why dont we allow users to configure the 21 million supply limit too? having user-configuration of consensus rules seems silly
11:46 < yanmaani> Yeah, but you are going to be able to create alternative clients.
11:47 < belcher> what do you mean?
11:47 < yanmaani> So, the reckoning is that you'll do LOT=true, and people won't dissent because they would have to fork everything.
11:47 < yanmaani> This seems true, but unfortunate. You would want for people to have a choice in that.
11:47 < aj> luke-jr: if you actually believe lot=false is harmful and should never be used, you should remove it from bip8 and not propose support for it via a pr
11:48 < stortz> he regrets including it
11:49 < belcher> yanmaani so you'd give people a choice but you know what the correct choice already is? and if they choose the wrong choice they get harmed
11:49 < belcher> why would anyone add an option to their software which harms users?
11:49 < belcher> if they want a choice they dont need to upgrade
11:49 < yanmaani> belcher: They might want to upgrade for other (non-taproot) reasons.
11:51 < aj> stortz: some regrets you can't do anything about; a BIP that you're the author of and an unmerged PR? easy to do something about those.
11:53 < yanmaani> for example, they might want mundane bug fixes or such. You said that LOT=true prevents a "social media blitz". But that seems like a bad thing, to me. If people are tricked into not wanting it, they still don't want it, and anything that prevents them from doing anything to stop it seems immoral.
11:57 < belcher> yanmaani for some reason your email (which i can see on the website) hasnt gotten to my mailbox, so i cant easily reply
11:57 < belcher> pretty weird
11:57 < yanmaani> belcher: might be in spam
11:57 < belcher> nope, checked that
11:58 < yanmaani> cause I don't think the ML sends to the target, cause you CC the list right?
11:58 < belcher> yeah something like that
11:59 < belcher> i wonder if i can just copypaste your email into my mail client and send that... hopefully the mailing list wont do something weird because of that
11:59 -!- jonatack_ [~jon@37.170.222.46] has joined ##taproot-activation
11:59 < yanmaani> if I respond to your email, I send to you and the list, but you don't get it twice right. so it must be a spam filter?
11:59 < yanmaani> belcher: I think you can import the mail
12:03 -!- jonatack [~jon@37.172.59.183] has quit [Ping timeout: 260 seconds]
12:04 < yanmaani> belcher: save this https://pastebin.com/exk9jKas as whatever.eml and open in your mail client, then click "reply all"
12:05 < AaronvanW> could be an issue with the email list, something like this happened before.
12:06 < yanmaani> AaronvanW: pretty sure it's not, cause direct replies to your messages aren't delivered by mailman
12:26 < belcher> thanks for the help yanmaani looks like i got it
12:27 < yanmaani> cool
12:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
12:35 < AaronvanW> belcher: don't you think MASF+flagday would in itself be a good enough reason not to do a LOT=true UASF?
12:36 < belcher> me personally? sure, though from what iv seen plenty of people out there like in the ##uasf channel would go for a LOT=true UASF regardless
12:37 < belcher> hold on... whats the difference between MASF+flagday and LOT=true?
12:37 < roconnor> lack of MUST_SIGNAL
12:37 < AaronvanW> yep
12:37 < belcher> right
12:37 < AaronvanW> at best, you'd speed up activation by days. at worst, you fork yourself off the network.
12:37 < belcher> MASF seems to still be vulnerable to social media attacks that incentivize brinksmanship
12:37 < AaronvanW> If we want to disincentivize brinkmanship, wouldn't that do the trick?
12:38 < belcher> if MASF nodes are adopted out there, it means a group of UASF people could trick them into following a UASF even if the MASF nodes didnt sign up for that
12:38 < belcher> if the UASF is successful they make the whole network adopt the soft fork, not just themselves
12:39 < AaronvanW> so that would be an even earlier UASF, right?
12:39 < AaronvanW> not a UASF at timeout, but a UASF after a few months.
12:39 < belcher> yes
12:40 < yanmaani> Doesn't a "social media attack" basically mean "changing what people want"?
12:40 < belcher> yanmaani the problem happens when a small group is able to make a larger group do what it wants even though the larger group didnt sign up to it
12:40 < belcher> in bitcoin we want entities to represent themselves
12:40 < roconnor> how are mast nodes tricked?  the are signed up to enforce rules when miners signal their readyness.
12:41 < belcher> roconnor they didnt sign up being at risk of a chain split if the brinksmanship didnt succeed
12:41 < yanmaani> belcher: Yeah, but what if the larger group is tricked into signing up for it by the smaller group?
12:41 < roconnor> are you sure they didn't sign up for that?
12:41 < roconnor> miners don't need a UASF to start orphaning each other's blocks.
12:41 < yanmaani> If the smaller group spreads clever propaganda to trick the large group into wanting (doing) something they didn't use to want, how's that distinguishable from the large group having bad preferences from the beginning?
12:42 < belcher> roconnor true they dont, but they dont have an incentive to either
12:43 < roconnor> depends on how valueable the miners thing the soft-forked chain coins are.
12:43 < AaronvanW> I think belcher's concern is more about non-upgraded nodes than about LOT=false nodes. (is that correct?)
12:43 < belcher> yanmaani the problem is brinksmanship
12:43 < belcher> holding a granade saying "ill blow us all up if you dont do what i want"
12:43 < belcher> thats only possible because of MASF nodes out there enforcing rules
12:44 < belcher> social media sockpuppets and bots are a symptom, they happen because the incentive is there
12:44 < yanmaani> belcher: Wait, can you explain this further?
12:44 < belcher> yanmaani were you around during 2017 in the segwit UASF?
12:44 < yanmaani> Would the miners do the brinkmanship?
12:44 < yanmaani> on the periphery. Some miners wanted bigger blocks and blocked segwit as something vaguely resembling revenge.
12:45 < belcher> right, and then a UASF movement scared those miners into giving up
12:45 < roconnor> we don't actually know that.
12:46 < yanmaani> So, my point is that you can't distinguish between someone opposing something for good reasons and for bad reasons.
12:46 < belcher> they way that UASF movement worked was it essentially threatened to cause lots of damage, and the miners would lose more money so they gave up.... but the problem was that everyone in the community had to take notice
12:47 < belcher> yanmaani read this https://bitcoinmagazine.com/business/op-ed-user-activated-soft-forks-and-intolerant-minority
12:47 < yanmaani> Seems reasonable. Where are you going with this?
12:47 < belcher> it explains the strategy
12:47 < belcher> if the threat is "ill got a granade and ill blow us all up unless you do what i want", then i want no part of it this time, because i dont want my bitcoins to be blown up
12:47 < roconnor> I'm still not really convinced that the LOT=false nodes are relevent for that strategy.
12:48 < yanmaani> Yeah, unless you get a competing UASF that forces the opposite. Then you have two intolerant minorities and someone ends up getting hurt in the end.
12:48 < belcher> yanmaani yeah, a so-called counter-UASF
12:49 < roconnor> A UASF movement can happen without LOT=false and the threated damage seem more or less idential to me.
12:49 < belcher> roconnor if there were no LOT=false nodes out there and if the UASF movement won, then it would have only enforced segwit for itself, basically wouldnt be able to do much
12:49 < belcher> for a UASF movement to win without LOT=false nodes being deployed, they basically need to convince almost evreyone in the bitcoin community, not just an intolerant minority, and thats a much higher bar
12:50 < belcher> much higher bar means its safer
12:50 < roconnor> if the UASF movement won then miners would be enforcing segwit on all blocks right?
12:50 < AaronvanW> belcher fwiw I think that intolerant minority article actually didn't get into the brinkmanship part very much, but I did try to explain it myself at the time: https://bitcoinmagazine.com/technical/op-ed-heres-why-all-rational-miners-will-activate-segwit-though-bip148
12:50 < belcher> roconnor miners dont enforce segwit
12:50 < yanmaani> So it seems like there's a bit of a contradiction there belcher
12:50 < AaronvanW> (intolerant minority is still interesting though.)
12:50 < yanmaani> "in bitcoin we want entities to represent themselves"
12:50 < belcher> roconnor if miners enforced segwit, then if the % of enforcing miners dropped below 50% then miners could steal your segwit coins
12:50 < belcher> AaronvanW good point
12:51 < yanmaani> If so, wouldn't it be unethical to have Core representing them? Wouldn't it be better to build everything in (UASF, counter-UASF, LOT=false, true, the whole 9 yards), and then let every node set it for themselves?
12:51 < roconnor> belcher: I mean, if UASF won then miners would only build on blocks with valid taproot spends, or rather would refuse to build on blocks with invalid taproot spends.
12:51 < belcher> roconnor right, but in that case UASF winning means basically every node has to update, not just a small minority
12:51 < AaronvanW> there was also this one by nicolas dorier: https://medium.com/@nicolasdorier/love-or-hate-it-but-do-not-ignore-it-52f8dd3c72e9
12:51 < belcher> yanmaani maybe they could build in a switch for changing the 21 million limit too
12:52 < roconnor> right, but this happens regardless of the existance of LOT=false.
12:52 < yanmaani> belcher: Is that really relevant? There's no demand for that, but it seems like you have people against this.
12:52 < yanmaani> (not sure who. "The Australian"?)
12:54 < yanmaani> I guess it depends on what your goal is. If your goal is to get Taproot, LOT=true makes total sense. If your goal is to get what people want, I do not think it does.
12:55 < belcher> roconnor no you're missing the important point again, if LOT=false nodes have been deployed then they will also enforce the new soft fork... so LOT=false nodes become part of the UASF movement even though they didnt sign up to taking that risk
12:55 < belcher> yanmaani are you suggesting people dont want taproot?
12:56 < roconnor> I don't think your characterization of "become part of the UASF movement" is fair.
12:56 < yanmaani> belcher: Basically, yes. There has to be some people against it. If not, literally anything would work.
12:56 < belcher> roconnor it is fair because without the LOT=false nodes the UASF movement becomes much harder to make successful
12:56 < belcher> essentially the LOT=false nodes got tricked into making bitcoin take a big risk, that wasnt made clear in the software (which is ultimately why its being opposed this time round)
12:57 < belcher> yanmaani point me to people who are against taproot
12:57 < roconnor> but if the UASF movmenet is ignored the only damage they do is to themselves. and this is the case whether or not LOT=false nodes exist or not.
12:57 < belcher> credible arguments not just fud like that guy who runs a surveillance company
12:57 < roconnor> so the UASF damage threat isn't a function of the LOT=false nodes.
12:57 < belcher> roconnor thats a big if, remember theres the brinksmanship going on
12:58 < yanmaani> belcher: None. I do not know any. I don't think the Australian's opposition is FUD.
12:58 < roconnor> well if the threat isn't ignored then taproot activates.
12:58 < yanmaani> He opposes it because it harms his business interests. The business interests deserve to die, but his opposition is sincere.
12:58 < roconnor> or if the threat is ignored and they active taproot regardless.
12:58 < belcher> yanmaani well if you dont know anyone against taproot then kindly stop suggesting there are people, its just irrelevant at this point
12:58 < yanmaani> Since he is a small minority, we ought to ignore him, but we ought to ignore him by having him lose the battle, not by forcing it regardless.
12:59 < yanmaani> belcher: Are you saying "nobody at all" or "an insignificant number"?
12:59 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:59 < belcher> if there was a credible reason why taproot is bad we would have heard it by now, or if you know of a reason you can send it to the mailing list
12:59 < belcher> right now you're just suggesting that someone, somewhere, doesnt like taproot but you cant tell me whats bad about it
13:00 < yanmaani> belcher: It harms the surveillance companies. That's bad for the surveillance companies; they are harmed by it.
13:00 < AaronvanW> roconnor: I think belcher's point (iiuc) is that a LOT=true movement would take a bigger risk of ending up on a majority chain if there are no LOT=false nodes, then *after* activation, miners could "switch back" to a chain without Taproot. If there are also LOT=false nodes, switching back becomes impossible. (Am I saying this rich, belcher?)
13:00 < roconnor> belcher: I guess what would be helpful would be tell me two sequence of events that occur in two worlds, one with LOT=true going it alone, and one with LOT=true in combination with LOT=false, and this is what happens and see how the outcome is worse becase of the existence of the LOT=false nodes.
13:00 < belcher> AaronvanW yes i think thats right
13:00 < AaronvanW> *ending up on a minority chain
13:00 < yanmaani> They are a tiny minority, and I do not like them, but they are opposed to it. So are you saying literally nobody opposes it, or almost nobody?
13:01 < roconnor> okay this is helpful. Let me digest that.
13:02 < AaronvanW> Soto repeat without typo: I think belcher's point (iiuc) is that a LOT=true movement would take a bigger risk of ending up on a MINORITY chain if there are no LOT=false nodes, then *after* activation, miners could "switch back" to a chain without Taproot. If there are also LOT=false nodes, switching back becomes impossible
13:02 < belcher> importantly, if LOT=false nodes (or any MASF nodes) were widely adopted in the economy
13:02 < AaronvanW> yes
13:02 < belcher> so taking the concrete example of segwit, see this list https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
13:03 < belcher> we had big names like localbitcoins, kraken, bitgo, bitstamp, etc saying they run code which implements a MASF
13:03 < belcher> turned out they also provided a massive incentive to try brinksmanship
13:03 < belcher> those big names didnt sign up for that, they were promised a low-risk update
13:03 < AaronvanW> my counter-argument though would be that if there are lots of MASF+flagday nodes on the network, that is ALSO a big disincentive against doing a UASF. Because the flagday guarantees activation anyways.
13:04 < AaronvanW> I don't know which disincentive is stronger.
13:04 < belcher> right, hmm
13:04 < AaronvanW> plus you have the benefit of a potential normal MASF, which is nice and safe.
13:04 < AaronvanW> and fast
13:04 < belcher> the disincentive is basically that argument "why are you so impatient? we'll get taproot in 18 months why are you rushing to get it in 6 months?"
13:05 < AaronvanW> yeah, or you could say 12 instead of 18. whatever.
13:06 < AaronvanW> LOT=true is currently aiming for 12. so at least the current LOT=true proponents shouldn't be aiming for an even faster UASF if there is MASF+flagday after 12 months.
13:07 < roconnor> ship it!
13:07 < roconnor> :)
13:10 < belcher> AaronvanW for MAST+flag day to be safe we'd have to know that nobody is planning push for a UASF that speeds it up
13:11 < AaronvanW> belcher: yeah, you can never *know* that. you can only strongly disincentivzize that. but I think the same is true for flag day without MASF.
13:11 < belcher> right now we have no indication anyone would try that, assuming MASF+flag day is the same thing as LOT=true and therefore all the ##uasf people would jump onto MASF+flag day
13:11 < belcher> its not exactly the same because forced signalling isnt possible in a flag day activation
13:11 < belcher> but yes similar i agree
13:12 < AaronvanW> forced signaling is still possible, it just wouldn't drag false nodes along. but that's ONLY an advantage in that it would take away the incentive to even try. which MASF+flagday would also do.
13:16 < _andrewtoth_> For those asking about anyone against Taproot https://twitter.com/nikzh/status/1332246112196063232
13:16 < belcher> yeah thats the guy i was thinking of who runs a surveillance company
13:16 < belcher> if we dont get taproot because a surveillance company doesnt like it, i think ill take the risk and join a UASF movement myself
13:16 < _andrewtoth_> Ahh ok I thought you were talking about The Australian
13:16 < _andrewtoth_> I don't find the arguments convincing btw
13:33 -!- Netsplit *.net <-> *.split quits: sword_smith, bsm117532, hugohn, qubenix, rodarmor
13:34 -!- Netsplit over, joins: qubenix, bsm117532, hugohn, rodarmor, sword_smith
13:36 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
13:38 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
13:42 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
13:46 < yanmaani> belcher: It could be a surveillance company, but it's still someone expressing an opinion. LOT=true basically ignores these minorities regardless of how big or how just their concerns are. That is not right.
13:46 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 264 seconds]
13:47 < belcher> why have you come in here fighting for the rights of surveillance company? who cares about them lol
13:48 < yanmaani> because any system that can be used to ignore a (evil) minority, can also be used to ignore a (good) minority.
13:49 < yanmaani> I do not think it is just to use Core's weight in this way. If the surveillance company itself is the economic minority, sure
13:50 < roconnor> fortunately in that particular case, their concerns have been considered and I think most people agree that the long-term privacy benfits outweigh any short-term impact, which appears very small.
13:50 < yanmaani> But if the surveillance company is tricking other people through social media, it's not longer only the surveillance companies opposing the change...
13:50 < roconnor> However, people who are concerned about that issue should avoid taproot at first.
13:50 < yanmaani> roconnor: considered, by whom?
13:50 < roconnor> well I did at least.
13:51 < mol_> yanmaani, iirc Nikita Zhavoronkov has always been an opponent to any improvement of bitcoin
13:51 < roconnor> I think it was discussed on reddit and twitter.
13:51 < yanmaani> Whatever system you have to override the illegitimate will of the people (i.e. gained through subterfuge) seems like it could also be used to override the legitimate will of the people (i.e. gained through honest, good-faith reasoning). "Let's ignore the surveillance companies because they're only 0.01%" = already done with MASF. "Let's ignore 10% of real users because they might have been
13:51 < yanmaani> tricked on social media" = evil
13:52 < roconnor> there are a certain group of people who are using complex multisigs who currently have almost zero-privacy whose privacy would be immediately improved by taproot.
13:52 < roconnor> And that seed is enough to snowball a larger taproot "anonymity set".
13:53 < yanmaani> roconnor: Right, you can't brush aside people's concerns by saying "I looked at it and it's not true". They still have concerns.
13:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
13:53 < roconnor> Agreed.  I don't think that is what happened here.
13:58 < yanmaani> It seems like what Belcher's saying? "Since there's no legitimate opposition to Taproot, we should force it through"
13:58 < yanmaani> "Since all the people who oppose us are wrong, we would do good to ignore them"
13:59 < belcher> yanmaani we're not talking about ignoring social media users, rather flag day stops them having an incentive to engage in brinksmanship
14:00 < yanmaani> belcher: What do you mean would be the difference?
14:07 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]
14:10 < mol_> yanmaani, i hope you are aware there're plenty of trolls in the bitcoin world
14:11 < mol_> you think their concerns are your concerns while actually they're just "trolling concerns"
14:11 < yanmaani> mol_: If they're just shitposting, that won't be a problem.
14:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
14:18 < yanmaani> but if they convince people, those people cannot be ignored
16:00 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
16:04 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
16:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
16:41 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
16:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
16:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
16:55 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
16:59 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
17:08 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
17:10 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
17:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 276 seconds]
17:25 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Ping timeout: 245 seconds]
18:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
18:29 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:32 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
19:03 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds]
19:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
19:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
19:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
19:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
19:34 -!- emzy [~quassel@unaffiliated/emzy] has quit [Ping timeout: 272 seconds]
19:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:43 -!- emzy [~quassel@2a01:4f8:192:628a::83] has joined ##taproot-activation
20:03 -!- drolmer [~drolmer@unaffiliated/drolmer] has quit [Ping timeout: 246 seconds]
20:15 -!- drolmer [~drolmer@unaffiliated/drolmer] has joined ##taproot-activation
20:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
20:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
20:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
21:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
22:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
23:40 -!- jonatack_ [~jon@37.170.222.46] has quit [Ping timeout: 260 seconds]
--- Log closed Thu Mar 04 00:00:46 2021