--- Log opened Thu Apr 29 00:00:40 2021
00:27 -!- ironhelix [~d@unaffiliated/ironhelix] has quit []
00:43 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
00:51 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
00:52 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 265 seconds]
01:31 -!- faketoshi [~quassel@192.252.212.46] has quit [Ping timeout: 240 seconds]
01:33 -!- bcman [~quassel@104.200.129.53] has joined ##taproot-activation
01:54 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
01:54 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:00 -!- mandelb[m] [mandelbmat@gateway/shell/matrix.org/x-qqomqcreejydtqeq] has quit [Quit: Idle for 30+ days]
02:17 -!- gevs [~evias@67.red-88-6-131.staticip.rima-tde.net] has quit [Quit: Leaving]
02:30 -!- liberliver [~Thunderbi@46.101.127.98] has joined ##taproot-activation
03:29 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds]
03:56 -!- gevs [~evias@67.red-88-6-131.staticip.rima-tde.net] has joined ##taproot-activation
06:09 < AaronvanW> Emcy: the UASF initiative predates Greg's ASICBOOST revelation. shaolinfry posted the idea on bitcoin-dev in february '17: https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg04703.html
06:10 -!- CARO [~Cesar@2804:7f4:c29d:4d83:7c3a:c9c7:c1a3:9e77] has joined ##taproot-activation
06:11 < AaronvanW> Emcy_ ^
06:11 -!- CARO1 [~Cesar@179.162.9.226] has quit [Ping timeout: 240 seconds]
06:16 < belcher> the asicboost revelation made many many more people at the time support the uasf, e.g. https://old.reddit.com/r/Bitcoin/comments/64sntn/the_problem_is_quite_urgent_or_why_some_uasf_does/
06:20 < AaronvanW> Yes, among other things. (NYA, Jihan acting like a troll on Twitter, people figuring out the game theory of UASF.)
06:21 <@michaelfolkson> You either prepare it when it isn't needed or you rush it when it is needed. I prefer the former personally but some people seem to prefer the latter
06:21 < AaronvanW> *prepare it before it's needed
06:21 <@michaelfolkson> Right
06:22 -!- woh0dly [~woh0dly@unaffiliated/wo0d-] has joined ##taproot-activation
06:22 <@michaelfolkson> You would guess most of the time it isn't needed. But you don't prepare for best case scenario
06:23 <@michaelfolkson> Or at least not exclusively at the expense of also preparing for bad case or worst case scenarios
06:24 < AaronvanW> I agree that it's better to prepare.. the next question is whether LOT=true is in fact the best fallback option, or if reverse signaling/flag day would be a better fallback option.
06:26 <@michaelfolkson> I prefer the forced signaling in a BIP 8(LOT=true) to Core telling everyone when the flag day should be and everyone accepting this as fact
06:27 <@michaelfolkson> Again you have to prepare for bad or worst case scenario where whatever flag day Core releases there is opposition to it and possibly alternatives released
06:27 < belcher> if Core implemented LOT=true wouldnt that also be Core telling us when taproot becomes active and everyone else just accepting it?
06:27 <@michaelfolkson> Essentially but I don't think Core should or will ever release LOT=true or a flag day.
06:28 < belcher> its not really core telling us if everyone has an opportunity to get involved in the core process
06:28 <@michaelfolkson> At least with LOT=true and the forced signaling you are preparing for scenario where you aren't 100 percent sure when Taproot rules are enforced
06:28 < AaronvanW> I think the answer to the question "what is the best fallback option" depends on *why* miners didn't signal. But you might not be able to find that out. In which case you have to take into account all different possibilities, and figure out the best option considering all of these.
06:30 <@michaelfolkson> I disagree. I don't think you'll find out why. We never found out for certain why they didn't in 2017.
06:30 < AaronvanW> Where miners against the proposal? Didn't they know about the proposal? Did they know but where they just being lazy?
06:30 <@michaelfolkson> You can ask but you don't know for sure the answer is honest
06:30 <@michaelfolkson> You'd have never got Jihan to admit he was stalling because of ASICBoost
06:31 < belcher> it was pretty obvious though
06:31 < AaronvanW> michaelfolkson: right, that's why I'm saying you need to come up with the best response considering that all of these options might be true.
06:31 < belcher> you had those blocks with just 12 transactions, exactly the amount needed so that they could rotate their ordering to change the bits of the merkleroot so that asicboost could work
06:31 < belcher> you also had those examples of blocks that were invalid because some transactions depended on other ones in the same block, but they were rotated and so became invalid
06:32 <@michaelfolkson> AaronvanW: It just comes down to whether you are prepared to force through the soft fork activation or not in the absence of a good reason why you shouldn't
06:32 < belcher> also you could see the asicboost stuff in the actual asics
06:32 -!- duringo [ac625de3@172.98.93.227] has quit [Quit: Connection closed]
06:32 < belcher> full evidence here: https://gist.github.com/chris-belcher/a8155df5051bb3e3aa96#segwit-is-being-blocked-because-it-breaks-asicboost-a-patented-optimization-used-by-bitmain-asic-manufacturer
06:32 < AaronvanW> michaelfolkson: yes but there are different ways to do that, is my point.
06:32 -!- duringo [ac625de3@172.98.93.227] has joined ##taproot-activation
06:33 <@michaelfolkson> AaronvanW: Agreed. I'm just arguing that the motivation for stalling (unless it is justified) doesn't really impact the discussion on what way to force it through is best
06:33 <@michaelfolkson> Interesting, thanks for link belcher
06:34 < belcher> (i just noticed a few of the links are sec, hold on while i try to add an archive.org link)
06:34 < belcher> links are dead*
06:34 < AaronvanW> michaelfolkson: you think that regardless of why miners didn't signal (against; ignorant; lazy) the best solution is LOT=true?
06:35 <@michaelfolkson> AaronvanW: Indeed. What reason (assuming honesty which you can't guarantee) would make you lean towards or away from LOT=true (or a flag day)?
06:37 <@michaelfolkson> I just think LOT=true is a superior solution to force through a soft fork regardless of what was motivating the miners to not signal/stall
06:37 <@michaelfolkson> I know some people don't share that opinion
06:38 < belcher> LOT=true still gives power to miners to choose when the update happens within a certain range, why give them any power at all if we're starting from the idea that miners cant be trusted
06:39 <@michaelfolkson> belcher: It doesn't. It just rejects blocks that aren't signaling before soft fork rules are enforced
06:39 < belcher> LOT=true has the whole year period where miner can activat
06:39 <@michaelfolkson> Oh sure. If miners want to activate early before the forced signaling they can
06:40 < belcher> why give them that power?
06:40 <@michaelfolkson> I don't see the problem with giving them ability to activate early before a flag day or forced signaling
06:40 <@michaelfolkson> Surely that is better than having to wait until the flag day
06:43 <@michaelfolkson> We want the soft fork activated. If all a malicious or stalling miner can do is activate it earlier than planned that doesn't seem a problem to me
06:54 < AaronvanW> belcher: With LOT=true, users decide when the soft fork activates (same as flag day), miners can move it _forward_ not _backward_. So they don't have the power to delay, which is what really matters.
06:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
06:57 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
07:26 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/105853/how-can-i-follow-the-progress-of-miner-signaling-for-taproot-activation-during-t/
08:11 -!- bcman is now known as faketoshi
08:14 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
08:14 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
08:19 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
08:19 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
08:22 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
08:24 -!- woh0dly [~woh0dly@unaffiliated/wo0d-] has quit []
08:27 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
08:30 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving]
08:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
08:32 -!- cguida [~Adium@205.209.28.54] has quit [Ping timeout: 260 seconds]
08:45 -!- woh0dly [~wo0d-@c-73-61-86-223.hsd1.nh.comcast.net] has joined ##taproot-activation
08:45 -!- woh0dly [~wo0d-@c-73-61-86-223.hsd1.nh.comcast.net] has quit [Client Quit]
08:46 -!- wo0d- [~wo0d-@c-73-61-86-223.hsd1.nh.comcast.net] has joined ##taproot-activation
08:46 -!- wo0d- [~wo0d-@c-73-61-86-223.hsd1.nh.comcast.net] has quit [Changing host]
08:46 -!- wo0d- [~wo0d-@unaffiliated/wo0d-] has joined ##taproot-activation
08:47 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
08:47 -!- wo0d- [~wo0d-@unaffiliated/wo0d-] has quit [Client Quit]
08:51 -!- cguida [~Adium@205.209.28.54] has quit [Ping timeout: 252 seconds]
08:51 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
08:56 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 276 seconds]
08:58 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
09:00 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-sgdrymxrtfyrvqyv] has quit [Quit: Idle for 30+ days]
09:01 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 268 seconds]
09:02 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
09:02 < Emcy_> AaronvanW yes, the idea of uasf was extant, and it was ignored until it became very clear there was a pressing need
09:02 < Emcy_> just like today
09:06 < AaronvanW> Right.
09:07 < AaronvanW> iiuc this is exactly how eg. faketoshi sees it. feel free to ignore this LOT=true release until there is a pressing need.
09:14 -!- ironhelix [~d@unaffiliated/ironhelix] has joined ##taproot-activation
09:15 < luke-jr> well, if you don't have it by November, you might be insecure unless you're paying attention and ready to upgrade within 2 weeks :p
09:16 < AaronvanW> unless Bitcoin Core releases a MASF client before November. (Could be LOT=false, LOT=true or MASF+flagday.)
09:18 < luke-jr> well, either way you'd need to upgrade to _something_ compatible
09:18 < AaronvanW> or MASF plus everse-signaling... but that sounds like a complicated solution.
09:18 < luke-jr> simplest to just update to the full activation upfront
09:18 < AaronvanW> *reverse
10:07 -!- jesseposner [~jesseposn@2601:645:200:162f:2183:5aca:4fde:dc3b] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:12 < luke-jr> [13:38:28] <belcher> LOT=true still gives power to miners to choose when the update happens within a certain range, why give them any power at all if we're starting from the idea that miners cant be trusted <-- false premise
10:13 < luke-jr> it's not a question of whether miners can be trusted or not, it's a question of creating a known vulnerability for no benefit
10:13 < luke-jr> just because miners can be trusted does not in any sense imply we should give them something to exploit
10:58 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
11:03 -!- lukedashjr is now known as luke-jr
11:21 -!- jesseposner [~jesseposn@2601:645:200:162f:2462:5349:223b:247d] has joined ##taproot-activation
12:08 -!- glozow [sid453516@gateway/web/irccloud.com/x-okmrsanguqkbwpwj] has left ##taproot-activation []
12:10 -!- duringo [ac625de3@172.98.93.227] has quit [Quit: Connection closed]
12:31 < faketoshi> AaronvanW: exactly
12:31 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 276 seconds]
12:37 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 252 seconds]
12:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
12:39 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
12:43 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
12:54 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-raubrxololzpuyor] has quit [Ping timeout: 245 seconds]
12:55 -!- provoostenator_ [~quassel@provoostenator.sprovoost.nl] has quit [Ping timeout: 260 seconds]
12:55 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
12:56 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-evlqyzwpcpnqgjmh] has joined ##taproot-activation
13:06 < faketoshi> compiled 0.21.1 for my mac. got quite a few warnings I don't usually see. idk if that's the case for anyone else?
13:07 < hebasto> faketoshi: pass `--enable-suppress-external-warnings` to your `configure` script
13:08 < faketoshi> thnx
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:03 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
14:14 < AaronvanW> I'm having a really hard time understanding the opposition against releasing LOT=false or MASF+flagday in Bitcoin Core. (On a timeline that would be more compatible with a LOT=false alt-client release. In this case a specific example would be, a LOT=false that times out in October 2022 or so.) I've seen people argue that this would allow a LOT=true minority to take the network "hostage", "threaten" the network, etc. B
14:14 < AaronvanW> ut why are these kinds of terms used in the context of an otherwise non-contentious upgrade? If I run a LOT=false node as a user, I'm *hoping* that activation will trigger, right? That's why I'm running a LOT=false node. So if some economic minority compels miners to trigger my LOT=false activation, why should I consider this a problem? Alternatively, if they fail to trigger it, they can have fun with their altcoin I
14:14 < AaronvanW> guess; that's true whether I was running LOT=false or not. (My question is about LOT=false specifically, because I do understand why Core might not want to deploy LOT=true; perception of "devs decide".)
14:14 < AaronvanW> Sorry, I should have said, "On a timeline that would be more compatible with a LOT=true alt-client release."
14:19 < belcher> AaronvanW what some call "have fun with your altcoin" other people might call "transactions moving million which already have 4 or 5 confirmations disappearing"
14:21 < belcher> the benefit of having a MASF followed by a UASF (i.e. bip8 lot=true) vs having a flag day UASF is just that the MASF can activate earlier, but it could be argued that benefit isnt that great, we save a few more months so what... while with a flag day we greatly reduce the risk of those reorgs
14:21 < AaronvanW> belcher: Like I said: "that's true whether I was running LOT=false or not."
14:23 < belcher> if bitcoin core doesnt have LOT=false then the small minority which aims to force signalling bip148-style is much less likely to successfully force the signalling, because even if they do do that they only gain taproot for themselves and not for everyone who runs core
14:23 < belcher> so yes its still possible but the incentive is a lower
14:24 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has joined ##taproot-activation
14:25 < AaronvanW> belcher: the incentive for who? the incentive for users to run LOT=true, or the incentive for miners to signal? (I think you mean users?)
14:25 < belcher> the incentive for the LOT=true users
14:26 < belcher> a big part of the bip148 events was if we won (and i include myself because i supported bip148) then we actually did win segwit for everyone... so even though the risk was big the reward was big too
14:27 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has quit [Client Quit]
14:30 < AaronvanW> Do you agree that the incentive for miners is the same?
14:30 < belcher> i think so yes
14:30 < belcher> the risk of a reorg is always pretty similar as you say, but the reward is much lower if theres no lot=false in core... and people start fights not if the risk is low but if the risk:reward is low
14:31 < AaronvanW> but isn't the risk of reorg the problem?
14:32 < belcher> yes?
14:34 < luke-jr> [21:25:59] <belcher> the incentive for the LOT=true users <-- not significantly; non-full nodes (ie, your Core) are at risk, not us
14:36 < AaronvanW> yes, LOT=false users get to share in the reward. right?
14:37 < belcher> right
14:38 < AaronvanW> right
14:38 < AaronvanW> so everyone is happy?
14:38 < belcher> the LOT=false users might not be because they didnt sign up for a reorg risk, but they're getting one anyway because of the LOT=true users
14:38 < luke-jr> LOT=false users are only at risk for 2 weeks
14:39 < luke-jr> belcher: they did sign up for it. nobody told them they couldn't run LOT=true
14:39 < belcher> luke-jr or we could not have lot=false at all and avoid the whole problem
14:39 < belcher> have a flag day instead
14:39 < belcher> same reward (get taproot), lower risk
14:41 < AaronvanW> belcher you said: "the risk of a reorg is always pretty similar as you say" <---- so that risk exists for LOT=false users and non-LOT=false users. While LOT=false users get to share in the reward. Why isn't LOT=false the preferable option?
14:42 < belcher> if very few users run lot=false then a lot=true bip148-style social media campaign will be much less convincing, because even if the signalling is forced you only win taproot for yourself and not for everyone else
14:43 < belcher> i could put it this way, i dont mine yet i still want my node to enforce a difficulty adjustment algorithm so that those who do mine keep the network secure
14:44 < belcher> part of the job of a full node is to make sure the network is healthy... so when people are considering whether to run lot=false something that will come up in their choice is what effect is has on the rest of the network, whether it adds an incentive to do a bip148-style social media campaign
14:44 < belcher> if there was no other way i bet people would risk it to get taproot, but there is another way which is flag day
14:45 < AaronvanW> "the risk of a reorg is always pretty similar as you say" <--- do you think this is the case, or not?
14:45 < AaronvanW> does a social media blitz change anything about that risk?
14:45 < belcher> well yeah, miners could always try to do a reorg (if they dont mind wasting money)
14:46 < belcher> support a miner wants to do a reorg right now, their risk is some value, their reward is zero... so they dont do it
14:46 < belcher> but if lot=false is out there and there is a lot=true campaign, then the miners risk is still the same, but the reward is higher... so they might try (and if they get it wrong then the network sees a many block reorg)
14:46 < luke-jr> [21:39:32] <belcher> have a flag day instead <-- stupid, but you alreayd know that
14:47 < luke-jr> [21:39:41] <belcher> same reward (get taproot), lower risk <-- higher risk
14:50 < AaronvanW> belcher: do you think the existence of LOT=true nodes creates reorg risk? If yes, does that risk increase/decrease depending on whether or not there are many LOT=false nodes?
14:52 < belcher> first question yes, second question the risk stays the same i guess, but the reward from successfully forcing signalling goes up, and so the risk:reward goes up
14:56 < AaronvanW> So we've established that the risk stays the same. Now we have two options. 1) LOT=false, 2) Nothing. LOT=false gets to share in the reward. Nothing does not. That means that the risk/reward ratio is more favorable for LOT=false nodes, right?
14:58 < belcher> that sounds wrong to me
14:59 < AaronvanW> The only way I can steelman your position, is that you'd wish that LOT=true nodes would just go away and that option would stop to be a thing. But I don't think that version of reality exists. So given that that version of reality doesn't exist, I can only conclude that LOT=false is preferable over nothing.
14:59 < belcher> my discussion on risk:reward is from the point of view of an activist whos considering doing a social media drama
14:59 < belcher> AaronvanW thing is right now if core and almost everyone else ignores lot=true then it would just go away
14:59 < belcher> or if core proposes a flag day UASF as an alternative
15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
15:00 < AaronvanW> "thing is right now if core and almost everyone else ignores lot=true then it would just go away" <--- if this were wrong, you'd agree with me?
15:01 < belcher> i think the incentives are such that most of the economy would adopt core and its flag day
15:01 < belcher> i dont see how i could be wrong (though of course im only human)
15:01 < AaronvanW> I know, I'm just asking, IF it was wrong, you'd agree with me, right?
15:02 < belcher> what does my being wrong mean in practice? i suppose it means lot=true gets adopted by 20-30% of the economy(?)
15:02 < AaronvanW> I don't know, what's your threshold?
15:02 < AaronvanW> From what % is LOT=true irrelevant?
15:03 < belcher> from my point of view that doesnt look good for bitcoin's future, if a substantial part of the economy adopts something needlessly risky
15:04 < belcher> when i wrote my mailing list email about flag day i actually PMed some people i know on twitter who have bitcoin companies and asked them if they'd adopt an alt-client which had a flag day, i was actually surprised at how conservative they were about it, the ones which replied said they would only adopt the thing which they thought had consensus (and in practice thats core one of them said)
15:04 < belcher> fact is a lot of users who matter dont care about taproot enough to risk a fork, thats why i think this lot=true thing wont really go anywhere... so in practice we have to cooperate with each other and not do unilateral actions like alt-clients (at least for taproot)
15:04 < AaronvanW> From what % is LOT=true irrelevant? Just a ballpark number would be fine too.
15:04 < luke-jr> ie, they've been tricked by ST advocates
15:05 < belcher> AaronvanW i really dont know, a number thats small enough that it can be safely ignored i guess, in the same way we ignore people who want e.g. censorship soft forks
15:05 < AaronvanW> ballpark?
15:06 < luke-jr> belcher thinks he can ignore the majority of the ecosystem https://twitter.com/brian_trollz/status/1380973341591363588
15:06 < belcher> luke-jr i see your twitter poll and i raise you my own twitter poll https://twitter.com/AaronvanW/status/1384205266737004558
15:07 < belcher> my poll (or rather AaronvanW's) has more respondants, 1351 votes vs 109 votes for your one
15:07 < luke-jr> belcher: that's AaronvanW's, not yours; and it's clearly biased
15:07 < mol> belcher 79 votes for yes is the community, get that! :D
15:07 < belcher> also bitcoinmechanic disagreed with the wording of aaron's and tried to make his own https://twitter.com/GrassFedBitcoin/status/1384238795332087809
15:08 < belcher> and still didnt get the result he wanted xD
15:08 < luke-jr> misrepresenting ST as "Core 0.21.1" and the communtiy release as "UASF"
15:08 < mol> i feel so sorry for luke
15:08 < belcher> but at 356 votes, still more than brian_trollz's poll
15:08 < mol> luke needs a vacation
15:08 < luke-jr> mol: that is true
15:08 < belcher> i thought it was interesting how popular "Show results" was, to me that means most people just want to stay in consensus
15:08 < mol> luke-jr, then do it! :D
15:09 < mol> luke-jr, nice weather everywhere right now
15:09 < luke-jr> mol: vaccines too iffy
15:09 < luke-jr> besides, you just was to exploit my absence
15:09 < AaronvanW> belcher: at 0%  it's irrelevant. at 20-30% it's relevant. so it must be somewhere in between these two.
15:09 < mol> just drive to a beach, book into a hotel, luke
15:10 < luke-jr> mol: sounds like a good way to get COVID
15:10 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-tcflvkzsljnpjlra] has quit [Quit: Connection closed for inactivity]
15:10 < belcher> AaronvanW i really dont know sorry, the threshold is where the network effect becomes weak enough
15:10 < belcher> the main reason we all want to stay in consensus is because of the network effect after all
15:10 < belcher> 20-30% could probably make their own economy that kind of works (or could they? maybe it should be higher)
15:11 < faketoshi> luke-jr lives in the one place we all want to go for vacation - except maybe texas
15:11 < AaronvanW> huh, 1% could make their own economy? Some altcoins are smaller than that.
15:11 < belcher> like for example id probably be happier if historical bitcoin blocks were smaller so that the blockchain is smaller and initial sync is faster, but its not... and i just have to put up with it because of the network effect
15:12 < belcher> AaronvanW i personally dont get paid in altcoins or spend altcoins, thats the network effect at play
15:13 < belcher> (can you even do it? i know bitrefill takes some alts, but bitcoin still has the majority of the liquidity for actual use)
15:13 < AaronvanW> belcher: but some people do. I don't think here is a place where network effects get "weak enough". (except 0%)
15:14 < belcher> right, thats one reason its so hard to put a number on it
15:14 < belcher> loss from poor network effect is like a cost.. some users are happy to put up that cost, some arent
15:14 < belcher> its subjective for every person
15:14 < AaronvanW> no I just put a number on it. it's 0 imo.
15:14 < belcher> so you reckon if even one person uses a lot=true full node wallet then that will result in everyone enforcing taproot?
15:15 < AaronvanW> Bitcoin started with 1. Network effects grow.
15:15 < AaronvanW> Otherwise everyone would just use USD because of network effect.
15:15 < belcher> what if the rest of the economy activates taproot with a flag day? seems like most people would adopt the safer option where they still get taproot, at the small cost of ignoring that one person
15:15 < belcher> we use bitcoin over USD because bitcoin has better features, taproot-from-flag-day has the same features as taproot-from-lot-true
15:16 < belcher> (or better features maybe, because reducing risk is a feature you could say)
15:16 < luke-jr> belcher: you can't activate Taproot with a flag day
15:16 < luke-jr> except subjectively
15:16 < luke-jr> which is stupid
15:16 < belcher> the block size limit which satoshi added was done with a flag day
15:16 < luke-jr> taproot-subjectively < taproot-objectively
15:17 < belcher> bip148 itself was a flag day too... its logic was that after a certain day (1st august in this case) a new rule takes effect
15:17 < AaronvanW> belcher: would you rather split the network than let LOT=true clients trigger MASF(+flag day) activation?
15:18 < luke-jr> belcher: BIP148 was signalling
15:18 < belcher> AaronvanW if the two choices in the split are taproot-with-flag-day and taproot-with-lot-true then id personally go for flag day (although in these decisions a really important thing is what everyone else does, staying in consensus is important ofc)
15:18 < luke-jr> flag day = subjective, reorg risk
15:18 < belcher> luke-jr what signalled for bip148 to start? nothing, it started on a certain date
15:19 < luke-jr> lot-true = objective, no reorg risk
15:19 < luke-jr> belcher: it signalled itself
15:20 < AaronvanW> belcher: that wasn't really an answer to my question.
15:20 < belcher> AaronvanW i dont get it?
15:20 < belcher> well i guess i cant choose to split the network on my own, the network is decentralized and it only splits when theres two or more factions
15:24 < AaronvanW> belcher: some LOT=true people prefer to split off than give up. Would you prefer they split off, or that they get their way?
15:24 < belcher> ah i see what you're asking
15:24 < mol> nah they won't split off
15:25 < belcher> depends on the other options, if flag day is available then id prefer that everyone else adopts flag day and they split off
15:25 < AaronvanW> why?
15:26 < belcher> i think flag day is a better method than lot=true... but the two are incompatible so i cant have both, instead id have to choose
15:26 < luke-jr> they're not incompatible
15:26 < AaronvanW> how about MASF+flag day? (indeed, they're not incompatible.)
15:26 < belcher> (you know if bip8 didnt have that forced signalling at the end then flag day and lot=true would be compatible if the flag day had the same block height)
15:26 < luke-jr> LOT=True chain is valid to flagday nodes
15:26 < belcher> i think the forced signalling makes them incompatible?
15:27 < luke-jr> flagday nodes won't reject signalling blocks
15:27 < belcher> hmm thats right then, miners might signal anyway
15:27 < AaronvanW> *they're not necessarily incompatible
15:27 < belcher> interesting thought
15:27 < luke-jr> miners have to signal to make valid blocks
15:27 < belcher> maybe no split is needed at all then
15:28 < AaronvanW> right. so then, what's the harm in running LOT=false in the mean time, before flag day
15:28 < luke-jr> AaronvanW: people might not upgrade to LOT=true in time
15:28 < luke-jr> or be tricked into thinking it's safe
15:28 < AaronvanW> luke-jr: My question was for belcher :)
15:28 < luke-jr> k
15:29 < AaronvanW> I understand the answer from your perspective.
15:29 < belcher> if i run lot=false then i contribute to the economic weight which would put pressure on miners to come up with a bip91-style collusion scheme
15:29 < belcher> which risks reorgs
15:29 < luke-jr> lolno
15:29 < belcher> also lot=false would presumably be an alt-client, so different to what everyone else would be running
15:29 < luke-jr> BIP91 was face saving, nothing more
15:29 < AaronvanW> no we stablished that reorg risks are the same belcher
15:30 < belcher> luke-jr bip91 had the orphaning mechanism didnt it
15:30 < belcher> 51% of miners would orphan off other blocks which didnt signal
15:30 < AaronvanW> belcher: I don't presume that LOT=false would be an alt-client, but I don't think it changes the answer.
15:30 < belcher> so yes it was face saving but also miners really did force each other
15:30 < luke-jr> belcher: BIP148 made those blocks invalid. BIP91 was just so miners could say they did it.
15:31 < belcher> i agree luke-jr, my point isnt about the blocks being valid or invalid, but orphaned or not orphaned
15:31 < luke-jr> (and tie it to 2X nonsense)
15:31 < belcher> being valid is about what the economy thinks, being orphaned is about what other miners think
15:31 < belcher> AaronvanW i think it does, because if its an alt-client then that means i wouldnt be enforcing the same rules as for example bisq traders, bitrefill, or other places that i often use
15:32 < luke-jr> belcher: not quite
15:32 < luke-jr> belcher: miners have no right to reject valid blocks; to do so is an attack
15:32 < belcher> who cares about rights
15:32 < belcher> bitcoin doesnt work with some kind of bill of rights, its the law of the jungle down here, what matters is power
15:32 < AaronvanW> fine, it doesn't matter. you, as an individual, would prefer to run LOT=false over nothing, right? I think that's the logical conclusion based on everything we've established so far.
15:32 < luke-jr> belcher: if miners add criteria above and beyond what nodes apply, then that means the network has ZERO full nodes
15:33 < luke-jr> and is centrally controlled by those miners
15:34 < belcher> AaronvanW well no, because if i ran lot=false it would add my own economic weight to the miner's decision to risk a reorg, so id rather not run lot=false
15:34 < belcher> luke-jr if miners apply criteria above and beyond what nodes apply then the only thing we can do is spend more in miners fees
15:34 < luke-jr> belcher: or change PoW
15:34 < belcher> i dont think that helps
15:34 < luke-jr> of course it does
15:35 < belcher> applying criteria above and beyond is censorship, you agree? by fee-bumping my censored transaction it means i give money only to miners who dont censor
15:35 < AaronvanW> ok maybe(?) you're right about that belcher, let's refocus on Core. I think it would be better if Core had LOT=false over nothing, right? I think that's the logical conclusion based on everything we've established so far.
15:35 < belcher> AaronvanW yes, if the only two options for core were lot=false or nothing then yeah it would be better to have lot=false (because nothing means we dont get taproot)
15:35 < AaronvanW> :)
15:36 < AaronvanW> progress
15:36 < belcher> but they're not the only two options, theres a third option which is flag day
15:36 < AaronvanW> no because flag day is compatible, remember?
15:36 < AaronvanW> *potentially compatible
15:36 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
15:36 < belcher> (or actually a whole family of options like reverse-signalling flag day, which nobody has really debated yet and probably no debate will happen until if ST fails)
15:37 < belcher> AaronvanW not sure i understand, there are still three options? lot=false, flag day or nothing.. how does flag day and lot=false being compatible change anything... "nothing" is also compatible in some cases
15:37 < AaronvanW> how about MASF+flag day?
15:37 < belcher> thats just lot=true isnt it?
15:37 < AaronvanW> no
15:37 < AaronvanW> no mandatory signaling
15:37 < belcher> ah
15:38 < belcher> it seems to me MASF+flag day still has all the problems about incentivizing a bip148-style social media campaign
15:38 < luke-jr> belcher: choosing transactions is not censorship; rejecting valid blocks is
15:39 < luke-jr> belcher: your fees won't go to the miners rejecting the blocks mining them
15:40 < AaronvanW> "it seems to me MASF+flag day still has all the problems about incentivizing a bip148-style social media campaign" <--- if reorg risk is the same, and the network stays together, what's the problem with a social media blitz? (I think we're established the first two points?..)
15:44 < belcher> AaronvanW we say miners are the employees of the economy, the problem with a social media campaign is it creates an uncertain situation wheres miner dont know which economy they're meant to serve, because there might be new rules coming into effect at different dates... this uncertainty might result in reorg if miners follow different rules
15:45 < AaronvanW> so reorg risks *aren't* the same? you're going back and forth on this, you realize that, right?
15:46 < belcher> maybe you've misunderstood or if not explained well, but its clear in my head
15:46 < belcher> lets take the example of bip148, you must agree that had inherent risks in it
15:46 < AaronvanW> yes
15:46 < belcher> thats the risk im talking about, whether that was actual risk going up or just risk:reward going up because risk stayed the same and reward went up
15:47 < AaronvanW> we're talking about the same thing.
15:47 < belcher> either way miners had to do something when in normal situations they definitely wouldnt do anything (like right now they definitely wont be attempting a reorg)
15:47 < luke-jr> belcher: without anything, miners certainly don't know
15:47 < luke-jr> it's strictly better for things to  break when they discern wrong, than for things to silently not work *correctly*
15:48 < AaronvanW> is that reorg risk smaller is there aren't LOT=false or MASF+flagday nodes?
15:48 < belcher> lets put it this way, in 2017 much of the economy out there was running bitcoin core 0.13.1 which today we might call lot=false... suppose that wasnt true and they werent running anything different, would bip148 still have worked?
15:49 < belcher> it wouldnt have worked, sure it would force signalling but we wouldnt have gotten segwit
15:49 < belcher> that probably means nobody would have even tried bip148
15:49 < AaronvanW> my answer is yes it would have worked. but my question is if the reorg risk had been the same.
15:50 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
15:50 < belcher> i disagree
15:50 < belcher> sec
15:51 < AaronvanW> ok so we've found a point of disagreement, which is great.
15:51 < belcher> look at this link https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/ it shows how big places like bitstamp, bitgo, localbitcoins were enforcing segwit
15:52 < AaronvanW> but my question stands.
15:52 < belcher> that means if someone stole coins in a segwit address they could send it to e.g. localbitcoins and sell them
15:52 < AaronvanW> only if someone would buy these coins.
15:52 < belcher> if you remember the "anyone can spend fud" which bcashers talked about, it would actually be true
15:52 < belcher> AaronvanW in the case of localbitcoins, the thing that matters is localbitcoin's full node and it would not be enforcing segwit
15:52 < belcher> it would accept the deposit as normal
15:53 < AaronvanW> no, the thing that matters is what users are willing to pay for.
15:53 < belcher> of course this would never really happen, because people would realize this and just not use segwit... it would be the same as if segwit had never activated at all
15:54 < AaronvanW> belcher: would the reorg risks have been the same?
15:54 < belcher> i dont know
15:54 < AaronvanW> it makes all the difference.
15:55 < belcher> lot=false being widely deployed would increase the risk of a reorg, thats slightly different to what you're asking i know but its what we think about when we decide if we'll tell people to run lot=false or not
15:56 < AaronvanW> no that's exactly what I'm asking. why would it increase the risk of reorg?
15:56 < belcher> we went over this already
15:56 < belcher> you agree that bip148 had extra risks right? its the same thing here
15:57 < AaronvanW> one of us is not connecting the dots.
15:57 < belcher> communication is hard sometimes
15:58 < AaronvanW> "you agree that bip148 had extra risks right? its the same thing here" <--- what difference does the existence of LOT=false nodes make for reorgs?
15:58 < belcher> sorry iv had enough of this conversation, we can speak again tomorrow, bye for now
15:59 < AaronvanW> if you think I should just re-read the log and think about it, I'll do that.
16:01 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
16:03 < mol> thanks, guys, for the nice, polite, civilized, freshing, educational conversation, i love it. Please do it again :D
16:23 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 246 seconds]
16:31 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
16:34 < AaronvanW> belcher: you don't have to answer now, but I'm going to ask my next question now, before I forget it. if there are LOT=true nodes on the network, whether they're 1% of the network or 10% of 50%, would you agree that miners have an incentive to comply with the UASF, hence keeping the network together? or is there any % threshold (other than 0) where they wouldn't have this incentive?
16:38 < AaronvanW> (thanks btw mol)
16:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
16:43 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
16:43 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
16:43 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
17:06 -!- bcman [~quassel@192.252.212.46] has joined ##taproot-activation
17:07 -!- belcher_ is now known as belcher
17:09 -!- faketoshi [~quassel@104.200.129.53] has quit [Ping timeout: 252 seconds]
17:34 -!- matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has joined ##taproot-activation
17:36 -!- matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has quit [Client Quit]
18:46 -!- iohzrd [~iohzrd@static-198-54-131-88.cust.tzulo.com] has quit [Quit: WeeChat 3.1]
20:05 < rocket_fuel_> +1 for good discussion
20:32 <@aj> AaronvanW: "if there are X nodes on the network, miners have an incentive to comply with X, hence keeping the network together" -- the same argument applies when X is "censors non-KYCed transactions" not just "LOT=true UASF of taproot". so if you want node popularity to be a factor, you want a %ge higher than what the FATF and affiliated gov agencies could manage...
20:34 -!- bcman [~quassel@192.252.212.46] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
20:34 -!- faketoshi [~quassel@192.252.212.46] has joined ##taproot-activation
20:36 < luke-jr> aj: that's where !X nodes come in
20:42 <@aj> mmm, i look forward to your support of !X nodes post ST
20:44 < faketoshi> I'm on the edge of my seat and we're still 200 blocks away from the beginning
20:50 < luke-jr> I never promised to support anti-Taproot users, if they even exist.
20:51 < mips> faketoshi, i keep refreshing too. :)
20:54 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
21:05 <@aj> luke-jr: maaku's anti-taproot; https://github.com/bitcoin/bitcoin/pull/21393#issuecomment-815698514
21:05 < AaronvanW> aj: 1) when I say "% nodes on the network" in this context, I really mean % of the economy. Sorry if that wasn't clear. 2) It's not about what I want. 3) If there are anti-Taproot users, I think they should start using anti-Taproot clients now, not only post ST.
21:06 <@aj> AaronvanW: in so far as you're part of the economy, of course it's about what you want
21:06 < AaronvanW> anything I've said today isn't about what I want.
21:06 <@aj> AaronvanW: there are people that are against the bip8 lot=true approach, not so much against taproot
21:08 < AaronvanW> would they rather split the network than have LOT=true people get their way?
21:11 <@aj> AaronvanW: have you stopped beating your wife?
21:12 < AaronvanW> It was a honest question. (I don't have a wife.)
21:12 <@aj> (invalid assumptions is the point of that rhetorical question...)
21:12 <@aj> AaronvanW: there's been plenty of explanations about how running lot=true risks you splitting yourself off from the network; anyone who chooses to run it despite that shouldn't be blaming anyone else for being split off the network
21:13 < AaronvanW> I'm not blaming anyone.
21:13 <@aj> "would they rather split the network" sure sounds like it's assigning blame
21:14 < AaronvanW> no. sorry, let me rephrase. would they rather see a network split than have LOT=true people get their way?
21:14 <@aj> "will they give up their chance to run sensible rules that reduce the risks of splits, just because other people deployed something first that has a high risk of a network split?"
21:15 < AaronvanW> isn't LOT=false sensible?
21:17 < AaronvanW> or even just, nothing. surely that's sensible? that's what all of us have been running up till a week ago?
21:19 < AaronvanW> either way, I really don't mind how the question is phrased. I'm just looking for an answer. the way you phrased it is ok too.
21:19 <@aj> AaronvanW: if ST fails, i don't think an additional lot=false is sensible (unless there's bugs found in taproot and ST fails for that reason and the bugs are fixed)
21:20 < AaronvanW> is no activation mechanism at all sensible?
21:21 <@aj> AaronvanW: not enforcing the rules at all? sure; that still results in lot=true nodes getting forked off when someone spends to a "taproot" address and some miner extracts the funds to themselves
21:22 < AaronvanW> "if there are X nodes on the network, miners have an incentive to comply with X, hence keeping the network together" <- so do you disagree with this, in the context of Taproot?
21:22 <@aj> AaronvanW: there are other UASF approaches than bip8's lot=true, that imo make a lot more sense than the alt-client with lot=true, no lot=false nodes approach
21:22 < AaronvanW> I know.
21:23 < AaronvanW> "if there are X nodes on the network, miners have an incentive to comply with X, hence keeping the network together" <- so do you disagree with this, in the context of Taproot LOT=true? (edited)
21:23 <@aj> AaronvanW: i think market signals matter more than number of nodes, and i think acting like your argument is true has bad repurcussions for the ecosystem when it's adopted for "bad" X's
21:24 < faketoshi> aj: nice to know that maaku shares my perspective on MTP and saw the inevitability of a 'UASF' client. Why is he against taproot itself though? Any links you can share?
21:24 < AaronvanW> sorry, again, when I say "nodes" I mean "% of the economy". I'll try to be more clear from now on. (I made the mistake again because I copy/pasted your text.)
21:24 <@aj> AaronvanW: with market signals, mandatory nVersion signalling at a 90% threshold isn't particularly necessary or even helpful -- the only time it is is when there's an existing lot=false deployment adopted by a majority of nodes that will also be triggered to enforce
21:27 <@aj> faketoshi: https://twitter.com/MarkFriedenbach/status/1375000915837521930 and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018641.html
21:27 < faketoshi> ty
21:27 < AaronvanW> 'i think acting like your argument is true has bad repurcussions for the ecosystem when it's adopted for "bad" X's' <--- I believe my argument is specifically *only* true in situations where there is no "bad" X. It's Nassim Taleb's intolerant minority concept. We all drink kosher soda not because we all want kosher soda, but because some people *only* want kosher soda, and the rest of us don't care if it's kosher or n
21:27 < AaronvanW> ot.
21:29 < AaronvanW> If some people definitely didn't want kosher soda, there would be kosher and non-kosher soda. But because there is no "bad" X, there is no split.
21:29 <@aj> AaronvanW: yes, luke's made the intolerant minority argument on this channel before in arguing why soft fork's don't need consensus
21:31 <@aj> AaronvanW: imo the argument falls down as soon as you have two mutually intolerant minorities; and in general that happens pretty much instantly. when it doesn't, or when you selectively ignore some minorities, you're paving the way to giving control to that minority, which is how you end up with a small group having centralised control
21:32 < jeremyrubin> the main bit of the intolerant minority argument is that your intolerance has very little impact at scale on others
21:32 <@aj> AaronvanW: "Coca Cola bottled in Mexico is not certified as kosher." - https://www.kashrut.com/consumer/soda/ eg
21:32 < AaronvanW> aj: soft forks *do* need consensus imo, or else there would be a split. but I don't think soft fork *activations* don't need consensus? they just need to be as safe as possible. in gmaxwell's words, they're essentially scaffolding.
21:32 < AaronvanW> that double negative was unintended.
21:33 < AaronvanW> rephrased -> but I don't think soft fork *activations* need consensus?
21:34 <@aj> there's always the option of not caring about a consensus change, rather than supporting or opposing it; i think the difference is it's much more reasonable to not care about activation details?
21:34 <@aj> not caring about bip148 or bip91 was easy, and post-activation you can stop caring about bip9-activation of segwit and just remember the height it activated at
21:34 < AaronvanW> jeremyrubin: I don't think that's correct, because it affects miner incentives.
21:35 < jeremyrubin> AaronvanW: I'm just giving you the literal definition of intolerant minorty phenom
21:35 < AaronvanW> aj: exactly!
21:35 < jeremyrubin> So I agree that it's application here is incorrect
21:36 < AaronvanW> jeremyrubin: oh sorry, I misread/misunderstood. no I agree with you.
21:36 < AaronvanW> well I don't exactly, I agree with your definition.
21:37 < AaronvanW> if miners comply with LOT=true, that has no averse effect on all other nodes, right?
21:38 <@aj> AaronvanW: "rough consensus" means addressing the concerns of the people who object; i think that still makes sense for activation, even if there are many people in the "don't care" boat
21:38 < AaronvanW> aj: that's why I'm trying to address the concerns.
21:38 <@aj> AaronvanW: complying with lot=true will trigger "unknown activation" warnings on nodes that don't have compatible activation parameters
21:39 < AaronvanW> aj: that's solved if these nodes run LOT=false.
21:39 <@aj> AaronvanW: luke-jr claims lot=false is always bad to run
21:39 < AaronvanW> (or LOT=true)
21:40 <@aj> AaronvanW: matt claims lot=true risks unnecessarily losing hashrate
21:40 < jeremyrubin> https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15
21:41 < jeremyrubin> I think you can think of devs as the grocers and users as the shoppers. It's much more costly for devs to produce a LOT=true client, so they will not. Doing LOT=true is asking most shoppers to change their normal shopping habits.
21:41 < AaronvanW> I don't think Luke would object to Core running LOT=false until the actual LOT point. He didn't object to the concept of Speedy Trial. But I don't want to speak on his behalf.
21:41 <@aj> AaronvanW: he specifically wrote an email about that, and promised to NACK any lot=false PRs in core
21:42 <@aj> AaronvanW: search for NACK in http://gnusha.org/uasf/2021-03-02.log and see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
21:42 < AaronvanW> luke-jr: would you object to -- say -- as second ST deployment in Core, if this ST times out? using BIP8 this time?
21:44 < AaronvanW> or extending the current one until the end of the year, or something like that, if that's possible?
21:44 < jeremyrubin> freenode_##taproot-activation.log:[Wednesday, April 14, 2021] [3:08:02 PM PDT] <AaronvanW>      luke-jr: I know you NACK both, but if you had to choose, do you have a preference between BIP 8 LOT=false (1 year) and the current version of Speedy Trial?
21:45 < jeremyrubin> so conceivably you do know that luke is nack BIP8 false already ;)
21:45 <@aj> AaronvanW: to have any relevance to the lot=true client, it'd need to be extended until whatever it's timeoutheight is
21:45 < AaronvanW> jeremyrubin: hmm
21:46 < AaronvanW> aj: no it would be better for Core users if ST is extended by however long is possible to get consensus on, imo.
21:48 < jeremyrubin> sigh
21:48 < jeremyrubin> FWIW this is why I NACK'd height for ST
21:49 < jeremyrubin> There is no point in doing ST at all if there's going to be a UASF client that ST has to be compatible with
21:50 < jeremyrubin> the whole point was to fail fast
21:50 < jeremyrubin> get another shot with better coordination'
21:51 < jeremyrubin> precomitting to the second shot before we resolve the first makes ST pointless...
21:51 < jeremyrubin> that's why it's disengenous that the client is called ST+BIP8LOT=true
21:51 < jeremyrubin> Notably, a trial cannot have a predetermined outcome
21:52 < jeremyrubin> failability is part of the design
21:52 <@aj> AaronvanW: the theory of speedy trial is to determine whether miners are immediately ready to activate; if they are, it succeeds with no problems; if they're not -- despite taprootactivation.com and whatever else -- we figure out if there's a good reason; if there is, we fix it; if there's not we do a UASF. in none of those cases is "give miners more time" generally useful (unless the "good
21:52 <@aj> reason" is that "upgrading to 0.21.1 didn't work because of huge unrelated bugs" maybe)
21:52 < AaronvanW> jeremyrubin: I think you wrote on the dev-list at some point that developers may wish that LOT=true didn't exist, but it does exist, so now that's the reality we have to start thinking in. that's all I'm trying to do. maybe that's obvious, but just wanted to emphasize that.
21:54 < AaronvanW> aj: I'm not proposing to give miners more time, not more time than the LOT=true october 2022 deadline anyways.
21:54 <@aj> AaronvanW: extending ST until the end of the year is just giving miners more time, nothing else
21:55 < AaronvanW> not more than the oct 2022 deadline...
21:55 <@aj> "<AaronvanW> or extending the current one until the end of the year,"
21:55 < AaronvanW> we're in 2021
21:55 <@aj> yes
21:55 <@aj> extending ST until the end of the year does nothing useful
21:56 < AaronvanW> it gives Core users Taproot if miners activate it before the end of the year, which then also protects them against ugly reorgs. (remember, they can activate on the LOT=true client either way.)
21:57 <@aj> if miners were going to activate it quickly, they'll do so in the ST period
21:57 <@aj> if they don't do that, why do you think they'll activte in a few months following that, particularly without any UASF code in core?
21:57 < AaronvanW> I hope you're right. but what if they don't? what if they activate in september?
21:58 < AaronvanW> I don't know *why* they would do it, I just know that they could.
21:58 <@aj> then that would be an amazing validation of luke's arguments that doing activation in outside of core with mandatory UASF is the way to do things
21:58 <@aj> s/in outside/outside/
21:59 < AaronvanW> yes it would be. but Core users would then not have Taproot (yet) and be at risk of ugly reorgs in the mean time.
21:59 < AaronvanW> what's the benefit
21:59 <@aj> they might also signal for activation in late october, causing the UASF nodes to activate in november, then steal taproot outputs as soon as activtion occurs to deliberately fork those nodes off the network
22:00 < jeremyrubin> AaronvanW: fwiw, what I said was:
22:00 < jeremyrubin> If I had to summarize the emotional dynamic among developers around LOT=true, I think devs wish it didn't exist because it is clear LOT=true *creates* the issues here. LOT=false would be fine if the LOT=true strategy didn't exist at all. But unfortunately the cat is out of the bag and cannot be put back in. To validate the emotions, I think it is fine to be angry about LOT=true and not like it, but we should either accept
22:00 < jeremyrubin> that it is most likely to create consensus OR we should find a new game theoretic activation strategy with better pro-social equilibriums.
22:00 < jeremyrubin> we did find that!
22:00 < AaronvanW> one miners can do that. what will the next miner do? mine on that chain, or mine on the more profiteable UASF chain?
22:00 < jeremyrubin> It's called ST
22:00 < AaronvanW> *one miner
22:00 <@aj> AaronvanW: why would the UASF chain be more profitable?
22:01 < AaronvanW> "if there are X [economic] nodes on the network, miners have an incentive to comply with X, hence keeping the network together"
22:01 <@aj> AaronvanW: you're going back to nodes not economic participants
22:02 < AaronvanW> if they mine the UASF chain, they (eventually) get ALL economic participants.
22:02 <@aj> AaronvanW: if miners know what the economy prefers, eg, because there's a future's market; then the miner that mined a UASF-invalid block just threw away 300k USD (assuming prices stay at current levels)
22:02 <@aj> AaronvanW: otoh, if they know the economy doesn't care about the lot=true UASF, then everyone will just keep building on the most work chain irrelevant of whether it's lot=true valid
22:03 < AaronvanW> aj: yes, if they know the economy doesn't care about the UASF chain _at all_ I agree. Do you expect that to be the case?
22:04 < AaronvanW> 0%
22:04 <@aj> AaronvanW: if there is a minority of hashpower on the UASF-valid chain, then the non-UASF miners will just do wipeout protection, by considering the UASF chain invalid. it's not hard
22:04 < jeremyrubin> aj: no code change required, just a call to invalidateblock
22:05 < AaronvanW> that would require miner coordination ie centralization, right?
22:05 < jeremyrubin> AaronvanW: nope; miners can just invalidateblock the stale orphans < 1 day ago
22:05 < jeremyrubin> *>
22:05 < AaronvanW> individual miners can.
22:06 < AaronvanW> ans risk getting stuck on a minority chain themselves.
22:06 <@aj> AaronvanW: it'd likely be done at the pool level, and only be relevant for a short period. mining a minority chain with bitcoin difficulty rules without a _lot_ of economic support seems pretty infeasible when you run the numbers
22:07 < jeremyrubin> also if a small # of miners are ruinning LOT=true, it might even be profitable a la selfish mining to force them off
22:07 < jeremyrubin> we already see miners devote hashrate to e.g. attacking other pools
22:07 < AaronvanW> so you think miners would want to split the network over this?
22:08 < luke-jr> [04:40:21] <aj> AaronvanW: matt claims lot=true risks unnecessarily losing hashrate <-- which is false
22:08 <@aj> AaronvanW: "mining either chain costs $200k per block in hashpower; this chain's reward is worth $300k, the other chain's reward is worth $50k, maybe i'll hack my pool software to be sure it never gives out work for the second chain" doesn't require centralisation to have everyone make the same decision
22:08 < luke-jr> AaronvanW: I don't see the point to a second ST
22:10 < AaronvanW> aj: you are suggesting that miners would rather go to "war", split the network etc. in order for (some) miners to steal Taproot outputs (one time)... instead of complying with the UASF. Is this a fair assesment?
22:11 < faketoshi> one of the easiest ways to be compatible with based luke-jr ?
22:11 < AaronvanW> I don't mean to strawman, please correct me if this was a strawman.
22:12 < AaronvanW> maybe not even "comply with the UASF"... just "enforce Taproot".
22:12 < luke-jr> faketoshi: it's not really compatible; it's a hardfork essentially
22:12 < jeremyrubin> AaronvanW: do you think any non signalling orphans would be generated during the final period?
22:12 < jeremyrubin> (as in orphans from PoV of LOT=true)
22:13 < jeremyrubin> s/orphans/invalid blocks
22:13 < AaronvanW> jeremyrubin: personally I think that's unlikely. we didn't see any in the case of BIP148 AFAIK.
22:14 < luke-jr> miners have nothing to gain from mining invalid blocks during MUST_SIGNAL
22:14 < jeremyrubin> but in all leading periods up to MUST_SIGNAL, it was not set to signal > 90%
22:14 < jeremyrubin> and in the last period that behavior changes
22:14 < jeremyrubin> I think it would be likely to see at least a few
22:15 < AaronvanW> yes that's what we saw in the case of BIP148. I think it's much more likely they'll activate long before that though.
22:15 < jeremyrubin> sure, but we're doing bayesian reasoning here
22:15 < jeremyrubin> so mind your priors
22:15 < luke-jr> it's unlikely we'd ever reach that point, so long as it's there
22:16 < AaronvanW> I didn't expect it then, and it didn't happen. I wouldn't expect it now.
22:17 < AaronvanW> I explained in an op-ed for Bitcoin Magazine at the time why I didn't expect it then: https://bitcoinmagazine.com/technical/op-ed-heres-why-all-rational-miners-will-activate-segwit-though-bip148
22:17 < AaronvanW> (Only article I ever published as an op-ed, because I wasn't *sure*.)
22:19 <@aj> AaronvanW: i could imagine some miners considering an unnecessary lot=true UASF attempt as a "first strike" and deciding to respond to that aggressively on a "they want war, we'll give them war" basis. i don't think it's likely; since it'd require failing ST and delaying taproot.
22:20 < AaronvanW> aj: if they wanted war, they could have gotten war in 2017.
22:20 <@aj> jeremyrubin: i think it's likely miners would run a bip91 style coordination mechanism prior to the must_signal phase
22:20 < AaronvanW> I don't think miners want war. they want peace. they want to make money.
22:21 <@aj> AaronvanW: i'm not saying miners want war, i'm saying lot=true advocates do (or may be perceived to)
22:21 < AaronvanW> I don't think that's true either.
22:21 < AaronvanW> LOT=true users want Taproot.
22:22 < AaronvanW> Not war.
22:22 <@aj> again, maaku's an example of someone who wants lot=true and does not want taproot
22:23 < luke-jr> some don't even care about Taproot, just want to keep the precedent that users decide protocol rules,  not miners (or devs)
22:23 < luke-jr> aj: maaku isn't even a bitcoiner
22:23 < luke-jr> (which is why I don't consider his NACK on Taproot to have any weight/relevance)
22:24 <@aj> luke-jr: he's a bip8 lot=true'er though
22:24 < luke-jr> aj: yes, because he understands the importance of decentralisation
22:24 < luke-jr> and knows that if Bitcoin dies, so will his altcoin
22:24 < luke-jr> (I think he acknowledges that.. could be wrong)
22:25 < jeremyrubin> maybe he wants bitcoin to die so his altcoin picks up traction
22:25 < jeremyrubin> who knows
22:25 < luke-jr> lol, that would never happen
22:25 < luke-jr> his altcoin could never compete - totally different economics
22:26 < jeremyrubin> i guess to be fair he would have ACK'd taproot and then popped it with a QC
22:26 < luke-jr> >implying such a QC exists
22:32 <@aj> every altcoin dev starts off by building themselves a working QC as a training exercise
22:48 < AaronvanW> so maybe there's two categories of LOT=true proponents. (or rather, two extremes.) one category just wants Taproot. the other category just doesn't want miner veto. but I don't think either wants war. (we could probably further subdivide into LOT=true'ers that want LOT=true in Core, and LOT=true'ers that want LOT=true in an alt-client to avoid the perception of dev control. But I digress.) "We don't war, but if you wa
22:48 < AaronvanW> nt war, you'll get war" is probably a fair characterization of some of them. "We just want war," really isn't, as far as I can tell. If that's a perception, and if that perception is really the problem/risk, it would be good if that perception could somehow change.
22:51 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
23:15 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Quit: Leaving]
--- Log closed Fri Apr 30 00:00:41 2021