--- Log opened Thu Apr 22 00:00:33 2021
00:36 < pox> I like ST because if miners don't signal in time, we see exactly which pool is the laggard and we can ask them why.
00:38 < pox> If it's just "laziness" (more realistically, unless they see TR as a boon to their profits, they don't have a strong incentive to upgrade / rock the boat), then something like LOT=true with a shorter period (3m) could incentivize them.
00:39 < pox> If they don't signal because of some material objection, it can be addressed and the community can decide if the objection is warranted and whether or not the SF should be forced despite it.
00:40 < pox> In a sense ST is optimistic activation + a fact finding mission.
00:44 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
01:10 <@michaelfolkson> Thanks for providing facts/information here and making clear what is your opinion jeremyrubin (no sarcasm intended, I think this is fine)
01:20 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 268 seconds]
01:25 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
03:06 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
03:09 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
03:36 <@michaelfolkson> I think I will upgrade my Core node to the release candidate and sync the Bitcoin Core 0.21.0-based Taproot Client 0.1 node from genesis this weekend.
03:37 <@michaelfolkson> Bitcoin Core 0.21.0-based Taproot Client 0.1 is currently syncing on Fork Monitor https://forkmonitor.info/nodes/btc
03:41 <@michaelfolkson> "once signaling officially starts getblockchaininfo will report the number of signaling blocks in the current period" https://mastodon.social/@ajtowns/106108519281794313
03:44 <@michaelfolkson> Miner signaling is due to start next Thursday (April 29th)
03:55 < AaronvanW> jeremyrubin: 'if miners are like "no, and here's why not" [...] Then we can at least... try to fix it' <--- I think this assumes that miners are a centralized/identifiable group of people. That actually to a large extent is the case today, unfortunately. But hopefully long-term miners will be more decentralised/anonymous. In that world, the only reliable answer you could get is based on hash power signalling itself. S
03:55 < AaronvanW> o in that world, devs would ask miners (through ST): "Hey do you want this?" Miners answer: "No." Devs (implementing LOT=true or a flag day): "Well here you have it anyways." So, in that world, devs might as well just implement LOT=true or a flag day right away, if that's the plan anyways.
03:56 < AaronvanW> In other words, ST might make some sense now, but only because mining is too centralized.
03:56 < AaronvanW> And therefore it definitely shouldn't be considered a long-term solution.
04:00 <@michaelfolkson> AaronvanW: But also what do you learn by them not signaling that you couldn't learn by asking them before signaling begins?
04:01 <@michaelfolkson> People seem to hold the signals in this magical regard. Unless you speak to them you have no idea why they did or didn't signal
04:02 <@michaelfolkson> If you couldn't contact them before signaling starts you probably can't contact them after signaling ends
04:02 < AaronvanW> michaelfolkson: I guess pox' answer is "you need to ask fewer pools; only the ones that didn't signal." But there are only a handful of pools out there anyways, so yeah... (Alejandro *did* in fact ask just about all of them.)
04:02 <@michaelfolkson> If you could contact them before signaling starts, contact them lol
04:04 <@michaelfolkson> Unless they include a message in their mined block (e.g. OP_RETURN) to say why they did or didn't signal. I don't think that has ever happened/will happen?
04:05 <@michaelfolkson> AaronvanW: Right Alejandro tried with all of them as far as I understand
04:06 < AaronvanW> I guess a new anti-Taproot pool could pop up *after* signaling started. We actually saw that happen with Segwit in ViaBTC. Then you have someone to ask. (Assuming that the anti-pool operator even has an opinion, and isn't just facilitating.)
04:07 <@michaelfolkson> How much hash rate did ViaBTC suddenly pop up with? Do you know approximately?
04:07 < AaronvanW> Just enough to block Segwit ;)
04:08 <@michaelfolkson> I guess with 95 percent threshold you don't need *that* much. Still a challenge though I'm guessing
04:08 < AaronvanW> It's generally considered to have been a Bitmain proxy.
04:08 <@michaelfolkson> Gotcha
04:08 < AaronvanW> I guess they had 8% or so.
04:11 <@michaelfolkson> Was there interest in following the signaling in online forums, social media at the beginning of the SegWit BIP 9 deployment?
04:11 <@michaelfolkson> I'm guessing it was pretty technical and not particularly mainstream until SegWit2x and UASF started happening
04:12 < ghost43> there were posts on reddit with state of signalling ~every week, urging miners to signal
04:13 <@michaelfolkson> ghost43: Cool, like niche Reddit posts or posts with lots of engagement?
04:15 < ghost43> I remember seeing them on the front page of the subreddit without much scrolling, so there definitely was interest
04:16 < ghost43> it seemed to take a long time to implement segwit and roll out activation in the first place, so people were eager to see results already when activation started
04:17 <@michaelfolkson> I wonder how fast the signals will come in this time. I'd have thought the shorter signaling period (3 months) would be a forcing factor to signal early. A year and there is no need to do anything for months
04:18 <@michaelfolkson> Not only shorter signaling period (3 months) but also presence of an alternative BIP 8(LOT=true) release
04:25 <@michaelfolkson> sipa had these graphs for SegWit http://bitcoin.sipa.be/versions.html
04:26 < AaronvanW> michaelfolkson: the block size war had already been underway for well over a year when segwit was released in bitcoin core, and people were definitely paying attention.
04:27 < AaronvanW> there were special segwit activation tracking websites and stuff like that iirc.
04:28 < AaronvanW> there were even popular node tracking websites, which were off course being sybil attacked etc.
04:28 < pox> >> "And therefore it definitely shouldn't be considered a long-term solution." <- indeed! in a future world of highly distributed mining the risk from large pools delaying activations is reduced. ST is the right solution for today.
04:29 < ghost43> funny to think about it, but I think for segwit, time between initial concept and mainnet activation was shorter than for taproot, hah!
04:29 < AaronvanW> yeah about nine months I think?
04:30 <@michaelfolkson> "Segwit went from early public discussions to merged in six months. So in spite being more complex and subject to more debate due to splashback from blocksize drama, segwit was still done in significantly less time already."
04:30 <@michaelfolkson> https://www.reddit.com/r/Bitcoin/comments/hrlpnc/technical_taproot_why_activate/fyqbn8s/
04:30 < ghost43> no I mean when where the first public talks/mailing list posts about segwit? near end of 2015? at it activated Aug 2017. so like 2 years
04:31 < AaronvanW> first publicly announced at Scaling Bitcoin II, December 2015.
04:31 < AaronvanW> Activation Code released in Bitcoin Core 0.13.1, October 2016.
04:32 < AaronvanW> Activated August 2017.
04:33 <@michaelfolkson> Right. That is a quick turnaround compared to Taproot
04:34 <@michaelfolkson> Taproot "announced" to mailing list January 2018 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
04:35 < pox> <@michaelfolkson> If you could contact them before signaling starts, contact them lol <- ST assumes they didn't outright lie about their intention to activate TR and gives them a chance to prove their earlier statements, and quickly. if they don't, it's *they* that need to approach the community and explain why they're withholding TR from the network. If they don't, then they essentially give up their seat in the discussion and if that turns
04:35 < pox>  out to be the case, which I doubt it will, there are always other options available to us. But to assume that they've been all lying and will stonewall after ST expires is irrational. TR isn't a SF that hurts miners in any way, and they have a vested interest in BTC's value not dropping owing to more forks.
04:35 < ghost43> segwit did not need months of discussing how to activate; bip9 was implicit. imagine if we started a bip8(1y, false) while arguing about activation. it would get activated sooner than with ST :P
04:36 < ghost43> or just bip9 like before
04:37 <@michaelfolkson> pox: That is your particular framing (which is fine). There are alternative framings though. ie If you aren't ready you don't signal readiness. But you don't lose your "seat at the table" just because you weren't ready
04:37 < ghost43> in any case I'm glad there is rolled out code now with activation, finally arguing is not really blocking things anymore
04:37 <@michaelfolkson> ghost43: Agreed
04:38 < pox> @michaelfolkson this assumes 3 months isn't a reasonable timeframe (with a 2x buffer) for any miner to "get ready". if that's correct, then ST should extend the timeframe accordingly. I can't imagine a simple version upgrade could take 3 months for a professional operation.
04:39 <@michaelfolkson> pox: So why was 1 year considered if 3 months is more than enough?
04:39 <@michaelfolkson> pox: To be clear approx 90 percent of mining pools have responded to a survey saying they support Taproot. That says nothing about readiness. Also 10 percent didn't respond
04:40 <@michaelfolkson> pox: So it is quite possible Taproot doesn't activate during Speedy Trial (hopefully unlikely)
04:40 < ghost43> 1 year was used in the past because there was no min activation height.
04:41 < pox> good question. 1y always seemed insanely long to me, but I'm not the right person to opine on that. and this is exactly the sort of input we would like to get in case ST fails - if miners can demonstrate that 3m is unreasonably fast for their ops then  that's good data.
04:41 <@michaelfolkson> ghost43: But it could have activated after the first 2 weeks of signaling
04:42 < ghost43> +2 week lock-in, but yes
04:42 < ghost43> though I think that's extremely unlikely
04:42 <@michaelfolkson> pox: My point is ask them before. If they wanted more than 3 months we should have asked them and they should have told us
04:42 < ghost43> just like it's extremely unlikely that ST will activate it during the first period
04:43 <@michaelfolkson> ghost43: Right. My point was just that giving a whole year for readiness seems long to me if it technically could activate within a month
04:43 < ghost43> I think the model with bip9 was that miners organically upgrade their software, and users likely upgrade in a similar fashion
04:44 < ghost43> if you assume that, then whenever it activates most users are already upgraded
04:44 <@michaelfolkson> pox: In a decentralized world that it is impossible (or at least much more difficult) of course
04:45 <@michaelfolkson> *that is impossible
04:47 < pox> If the claim is there's no difference for miners between informal polling by a dev and actively avoiding upgrading their nodes in order to not signal readiness, then I find it unconvincing. if ST fails to activate and it's clear that <MINER NAME> was the one withholding the last % hashrate, it's a very public and inconvenient bit of PR for them. that pool could hurt its business if "grinders" see it as being detrimental to their bitcoin
04:47 < pox>  business.
04:48 < ghost43> the model with ST is to urge miners to quickly upgrade to show that they want taproot otherwise it gets delayed for who know how longs. the model (I think) with bip9 was to have people organically upgrade, detect when that reaches critical mass, and then activate. ST does not work like that: we have data that suggests people would not normally upgrade within 3 months
04:49 <@michaelfolkson> pox: My point is whatever information you could get after a failed Speedy Trial you could have probably gotten before the Speedy Trial started. I agree that you can be more targeted on who you ask afterwards
04:49 < ghost43> michaelfolkson: that point was disproven with segwit activation though
04:49 < ghost43> as others have said before
04:51 <@michaelfolkson> ghost43: In war it was disproven. In peacetime it hasn't. Plus it is probabilistic. I'm not saying it will *always* happen a certain way. I'm saying it is most likely that info before = info after regarding readiness or not
04:51 <@michaelfolkson> Outliers happen
04:52 < ghost43> but even with segwit it was not clear it was "war" until signalling started
04:52 < ghost43> how do you know it is peacetime now?
04:52 < pox> Having any sort of deadline to incentivize action (in either direction) is typically helpful for a project. The notion that miners are oblivious to core releases and would only update organically on their spare time over the weekend is weird. And also having "surprise" activation hoisted on said oblivious miners just because an arbitrary threshold has been crossed *at an unpredictable date* is riskier than trying to get everyone to upgrade
04:52 < pox>  quickly in a reasonable timeframe, without negative consequences if it fails (only positive ones: more accurate data on who's not on board)
04:52 <@michaelfolkson> ghost43: If it isn't I'm not looking forward to the rest of this year ;)
04:54 <@michaelfolkson> ghost43: I do think people read waaaay too much into what happened re SegWit for future soft forks. It was a sample size of 1 after all. Different dynamics, different players each time. There were lessons to learn though
04:54 <@michaelfolkson> Not that I want to get into what those lessons were though as that will kick the hornets nest again
05:00 <@michaelfolkson> pox: Agreed, those are basically the arguments for Speedy Trial
05:08 < pox> the comparison with segwit isn't helpful. faster isn't always better. bitcoin has grown immensely since then I'm, for one, perfectly content with enhancements being made very slowly. I think the TR activation discussion yielded a much more reasonable method (ST), which I don't see as a compromise at all - it's better than what was widely popular initially (LOT=false,1y) in a few ways. It isn't bike shedding if it's literally the underpinning
05:08 < pox>  of a trillion dollar asset. The UASFYOLO, "enough talking", "miners have no say" attitude is unclear to me. we get TR when we deserve it ;)
05:13 < aj> AaronvanW: ST really asks something more like "Hey, do you want this ASAP?" -- "no" doesn't necessarily mean "not at all", it may just mean "no, it's not enough of a priority for us to upgrade and signal quickly"
05:13 < aj> AaronvanW: miners upgrading is the only real way you can do a quick soft fork safely -- if hashrate doesn't uprade, you can get short forks easily that are visible to anyone else who can't upgrade quickly
05:15 < aj> AaronvanW: as far as "because you can ask them" -- miners could add a "taproot isn't quantum safe enough" tag to their coinbases if they wanted, without requiring them to reveal an identity; and pools could publish the %ge of shares that have that signal if you wanted a finer-grained judgement from miners than ~2000-every-two-weeks
05:16 <@michaelfolkson> pox: You either give miners a permanent veto on soft forks or someone pushes a BIP 8(LOT=true) release. You will never get overwhelming consensus on when to push that BIP 8(LOT=true) release and who should push it
05:17 <@michaelfolkson> pox: Personally I am very happy that if Speedy Trial fails we don't have to have a 6 month discussion or longer on when BIP 8(LOT=true) would be appropriate to push out
05:18 <@michaelfolkson> pox: Hence I disagree with your framing that it is "miners have no say". At some point miners have no say unless you want to give them a permanent veto
05:19 <@michaelfolkson> pox: We just disagree on when that point should be. I think (and many others do) that November 2022 is perfectly reasonable
05:20 < pox> that's like saying miners have a veto on which tx get mined. yes, they do. only thing preventing censorship is their economic interest. they also need to actually mine TR, and if they don't for some reason then they either engage and explain why. otherwise they lose business. hashing power will divert from incalcitrant pools.
05:21 < pox> the thing about owning nukes is that you don't really have to use them all the time. or hardly at all. the threat of flag day activation is always there, as an added incentive to play along. doesn't mean it has to used for every SF.
05:21 < aj> ghost43: bip9 had months of discussing about how to activate; see https://github.com/bitcoin/bitcoin/pull/6816 to https://github.com/bitcoin/bitcoin/pull/6816 (not sure when discussion started prior to PRs being proposed for merge)
05:22 <@michaelfolkson> pox: It doesn't get used here unless we get to November 2022. If we get to November 2022 something has gone badly wrong
05:23 < aj> bip 34 took about 9 months to activate via ISM, rounding that up might have been why 1 year was picked
05:24 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
05:24 <@michaelfolkson> aj: Those two links are the same?
05:25 < ghost43> aj: right; I meant segwit did not need discussion how to activate once bip9 was there. bip9 itself had quite some discussion prior to that indeed
05:25 < aj> 7575 was the one that was actually merged
05:27 < aj> miners not upgrading isn't "something going badly wrong"
05:27 <@michaelfolkson> aj: It is by November 2022. What has gone on to get there?
05:28 <@michaelfolkson> pox: Different problems. A transaction only needs to get mined by a single miner. A soft fork needs to be signaled by 90 percent of miners (in this case)
05:31 < pox> I was just making a point about economic incentives. A single mining pool withholding TR could get punished a lot more severely than a miner that forgoes some censored tx fees. Pools are a schelling point for miners and are susceptible to reputational damage, a lot more than any pool that silently censors a tx.
05:33 < pox> but again, the point is there's no need to assume miners only ever upgrade because once the UASF nuked was dropped. they will, and if they don't there's no real harm in engaging with them to hear why. the "or else" is implied and that just helps.
05:36 < AaronvanW> ghost43: 'but even with segwit it was not clear it was "war" until signalling started' <--- yes, it was. eg.: https://bitcoinmagazine.com/business/antpool-will-not-run-segwit-without-block-size-increase-hard-fork-1464028753
05:38 <@michaelfolkson> luke-jr: "Does anyone expect to have more than 10 ongoing softforks at a time anyway?" https://github.com/bitcoin/bitcoin/pull/6816/files#r42942565
05:38 <@michaelfolkson> Lol gotta love 2015
05:43 < aj> michaelfolkson: no, not upgrading even by nov 2022 is fine -- that's why bip8 allows for 10% of miners not to signal even if the MUST_SIGNAL phase is reached, and a pure flag day works okay even with only 1%-10% of hashrate upgrading (provided the rules are still enforced by nearly all nodes used for economic purposes)
05:46 <@michaelfolkson> aj: "get to November 2022" = "We haven't managed to get 90 percent of miners to signal readiness in 1.5 years
05:46 <@michaelfolkson> If they're not going to do it in 1.5 years they're never going to do it
05:47 <@michaelfolkson> Forced signaling or flag day, whatever. You're not giving miners a say anymore at that point
05:48 <@michaelfolkson> There are arguments for forced signaling https://bitcoin.stackexchange.com/questions/102585/what-is-the-benefit-of-forced-signaling-in-a-soft-fork-activation-mechanism
05:48 < AaronvanW> aj: I agree that ST failing doesn't necessarily mean miners don't want Taproot, but my point remains the same. The _only_ extra feedback devs could have possibly gotten after ST, came back negative. (Miners didn't want Taproot enough to upgrade quickly.) How can devs justify deploying LOT=true or flag day after ST, if they couldn't justify it before ST?
05:50 < aj> michaelfolkson: "get to November 2022" -- the only way you do that is by miners not upgrading. (or i mean, in some more absolute sense, i guess "by not dying" would be an answer...)
05:50 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
05:51 < AaronvanW> IMO there are three options. 1) Core devs can deploy activation code based on their best judgement of what users want. ST doesn't change anything. 2) Core devs cannot deploy activation code based on their best judgement, if miners don't activate, activation needs to happen through alt-clients. 3) Miners have a veto on upgrades. (I don't think 3 is possible, given that users can always UASF, but it can be the "official
05:51 < AaronvanW> " Core dev position anyways.)
05:52 < AaronvanW> By "activation code" I mean LOT=true or flag day.
05:53 <@michaelfolkson> AaronvanW: Agreed. I'm 2) I don't think Core will ever deploy forced signaling or flag day code again based on some people's views expressed during this exercise
05:53 < aj> AaronvanW: from my perspective, the change that justified ST was the sudden loss of any liklihood of achieving consensus around an upgradable lot=false release -- ie lot=false on a long timeframe in core, with a later upgrade switching it to lot=true. that possibility disappeared (in my opinion) in late february when luke posted his "lot=false is dangerous in all cases" mail to the list, patches
05:53 < aj> weren't being proposed even to bring the bip8 PR up to the standards that the bip148 client met, and suhas and matt were also raising more concerns about alt clients for lot=true, etc.
05:53 < aj> s/late february/late feb or early march/
05:55 < AaronvanW> aj: I understand how ST came to be, and I'm not necessarily against it, I just don't think it really makes any sense, at least long-term. I think Core devs will have to make a choice between options 1, 2 and 3 outlined above sooner or later.
05:55 <@michaelfolkson> AaronvanW: I also thought it was possible that Core wouldn't release any activation code whatsoever for Taproot
05:56 < aj> AaronvanW: lot=true simply isn't the only other option than lot=false; but "just signalling against activation / not upgrading" isn't the only thing miners can do either. it's certainly not all they did during segwit -- there were conferences, alternative implementations, in person meetings, etc. and that was (presumably) _with_ a secret agenda that they didn't want to reveal publicly
05:58 < AaronvanW> aj: LOT=true, LOT=false, flag day, do nothing. Am I missing an option?
05:58 <@michaelfolkson> AaronvanW: I think ST could be used again for future soft forks as the only attempt by Core to get a soft fork activated before leaving it to alt clients
05:58 < aj> AaronvanW: speedy trial is (in my opinion) pretty perfectly optimised for the good case -- it checks there's a supermajority of miners in support which is what makes it safe to activate fast -- you can do it with 50%-80% of the economy upgraded; if you don't have miners upgraded, you need something closer to 99% -- because the nodes that aren't upgraded are vulnerable to long reorgs
06:00 < AaronvanW> My question is more about what to do after ST.
06:02 < AaronvanW> (In the good case I think anything probably works. I'm more interested in the bad case.)
06:02 < aj> AaronvanW: decreasing threshold, revocable flag day, combinations of those options, probably others. we had been exploring lot=false->lot=true along the lines of bip148 to the exclusion of those ideas.
06:04 -!- Netsplit *.net <-> *.split quits: bob333, _0x0ff, jesseposner, belcher, jonatack, nioc
06:04 <@michaelfolkson> Just seems like overengineering and indecisiveness to me (plus none of these were seriously discussed when harding first did his summary)
06:04 < aj> AaronvanW: "if it bleeds it leads", i guess. it's good to have an ER be able to induce a coma and put you on a respirator when that's necessary, probably worth making sure there's a smoother path when that's not necessary
06:05 <@michaelfolkson> You are either going to eventually enforce the soft fork rules or you're not
06:05 -!- Netsplit over, joins: jonatack, belcher, _0x0ff, nioc, bob333, jesseposner
06:05 <@michaelfolkson> This dipping toe in and out of the water seems suboptimal
06:06 < aj> "you're not" may involve enforcing the same soft fork rules under incompatible activation parameters, or an improved but incompatible variant. it's not a useful dichotomy.
06:06 < AaronvanW> aj: these all fall within the three options I laid out (option 1), or do you disagree with that?
06:06 < aj> AaronvanW: no, none of those are compatible with a lot=true client
06:08 < aj> AaronvanW: i could see you considering them variations of a flag day, i guess, but then you might as well call lot=true a flag day too
06:08 < AaronvanW> aj: Hm? I didn't single out LOT=true or a LOT=true client? Option 1 was: Core devs can deploy activation code based on their best judgement of what users want.
06:08 < aj> <AaronvanW> aj: LOT=true, LOT=false, flag day, do nothing.
06:08 < aj> "core devs will deploy activation code based on their best judgement" seems like a tautology to me
06:09 <@michaelfolkson> I think AaronvanW's point is there wouldn't be overwhelming community consensus for any one of these
06:09 <@michaelfolkson> Even in the case where one was superior to BIP 8(LOT=true) which I don't think any of them are
06:09 < aj> we haven't even started discussing any of them, of course there's no overwhelming consensus for any of them
06:09 < AaronvanW> "i could see you considering them variations of a flag day, i guess, but then you might as well call lot=true a flag day too" <-- sure
06:10 < AaronvanW> So let me rephrase option 1. Core devs can deploy a flag day based on their best judgement of what users want.
06:10 < AaronvanW> (And we'll consider LOT=true a flag day.)
06:11 < aj> AaronvanW: yes, that's what matt's been saying forever, and what almost everyone's said should happen if ST fails without there being some good reason discovered for why it should fail
06:12 < AaronvanW> If you think option 1 is the right answer, I see no added benefit in trying ST first. Just start with decreasing threshold, or... whatever.
06:12 <@michaelfolkson> 1 is Core devs decide this will activate at some point regardless of what miners think
06:12 < AaronvanW> That's my point.
06:13 < AaronvanW> I guess it's "fine" for now because it helps move things forward, but I see no good reason why it should be considered a long-term solution.
06:13 < aj> AaronvanW: prior to ST, the bip8 plan had the startheight targetted at july or august since lockin could happen two weeks later, and nodes would still be running non-taproot-aware 0.20.x versions (which will still be "supported" until 22.0 is released), ST brings the possibility of lockin forward dramatically
06:14 < aj> AaronvanW: iirc the ST timeline was roughly set so that it would be over by the time bip8 lot=something was going to begin, though i suspect that slipped in the meantime
06:15 <@michaelfolkson> I'm 2 though AaronvanW. Speedy Trial in Core. If that fails Core leaves it to alt clients. Could be repeatable for future soft forks
06:16 < aj> michaelfolkson: no, that's not true. core devs will implement software that does what they think's best, same as everyone should do. if miners come up with good reasons why core devs are mistaken in their belief of what's best, they'll change their minds. if they just disagree and aren't able to provide good reasons why, they'll get argued with, and eventually ignored.
06:16 < AaronvanW> aj: delayed activation can be combined with any oter activation scheme. (the LOT=true client in fact does this.)
06:17 <@michaelfolkson> aj: One I'm not exactly sure of an example of a good reason excluding a bug. Two, is Core going to try to get community consensus on this follow up or make decisions without consulting the community?
06:18 < aj> AaronvanW: sure, it's software, lots of things can be combined. the advantage of it ending soon is that you can react and change your mind if necessary. that's not something luke and other lot=true advocates value in this case, but it's something other people, including myself, do
06:18 < aj> michaelfolkson: an enormous optimisation would be a good reason to fail a soft fork, make changes, and re-release it
06:18 < AaronvanW> you can have a MASF phase prior to LOT=false, LOT=true or flag day, and you can implement a min start height in all cases.
06:19 < AaronvanW> aj: I think what I'm trying to understand is what you would expect you can learn from a ST phase that you couldn't learn without it.
06:20 <@michaelfolkson> aj: I guess. An enormous optimisation is probably even unlikelier than a bug being found though
06:21 < aj> AaronvanW: "MASF phase prior to lot=false" ? that doesn't make any sense: lot=false is MASF
06:22 < AaronvanW> aj: I udnerstand LOT=false as what happens on timeout (nothing), but sure we agree.
06:22 < aj> michaelfolkson: unlikely things happen, it's prudent to plan for their possibility.
06:23 <@michaelfolkson> aj: True. In this case we are weighing up competing unlikely scenarios though. If there was only one unlikely scenario to avoid we would choose to avoid it
06:24 <@michaelfolkson> aj: Juggling a bunch of different risks. Totally avoiding one leaves another completely exposed
06:24 < aj> AaronvanW: "what you can learn": (1) if there are any reasonable objections to taproot, that people have somehow not made public already; (2) whether miners are willing/able to upgrade quickly so that quick activation is safe; (3) if, post-segwit, activation is a horibble nightmare that's just a pain to be involved in
06:27 < aj> michaelfolkson: no, we're not trading off anything. if ST fails for no good reason, we could immediately do a bip8/lot=true deployment with the original stopheight parameter (probably would be wise to change the startheight and add some min_activation_height). or, more likely in my opinion, do something better than bip8 since doing a lot=false release that will get upgraded to lot=true is likely
06:27 < aj> to never happen.
06:28 < AaronvanW> 2: LOT=true asks that exact same question, and embeds an answer. (There IS a MASF phase.)
06:29 <@michaelfolkson> aj: In theory you could. Are you going to get community consensus to do that? Or is Core going to make that decision?
06:29 < aj> AaronvanW: it embeds a *response* it doesn't tell us the answer. the same response also applies to (1), and means we'd need to ignore any reasonable objections to taproot that are discovered
06:30 <@michaelfolkson> aj: Then you're taking risks with doing things without community consensus. You can't avoid risks I'm afraid
06:30 < AaronvanW> 1: I guess the answer response would be, objections should have been raised already.
06:30 <@michaelfolkson> aj: Just pick your poison
06:30 < aj> michaelfolkson: in my opinion, you've been using "community consensus" as a proxy for "what i think, since hey, i'm part of the community"
06:30 < AaronvanW> 3: Not sure what to make of that. I don't think it needs to be a horrible nightmare.
06:31 <@michaelfolkson> aj: I have at least organized multiple community meetings with agendas and meetings notes to the mailing list. You have done a developer survey. We've both tried our best to avoid that particular criticism
06:32 <@michaelfolkson> aj: But agreed never going to be bulletproof to that particular criticism
06:32 < AaronvanW> aj: and sure, s/answer/response.
06:33 < aj> AaronvanW: "should have been raised earlier" is .. true, but why put yourself in that position when it's avoidable?
06:33 < AaronvanW> aj: I mean, where do you draw the line? Maybe people will only really-really start to review the proposal when a flag day is set?
06:34 < aj> AaronvanW: "hey want to go to a restaurant?" "sure!" [later, to the waiter] "oh, hey, do you have anything without peanuts? i'm alleargic" "no, sorry, you have to eat our peanut sauce."
06:35 < aj> AaronvanW: "where do you draw the line" august 11th?
06:35 < aj> (ish)
06:35 < AaronvanW> Seems pretty arbitrary...
06:35 < aj> so?
06:36 < aj> not every number has to be fraught with deeper meaning
06:39 < AaronvanW> I think you know what I mean. At what "development phase" do you draw the line? Apparently you want to draw the line *after* a MASF (LOT=false) phase. I'm not against that, but I also don't see the point. Drawing the line *before* the deployment of any activation code (MASF, UASF, flag day, whatever) seems like a more logical place to me.
06:39 < belcher> aj what do you mean by _revocable_ flag day, do you know where i can find references to it? (i just searched the mailing list)
06:40 < aj> belcher: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018723.html
06:41 < aj> belcher: search for "reverse" if you want to skip to the right bit
06:44 < belcher> ah! i dont know why i didnt get this at the time, yes that seems like a good idea
06:46 <@michaelfolkson> Except it would be disputed when it would be acceptable to revoke. And would need to get community consensus in the first place. Always a poison
06:46 < aj> AaronvanW: maintaining the ability to back out of a soft fork deployment attempt for as long as possible seems ideal to me. when you start an activation attempt, you're no longer definitively able to back out, but being able to do so with miner support in the event of a problem is better than having to do a hard fork, or a soft-fork-upon-a-soft-fork to fix things
06:47 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
06:48 < aj> AaronvanW: (after lockin or activation, there's no choice but to do a hard fork or soft-fork^2; a revocable flag day lets you set a flag day that can be aborted by 90% of hashpower instead of 10% of hashpower eg. perhaps there are other options)
06:48 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
06:50 < aj> michaelfolkson: in a big enough project, everything will get "disputed". see maaku's objections to taproot, eg.
06:52 <@michaelfolkson> aj: Indeed but I think we would both agree Taproot did achieve overwhelming community consensus. Nothing other than Speedy Trial (by fudging the BIP 8, 9 aspects) got overwhelming community consensus.
06:53 <@michaelfolkson> aj: BIP 8 got close but on what LOT should be set to didn't get overwhelming consensus
06:53 <@michaelfolkson> It isn't boolean. Consensus or not
06:55 <@michaelfolkson> We don't know whether a totally new proposal e.g. revokable flag day would get consensus or not without taking it to the community. I wouldn't support it, maybe the community would
06:56 < belcher> why wouldnt you support revocable flag day?
06:57 < aj> michaelfolkson: bip 8 (in the sense of "merge lot=false with a stopheight a year or so away and then switch it to lot=true later") wasn't that close; matt's objections on the PR weren't addressed; luke was opposed to lot=false anywhere; rusty was wanting to NACK anything that didn't include a config option to switch, while morcos and suhas wanted to NACK anything that encouraged people to run
06:57 < aj> lot=true prematurely (whether a config option or the availability of an alt client with lot=true)
06:58 < AaronvanW> aj: ok, thanks for explaining. (I had heard the argument before, but I was under the impression that most devs didn't really consider it a compelling argument. Clearly you disagree with that.)
06:59 < aj> AaronvanW: (which argument?)
06:59 <@michaelfolkson> aj: I'm not sure exactly why morcos and suhas didn't attend the meetings or respond on the mailing list. Perhaps because they knew how challenging it was going to be. But if people don't say anything publicly it is hard to factor in their opinions
06:59 < AaronvanW> aj: the backing out of a soft fork argument.
06:59 <@michaelfolkson> aj: And feeds into the narrative that developers make decisions behind closed doors
06:59 < aj> AaronvanW: 1 sec
07:00 <@michaelfolkson> aj: Suhas did release a blog post but it didn't express any particular preference or opposition to a particular activation mechanism
07:00 < aj> michaelfolkson: https://medium.com/@sdaftuar https://twitter.com/morcosa/status/1363854163159973892 ; the whole "activation is a horror show" is why smart people aren't commenting publicly as much as would be nice
07:01 <@michaelfolkson> aj: And you have a magic wand for not making it a horror show when there are such strong opinions and post SegWit PTSD?
07:01 <@michaelfolkson> aj: You were free to take charge at the beginning of this if you had a plan for plain sailing
07:02 <@michaelfolkson> aj: Behind closed doors with your mates is always going to be less stressful
07:03 < aj> AaronvanW: i'm of two minds; it'd certainly be better for complaints to be raised earlier -- i think activating things on signet and trying to get wallets etc to do tests of new features on signet would be one way to make that happen (of course when i then say "and this makes it easier to do activations on signet" that's met with "bah who cares about test nets"...); and it's really risky to try to
07:03 < aj> leave criticisms late -- miners might just activate it over your objections at that point anyway; but otoh, having more ways of avoiding risks is always better
07:03 < aj> michaelfolkson: no, i'm just willing to put with a horror show
07:04 <@michaelfolkson> aj: As was I. But I was under no illusions it was going to be plain sailing
07:04 <@michaelfolkson> aj: Always easier to sit there from the comfort of your own offices and criticise those trying to make progress within the horror show
07:05 < aj> michaelfolkson: i'm chatting to you at midnight with a 5am meeting in the morning
07:06 <@michaelfolkson> aj: Not directed at you. Directed at the people who criticize from the sidelines.
07:10 < aj> eh "criticising from the sidelines" is just another word for "community involvement"
07:12 <@michaelfolkson> aj: Nope getting involved in the community discussion is leaving the sidelines. Talking quietly with you mates while criticizing the "horror show" of the community discussion is staying on the sidelines
07:12 <@michaelfolkson> Again not directed at you
07:13 < aj> bitcoin isn't just for the brave and foolhardy, if you don't want to paint a target on your back by getting involved in contentious activations, your opinion still counts as much as anyone else's
07:13 <@michaelfolkson> As long as you state it publicly, sure
07:14 < aj> that's why the rule is "significant, reasonable, and directed
07:14 <@michaelfolkson> If you don't you can't expect your opinion to be discussed or taken into account
07:14 < aj> objection." not "someone said NACK"
07:29 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]
07:43 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
08:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
08:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
08:20 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
08:28 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
08:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
08:33 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
08:41 -!- sdaftuar_ is now known as sdaftuar
08:49 -!- _joerodgers [~joerodger@89.38.224.123] has joined ##taproot-activation
08:53 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Ping timeout: 252 seconds]
09:13 < jeremyrubin> read the scrollback... AaronvanW I think that one can think of ST failable signalling as a way to ~relatively anonymously gather weighting for how much people who expressed NACKish sentiments for Taproot actually had their feedback addressed
09:13 < jeremyrubin> Conceivably, as aj points out, there might be a decent set of people who *don't* want to engage in publice debate
09:14 < jeremyrubin> Maybe they register a comment, maybe they don't.
09:14 < jeremyrubin> Maybe they read rusty's NACK and were like hmm yeah we should wait out something better
09:14 < AaronvanW> What does that have to do with ST though?
09:14 < luke-jr> >implying people can generally prevent miners from signalling
09:14 < AaronvanW> ^
09:15 < jeremyrubin> One could interpret, absent new, introduced arguments, that one should reexamine any extant NACKs for a proposal
09:15 < jeremyrubin> In general I think ST positive signal, Cancellable Flag Day, then Flag day (mandatory signal or not) is a pretty good 3 step process
09:16 < AaronvanW> Yes, but that was in fact my point. The _only_ feedback that devs got back was negative. Then what could possibly be the justification for deploying a flag day?
09:16 < jeremyrubin> 1st is: upgrade happens soon if you want it! 2nd is: upgrade doesn't happen if you don't want it! 3rd is: upgrade happens.
09:16 < jeremyrubin> [4/22/21 09:16] <AaronvanW> Yes, but that was in fact my point. The _only_ feedback that devs got back was negative. Then what could possibly be the justification for deploying a flag day?
09:16 < jeremyrubin> Only fdbk on what?
09:16 < AaronvanW> Taproot in this cse.
09:16 < AaronvanW> *case
09:16 < jeremyrubin> is this hypothetical?
09:17 < jeremyrubin> I saw mostly positive
09:17 < AaronvanW> yes, after ST faled.
09:17 < jeremyrubin> Can you just re-state your sentence entirely filling in any references
09:17 < belcher> negative feedback only from miners
09:18 < AaronvanW> Yes it's hypothetical, I'm talking about a scenario after ST failed. You'd have all the current information PLUS negative feedback from miners (they didn't activate.)
09:18 < jeremyrubin> Ah right.
09:18 < jeremyrubin> Well it's not quite true
09:18 < jeremyrubin> You get a %age
09:18 < belcher> back in the block size debates when miners were blocking segwit their reasons were things like "we want to use Bitcoin Unlimited instead"... and everyone just interpreted that as "miners are stalling"
09:19 < jeremyrubin> So let's say there's two cases, one case is 75% signalling, one case is 20% signalling in ST
09:20 < jeremyrubin> These cases are materially different.
09:20 < jeremyrubin> Further, miners can set a message if they so choose in the CB (want Taproot but need new code)
09:20 < AaronvanW> If it's 75% and this 75% thinks that's enough, they could just activate. fwiw.
09:20 < jeremyrubin> We should probably encourage this! but we're not entitled to it
09:20 < jeremyrubin> AaronvanW: sorta
09:20 < AaronvanW> (75% of miners can orphan non-signaling blocks.)
09:20 < jeremyrubin> the social contract is 75% want 90% to activate
09:21 < jeremyrubin> they might not want to e.g. potentiall lose that hashrate
09:21 < jeremyrubin> So if you drop the threshold to 74%, then some may say "no" as it's a diff q
09:21 < jeremyrubin> Anyways, the main point I'm making is counter to that
09:21 < AaronvanW> Yeah but the solution is for devs/users to not reuire any hash rate, so...
09:22 < belcher> flag day activation with 75% support is effectively orphaning noncompliant blocks
09:22 < belcher> support of miners*
09:22 < AaronvanW> right
09:22 < jeremyrubin> no, belcher, it's making them SPV mine
09:22 < belcher> so if we assume 75% support of ST equals 75% support of flag day, then even seeing 75% support from miners is good to go ahead with a UASF
09:22 < jeremyrubin> if they don't activate and it's a "friendly" SF, mempool policy protects
09:23 < belcher> jeremyrubin ah yes you're right, a chain split requires an invalid taproot spend to be mined
09:23 < jeremyrubin> anyways this is drifting very far belcher if you could -- with all due respect -- butt out for a second, I'm trying to answer AaronvanW's question :p
09:23 < belcher> ok
09:23 < jeremyrubin> Which is "what new information do we gain and how does it inform us" (paraphrased)
09:23 < AaronvanW> yes
09:23 < jeremyrubin> (AaronvanW correct if wrong)
09:24 < jeremyrubin> so we learn a percentage which tells us generally if we're either mostly supported or not
09:24 < jeremyrubin> we also learn -- if a miner *cares to*, any new feedback
09:24 < AaronvanW> cares to?
09:24 -!- duringo36 [ad004d53@173.0.77.83] has joined ##taproot-activation
09:25 < jeremyrubin> if they e.g. put a msg hash in their CB for why they oppose
09:25 < AaronvanW> yeah that's basically aj's argument.
09:25 < jeremyrubin> If it's looking like 75% support, they should probably voice their NACK
09:26 < jeremyrubin> if it's looking like 25% support, it's either insufficient upgrade time or they think the NACK is already clear
09:26 < jeremyrubin> In any case, we should re-round up all the NACK arguments and re evaluate them
09:27 < jeremyrubin> Once that is done, we could choose to either re-try a ST (perhaps non-ST timeout if the issue was just insufficient upgrade time)
09:27 < AaronvanW> Would that really change anyone's mind though? Especially if the arguments have already been considered...
09:27 < jeremyrubin> or we could go to a negative signal
09:27 < jeremyrubin> AaronvanW: it *might*?
09:28 < jeremyrubin> clearly the counterarguments to NACK ST Taproot were insufficiently considered
09:28 < jeremyrubin> be it too fast upgrade time or a problem with taproot or a problem with ST generically
09:28 < jeremyrubin> So there's a wide range to open for discussion
09:28 < AaronvanW> or maybe miners were just lazy.
09:29 < jeremyrubin> AaronvanW: notably, ST is designed to somewhat address this. And if miners are lazy, then we need to re think SF's anyways
09:29 < jeremyrubin> Because even tho "users decide", a situation where the most work chain is not valid is bad, very bad
09:30 < jeremyrubin> (ignoring that the most-work chain definitionally has to be valid)
09:31 < AaronvanW> LOT=true or flag day could disinceitvize laziness.
09:31 < jeremyrubin> or it could incentivize miners to false signal
09:31 < AaronvanW> anyways, just pointing out that non-activation doesn't make it "clear" that there is anything wrong with the proposal.
09:31 < jeremyrubin> AaronvanW: of course!
09:32 < jeremyrubin> but it's an opportunity to re-examine assumptions
09:32 < jeremyrubin> Is it not?
09:32 < jeremyrubin> I assume ST Taproot will activate
09:32 < jeremyrubin> If it doesn't one of my assumptions was wrong
09:32 < AaronvanW> yes, I acknowledged that when I was discussing that with AJ earlier.
09:32 < jeremyrubin> is it pointless to try to see if it's a stupid assumption?
09:32 < jeremyrubin> yeah I skimmed it, just wanted to make sure your question was answered
09:33 < AaronvanW> I agree it's an argument. I don't think it's a very compelling argument in the scheme of things, but it's an argument.
09:33 < jeremyrubin> It's also not an argument against lOT true
09:33 < jeremyrubin> it's just an argument against lot true *now*
09:33 < jeremyrubin> AaronvanW: think in black swan terms maybe?
09:33 < AaronvanW> right.
09:34 < jeremyrubin> there's *some* epistemic value in waiting till after the timeout
09:34 < jeremyrubin> we won't actually know how big until then
09:34 < jeremyrubin> If it's a normally distributed amount of information, then LOT=true is probably safe
09:34 < jeremyrubin> if it's cauchy, then probably not
09:36 < jeremyrubin> both cauchy and normal "look" the same when you focus on the range of *reasonable* outcomes
09:37 < jeremyrubin> but when you actually examine them, you find that there's an infinite density of information in the tails of cauchy
09:38 < jeremyrubin> Can you say with confidence the information we'll learn after ST timeout is normal?
09:38 < jeremyrubin> Or is there *any* chance it could be cauchy?
09:38 < luke-jr> frankly it sounds like with jeremyrubin's logic, miners should intentionally not signal during ST ;p
09:39 < jeremyrubin> Counterintuitively, even if you were 99.999% sure it was normal, then cauchy would still dominate since it is infinite
09:39 < jeremyrubin> luke-jr: threat models; bitcoin is cryptographic, we make probability assumptions :)
09:40 < jeremyrubin> I'm just trying to give AaronvanW a framework why ignoring tail risk events is... risky... when you don't know exactly what sort of distribution the events/maginitudes fall on
09:41 < AaronvanW> jeremyrubin: I can't think of any information that would be 1) valuable, 2) not a problem anyways (in case of LOT=false) and 3) not fixable in context of LOT=true. But sure, maybe it's an unknown unknown.
09:43 < luke-jr> AaronvanW: no, you're right. there is no plausible reason.
09:43 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has left ##taproot-activation ["liver being pecked out and consumed by a giant pigeon before regenerating the next day"]
10:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:38 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has joined ##taproot-activation
10:43 -!- willcl_ark_ [~quassel@unaffiliated/willcl-ark/x-8282106] has joined ##taproot-activation
10:43 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
10:47 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined ##taproot-activation
10:48 -!- Netsplit *.net <-> *.split quits: wraithm_, ctrlbreak, willcl_ark
10:48 -!- duringo [ad004d53@173.0.77.83] has quit [Quit: Connection closed]
10:48 -!- duringo36 [ad004d53@173.0.77.83] has quit [Quit: Connection closed]
11:31 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
11:50 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
12:43 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
12:45 -!- cguida [~Adium@205.209.28.54] has quit [Client Quit]
12:48 -!- ctrlbreak_MAD is now known as ctrlbreak
12:52 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-elisawrkhzqhccwc] has quit [Ping timeout: 250 seconds]
12:52 -!- hebasto [sid449604@gateway/web/irccloud.com/x-qaszoypbxhvkorln] has quit [Ping timeout: 240 seconds]
12:53 -!- fjahr [sid374480@gateway/web/irccloud.com/x-bvvkqfeiyvkgcmqm] has quit [Ping timeout: 246 seconds]
12:57 -!- fjahr [sid374480@gateway/web/irccloud.com/x-mmvomsklbhcubwkr] has joined ##taproot-activation
12:58 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-ygblirckeyrfuqrb] has joined ##taproot-activation
12:58 -!- hebasto [sid449604@gateway/web/irccloud.com/x-gkvwysjshowrbwdf] has joined ##taproot-activation
13:00 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
13:19 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
13:20 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
13:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
13:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
13:57 < aj> AaronvanW: "if it's 75%" -- you can't just activate quickly with 75% hashpower, that implies 25% of hashpower would extend an invalid chain, giving (eg) a 6% chance of 3-confirms provided someone mines a taproot invalid block. i suppose you could say "if 90% gets hit, activation is in 6 months; if only 65% gets hit, activation is in 2 years" ; that would be a new variation on decreasing threshold
14:00 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has joined ##taproot-activation
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
14:05 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
14:06 < AaronvanW> aj: "you can't just activate quickly with 75% hashpower" <--- not sure who "you" refers to in this context?
14:06 < AaronvanW> 75% of miners _can_ activate even if the threshold is 90%.
14:07 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
14:08 < AaronvanW> (yes there would be reorgs, I agree with that of course.)
14:15 < luke-jr> that's no longer a softfork, it's an attack
14:16 < luke-jr> softforks - no matter who activates them - are always user-*enforced*
14:18 < AaronvanW> I'm not endorsing it, just stating the obvious: it's possible.
14:27 < aj> AaronvanW: "you can't" == "it's not safe for people who are trying to run businesses with bitcoin, if you"
14:28 < viaj3ro> if 90% of users have upgraded and 75% of miners activate and 25% of miners mine invalid blocks sometimes, how is that an attack?!
14:28 < viaj3ro> it's just stupid lazy miners losing money
14:28 < aj> "if 90% of users have upgraded" -- that takes time, so you're not activating quickly if you're waiting for that to happen
14:29 < viaj3ro> just countering Lukes argument
14:30 < aj> luke's just saying that if 75% of miners are orphaning 60% of other miners otherwise valid blocks in order to hit the 90% threshold, that's an attack
14:30 < viaj3ro> @jeremyrubin
14:30 < viaj3ro> what's missing for BIPO119 to be ready?
14:30 < AaronvanW> aj: sure, I agree more orphans/reorgs are less desirable.
14:31 < viaj3ro>  BIP119 I mean?
14:32 < viaj3ro> aj: is it? not if >90% of users/nodes are enforcing the new rules imho
14:33 < luke-jr> viaj3ro: then the threshold is 75%, not 90%
14:34 < aj> viaj3ro: the assumption is that nodes aren't doing a UASF to force signalling so wouldn't be rejecting the non-signalling blocks (yet, any way), it's just miners deciding to do it
14:34 < viaj3ro> yeah
14:34 < viaj3ro> @aj sure. but still no attack imho
14:35 < luke-jr> it is, because they're rejecting valid blocks
14:35 < luke-jr> a softfork is fundamentally different
14:35 < aj> viaj3ro: it's a 51% attack. i mean, if you don't want to call that an attack you can...
14:35 < luke-jr> it constrains the definition of valid blocks
14:35 < luke-jr> a softfork that is*^
14:35 < viaj3ro> could be they just waited for say 9+ months and the 25% were just neglient.
14:35 < luke-jr> if miners reject anything users accept, it's not a softfork anymore
14:36 < viaj3ro> when we have learned one thing in the last few days, it's anyone can call anything an attack. the word might have become meaningless in regards to bitcoin ;)
14:36 < luke-jr> you learned the wrong lessons then
14:37 < viaj3ro> according to you....
14:37 < viaj3ro> you are calling the official core release an attack....
14:37 < luke-jr> because it is
14:38 < luke-jr> and violates the standard norms for official Core releases
14:38 < viaj3ro> exactly. anything is an attack now
14:38 < viaj3ro> exactly my point
14:38 < luke-jr> not anything, only actual attacks
14:38 < viaj3ro> actual attacks as defined by Luk
14:38 < viaj3ro> luke
14:39 < luke-jr> bye
14:39 < viaj3ro> different question. will you merge https://github.com/bitcoin/bips/pull/1104 ?
14:40 < viaj3ro> if not, why?
14:40 < viaj3ro> if yes, whats the hold up?
14:41 < viaj3ro> or am I already on *ignore because I don't agree that core is attacking core (and bitcoin)?
14:43 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed]
14:49 -!- _joerodgers [~joerodger@89.38.224.123] has quit [Read error: Connection reset by peer]
14:52 -!- joerodgers [~joerodger@89.38.224.100] has joined ##taproot-activation
14:54 -!- joerodgers [~joerodger@89.38.224.100] has quit [Read error: Connection reset by peer]
15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
15:01 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
15:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:10 -!- joerodgers [~joerodger@89.38.224.117] has joined ##taproot-activation
15:11 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
15:14 -!- joerodgers [~joerodger@89.38.224.117] has quit [Read error: Connection reset by peer]
15:16 -!- joerodgers [~joerodger@89.38.224.100] has joined ##taproot-activation
15:17 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
15:17 -!- joerodgers [~joerodger@89.38.224.100] has quit [Read error: Connection reset by peer]
15:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
15:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
15:20 -!- joerodgers [~joerodger@89.38.224.101] has joined ##taproot-activation
15:25 -!- joerodgers [~joerodger@89.38.224.101] has quit [Read error: Connection reset by peer]
15:26 -!- joerodgers [~joerodger@89.38.224.105] has joined ##taproot-activation
15:27 -!- joerodgers [~joerodger@89.38.224.105] has quit [Read error: Connection reset by peer]
15:29 -!- joerodgers [~joerodger@89.38.224.101] has joined ##taproot-activation
15:51 < shinobiusmonk> Just for everyone's general knowledge: viaj3r0 is a troll who constantly wastes users time on a mumble server I run
15:51 < shinobiusmonk> he just doxxed himself as that handle posting screenshots of the chat including his disconnect in the mumble server
15:53 < shinobiusmonk> (if I'm incorrect there, apologies, but the person I'm referring to just got very defensive about why that specific IP was censor barred in the screenshot)
15:55 -!- duringo [ad004d13@cam4-17.as22384.net] has joined ##taproot-activation
16:04 -!- ironhelix [~d@154.6.28.63] has quit [Changing host]
16:04 -!- ironhelix [~d@unaffiliated/ironhelix] has joined ##taproot-activation
16:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
16:19 < mol> shinobiusmonk, are you sure? I've never seen him troll and he's a very active LN user on Eclair forum and reddit
16:19 < mol> just look here:  https://gitter.im/ACINQ/eclair
16:21 < shinobiusmonk> @mol: no I was incorrect
16:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
16:58 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
17:01 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
17:09 -!- belcher_ is now known as belcher
17:22 < robert_spigler> Read all the backlog, I think AaronvanW brings up a lot of good points.  I'm still not sure what info ST can bring us if it fails (that's one of the reasons why I was originally for BIP8 LOT=true).  Regardless, I'm glad we have consensus (yes, I believe we have consensus) around ST, and I hope it will activate taproot
17:25 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 260 seconds]
17:37 < shinobiusmonk> (wasn't about content here, but content somewhere else in a voice chat with screenshots from here)
18:23 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has joined ##taproot-activation
18:26 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has quit [Read error: Connection reset by peer]
18:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
19:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
19:08 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has joined ##taproot-activation
19:13 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has quit [Quit: Leaving.]
19:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
19:31 < Emcy> st failing still isnt automatic uasf. wed have to rationally ascertain why it failed
19:32 < Emcy> RATIONALLY
19:32 < luke-jr> BIP8 is already live
19:35 < Emcy> you are stuck in an epistemological shard with no more than ten other people. no one can figure out how to pierce this veil.
19:36 < Emcy> so good luck with your fuckin bitcoin fork m8
19:36 < luke-jr> dunno why you imagine this
19:37 < luke-jr> you're the one trying to hardfork
19:38 < Emcy> im nobody
20:02 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has joined ##taproot-activation
20:14 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has quit [Quit: Leaving.]
21:11 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has joined ##taproot-activation
21:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
21:17 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
21:18 -!- cguida [~Adium@2601:282:200:ae00:7078:3875:9b88:f61a] has quit [Quit: Leaving.]
21:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds]
21:22 -!- lukedashjr is now known as luke-jr
21:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
22:04 -!- duringo [ad004d13@cam4-17.as22384.net] has quit [Quit: Ping timeout (120 seconds)]
22:13 -!- CryptoSiD [SiD@CryptoSiD.DonSiD.net] has joined ##taproot-activation
23:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
--- Log closed Fri Apr 23 00:00:34 2021