--- Log opened Thu May 13 00:00:53 2021
00:07 -!- catwith1hat [~112212@185.72.66.245] has quit [Quit: Leaving]
00:22 -!- jesseposner [~jesseposn@2601:645:200:162f:bcd4:42d8:7d4a:791f] has quit [Ping timeout: 245 seconds]
00:35 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 265 seconds]
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
01:01 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
01:15 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
01:28 < pox> The way signaling for ST is unfolding I'm starting to think LOT=true with a longer time frame was the right thing to do all along. 90% threshold is way too susceptible to fail just because of some small lazy pools who simply don't care enough. Their only incentive is good will towards Bitcoin. All carrot, no stick.
01:31 < pox> In a way ST makes more sense the more the hashpower is centralized. Major pools who care about the optics of signaling because it impacts their reputation are more likely to signal cooperatively and quickly, and we're seeing that happen. But all those <1% hashrate pools who don't seem to have this problem (too small and independent to care about their reputation) don't have much of an incentive to signal in time.
01:32 < pox> ST signaling is basically bitcoin virtue signaling (TM) :-)
02:43 -!- belcher_ is now known as belcher
02:44 < belcher> pox it was always agreed that if ST fails then we go for some kind of UASF (possibly LOT=true, possibly flag day)
02:54 < gevs> can someone give a small explanation on what is "flag day activation" ? I keep seeing this in relation to forks, hope its not too off topic here :)
02:58 < belcher> gevs no miner signalling, but after a certain date or block height that we choose the new taproot rules become active, and miners just need to avoid creating or building-on invalid blocks (and taproot transactions are non-standard to non-upgraded nodes so miners wont mine them accidently unless they modify their software)
03:00 < belcher> this tweet put it in a memorable way https://twitter.com/benthecarman/status/1367263895220596740
03:01 < gevs> *we choose* ; as in "the [core] devs" / reviewers, is that correct?
03:03 < belcher> yeah and the community
03:04 < belcher> any block height or date will work, but the community and/or devs will probably choose to avoid putting it around holidays for example
03:04 < belcher> in the same way if we were using LOT=true we'd avoid putting the lockin date close to christmas or chinese new year say
03:05 <@michaelfolkson> gevs: Essentially Core would have to merge it and release it yes. And part of the community would oppose it and support BIP 8 rather than a flag day. So it remains to be seen what actually happens
03:05 < gevs> Yep makes sense, thanks.
03:08 <@michaelfolkson> At one point there was overwhelming consensus on a 1 year BIP 8 deployment. So giving up on miner signaling after 3 months would be strange. And then there is the forced signaling vs flag day argument
03:10 <@michaelfolkson> I still think with a few nudges Speedy Trial will activate
04:38 <@michaelfolkson> Alejandro seems confident too https://twitter.com/bitentrepreneur/status/1392574908224479242?s=20
04:39 <@michaelfolkson> Haven't listened to this yet https://www.unhashedpodcast.com/episodes/alejandro-de-la-torre-miner-taproot-signalling
04:48 < bcman> belcher: it was? then the animosity to the based client makes even less sense
05:05 < bcman> [02:44:06] <belcher> pox it was always agreed that if ST fails then we go for some kind of UASF (possibly LOT=true, possibly flag day)
05:22 <@michaelfolkson> Also on Slush signaling: https://stephanlivera.com/episode/275/
05:25 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
05:34 <@michaelfolkson> It is cool to get some insights, public exposure of mining pools during this Taproot activation
05:37 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
05:37 < pox> belcher I
05:39 < pox> I'm aware. I'm just saying it might have been better to do UASF in the first place. I guess I can say I know now more than I did before ST started, so it did have some value in that sense. And it is nicer than the vast majority of pools will already have upgraded by the time the UASF is brought out (if it reaches that). But that's more a statement about my lack of foresight than anything else.
05:41 < pox> idk I don't feel strongly either way now tbh. Before, I felt like ST was the far better option. now I'm neutral.gif
05:45 < murch> pox: Sure, right after you tell me how we measure sentiment among a heterogeneous industry and community without rolling out a client
05:45 < murch> the dozen very loud people on Twitter and three people participating in the actual debate are probably not all that representative
05:47 < belcher> the winning argument seemed to be that a UASF has to take a long time to improve safety, while if we can get a MASF to succeed then it would go much faster, so we may as well try MASF/ST first
05:48 < belcher> also we had the information that ~90% of hashpower said they would activate according to taprootactivaton.com, so that added to the feeling that a MASF would work and quickly
05:50 < murch> What michaelfolkson fails to mention here is that the "overwhelming consensus on BIP8" was never more than a "sounds like a reasonable direction to explore" and never managed to agree on the nitty gritty details. Which makes labeling that as "consensus" tenuous.
05:51 <@michaelfolkson> murch: :/ disagree. High level details agreed, what LOT parameter set to wasn't agreed
05:52 <@michaelfolkson> murch: By your logic Speedy Trial didn't have consensus either because there was disagreement over MTP/block height. In that sense you are perhaps in the same camp as Luke
05:53 <@michaelfolkson> If you agree on high level details but can't agree on lower level details that does not throw out the agreement on the high level details
05:54 < murch> There are a few shades of difference between half the developer communiy preferring something else and one third actively pushing back, and rough consensus on an approach with one person not liking it because it doesn't cater to some previously assumed dogmatic stance.
05:55 < Emcy> murch theyve been corrected on the 'overwhemling consensus' thing a few times now, but they still repeat it
05:55 < Emcy> i think its just an article of faith at this point
05:55 < pox> murch I didn't say don't roll out a client. I said the other option was to go with a UASF. And when I consider what kind of sentiment analysis 80% would give us at the end of ST I'm honestly not sure what that's worth.
05:55 <@michaelfolkson> Go read the meeting logs. No one had a problem with BIP 8. Persistent attempted revisionism
05:56 < Emcy> get back @ me when you understand that your little committee in here != 'the community'
05:56 < murch> pox: The point that I was trying to make is that "not getting any public negative response" and "there being overwhelming support" is hard to measure from the developers' perspective when 95% of the industry does not participate in the debate
05:57 < Emcy> i know youve had great fun organising all this, but youre a big fish in a small pond my dude
05:57 <@michaelfolkson> Emcy: Very lazy. Review the logs of those first two meetings and see how many people and who showed up to those first two meetings
05:57 < murch> Then issuing a fixed date to activate a new feature in the first approach seems to be pretty dictatorial.
05:57 <@michaelfolkson> Emcy: You won't because it doesn't fit your narrative. But if you did you would understand that the pond in those first two meetings was very large
05:57 < pox> murch yes, I agree. I'm not sure how I would have felt about Taproot's activation safety if it weren't for that unofficial poll that was done among pools beforehand.
05:58 <@michaelfolkson> And I am quite happy to be a very small fish as long as people don't do lazy revisionism
05:59 < murch> michaelfolkson, I think you're still not getting it. You announcing that you facilitate the Taproot activation debate and then acting as if anyone else agreed with that doesn't make you some sort of authoritative figure on the process. What happened was that most people ignored you because you seem to have zero empathy for what's going on around you.
06:00 < pox> @michaelfolkson I appreciate the work you've done with taproot activation discussion fwiw :pray:
06:00 <@michaelfolkson> murch: Stop throwing stones at me and go revisit those conversation logs. How many people showed and who showed to those first two meetings
06:00 <@michaelfolkson> murch: I am quite happy to be totally irrelevant and the tiniest of fishes
06:01 < murch> Well, why are you then trying to insert you into all these debates and just repeating Luke's bollocks?
06:01 <@michaelfolkson> Because you are attempting (repeatedly) lazy revisionism
06:01 < Emcy> murch hisd argument is basically the same as the argument for NYA, and just as faulty
06:01 < murch> It's not helping, but just wasting a ton of time with people needing to respond to it again and again
06:01 < Emcy> they swore up and down that they had 'consensus' for s2x too
06:02 < Emcy> but it was consensus of a small insular little group with ideas above its station
06:02 <@michaelfolkson> Revisit. the. conversation. logs.
06:02 < pox> I guess ST does make sense not as an activation mechanism per se but more of a way to gauge pools' sentiment towards a SF. devs throw it out there, a few months pass, we see if there are some glaring holes in terms of various pools not activating. if it looks like there's a clear majority, and no pool voices objections, then it's safe to continue with a flag day or whatever.
06:02 < murch> michaelfolkson: Find yourself a truthsayer that you trust.
06:03 <@michaelfolkson> murch: I trust in conversation logs
06:03 < murch> Okay…
06:03 < Emcy> pox yeah thats part of it. it was always a case of if ST activates, great we can stop arguing about all this, but if it doesnt then at least we get more information to triage
06:06 -!- joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has quit [Read error: Connection reset by peer]
06:06 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:07 < pox> yes, polling the miners in this more formal way has no downsides. it doesn't cost anything and it doesn
06:07 < pox> 't take any option off the table
06:07 < pox> *that I can think off, I should say :grin:
06:07 < Emcy> well, you could argue that it costs a little bit of time. but so what
06:08 < Emcy> if the community cared about the timeframes then taproot could have been deployed 2 years ago from what i gather
06:08 < pox> not even sure about that. the ST time gets deducted from the UASF "budget" that would otherwise have been given to pools
06:08 < pox> UASF in 12 months or ST in 3 + 9 months of UASF later
06:08 < murch> pox: Using the miners to coordinate is quick, convenient and some of the easiest measurable signal we can get (although it's still only losely tied to them actually enforcing the rules later). The other important part is to see how the uptake of the new client version is
06:09 < Emcy> yeah only if you accept this 2022 'deadline' imposition
06:09 < pox> uptake in term of node count?
06:10 < murch> Emcy: The consensus code changes for Taproot were only finalized end of last year.
06:10 < Emcy> yeah because the dev process around it was slower than expected
06:10 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
06:10 < pox> the holy grail would be a "vote" of the economic majority. and I don't mean in the form of forked coins battling it out on coinbase...
06:11 < Emcy> reminder that 'taproot' we had today is only about half the original proposal, it was pared back in the interests of expediency. obviosuly that didnt work out lol
06:11 < pox> well, actually, maybe not. that would be basically democracy == PoS ..
06:11 < murch> Yeah, I also expected it to be quicker. It got significantly faster after it was pruned back from including CISA, Graftroot, G'root, and ANYPREVOUT
06:12 < Emcy> pox the day bitcoin becomes a straight democracy is the day it dies
06:13 < pox> yea. but that's what it boils down to when people say the economic majority ultimately decides on forks.
06:13 < murch> pox: Yeah, some people like the idea of futures markets as signal
06:14 < pox> murch that's PoS in a sense as well. if you can afford to sway those market you can influence bitcoin.
06:14 < murch> Not sure how easy that would be to implement for soft forks, though, since optimally only one of the two branches will survive and only one is wipeout-protected
06:14 < Emcy> i think there should be a futures market between 'core based client' and bitcoin core
06:14 < Emcy> it really helped settle the matter with s2x
06:14 < murch> Emcy: S2x was a hardfork, tho
06:15 < Emcy> you can place bets on anything
06:15 < Emcy> there are scenarios where core based client could fork off the chain
06:15 <@michaelfolkson> What do you bet on? Whether they end up being consensus compatible or not?
06:15 < murch> Sure, but it would be hard to get an unbiased signal if the two outcomes have inequal survivability
06:16 <@michaelfolkson> You can't bet on a "winner". Because the expectation is that they are consensus compatible
06:16 < murch> I don't expect core-based client to be consensus compatible if ST fails
06:17 <@michaelfolkson> murch: I suspect Core won't release anything if ST fails. I expected Core to release a BIP 8(LOT=false) to be compatible but it appears yourself and others will oppose that
06:18 <@michaelfolkson> murch: There will definitely people who oppose anything that isn't compatible (eg flag day)
06:18 < murch> I'm keenly interested in the source of your powers to divine the future.
06:19 <@michaelfolkson> "I suspect" and "I expected" declare predictive power
06:20 <@michaelfolkson> Re: "There will definitely people who oppose anything that isn't compatible (eg flag day)" This is absolute fact. No predictive power required
06:20 < murch> I think that an amendment of the Taproot soft fork proposal is possible if ST fails. Then the "core-based client" would be trying to activate something else than whatever Core releases next.
06:20 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
06:21 <@michaelfolkson> It has no authority
06:21 <@michaelfolkson> (I think)
06:21  * michaelfolkson shrugs
06:21 < murch> What has no authority?
06:21 < Emcy> murch i dont think hes really trying to predict the future, theyre doing the intolerant minority gambit
06:21 < Emcy> its a anotehr cargo cult from the bip148 days
06:21 < murch> yeah
06:21 <@michaelfolkson> The BIP doesn't declare authoritatively what the activation mechanism and params are
06:22 < murch> I just don't think that we would try to activate the same Taproot proposal by November 2022.
06:22 < murch> michaelfolkson: But the BIP describes what consensus rule changes are being made.
06:22 <@michaelfolkson> It is at best the BIP authors recommendation for activation mechanism and params
06:22 < Emcy> i dont see why at this point if ST fails for eg, why dont we just pull the whole current proposal and try again with the full taproot proposal as it originally was
06:23 < murch> Emcy: Exactly
06:23 <@michaelfolkson> Ah I see. That's why everyone was so desperate for Luke to merge it :) Didn't make that clear at the time ;)
06:23 < Emcy> i mean the reduced proposal has already failed in the sense that it was reduced to save time...lol
06:23 < murch> E.g. CISA is pretty close and if it were added later in a separate soft fork, it would need a new output type.
06:24 < belcher> is there a place to follow the progress on CISA?
06:24 < murch> michaelfolkson: The BIP repository is a convenient place to collect documents under debate
06:24 < belcher> a talk by people working on it for example
06:24 < Emcy> look, i understand the hate boner for 'the miners' [i was one of the 1400 or so bip148 nodes], but it wasnt 'the miners', it was jihan.
06:24 < Emcy> and now things are different
06:24 < murch> nah, just heard things through the grapevine
06:24 < Emcy> the first pool to signal in ST was antpool
06:25 <@michaelfolkson> belcher: Murch has introduced a tag for CISA on StackExchange https://bitcoin.stackexchange.com/questions/tagged/cross-input-signature-aggregation
06:25 < murch> michaelfolkson: people wanted it to be merged because it was what the authors of the BIP and the development community at large hat agreed on, and it made sense to publish it
06:25 < murch> s/hat/had/
06:25 <@michaelfolkson> belcher: Those posts are all that I've seen on the subject
06:26 < Emcy> belcher is cisa a new name for 'siggagg'
06:26 <@michaelfolkson> Emcy: Right
06:26 < murch> Emcy: Cross-input signature aggregation
06:26 < belcher> yes, because sigagg might also refer to key and signature aggregation like musig which this taproot today can already do
06:27 < murch> I guess MuSig should be rather categorized as "key aggregation"
06:30 <@michaelfolkson> murch: It disappoints me you appear to be gearing up for an attempt to get Core to release something incompatible with BIP 8 and an existing client on the network. I think you'll fail as Core won't do something contentious but even the attempt won't be pretty
06:31 <@michaelfolkson> But it seems very misguided to me (if Speedy Trial ends up failing)
06:31 <@michaelfolkson> It seems completely unnecessary too. But you are free to try
06:32 < Emcy> since when did you fellas care about the absolute integrity of the network :D
06:32 < Emcy> dont be a hypocrite now
06:33 <@michaelfolkson> BIP 8 is designed to be compatible (until the final two weeks)
06:33 < Emcy> idk why people are still doing this dance. like some retarded fandango
06:33 < murch> michaelfolkson: I'm pretty sure most dves are simply going to disregard the existence of your client since it is widely regarded as an incredibly stupid move.
06:34 <@michaelfolkson> Multiple people are uncomfortable with Core releasing something that (supposedly) definitely activates re flag day or forced signaling
06:34 <@michaelfolkson> So in reality I think it is BIP 8(LOT=false) or nothing
06:35 <@michaelfolkson> Core devs propose, they don't activate
06:35 < murch> That may be the case, but I don't expect any proposals to feel obligated to be compatible to the core-based client
06:36  * murch is just speaking for himself, obviously
06:36 <@michaelfolkson> No, I wouldn't use the term "obligated" either. It is a consideration though
06:38 < belcher> i wonder what would happen if a third group releases their own alt-client which is intentionally incompatible with the based client, maybe they'd say they want to resist the idea that a tiny group of people can push bitcoin around, i guess this other alt-client would have some rule that the first blocks after the bip8 flag day _must not_ signal
06:39 <@michaelfolkson> belcher: They are free to. I guess it would be up to them to convince the community on the motivation for it
06:39 <@michaelfolkson> belcher: It would be an alternative UASF though. Which would be pretty ironic if anti-UASF people supported it
06:40 <@michaelfolkson> I dislike UASFs so I am going to do my own UASF
06:40 < belcher> well yeah, thats why its not accurate to say that people who oppose the based client are anti-UASF
06:42 <@michaelfolkson> That's why I keep going back to those conversation logs of those first 2 meetings and why some people want to ignore them
06:42 <@michaelfolkson> If the based client had completely ignored community and done something the community clearly opposed I think the alternative UASF would be on firmer ground
06:42 < Emcy> maybe its not helpful to just refer to scripture
06:43 <@michaelfolkson> When there's revisionism going on it is all we have
06:44 < Emcy> 'i have logs of some people talking about it' never disproved the point of the insularity and non-representation of your group
06:44 < Emcy> i think youre doing the thing of trying to counjure authority by simply acting like your have authority for all the world. Granted, that works a lot of the time.
06:45 <@michaelfolkson> Are you not reading anything I say lol?
06:45 < Emcy> but i dont think a lot of these people youre arguing with are so easily led as you seem to think
06:45 < murch> I'm not even sure he's doing it on purpose at this point
06:46 < Emcy> it might work on the normies though, so i dont know why youre not arguing things out there instead of in here
06:46 <@michaelfolkson> [13:57:52]  <@michaelfolkson> Emcy: You won't because it doesn't fit your narrative. But if you did you would understand that the pond in those first two meetings was very large
06:46 -!- murch [~murch@gateway/tor-sasl/murch] has quit [Remote host closed the connection]
06:46 <@michaelfolkson> [14:00:12]  <@michaelfolkson> murch: Stop throwing stones at me and go revisit those conversation logs. How many people showed and who showed to those first two meetings
06:46 -!- murch [~murch@gateway/tor-sasl/murch] has joined ##taproot-activation
06:47 <@michaelfolkson> [14:02:17]  <@michaelfolkson> Revisit. the. conversation. logs.
06:50 <@michaelfolkson> The pond shrank in later meetings so by the coin flip meeting attendance was quite small. But not the case for the first two meetings
06:54 < murch> So, your argument is because a few more people were curious how the first couple meetings would pan out that they were in some fashion binding for the overall outcome of the process spanning numerous channels?
06:55 < Emcy> ok and adam back singed the NYA too....that didnt mean shit either
06:55 <@michaelfolkson> Nothing is binding. But the IRC channel and the mailing list was open for opposition to BIP 8 24/7
06:55 < murch> which it received eventually?
06:56 <@michaelfolkson> Well people like you have this (in my view weak) argument that because there wasn't consensus on what to set a parameter to that throws out consensus around that BIP
06:57 < murch> yes
06:57 < Emcy> i really dont get it, the mere fact that they have so much opposition now would invalidate the 'overwhelming consensus' claim alone
06:57 < murch> It kinda is hard to deploy something that is inacceptable in every possible configuration.
06:57 < murch> Emcy: QFT
06:58 <@michaelfolkson> Emcy: This is where you are highlighting your own small pool and groupthink
06:58 < Emcy> like being generous and assuming they really thought that they did have consensus before when they were just mostly going unnoticed, there should be no excuse for hanging onto it at this point
06:59 <@michaelfolkson> Only Matt has been consistent publicly on not wanting to facilitate UASFs within a BIP 8 like activation mechanism
06:59 <@michaelfolkson> (I think)
07:00 < murch> You're conflating people agreeing that it is an acceptable tool eventually with people agreeing that it should be the first move
07:00 <@michaelfolkson> gmax seems very anti BIP 8 *now* but back then he was proposing a configurable LOT switch in Core
07:00 <@michaelfolkson> Rusty also wanted LOT switch
07:01 < Emcy> put me on the list too dude, for a long time after segwit activated i was all like 'UASF flag day bip 8 represent fuck the miners lmao'
07:01 <@michaelfolkson> So this small pool you keep referring to includes two of the brightest minds in Bitcoin (at least it did back in February)
07:01 < Emcy> people are allowed to reconsider their positions
07:02 < murch> So, you're lamenting that people are intelligent enough to update their opinion as the debate evolves?
07:02 <@michaelfolkson> Emcy: Of course but I don't know what has changed since to reconsider the position
07:02 < Emcy> im still reconsidering. if ST fails that will be more info with which to reconsider
07:02 < Emcy> you can rest assured that if there is evidence that miners are being actively malicious, my attitude will significantly harden
07:03 < murch> michaelfolkson: Don't you think it is disingenious to keep citing people's earlier thoughts after they have publicly evolved their opinion?
07:04 <@michaelfolkson> murch: It is purely in response to your attempted revisionism that BIP 8 didn't have consensus back in February/March
07:04 <@michaelfolkson> murch: I am merely pointing out facts
07:04 <@michaelfolkson> Of course (in theory) everyone can change their minds on a dime
07:04 < murch> People thought that BIP8 was a good idea, but then realized that they did not agree on LOT
07:05 < murch> I think that's pretty obviously a fact, not revisionism
07:05 <@michaelfolkson> My two arguments to you are:
07:05 <@michaelfolkson> 1) BIP 8 had consensus back in February/March
07:06 <@michaelfolkson> 2) I don't think disagreement on what to set a parameter to within BIP 8 means you can throw that consensus out the window
07:06 <@michaelfolkson> That's all
07:06 <@michaelfolkson> In theory everyone changed their minds on a dime overnight. I don't think that happened but I can't tell for sure
07:06 < Emcy> michaelfolkson anyway re: gmax he was always on record as opposing UASFs very broadly, he was the most significant detractor of bip148 amongst the devs
07:07 < Emcy> i think hes been consistent on that, working on a lot switch doesnt change it
07:07 < luke-jr> flag day w/o signalling is a contentious hardfork with no precedent
07:07 <@michaelfolkson> Emcy: Agreed. I don't understand why he was proposing a LOT switch then when LOT=true is a UASF (that he supposedly always opposes)
07:08 < luke-jr> [12:50:11] <murch> What michaelfolkson fails to mention here is that the "overwhelming consensus on BIP8" was never more than a "sounds like a reasonable direction to explore" and never managed to agree on the nitty gritty details. Which makes labeling that as "consensus" tenuous. <-- false; it wasn't simply "for exploration", it was agreed upon as the path forward and implemented as planned before this ST nonsense popped up
07:09 <@michaelfolkson> Emcy: A consistent anti UASF position has effectively been displayed by Matt. I think he has been against any form of UASF being facilitated from start to finish. I disagree with him but he has been consistent (I think)
07:10 < Emcy> yes he has also been consistent
07:12 < luke-jr> [14:06:50] <Emcy> michaelfolkson anyway re: gmax he was always on record as opposing UASFs very broadly, he was the most significant detractor of bip148 amongst the devs <-- pretty sure he admitted he was wrong after BIP148's success…
07:12 < Emcy> wrong about what
07:14 < Emcy> iirc i dont think he ever disputed that 148 could work under those specific circumstances back then, only that he disagreed with the risk
07:15 <@michaelfolkson> People are free to change their minds. But decisions are made based on consensus at a particular time. And it would be nice to have clear explanations on why people have changed their minds exactly
07:15 < Emcy> in any case its no good trying to divine his opinions, im not so comfortable speaking in his stead anyway. people would have to ask him what he thinks. though he seems a lot less minded to interact or debate with the community these days
07:15 < Emcy> its unfortunate but understandable i think
07:16 <@michaelfolkson> Agreed, he still posts regularly on Reddit though
07:16 < murch> Emcy: It's not exactly like you have to ask: https://github.com/bitcoin/bips/pull/1119
07:16 < Emcy> last i saw he had a palaver with the r/bitcoin mods and seems to have quit posting there now
07:16 <@michaelfolkson> I don't care where people post as long as they post their views/suggestions somewhere :)
07:18 < murch> luke-jr: I believe people agreed to work on implementations of BIP8. I don't think that at that stage any concrete proposal had broad support
07:18 < luke-jr> murch: it did, stop trying to rewrite history
07:18 < murch> okay
07:19 <@michaelfolkson> murch: Oh sure, gmax definitely seems anti BIP 8 and anti UASF today. But the decision on what to put in the based client wasn't made today
07:19 < Emcy> murch oh yeah that thread, i read that before. idk why michaelfolkson was kinda rude to him there, thats part of the reason he has largely withdrawn from the community.
07:19 <@michaelfolkson> Emcy: What quote was rude? I will happily edit
07:20 < CubicEarth> I think the threshold should have been 80% or 85%
07:20 < Emcy> i dont think it matters now
07:20 < luke-jr> the based client was a month late, primarily because new people had to learn the ropes
07:20 <@michaelfolkson> Emcy: Big fan of gmax. Last thing I'd want to do is push him away from engaging
07:21 < belcher> it is very untrue to say that bluematt is against UASF, in fact he first proposed flag day activation for taproot on the mailing list
07:21 < Emcy> thats pretty surprising to hear frankly
07:21 < belcher> the problem seems to be conflating opposition to the based alt-client with opposition to UASFs in general
07:21 <@michaelfolkson> Emcy: Why?
07:22 < Emcy> seems incongruous with faction loyalties
07:22 < luke-jr> the problem is people misrepresenting based as the alt-client
07:22 < luke-jr> based is the activation client; "Core 0.21.1" is now trying to shove an alt activation
07:22 < belcher> also untrue to say that gmax was against a UASF, even in 2017 he was against bip148 but pro bip149
07:23 <@michaelfolkson> Emcy: I don't think outside of soft fork activation those factions exist. They certainly don't for me
07:23 < belcher> luke-jr based client has ~zero support from the economy
07:25 < luke-jr> belcher: no evidence of your claim
07:25 < luke-jr> in fact, it's easily disproven
07:26 < belcher> also no evidence for your claim that the based-client is the real activation, so we're even now
07:26 < luke-jr> lots actually
07:26 < Emcy> michaelfolkson frankly im not so sure anymore that you guys want taproot activates so much as you want to set the precedent that soft forks only get activated via regimented UASFs
07:27 < murch> According to your own node tracking site, there are 10 clients running based, and almost 1000 either running 0.21.1 or 21.99.0
07:27 < Emcy> but im not entirely sure about that, and id prefer to think it wasnt so
07:27 < murch> sorry, more than 1000: 568+486
07:27 <@michaelfolkson> Emcy: It isn't regimented. It is designed to give freedom for Core to run either LOT=true or LOT=false in parallel with an alternative client
07:28 <@michaelfolkson> Emcy: The whole point is flexibility of parallel deployments given it is so hard to get consensus on exact details
07:28 < Emcy> yeah i mean having consensus divergent clients in play at every possible soft fork upgrade is insane, so
07:28 <@michaelfolkson> Only divergent in final two weeks
07:28 <@michaelfolkson> 50 weeks of total compatibility
07:28 < Emcy> divergent nonetheless
07:28 < luke-jr> murch: that would be meaningful if ST wasn't being deceptive
07:29 <@michaelfolkson> And if miners don't signal for an entire year what exactly are we supposed to do? Give up on the soft fork?
07:29 < luke-jr> 21.99.0 isn't necessarily ST, so that also doesn't count
07:29 < luke-jr> Emcy: so complain to ST, which diverged
07:29 <@michaelfolkson> Core could also release LOT=false to start with and then LOT=true if it wanted
07:30 <@michaelfolkson> Lots of options, pretty much maximum flexibility
07:30 < Emcy> luke-jr i cant to to you about stuff when youre like this
07:30 < luke-jr> Emcy: sorry you hate the truth
07:30 < Emcy> yeah, like that
07:31 < luke-jr> that's you, not me
07:32 < Emcy> im really not sure what went wrong with your friend/enemy mental heuristics
07:32 < Emcy> i mean youve always been a little bit like this, but never nearly to this extent
07:32 < luke-jr> nothing at all, stop trying to make this about me
07:33 < Emcy> im not the only one to consider that your demeanour has qualitatively changed this time
07:34 < luke-jr> doesn't mean you're not wrong
07:35 < Emcy> friends have tried to steer you away from your current path too, as well as enemies. But its like you cant even see the difference between those two things any more.
07:35 < luke-jr> just because you have a little group of people trying to strongarm a consensus change without community support doesn't mean everything your group says is right
07:35 < luke-jr> my current path is correct
07:36 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
07:36 < Emcy> like i joked before that maybe you went all 'false pope' about bitcoin core, but perhaps you really have now
07:36 < luke-jr> and considering all you have against it is lies and ad hominem, is not in the slightest bit convincing
07:36 < CubicEarth> michaelfolkson: perhaps miners would just start orphaning the non-compliant blocks
07:37 < CubicEarth> or non-activating
07:37 < luke-jr> CubicEarth: that's a 51% attack
07:37 < luke-jr> on the entire network
07:37 < CubicEarth> luke-jr: it would be a 70% attack , as of now
07:37 < CubicEarth> miners are users too. It's not that different than a UASF
07:37 < luke-jr> CubicEarth: irrelevant, it harms Bitcoin
07:37 <@michaelfolkson> CubicEarth: You mean the forced signaling in the final two weeks (due in November 2022)?
07:37 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Read error: Connection reset by peer]
07:37 < luke-jr> yes it is
07:38 < luke-jr> CubicEarth: that means full nodes cease to be full nodes, en masse
07:38 < CubicEarth> miners are free to choose which blocks to build on top of
07:38 < luke-jr> CubicEarth: no
07:38 < CubicEarth> they are
07:38 < luke-jr> CubicEarth: no, they're not
07:38 < CubicEarth> I guess you are an authoritarian?
07:38 < luke-jr> Bitcoin depends on the assumption that miners only build on the latest valid block
07:38 < CubicEarth> It does not
07:38 < luke-jr> it does
07:38 < CubicEarth> does not
07:39 <@michaelfolkson> CubicEarth: I actually agree with CubicEarth here :) They are free to do whatever they like
07:39 < luke-jr> smh
07:39 <@michaelfolkson> We need users to enforce the forced signaling
07:39 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
07:39 <@michaelfolkson> If users aren't enforcing the forced signaling the forced signaling is irrelevant
07:40 < CubicEarth> "Bitcoin depends on the assumption that miners only build on the latest valid block " - this is an absurd statement. What even is a miner, luke?
07:40 < CubicEarth> please define
07:40 <@michaelfolkson> Miners can attempt to avoid the forced signaling. It is their right to mine whatever blocks they like. And it is users' right to accept or reject any blocks they like
07:41 < luke-jr> enjoy your consensus failure I guess
07:42 <@michaelfolkson> That's why we do everything in our power to avoid that scenario. Like giving 12 months+ of miner signaling
07:43 < CubicEarth> luke-jr: Your fundamental failure is to understand and define who is part of the consensus process
07:43 < CubicEarth> "miners
07:43 < CubicEarth> " - who are they?
07:43 < CubicEarth> What defines a miner?
07:47 <@michaelfolkson> Consensus is such a hideously slippery concept. I disagree with Luke on some of his perspectives on consensus and I disagree with some of the "BIP 8 never had consensus" crowd
07:47 <@michaelfolkson> And by crowd I mean murch and Emcy
07:48 < Emcy> its more people than us
07:48 <@michaelfolkson> I'd direct them to the conversation logs if they showed up too
07:48 < Emcy> again i think all you can see is whats immediately in front of you, in this channel
07:49 <@michaelfolkson> Nope, I monitor various content distribution
07:49 <@michaelfolkson> And post it in this channel generally
07:50 <@michaelfolkson> Including perspectives I disagree with (eg Matt's anti UASF stance in podcasts)
07:51 < belcher> if matt is so against UASF why did he propose a flag day UASF on the mailing list? maybe things are not as simple as you say
07:52 <@michaelfolkson> belcher: Ok agreed I should be more precise. He was anti the UASF in 2017 and he is anti forced signaling for Taproot
07:52 <@michaelfolkson> I am 100 percent sure the above is correct
07:54 < Emcy> interesting, i didnt see that re: matt
07:55 < belcher> my understanding of his view is that he doesnt like forced signalling (shared by bip148 and bip8 lot=true) and back in feburary he wrote the flag day email to give people a good alternative to it
07:56 < belcher> the argument seems convincing to me, forced signalling adds risk in return for no benefit
07:56 <@michaelfolkson> MASF had a opt in flag day after 3.5 years https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html His view might have changed since then. That was January 2020
07:57 <@michaelfolkson> Whether forced signaling has benefits or not: https://bitcoin.stackexchange.com/questions/102585/what-is-the-benefit-of-forced-signaling-in-a-soft-fork-activation-mechanism
07:57 < luke-jr> belcher: it is not a good alternative, it is insane
07:58 <@michaelfolkson> I disagree with a flag day even in a scenario where the based client didn't exist/hadn't been deployed/would never be deployed
07:58 < copumpkin> btc.com seems to be signaling now :)
07:59 < copumpkin> \o/
07:59 < Emcy> looks like btc com just started signalling
07:59 <@michaelfolkson> copumpkin: Cool
07:59 < Emcy> snap
07:59 < belcher> michaelfolkson i always used "MASF" to mean "miner activated soft fork", i just realized maybe you used it to mean "Modern Soft Fork Activation" (matt's framework) ?
07:59 < belcher> a slight confusion if so
08:00 <@michaelfolkson> belcher: Oops yeah that was a typo. MSAF, Modern Soft Fork Activation. Apologies
08:00 < belcher> all good, just wanted to check
08:01 < luke-jr> MSFA* though the name is ridiculous
08:02 < luke-jr> the concept therein reminds me of PoS: security by overcomplication and hoping people can't figure it out
08:02 <@michaelfolkson> Security by obscurity, yeah I was thinking that with the MTP and block height thing
08:04 < luke-jr> yes, I suppose even there to a lesser degree
08:05 < luke-jr> design something prone to flaws, then address each flaw as it's discovered with a hack
08:05 < luke-jr> rather than just using a design that is clearly not flawed
08:05 <@michaelfolkson> With code we can stop a UASF or an alternative client with forced signaling in its tracks. Except you can't, at least not in advance. You can later release something incompatible, that's all you can really do
08:06 <@michaelfolkson> That's been an expensive lesson (in terms of developer time expended in the last few months)
08:20 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
08:33 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
08:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:37 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
08:58 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
09:04 -!- larryruane__ [uid473749@gateway/web/irccloud.com/x-xhtqlkezxheqtixt] has joined ##taproot-activation
09:13 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
10:16 < AaronvanW> Emcy: Adam Back did not sign the NYA.
10:16 < AaronvanW> Problem with the NYA (for me) was that is was a closed door, invite only thng.
10:17 < AaronvanW> Whatever you think of BIP8 or the LOT=true client, that wasn't the case for any of the ##taproot-activation or ##uasf meetings.
10:22 < luke-jr> AaronvanW: so if it wasn't closed-door, you'd be okay with NYA forcing 2X on everyone?
10:24 < AaronvanW> no. I guess I should have said, "one of the problems..."
10:30 -!- realname192 [~real@mob-5-90-90-228.net.vodafone.it] has joined ##taproot-activation
10:31 -!- realname192 [~real@mob-5-90-90-228.net.vodafone.it] has quit [Client Quit]
10:50 < AaronvanW> belcher: "i wonder what would happen if a third group releases their own alt-client which is intentionally incompatible with the based client, maybe they'd say they want to resist the idea that a tiny group of people can push bitcoin around, i guess this other alt-client would have some rule that the first blocks after the bip8 flag day must not signal" <--- this is what I meant when I asked the other day if anyone wo
10:50 < AaronvanW> uld split the chain over LOT=true, btw. (to which aj took offence I think, but I meant it as an honest question.)
10:52 < luke-jr> that's a contentious hardfork
10:52 < AaronvanW> it's a soft fork v. soft fork split.
10:53 < belcher> luke thinks that bip8=true is the real bitcoin and therefore this thing is a hard fork :p
10:56 < AaronvanW> the question for me would be, would the anti-client coin have any value? (and if so, why?)
10:56 < belcher> it would be for people who disagree with forced signalling, and/or who disagree with the intolerant minority pressure where a small group changes bitcoin for everyone
10:57 < belcher> so it would depend on how much that convinces
10:57 < belcher> i think its mere existence would help remove the argument that core should adopt bip8 lot=false just to be compatible with the based alt-client
10:57 < AaronvanW> why?
10:58 < AaronvanW> LOT=false would also be compatible with the anti-client, namely if miners don't signal.
10:58 < AaronvanW> LOT=false would be saying: whatever miners decide. (Which is indeed what LOT=false is.)
10:58 < belcher> bip8 has a forced signalling period if the signalling ends up true doesnt it? even if lot=false
10:58 < CubicEarth> The idea of a hard-fork is only relevant in terms of the relatively undesirable technicality of having a specific block height where non-upgraded clients get forced off
10:59 < AaronvanW> belcher: LOT=false clients would only follow the LOT=true chain if it's longer.
10:59 < CubicEarth> Any political goal can be achieved via a soft fork
10:59 < CubicEarth> ANY
10:59 < belcher> CubicEarth can printing more than 21 million coins be achieved with a soft fork?
11:00 < CubicEarth> belcher: sure
11:00 < CubicEarth> "extension coins"
11:00 < CubicEarth> like extension blocks
11:00 < CubicEarth> they would be invisible to non-upgraded clients of course
11:01 < belcher> extension coins arent bitcoins
11:01 < belcher> we have those extension coins today because namecoin is merge mined with bitcoin
11:01 < CubicEarth> I mean you could keep saying that, but if 90% of economic power and exchanges etc embraced the idea, they basically would
11:01 < belcher> i think the tether stablecoin also used to be an extension coin on bitcoin, and it also didnt effect the 21m limit
11:02 < belcher> well if 90% of economic power do it then they can do a hard fork as well
11:02 < CubicEarth> I'm not saying they couldn't do a hard fork... but doing it as a 'soft fork' would just mean a smoother upgrade path
11:03 < CubicEarth> less risk at a moment in time
11:03 < belcher> a hard fork seems smoother tbh, because SPV wallets would go along with it too without needing to be updated
11:03 < luke-jr> belcher: making the bit invalid is itself a forced signal
11:04 < luke-jr> belcher: and no, BIP8 only ever has FS if we reach the final signalling period without lockin
11:04 < belcher> i see
11:05 < luke-jr> also after 10% of the final signalling period is non-signalling
11:05 < luke-jr> (during MUST_SIGNAL, up to 10% of blocks are tolerated without a signal)
11:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:09 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds]
11:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
11:21 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
11:24 < CubicEarth> So BTC.TOP signaled with 2 of their 6 blocks so far?
11:24 < CubicEarth> sry
11:24 < CubicEarth> meant btc.com
12:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
12:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:22 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
12:27 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
12:54 -!- duringo [2578d7e6@37.120.215.230] has joined ##taproot-activation
13:03 -!- bcman [~quassel@192.252.212.38] has quit [Read error: Connection reset by peer]
13:04 -!- bcman [~quassel@192.252.212.38] has joined ##taproot-activation
13:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
14:00 -!- CARO [~Cesar@2804:7f4:c19f:705e:60b5:48cf:f47c:1035] has joined ##taproot-activation
14:02 -!- CARO1 [~Cesar@2804:7f4:c19f:705e:588c:8b33:6303:91ad] has quit [Ping timeout: 260 seconds]
14:57 -!- paultroon [rich@2600:3c00::f03c:92ff:fe8e:dce6] has quit [Ping timeout: 258 seconds]
15:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
15:27 -!- rich [rich@2600:3c00::f03c:92ff:fe8e:dce6] has joined ##taproot-activation
15:29 -!- duringo [2578d7e6@37.120.215.230] has quit [Quit: Connection closed]
15:41 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
16:32 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
16:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
16:36 -!- lukedashjr is now known as luke-jr
17:16 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
17:19 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
17:20 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
17:24 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
17:27 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds]
17:39 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
17:48 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
17:51 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
17:52 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
17:53 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
17:59 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has joined ##taproot-activation
18:03 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Ping timeout: 260 seconds]
18:21 -!- duringo [2578d7e6@37.120.215.230] has joined ##taproot-activation
19:39 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
19:42 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
20:16 < robert_spigler> luke-jr: if bitcoin assumes miners build valid blocks (on valid blocks), you wouldn't need full nodes? Full nodes assure that they do
20:20 < robert_spigler> MUST_SIGNAL only occurs with LOT=True and if LOCKED_IN was not reached?
21:12 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
21:13 < luke-jr> robert_spigler: full nodes are needed to ensure they don't have an incentive to perform attacks
21:17 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
21:19 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Client Quit]
21:24 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
23:23 -!- molz_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
23:54 -!- larryruane__ [uid473749@gateway/web/irccloud.com/x-xhtqlkezxheqtixt] has quit [Quit: Connection closed for inactivity]
--- Log closed Fri May 14 00:00:54 2021