--- Log opened Fri Feb 12 00:00:27 2021
01:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:39 -!- belcher_ is now known as belcher
02:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
02:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:09 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:7c3a:c9c7:c1a3:9e77] has quit [Read error: Connection reset by peer]
03:29 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
03:30 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:30 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 240 seconds]
03:33 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation
03:53 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:20 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
04:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:47 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
05:09 -!- commmon [~common@unaffiliated/common] has quit [Remote host closed the connection]
05:09 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
05:17 -!- Murch [murch@gateway/shell/hashbang/x-hnduywbopvlelqpr] has quit [K-Lined]
06:45 -!- jonatack [~jon@37.169.23.248] has joined ##taproot-activation
07:15 -!- CARO2 [~Cesar@2804:7f4:c19d:f7fa:bdc8:d47e:8c15:d22a] has joined ##taproot-activation
07:19 <@michaelfolkson> Transcript of Matt Corallo on TFTC podcast discussing UASF and Taproot activation: https://diyhpl.us/wiki/transcripts/tftc-podcast/2021-02-11-matt-corallo-taproot-activation/
07:29 < luke-jr> from the start it sounds like FUD
07:37 < luke-jr> ironic Matt decries history rewriting, then goes on to try to rewrite it
07:39 < luke-jr> "[BIP148's success] is obviously a little wrong because to my knowledge no pool or materially sized transactor ever run that code" <-- this is worth calling out specifically; miners don't decide the protocol of course
07:40 < luke-jr> and the latter part is simply false
07:44 < luke-jr> "One Bitcoin node forking off from the rest of the network and finding other peers to connect to that are on its fork is not a solved problem in the codebase at all." <-- it was solved in the UASF fork, and in Knots
07:50 < luke-jr> Literally nobody is suggesting a straight UASF/flag day like Matt is ranting about..
07:52 < luke-jr> "I think the latest terminology you might see is BIP 8(true) which is just a flag day, there are some other technical features but it is largely a flag day activation"
07:52 < luke-jr> except it isn't.
07:52 < luke-jr> it's pretty much still a MASF, just without the veto bug
07:59 < luke-jr> in other updates, only 15% updated to 0.21 so far :/
08:07 < luke-jr> I wonder if Matt is intentionally spreading disinformation and FUD, or maybe he just really doesn't understand what BIP8(true) is
08:16 -!- viaj3ro [1f114650@31.17.70.80] has joined ##taproot-activation
08:17 -!- viaj3ro [1f114650@31.17.70.80] has quit [Client Quit]
08:17 <@michaelfolkson> The history is only relevant for how it informs this Taproot discussion
08:18 <@michaelfolkson> I've said above "Using a rushed, chaotic UASF in 2017 as a reason not to do a measured 1 year long MASF with the so called UASF only kicking in at the end of that year I don't think is a fair comparison"
08:19 -!- viaj3ro-[SilentB [1f114650@31.17.70.80] has joined ##taproot-activation
08:19 <@michaelfolkson> I personally think he's wrong but people can be wrong with good intentions
08:20 < viaj3ro-[SilentB> is this cxhat being logged? if yes, where can I read the logs?
08:20 <@michaelfolkson> http://gnusha.org/taproot-activation/
08:21 < viaj3ro-[SilentB> thanks
08:32 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
08:33 < maybehuman> luke-jr: So in your view, a soft fork is kind of a foregone conclusion in the sense that once it's merged if it doesn't activate, that indicates a bug?
08:36 < luke-jr> maybehuman: an activation's purpose is to activate. if it doesn't, then it is a bug, yes..
08:36 < luke-jr> especially if the reason it doesn't, isn't a logical reason
08:36 < luke-jr> (ie, letting miners arbitrarily decide not to allow it)
08:36 < maybehuman> so why have a lot parameter at all in the bip then?
08:40 < maybehuman> re "allow it": ppl here say all the time it's not voting but coordination. So threshhold not reached would then mean coordination failed. But lot=true treats it like succeeded, it's kind of weird if you look at it that way
08:41 < maybehuman> Silly analogy: The plane's landing procedure failed, but we still allow passengers to disembark
08:41 < luke-jr> that's the point: allowing miners to block it makes it voting
08:41 < maybehuman> then lot=false is a bug in the bip, no?
08:41 < luke-jr> yes IMO
08:41 < luke-jr> I regret making it an option and implying it was reasonable
08:42 < maybehuman> kind of stranged that you merged it in then, you're the bip editor, right?
08:42 < luke-jr> BIP editor is a very limited role
08:42 <@michaelfolkson> If the BIP 8(3 month) was chosen I think the argument for LOT=false would be stronger
08:42 < luke-jr> what's strange is that I wrote the changes to make LOT an optional thing
08:42 < luke-jr> 3 month UASF is rushed and dangerous
08:43 <@michaelfolkson> That's my point. If "Let's see what happens" was chosen for a future soft fork you may want LOT=false
08:43 < luke-jr> if there's too much opposition to 1 year LOT=true, then 2 year LOT=true is better than 1 year LOT=false
08:43 < maybehuman> so maybe open a PR against the BIP to clarify, might also be another venue for gathering feedback
08:43 < luke-jr> "Let's see what happens" is not reasonable
08:43 <@michaelfolkson> It was an option that had some (limited) support
08:44 <@michaelfolkson> It wasn't my first choice
08:44 <@michaelfolkson> The point is we have to offer flexibility for future soft fork activations even if we think it is stupid for this one
08:44 < luke-jr> I'm not sure it ever makes sense
08:44 <@michaelfolkson> Ever is a strong word
08:44 < maybehuman> out of curiosity: What would happen if only say 20% signal and lot=true kicks in. 80% of hashrate would just have to suck it?
08:44 < luke-jr> counter example?
08:45 < luke-jr> maybehuman: or that 20% becomes 100%
08:45 < luke-jr> maybehuman: it's no different than if they decided to claim 50 BTC subsidies
08:46 < luke-jr> activation isn't there to get miners' permission
08:46 < maybehuman> and you don't think the former 80% (which are then 400% compared to the miners) would tr to cause some trouble?
08:46 < luke-jr> maybehuman: whether they do or don't, isn't relevant
08:46 < maybehuman> well, chainsplits were mentioned as an argument I think
08:47 < luke-jr> LOT=true has no chain splits. Miners might intentionally induce one as an attack, but that's something they can do with or without a change.
08:47 < nothingmuch> luke-jr: do you think LOT=false is appropriate for soft forks which might have downsides for users? (e.g. something like segwit's effective capacity increase)
08:47 < maybehuman> yes, but losing their job would be eytra motivation
08:48 < luke-jr> nothingmuch: no; either it should or should not activate. There is no case where it should activate only based on miners' judgement
08:48 < nothingmuch> (assuming it is configurable, just re the default value)
08:48 < luke-jr> maybehuman: nobody is firing them
08:48 < luke-jr> maybehuman: they're welcome to continue mining Bitcoin
08:49 < maybehuman> "they brought this on themselves"
08:50 < luke-jr> ?
08:50 < luke-jr> they're not being stopped from mining at all\
08:50 < luke-jr> if they choose to stop mining, that's literally their own action
08:51 < maybehuman> yes, you're arguing more around logical definitions, I'm looking at the emotional (for lack of a better word) aspect
08:52 < maybehuman> It's not like you can assume people are perfectly rational
08:54 < maybehuman> but again, if you are convinced that lot=false is wrong in all cases, open a PR to remove it from the bip. Then this discussion won't ever have to happen again
08:56 < maybehuman> but going a bit further, what is the value of signalling/masf at all in this scenario? Only to speed it up a little? In the end you could also say "this will activate in X blocks, see that you're ready". Would simplifiy the activation mechanism even more
08:59 < luke-jr> yes, to speed it up
09:00 < maybehuman> btw, is the opposite scenario a concern? i.e. miners activating it before a sufficient number of nodes has updated?
09:01 <@michaelfolkson> It is a soft fork, nodes won't be forked off the network if they don't update
09:01 < maybehuman> but they donÄt fully validate
09:02 <@michaelfolkson> It is recommended to update as they won't be doing full validation on Taproot transactions but they will continue to validate non Taproot transactions
09:02 < maybehuman> luke-jr I think that's a bit where the hangup is for me: On the one hand we say "we need x% to activate safely" and at the same time we say after a while "oh well, we didn't get the numbers, but we're going ahead anyway"
09:03 < luke-jr> maybehuman: we don't need x% to activate safely
09:03 < luke-jr> we need x% *of the economy* to activate safely
09:03 < luke-jr> PLUS
09:03 < maybehuman> which we can't measure, right?
09:04 <@michaelfolkson> If it is exclusively for readiness we can't tell when exactly miners will be ready
09:04 < luke-jr> y% *of miners* to protect the 100-x% of the economy
09:04 < luke-jr> OR
09:04 < luke-jr> ~100% of the economy
09:04 <@michaelfolkson> We can say 1 year is more than enough time to get ready though
09:04 < luke-jr> ie: (85% of economy + 85% of hashrate) || (99% of economy)
09:05 < luke-jr> startheight is intended to be when we expect 85% of the economy is ready
09:05 < luke-jr> timeoutheight is intended to be when we expect 99% of the economy is ready
09:07 < maybehuman> I think all of this should be in the bip's motivation section. Right now that only contains explanations why bip9 was bad
09:07 < maybehuman> but again, % of economy will always be a guess, right?
09:07 < luke-jr> yes
09:08 < luke-jr> an educated guess hopefully
09:08 < maybehuman> that's the advantage of miner signalling btw, it's a hard number. I think that's why people kind of cling to it (perhaps irrationally :-))
09:10 < luke-jr> but it's not a relevant hard number
09:10 < maybehuman> relecant for your calculation above apparently
09:10 < luke-jr> not by itself
09:12 < maybehuman> ok, so the view is that the oneline explanation of bip8 should be somethig like "This activates a softfork after X blocks. Alternatively, it can be activated sooner by Y% of hashrate"?
09:13 < luke-jr> I guess
09:13 < luke-jr> perhaps "within X-Y blocks"
09:13 < maybehuman> like I said, the bip should be updated then
09:14 < luke-jr> in the middle of a dispute isn't the time to do it
09:15 < luke-jr> after Taproot gets released with LOT=true would make sense
09:16 < maybehuman> but that's what the dispute is about, no?
09:17 < maybehuman> also, isn't there some policy against substantially changing bips that are used "in the field". I feel like there should be
09:17 < luke-jr> yes, but LOT=false isn't used in the field, and hopefully never will be
09:18 < luke-jr> hmm, an example where LOT=false *might* make sense: a softfork smoothing out the subsidy to be more gradual
09:18 < luke-jr> that *could* possibly be simply put to miner vote
09:27 < maybehuman> not sure what makes that case so special
09:28 < maybehuman> changing the inflation schedule affects the rest of the economy, too
09:28 -!- Murch [murch@gateway/shell/hashbang/x-vmabeawmbexmblgo] has joined ##taproot-activation
09:29 < maybehuman> and taproot affects miner's revenues by reducing fees
09:32 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
09:34 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
09:35 <@michaelfolkson> To get rid of an option within a generalized activation mechanism you need to be 100 percent sure it will never be needed
09:36 <@michaelfolkson> We can't predict anything about the future especially if you go 2, 5, 10 years out
09:36 <@michaelfolkson> As I said in a BIP 8(3 month) false makes more sense to me than true
09:37 < maybehuman> hard to see a plausible scenario for that though
09:37 <@michaelfolkson> The onus isn't on me to convince you it will be needed
09:37 < maybehuman> "we want this really quick, but if not, we forget about it"
09:37 <@michaelfolkson> The onus is on you to convince me it will never ever be needed
09:38 <@michaelfolkson> You are claiming it will never ever be needed
09:38 <@michaelfolkson> Quite the claim
09:38 < maybehuman> I mean I still like lot=false better fwiw, I'm just trying to see the other side of the argument
09:38 < luke-jr> michaelfolkson: why would 3 months ever make sense?
09:39 <@michaelfolkson> I don't know. I can't tell the future
09:40 < luke-jr> I suppose a softfork that only effects for 3 months
09:40 <@michaelfolkson> If you are considering getting rid of that option entirely you are saying you know for certain it will never be needed in Bitcoin's entire lifetime
09:40 < luke-jr> but even then LOT=true is harmless
09:40 <@michaelfolkson> I am saying I don't think it will ever be needed but the option shouldn't be deleted
09:41 < maybehuman> if the consensus is on true, I would say yagni on false. If something unforseen comes up, you can always wrtie a new bip
09:42 <@michaelfolkson> There's no point in writing new BIPs because you removed flexibility in an old BIP
09:44 < maybehuman> if I'm not mistaken, bip8 is still unused. So we're talking about adding unused functionality because in some unknown future, someone might use it
09:45 <@michaelfolkson> The aim isn't to have a new activation BIP used every time there is a soft fork
09:46 <@michaelfolkson> We're designing BIP 8 so it can hopefully be used for future soft forks
09:46 < maybehuman> (not sure if everyone is familiar with yagni, so just to be on the safe side: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
09:47 <@michaelfolkson> Maybe future soft forks will choose to use something else. But at least we can leave them a BIP with flexibility that was used on Taproot
09:48 <@michaelfolkson> We are having practically an entire meeting to discuss LOT being true or false. To say any decision made from that meeting should be binding on future soft forks is dumb
09:49 < maybehuman> some might say leaving an unused and untested mechanism in a spec is dumb
09:50 <@michaelfolkson> LOT is set to true, works, and suddenly we know for certain that it will work best for all future soft forks based on a sample size of 1?
09:51 < maybehuman> probably you won't even see if lot=true works, because the masf kicks in first
09:51 <@michaelfolkson> Yup sample size of zero in that case
09:51 <@michaelfolkson> Either way small sample size
09:53 <@michaelfolkson> You have to have epistemic humility with these things especially when you can't predict the future
09:53 < maybehuman> again, this is exactly the same thing the yagni people say
09:54 < luke-jr> michaelfolkson: we also still need to address signalling start, and specific heights, etc :p
09:54 <@michaelfolkson> We do. Maybe it will be famous last words but I don't think those will take long to discuss
09:54 < luke-jr> sample size 1 because BIP148 already happened ;)
09:54 <@michaelfolkson> Ha ok
09:56 <@michaelfolkson> On the yagni thing, there is a difference between providing a user feature that no one will use versus allowing future soft forks the freedom to make their own minds up on the right activation mechanism
09:56 < maybehuman> they will make up their own minds anyway
09:56 <@michaelfolkson> So why make them need a new BIP if they make a different decision to us?
09:57 <@michaelfolkson> Just makes no sense
09:57 < maybehuman> well, the new bip is for them to make, should the need arise
09:58 < maybehuman> if we can't see why lot=false could be useful, it would be sheer luck if it captures their use case in its current form
09:59 <@michaelfolkson> We are only giving our personal opinions on it here. I don't know what people will say in the meeting. And I definitely don't know what people will say when discussing the next soft fork
09:59 <@michaelfolkson> I would NACK getting rid of lot=false option for future soft forks
10:00 < maybehuman> let's hope you don't condemn future softforkers to repeat the same true/false discussion every time then
10:00 <@michaelfolkson> They have to have that discussion, hopefully they won't need a whole meeting on it...
10:00 < maybehuman> at least it would be nice if the bip could give some guidance on when which setting might be appropriate
10:01 < luke-jr> there's also the option to elaborate in the BIP that LOT=true should be the default and why
10:01 <@michaelfolkson> I'd be happy with that
10:01 < maybehuman> yes, that would help
10:01 <@michaelfolkson> Assuming LOT=true is chosen this time and it works fine
10:02 < luke-jr> I'm 100% certain it can work fine
10:02 <@michaelfolkson> Again 100 percent is a strong statement. There is very little I am 100 percent sure on.
10:03 <@michaelfolkson> We are trying to pick the optimal option between LOT=true and LOT=false
10:03 <@michaelfolkson> We aren't saying either of them is 100 percent going to be fine, merely which is optimal
10:04 < luke-jr> michaelfolkson: "not a doubt"? :P
10:05 < maybehuman> to be fair, he wrote *can* work, not *will* work :-)
10:05 <@michaelfolkson> Ha
10:05 <@michaelfolkson> I can only imagine how certain people were of things going into 2017 and look how that turned out
10:06 < luke-jr> maybehuman: well, I would have said *will* except it's uncertain if we use it
10:06 < maybehuman> yeah, I'm still waiting for the multiple parallel softforks we were promised back then
10:06 < luke-jr> michaelfolkson: BIP148 was basically the case of "everything that can go wrong did" and it still worked fine
10:07 <@michaelfolkson> There is always more that can go wrong ;)
10:07 < luke-jr> I mean in setup
10:08 < luke-jr> it was rushed, no preparations, Core refused to release it even with community support, etc
10:08 <@michaelfolkson> Ok gotcha
10:09 < maybehuman> so if we land on true and core refuses, can we just auto-propose false as a fallback then?
10:09 < maybehuman> just to get things rolling
10:09 < maybehuman> and people can still set true if they want to on their own nodes
10:09 < luke-jr> maybehuman: if Core acts maliciously, it makes more sense to just roll a Bitcoin Core Taproot release
10:09 <@michaelfolkson> I'm not involved then so I'll sit out that discussion
10:10 < luke-jr> michaelfolkson: ?
10:10 < maybehuman> michaelfolkson I mean the proposal to Core should then be "We'd like you to set true, but if you won't pls set to false and leave the rest of the parameters as proposed"
10:11 <@michaelfolkson> I want to propose something after the meeting and the code review. If that proposal fails for whatever reason I think someone else should pick this up
10:11 < luke-jr> maybehuman: the proposal we make, is proposed to the community, not Core
10:11 < maybehuman> ok, now I'm confused
10:12 <@michaelfolkson> We propose something on the mailing list to the community but theoretically and/or practically Core could refuse to implement it or merge it
10:12 < maybehuman> I thought proposal would be something that gets either sent as a PR or is brought up in a core meeting?
10:12 < maybehuman> oh, ok. Must have missed that part
10:12 <@michaelfolkson> Just an email to the mailing list (community)
10:12 < luke-jr> maybehuman: There will be a Core PR, but the actual decision needs to be the community
10:13 < maybehuman> so basically the proposal just means the discussion is moved from chat to email?
10:13 <@michaelfolkson> Well we've tried to frontload all the discussion on this channel
10:13 < luke-jr> hopefully at that point it's simply a matter of the community saying ACK or NACK collectively
10:13 < luke-jr> should get the discussions done here before that
10:16 < maybehuman> not trying to sound snarky, but you really think that will happen? That the mailing list subscribers will just say yes or no?
10:17 < luke-jr> it's not the subscribers who matter, but the community as a whole
10:18 < maybehuman> will the proposal include a concrete startheight or some relative offset (like X blocks after release)?
10:19 <@michaelfolkson> We present all of these conversation logs, the meeting minutes, the developer survey, the mining pool feedback etc etc. By that point it should effectively be a formality. If it turns out not to be a formality then I guess we're back at square one
10:19 <@michaelfolkson> Yeah all activation parameters should be proposed
10:19 < luke-jr> maybehuman: I think it should be concrete
10:19 < luke-jr> maybehuman: something that translates directly to a PR
10:20 < maybehuman> ok, so at least there's some time limit for discussions
10:20 < luke-jr> I intend to propose July 4th startheight
10:20 < maybehuman> I can see the memes already..
10:20 < luke-jr> XD
10:21 < luke-jr> this results in activation being approx the same time that maintenence ends for 0.20
10:21 < luke-jr> (assuming miners signal immed)
10:24 <@michaelfolkson> And presumably you're happy with 95 percent threshold?
10:25 <@michaelfolkson> July 4th sounds good to me too
10:26 < maybehuman> ok, so the way it will probably play out is that lot=X is proposed to the mailing list and/or community, a correspondig PR is opened and someone in the lot=Y camp will open a competing PR with the opposite setting, and then Core will have to pick which one to merge, right?
10:27 < luke-jr> michaelfolkson: I don't care about threshold so long as it's between 85-95
10:27 <@michaelfolkson> Well this channel is here to avoid that
10:27 < luke-jr> michaelfolkson: 55-85 is IMO on the table, but needs serious thought
10:28 <@michaelfolkson> Sure anyone is free to open a PR doing anything to Core but (hopefully) only one PR will match what we propose on the mailing list
10:28 < luke-jr> if we're talking <85%, I think it will need a dedicated meeting
10:28 < maybehuman> for lot=true it should be pretty high I'd say (if only for optics)
10:28 < luke-jr> why?
10:29 <@michaelfolkson> I don't think there's consensus for below 90 from reading developer survey
10:29 < maybehuman> because it's less people you'd have to kick out if push comes to shove
10:29 < luke-jr> huh?
10:29 < luke-jr> LOT and MASF threshold are exclusive scenarios
10:29 <@michaelfolkson> Yeah threshold only matters for the MASF
10:30 <@michaelfolkson> UASF only happens at the end of the year if the threshold hasn't been reached
10:30 < luke-jr> if anything LOT=true makes a lower threshold more rational since it's going to lock in either way
10:30 < luke-jr> could do 6 months at 95% and 6 months at 90%, but then the code gets complicated a bit more
10:31 <@michaelfolkson> Yeah I think easiest path for consensus is to go with a simple 95 percent
10:31 < maybehuman> I mean the scenario for the flag day is that there is an uncooperative minority that stalls it, right?
10:31 < maybehuman> which would have to be 6% at least at 95 threshhold
10:31 < maybehuman> 16 at 85
10:32 < maybehuman> so it would be more people you'd have to kick out
10:32 <@michaelfolkson> But those 6 or 16 percent don't get "kicked out". They can still choose to signal during forced signaling
10:32 < maybehuman> but I might be missing something
10:32 < maybehuman> yesyes, I'm just talking worst case
10:32 <@michaelfolkson> It is just that they chose not to activate it before the end of the year
10:33 <@michaelfolkson> No kicking out. Just how high bar needed for miner activation to happen before the end of the year
10:33 < maybehuman> well, they do get kicked out eventually, that's the point, no?
10:33 <@michaelfolkson> They get "kicked out" if they don't signal during forced signaling (under lot=true)
10:34 < maybehuman> exactly
10:34 <@michaelfolkson> But they could choose not to activate early and still signal during forced signaling
10:34 <@michaelfolkson> They aren't "punished" for not activating before forced signaling
10:34 < maybehuman> of course. It's just that it's hanging over their head
10:35 <@michaelfolkson> It is their prerogative to not activate early if that is what they choose
10:35 <@michaelfolkson> Hopefully they will choose to activate early
10:35 < luke-jr> don't agree
10:35 < maybehuman> so they do get a vote after all in the sense that they can vote to postpone it :-)
10:35 <@michaelfolkson> Something they have pledged support for is "hanging over their head"
10:35 < luke-jr> choosing to stall isn't an acceptable action for miners either
10:36 <@michaelfolkson> We are giving them the option to
10:36 < luke-jr> we're giving them the option to coordinate on their schedule; but not giving them the option to not-coordinate
10:37 <@michaelfolkson> Not according to the BIP. Maybe that is your expectation
10:37 < luke-jr> with LOT=true
10:37 <@michaelfolkson> They have the option to not activate until the end of the year
10:37 <@michaelfolkson> with LOT=true yes
10:37 < maybehuman> but that is really only semantics. By their actions it will activate sooner or it will activate later
10:38 <@michaelfolkson> We hope they don't use that option of delaying a year. But it is a possibility
10:38 < luke-jr> the scheduling is for scheduling, not delaying
10:39 -!- jonatack [~jon@37.169.23.248] has quit [Ping timeout: 256 seconds]
10:40 < luke-jr> delaying would be an abuse, not prerogative
10:40 < maybehuman> you give them a year. What they do with it you can't really influence
10:40 <@michaelfolkson> We can request that they don't use the full year without a rationale
10:41 <@michaelfolkson> They can refuse to follow that request under BIP 8
10:41 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
10:43 <@michaelfolkson> Maybe that should be included in the proposal to the mailing list. That under this proposal we expect miners to activate before the end of the year but signaling is only enforced at the end of the year (under lot=true)
10:43 < luke-jr> michaelfolkson: they can, but that's abuse, not prerogative
10:43 <@michaelfolkson> Ok agreed. I take that wording back
10:43 < luke-jr> (prerogative implies they aren't abdicating their job)
10:44 <@michaelfolkson> I think abuse is too strong but prerogative isn't right
10:46 < CubicEarth> I have only been casually following this process, but I don't see the value in 95%. Why allow 5% hashpower to veto? Honestly I'd prefer 85%.
10:46 < CubicEarth> Or perhaps I should sat 'stall' instead of veto
10:47 <@michaelfolkson> To avoid a meeting on threshold percentage ;)
10:47 <@michaelfolkson> Consensus from developer survey was 90 or 95
10:47 <@michaelfolkson> Precedence from SegWit was 95
10:48 < CubicEarth> Ug.
10:48 < maybehuman> that's another reason why the threshhold should be lower on lot=false, because it gives more power (veto vs stall)
10:48 < CubicEarth> The difference is a factor of 2. Are we going to allow 5% to stall the process, or do we demand at least 10%
10:48 <@michaelfolkson> We're up to 90 percent of mining pools pledging support for Taproot
10:48 <@michaelfolkson> 10 percent haven't responded last time I checked
10:49 < CubicEarth> We shouldn't even talk about "miners"... we are talking about anyone or any organization who can buy or rent ASICs equal to 5% of the total.\
10:49 <@michaelfolkson> My preference would be 90 based on that but I'm thinking a whole meeting on threshold would be overkill
10:50 < maybehuman> CubicEarth well, if they run those asics, they're miners by defintion, no?
10:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:50 < CubicEarth> I don't think so
10:50 <@michaelfolkson> All hash rate is equal
10:50 < CubicEarth> In one sense
10:51 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 240 seconds]
10:51 <@michaelfolkson> If you have 5 percent you have 5 percent to activate early or delay
10:52 < luke-jr> michaelfolkson: I only expect a whole meeting on threshold to be necessary if discussing <85%
10:52 < luke-jr> 90% I think would just be okay or not
10:52 < CubicEarth> 85% 90% 95% or 99.99% - those all encompass the concept of "a substantial, overwhelming majority"
10:52 < luke-jr> CubicEarth: not necessarily overwhelming at 85-90%
10:52 < luke-jr> remember mining has variance
10:52 < luke-jr> 85% is just a "clear majority"
10:53 < CubicEarth> But when you look at the percents on the other side -  00.01%, 5%, 10% or 15% -  those have very different meanings in this context about the cost to let some anonymous entity try to harm the process here
10:53 -!- jonatack [~jon@37.169.23.248] has joined ##taproot-activation
10:53 <@michaelfolkson> I don't want to get into the discussion of how we define overwhelming majority and clear majority :)
10:53 <@michaelfolkson> Definitely won't get overwhelming consensus on how to define those
10:55 < CubicEarth> My point is... at any of these levels... we should be thinking about the percent needed to block / stall / interfere, rather than the percent needed to approve
10:55 <@michaelfolkson> But it is a bit finger in the air and less scientific. In which case we go with conservative and consensus building option
10:56 <@michaelfolkson> Which appears to me to be 90 or 95
10:57 < maybehuman> so let's say some subset of miners have some technical issue which prevents them from signalling quickly. Could the others exploit that by reaching the the threshhold super fast, causing their competition to get kicked off?
10:58 <@michaelfolkson> You misunderstand the kicking off. Again this is a soft fork. They can mine a block with no Taproot transactions in it if they want
10:59 < maybehuman> the must_signal only applies to the flag day?
10:59 <@michaelfolkson> And they accept blocks with Taproot spends in them as anyone can spend
10:59 <@michaelfolkson> Must signal only happens at the end of the year, right
10:59 < maybehuman> ok, got it
11:00 < CubicEarth> michaelfolkson: I hope it ends up being that we make the cost of obstruction at least 10%
11:00 < luke-jr> maybehuman: to kick off the miners who failed to upgrade, someone first needs to make an invalid block
11:01 <@michaelfolkson> CubicEarth: 10 would be my personal preference. But 5 is a distinct possibility
11:01 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Remote host closed the connection]
11:02 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has joined ##taproot-activation
11:03 <@michaelfolkson> "And they accept blocks with Taproot spends in them as anyone can spend" Just to be clear here only the Taproot spends in the block are treated as anyone can spend. Non Taproot spends are fully verified
11:03 < CubicEarth> I am also just encouraging the consistent framing of the matter as the cost to "DOS" the upgrade mechanism
11:04 <@michaelfolkson> Right. Come to the meeting and encourage that framing :)
11:05 < CubicEarth> Can I write a bot to attend on my behalf?
11:07 < maybehuman> I'm beginning to wonder if I misunderstood the lot=true mechanism all along
11:08 < maybehuman> skimming the bip, must_signal is when blocks by non-signalling miners are discarded, right?
11:08 < maybehuman> once it's active, there's no must_signal anymore, is there?
11:09 -!- viaj3ro-[SilentB [1f114650@31.17.70.80] has quit [Quit: Connection closed]
11:09 < maybehuman> and the non-signallers could rejoin, or am I missing something?
11:12 < luke-jr> correct
11:13 < maybehuman> oh ok, then it's a temporary suspension rather than a perma-ban. That's not so bad
11:17 < maybehuman> still not super nice, but at least it'll make the affected a lot less likely to reach for their pitchforks
11:18 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ilnpppfafwrqpnib] has joined ##taproot-activation
11:19 <@michaelfolkson> CubicEarth: I am happy to be that bot and put forward that framing
11:19 < CubicEarth> :)
11:19 < maybehuman> You guys should definitely mention that when someone brings up miners, that their worst case is 2 weeks revenue loss
11:20 < CubicEarth> When is the meeting?
11:20 <@michaelfolkson> Tuesday
11:21 <@michaelfolkson> And a year to prepare for that eventuality maybehuman
11:21 <@michaelfolkson> (As the worst case)
11:23 < maybehuman> yes, the 1 year part is obvious
11:33 < nothingmuch> why is MASF threshold a meaningless hard number? with mandatory signalling doesn't that give a fairly strong assurance that the cost of defecting is high in terms of work required to reneg? i agree that it says little about what the economic majority prefers so drawing conclusions about consensus of soft fork from miner signalling is fallacious, but with every additional block during
11:33 < nothingmuch> mandatory signalling the total work required to reorg out actviation increases
11:40 < luke-jr> https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
11:40 < luke-jr> Thoughts on polishing this at the meeting, for publication as the proposal?
11:41 < luke-jr> maybehuman: 2 weeks loss, only by their own choice; even if they don't upgrade, they can still signal
11:48 < luke-jr> (can move it to the Bitcoin Wiki, but for realtime editing, GDocs probably works better)
12:17 <@michaelfolkson> Ah nice work luke-jr
12:18 <@michaelfolkson> Skimmed but will review with greater care soon
12:19 <@michaelfolkson> Double check height numbers etc
12:19 < luke-jr> thanks
12:23 < luke-jr> michaelfolkson: I wonder if it would improve it, to turn your F#s into rationales
12:26 <@michaelfolkson> You mean the Ts? T were arguments for true, F were arguments for false. Yeah I think we should explain the rationale for whatever is chosen on LOT
12:29 < luke-jr> both ☺
12:29 < luke-jr> in the case of the Fs, answers thereto
12:29 <@michaelfolkson> Sure, yeah
12:30 <@michaelfolkson> Oh I see what you mean now, sorry
12:30 <@michaelfolkson> Yeah counterargue the Fs, yeah
12:33 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
13:19 -!- jonatack [~jon@37.169.23.248] has quit [Read error: Connection reset by peer]
13:21 -!- jonatack [~jon@37.169.23.248] has joined ##taproot-activation
13:21 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
13:23 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Client Quit]
13:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
14:36 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
14:39 < maybehuman> One more question: Is it really ok not to require some minimum signalling in the lot=true case? If for whatever reason only 20% signal, then blocks in the must_signal phase would take 50 minutes. Or do we expect that the fee market will somehow take care of this?
14:40 < luke-jr> we do require signalling in the LOT=true case ;)
14:41 < maybehuman> well, there will be only 20% of the hashrate needed for the difficulty, right?
14:43 < luke-jr> ?
14:44 < maybehuman> the scenario would be right before must_signal kicks in, only 20% signal. It kicks in and the blocks from the other 80% are rejected
14:45 < maybehuman> so effectively you'd have only 20% of the hashrate that the difficulty was calculated for
14:49 < luke-jr> no, the other 80% have to signal too
14:49 < luke-jr> you assume they're going to attack the network
14:49 < luke-jr> that's very unlikely
14:49 < maybehuman> yes, I agree
14:50 < maybehuman> but possible nonetheless
14:55 < maybehuman> the good thing for them would be that it's like a sit down strike. So you might call it an attack, but they don't have to take any aggressive action. If they could combine it with a plausible narrative (and everyone going crazy about insanely high fees), it could be quite ugly
14:55 < maybehuman> but yes, unlikely
14:56 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
14:57 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
15:03 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
15:16 < aj> luke-jr: "3 months, lot=false" -> "we already have x% of the economy and are happy to activate with y% of miners protecting the remaining 100-x% of the economy. we do not have any idea how long it will take to get ~100% of the economy, but expect data from a failed activation attempt to tell us how long that will likely be so that we can make a second attempt with lot=true."
15:17 < luke-jr> aj: how is that better than "10 years, LOT=true"?
15:23 < aj> luke-jr: decreasing threshold doesn't really complicate the code much (i did that having the threshold reduce a little bit each retarget period for modern-softfork-activation), but it's a more complicated spec. if we actually wanted it, i think a bip91 setup where you had an additional rule that says "if you get x% singalling in period X, 95% has to signal in period X+1, then you hit lockin in
15:23 < aj> X+2" would be simpler to deal with
15:25 < luke-jr> considering 90% of miners already are onboard, I'm not sure it's worth the extra work
15:26 < luke-jr> also easier to get consensus on 90 or 95% than some function
15:27 < aj> a 95% threshold doesn't give 5% a certain veto -- 65%-90% of hashpower can do bip91 coordination to reject vetoing blocks
15:27 < aj> the miner survey having 90% of hashrate responding seems like a good reason to go from 95% to 90% threshold though
15:29 < aj> (i think there's a good argument that fixed retarget periods rather than the rolling ones used before bip9 would have justified 95% -> 90% or so too, though we didn't take advantage of that)
15:30 < luke-jr> aj: BIP91 was an attack on the network, not something to repeat or encourage
15:30 < aj> luke-jr: the variance over 2016 blocks is only a % or two, so real-hashrate at 85% -> observed hashrate at 83%-87% with 99.9%+ probability (i did the math somewhere, don't remember it exactly)
15:31 < luke-jr> really? ok
15:31 < luke-jr> I would have expected it to be much higher
15:31 < luke-jr> does the % variance shift with lower %s?
15:32 < luke-jr> eg, if we only really care about a majority, would 55% actually work?
15:33 < luke-jr> perhaps the problem is the variance after new rules are in force, less than the measurement of signalling..
15:33 < luke-jr> actually, I'm not sure I ever considered the latter
15:34 < luke-jr> gmaxwell had a calculator somewhere, but I forget where :/
15:37 < aj> luke-jr: (a) it's not (IMHO); (b) if allows the deployment to fail (if we were trying to activate it super-quick so weren't already as sure as we should be and trusted miners to veto bad code); (c) it means nobody who's uncomfortable with lot=true has to stress about it right now; (d) it avoids making 10 year plans
15:39 < luke-jr> (b) doesn't make sense
15:39 < aj> https://twitter.com/ajtowns/status/1321277134225043457 might be interesting for some of matt's perspectives but with more math
15:41 < luke-jr> can
15:41 < luke-jr> can't find gmaxwell's calc :/
15:44 < aj> if the threshold is x%, exactly x% of hashpower is compliant, an invalid block is mined that's extended by the non-compliant miners then the odds of the violating chain being longer than than the valid one for t minutes is:
15:44 < aj>   95% -- 30min  7.1% ; 1h  0.6% ; 2h  0.0%
15:44 < aj>   90% -- 30min  9.5% ; 1h  1.5% ; 2h  0.1%
15:44 < aj>   85% -- 30min 12.4% ; 1h  2.8% ; 2h  0.2%
15:44 < aj>   80% -- 30min 16.0% ; 1h  4.5% ; 2h  0.6%
15:44 < aj>   75% -- 30min 19.6% ; 1h  7.0% ; 2h  1.5%
15:44 < aj>   70% -- 30min 23.5% ; 1h 10.3% ; 2h  3.1%
15:44 < aj>   60% -- 30min 33.5% ; 1h 19.4% ; 2h 10.0%
15:48 < aj> if they x% of validating nodes also do non-validating spy mining for 5s or 20s those numbers stay pretty much the same (5s -> 7.1%-33.4%; 20s -> 8.0%->34.4%) but get much worse eventually obv (45s -> 9%-36.2%; 120s -> 12.3%-40.9%) (just summarising the 30min values)
15:50 -!- jonatack_ [~jon@37.166.60.165] has joined ##taproot-activation
15:50 < aj> 2016 block period, 66% of (real) hashpower signalling, then a threshold of 68% / 1380 blocks gives <1% chance of activation; threshold of 63%/1282 gives >99% chance of activation were specific numbers in my email history
15:52 < luke-jr> it's AFTER locked_in that we want to ensure reasonable confidence for ec.minority nodes
15:53 -!- jonatack [~jon@37.169.23.248] has quit [Ping timeout: 240 seconds]
15:54 < aj> we care if the threshold gets hit during MUST_SIGNAL too
15:54 < aj> (ie there's already 100/200/whatever non-signalling blocks, so the next one that comes along can create an invalid chain)
15:55 < aj> oh -- having decreasing threshold as a separate bip means we can do it much later and only if it turns out to be necessary
16:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
19:36 -!- jonatack_ [~jon@37.166.60.165] has quit [Ping timeout: 246 seconds]
20:53 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds]
21:14 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
21:27 < CubicEarth> aj: of course miners could coordinate to reject vetoing blocks
21:28 < CubicEarth> but that seems like it would be a divisive move
21:30 < CubicEarth> because it would be working around the limit specified in the code
21:30 < CubicEarth> *threshold
21:30 < CubicEarth> luke-jr: Yeah, 55% would be fine
21:33 < CubicEarth> Presumably the threshold is to effect a safe upgrade. 55% actually would be a bit to close for comfort... we would want to be far enough into majority territory that we were certain the taproot fork would never - or even be close to - have less hashpower
21:34 < CubicEarth> In terms of giving miners a chance to do this on their own, the appropriate threshold should be the one where miners themselves would feel confident going forward with it. It should reflect their preferences.
21:35 < CubicEarth> It the number is too high and there are vetoers, the miners in favor could coordinate as aj is suggesting
21:37 < CubicEarth> if the threshold were at 55%, miners, not being fools, would probably not bother signaling unless they ascertained out-of-band that there was in fact a higher level of support
21:39 < CubicEarth> So since they can do what they want anyway, either to support or reject, irrespective of the threshold set in Core, the purpose of the threshold should be seen as a way to help the miners coordinate
--- Log closed Sat Feb 13 00:00:28 2021