--- Log opened Tue Apr 13 00:00:24 2021 00:08 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 00:11 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds] 00:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 00:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 252 seconds] 01:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 01:14 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation 01:21 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Quit: Leaving] 01:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 02:10 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection] 02:28 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 02:57 -!- mips_ [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 02:57 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 03:02 -!- grubles_ [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 03:07 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 03:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation 03:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 04:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 04:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 05:10 <@michaelfolkson> There are going to be a number of meetings I suspect in the coming days and weeks on Taproot activation in this channel. There is one scheduled today at 19:00 UTC https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018769.html 05:10 <@michaelfolkson> Today's one wants to discuss an alternative release to Core. 05:12 <@michaelfolkson> I think I will attend all meetings from this point on and insist that agendas are followed 05:16 <@michaelfolkson> I won't organize any meetings personally but if the organizer of the meeting feels someone is disrupting the meeting and not allowing the agenda to be discussed I (with my current ops) will boot them after warning and only in consultation with the meeting organizer 05:23 <@michaelfolkson> Anyone is free to organize a meeting on this channel as long as that time slot hasn't already been booked. 06:32 < Emcy> >alternative release to core 07:03 <@michaelfolkson> Emcy: You have a question? 07:07 < Emcy> yeah. what the fuck does alternative release to core mean. 07:14 < emzy> I think we talk about Bitcoin Knots 07:15 < Emcy> obviously but i didnt want to straight up call it 07:17 -!- belcher_ is now known as belcher 07:18 < emzy> Othere are free to do the same. 07:20 <@aj> Emcy, emzy: https://github.com/BitcoinActivation/bitcoin/pulls?q=is%3Apr ; see http://gnusha.org/uasf/ as well perhaps 07:21 < harding> michaelfolkson: you could give ops to the meeting organizer, that way they can warn and kick disruptive people directly. You can de-op them after the meeting. 07:21 < Emcy> owo whats this 07:22 <@michaelfolkson> harding: Thanks, that makes more sense. I will do that 07:23 < Emcy> so whos bitcoinmechanic 07:26 <@michaelfolkson> Emcy: What exactly do you want to know about them? I can't answer your question but there are a lot of pseudonyms in this community 07:30 < Emcy> if the idea is to get people to run some alternative node, the first thing people want to know is 'from whom' 07:30 < Emcy> is it you? 07:30 < belcher> well in principle because its all open source it doesnt matter who created it (i know practice reputation and personality matters, but ideally it wouldnt) 07:32 < Emcy> yes in principle, but there are a few heretofore axiomatic principle of open sources that dont necessarily apply to the bitcoin project as they would nearly anything else 07:32 <@michaelfolkson> Emcy: I can personally confirm it is categorically not me 07:32 < Emcy> the idea of running alternative nodes whatsoever, for a start 07:43 < queip> the patch between this and bitcoin core should be pretty small, right? do manual review before building? 07:43 < queip> maybe recommend people to 1) download core 2) run patch -p0 tapuasf.patch 3) make 07:44 < queip> alternatively, have a well known person, like luke, confirm and sign that such and such binary is result of build from core + given patch, and the patch has following effects 07:45 < Emcy> its not just about this single release, its about future releases too, and its about not having node running entities split between running code from disparate repos 07:46 < Emcy> i know its counterintuitive to the received wisdom of foss, but the arguments have all been gone over before 07:47 -!- bcman [~quassel@static-198-54-131-123.cust.tzulo.com] has joined ##taproot-activation 07:47 < bcman> Hi Emcy - I'm BitcoinMechanic 07:48 < Emcy> hi 07:48 < Emcy> i dont recognise the name 07:48 < bcman> Can confirm I'm neither Luke or Michael 07:48 <@aj> how would you do that? 07:48 < bcman> I'm not anon 07:48 < bcman> But unknown to devs 07:48 < bcman> Have been in the community for years 07:49 -!- faketoshi [~quassel@static-198-54-131-46.cust.tzulo.com] has quit [Ping timeout: 268 seconds] 07:50 <@aj> it's craigh wright?? 07:50 < BlueMatt> aj: lolol 07:50 <@aj> h? where'd that come from 07:50 <@aj> oh no, it's h for they've Hacked my keyboard 07:51 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving] 07:51 <@aj> pls note, in future any typos i might make are are all craig wright's fault 07:51 <@aj> see, like that extra are there 07:51 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 07:51 < BlueMatt> queip: it doesn't matter *where* the code is, the point being that running multiple divergent consensus implementations on a *consensus network* carries with it very significant risk. sure, in a emergency or dire situation that risk may be worth taking, but suggesting the risk is worth it today is, like, lulzy 07:52 < BlueMatt> aj: makes about as much sense as anything else related to craig lol 07:53 < bcman> You're free not to run what we release 07:54 < bcman> the whole coinflip MTP thing, I think devs have completely missed the mark on what users actually want 07:54 < BlueMatt> bcman: risk to the network, if large enough (luckily it wont be), in addition to the end users. point being educating people on the risks is important, its a distributed system people run what they want :). 07:54 < BlueMatt> bcman: there was no goddamn coinflip 07:55 < BlueMatt> bcman: a few people *suggested* a coinflip, but at the end of the day people came to agreement on a way forward before having to use the coinflip result 07:55 < Emcy> the coinflip occured, but it was already mooted by the time the result came up 07:55 < Emcy> so its moot 07:56 < BlueMatt> heh, fine, pedantics 07:56 < bcman> Frankly I think it's a better precedent. Why does it have to be up to you guys to roll out activation? It only causes division - just let it be grassroots? 07:56 < bcman> That's why we got segwit when we did - though I know you disagree 07:56 < belcher> the vast majority of users dont care how we get taproot as long as we get it, users care about actual issues like privacy, miner fees and fungibility 07:56 < Emcy> actually i ran a bip148 node back in the day 07:57 < bcman> What about Rusty's point that we need to fix the actual process so that we don't have to keep going through all this everytime we want to activate? 07:57 < Emcy> i dont know if id do the same now though. and the situation was not nearly comparable to now 07:57 < copumpkin> where's the division coming from right now? folks harping on MTP vs. height and LOT boolean values, which 99.9% of users don't give a **** about :) the noise from these arguments is causing far more division than any particular decision is 07:58 < BlueMatt> bcman: because if we stop to "fix the process" we'll never go anywhere lol 07:58 < BlueMatt> bcman: look around, no one can agree on anything, and without that we go nowhere. 07:58 < bcman> you don't need to do anything :P 07:58 < Emcy> > faketoshi (~quassel@static-198-54-131-46.cust.tzulo.com) left IRC (Ping timeout: 268 seconds)....(~quassel@static-198-54-131-123.cust.tzulo.com) has joined 07:58 < Emcy> whats going on here 07:58 < BlueMatt> what copumpkin said. 07:58 < copumpkin> if bitcoin had binding precedent, then process might be something to strive for, but nobody can agree on the color of the sky, let alone anything meaningful 07:58 < BlueMatt> right, that. 07:59 < belcher> bitcoin has broken precedent many times 07:59 < belcher> bitcoin works with code, not precedent 07:59 < belcher> you cant force the future to do something 07:59 < BlueMatt> anyway, I need coffee. Maybe we can debate the color of my coffee, its probably a decent shot at agreement, but I'd give it 50/50 07:59 < copumpkin> bitcoin needs covenants, but for people :D *runs* 07:59 < Emcy> BlueMatt if you dont take it dark fuck you 08:00 < BlueMatt> Emcy: does an iced americano with half-water count? 08:00 < bcman> >99.9% of users don't give a fuck about...... 08:00 < bcman> uh yeah that's wrong 08:01 < Emcy> BlueMatt ill allow it 08:01 < BlueMatt> lololol, you think even 1% of bitcoin users cares about the precise activation method? man you need to get our of your filter bubble 08:01 < queip> coffee https://i.pinimg.com/474x/ff/cf/3b/ffcf3b562a6d26e1dd140edccf25dd4e.jpg 08:01 < bcman> that'd be 0.1% 08:01 < bcman> not 1% 08:01 < copumpkin> see, we can't even agree on a number pulled out of a hat :) 08:01 < BlueMatt> same point, you get my point 08:01 < BlueMatt> copumpkin: lol 08:02 < bcman> have your coffee bro 08:03 < bcman> if your concern is two different activation methods going live on the network at the same time, just use same params as us. we aren't doing anything that wasn't basically considered fine by pretty m uch everyone in here anywya 08:03 < copumpkin> they think they care because random reddit posts pop up asking for a random opinion on technical minutiae that doesn't actually affect them. People like to pick factions, it's a well understood phenomenon. Swift described it around which side eggs get eaten from and we named a computing concept after it, but then we go poll people about stuff they barely understand and expect an informed opinion or a meaningful vote out of it 08:03 < bcman> bip8, lot true, plan y from here basically: 08:03 < bcman> https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0 08:04 < bcman> this gets released today probably. if you all want to create an incompatible release then you're defying your own arguments 08:04 < bcman> again, this isn't stuff that wasn't basically fine with almost everyone in here anyway 08:04 < copumpkin> I don't really care, I just think it's silly 08:04 < bcman> with the added bonus of not having to worry about devs looking like they have too much power 08:04 < Emcy> bcman WHO IS WE 08:05 < Emcy> -CAPS 08:05 < Emcy> -caps 08:05 < bcman> it might be silly but it'll get us taproot and prevent more bikeshedding 08:05 < bcman> so doesn't seem so to me 08:06 < belcher> the hard part is convincing many people to actually run it 08:07 < bcman> I really don't think that'll be particularly hard 08:07 -!- bcman [~quassel@static-198-54-131-123.cust.tzulo.com] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 08:07 -!- bcman [~quassel@static-198-54-131-123.cust.tzulo.com] has joined ##taproot-activation 08:08 < queip> is bcman's proposed version good? if ppl here say so, I could, for one, run it (guarding my small wageslave stash) 08:09 < queip> or rather - is there any better ready or planned? 08:09 < Emcy> wait so you dont intent to at least let the ST run first? 08:11 < bcman> this is ST compatible 08:11 < bcman> no, I think I will run this by end of day today 08:12 < Emcy> ok 08:12 < Emcy> but who else is organising it? luke? 08:13 < bcman> me, michael folkston, shinobi, tomer, and a couple of anons 08:14 < bcman> i don't honestly know :) 08:15 < Emcy> alright thanks 08:16 <@michaelfolkson> It only takes one person to organize a meeting. bcman is organizing the meeting. I was aware of it as are many others. The mailing list has been informed 08:16 <@michaelfolkson> It isn't hard. If you want to organize a meeting Emcy you can. Just let me know a time and announce it to the mailing list 08:16 < Emcy> i didnt say i did 08:17 < bcman> my bad, michael isn't any more responsible for anything going on here than I might have made him out to be 08:17 < Emcy> i already started a 'meeting' here anyway 08:17 < bcman> don't wanna get anyone in hot water 08:17 <@michaelfolkson> I don't understand your questions on who else is organizing it, that is all 08:17 <@michaelfolkson> It just takes an individual 08:17 < Emcy> organising the forked client 08:18 < bcman> I'll take the heat for that 08:18 <@michaelfolkson> Ok that is a different question Emcy 08:18 <@michaelfolkson> You are asking who the contributors are of the forked client? 08:18 < Emcy> bcman talked about 'we' will run it today etc 08:18 <@michaelfolkson> That is different to who organizes a meeting 08:18 < bcman> did i answer you Emcy? 08:19 < Emcy> i dont think so? you answred the wrong question 08:19 < Emcy> or maybe i asked the wrong way 08:19 <@michaelfolkson> Anyone can fork Core, anyone can contribute to a project, anyone can release a project 08:20 < bcman> why does it matter? code is code and it's what the community wants. and it's not maliciously incompatible with what might eventually be a core release. 08:20 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has joined ##taproot-activation 08:20 < Emcy> i think we already went thru that 08:21 < copumpkin> IMO it's too focused on technical consensus ignoring human consensus factors because it's much easier to measure, but we obviously can't stop you :) 08:21 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 258 seconds] 08:22 < Emcy> no one can stop anyone forking anything, and no one suggested it either 08:22 < bcman> uh that's wrong 08:22 < bcman> loads of people wanted to shaolinfry this for a long time now 08:22 <@michaelfolkson> So are you considering running this software and you want to know who has signed off on it Emcy? I'm trying to understand exactly what information you want 08:22 <@aj> i think emcy meant "no one suggested anyone can stop people forking things" 08:23 < queip> bcman: curious, what do you mean, by that they wanted to shaolinfry it? (yes I know he's author of 148 patch) 08:23 <@michaelfolkson> aj: Ok, I just don't know what information he wants, that is all 08:23 <@aj> michaelfolkson: the above was in reply to bcman's comment not yours fwiw 08:23 < bcman> write a client that would enforce miner signalling 08:23 < belcher> the difference with 2017 and bip148 is there was already a MASF deployment out there, which only required forced signalling... while today we dont have that and mere forced signalling isnt enough 08:24 -!- roconnor [~roconnor@host-45-78-202-80.dyn.295.ca] has joined ##taproot-activation 08:25 < BlueMatt> if your concern is two different activation methods going live on the network at the same time <-- what? no, dude, we've been over this many times, the issue is divergent consensus rules *period*. Please read and think very, very carefully about goals #3 and #4 of https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 08:25 < Emcy> michaelfolkson i wouldnt run it at this juncture. im confused why bcman would reveal himself to me as a principal of the client fork, and reveal there are others but not say who 08:25 < BlueMatt> I couldnt care less if taproot activates via X or Y or Z, the issue isn't two different nodes deploying X and Y its the basic principle of divergent consensus rules carry significant risk. 08:25 < belcher> the effect back in 2017 was that if segwit activated, then even if a miner stole coins on a segwit address and sent them to places like coinbase or bitstamp they would reject the transaction, because they were all running bitcoin core 0.13.1... while today if a miner stole taproot coins then coinbase or kraken would accept them (unless you think coinbase will run an altclient)... thats why i say a UASF this time around is much harder 08:25 < belcher> and cooperation is better 08:27 < BlueMatt> right, UASF has *always* been about forcing others to activate a soft fork by force, not activating it on its own merit 08:27 < BlueMatt> so much for libertarian ideals in bitcoin, I guess 08:27 < Emcy> BlueMatt when it was literally 1 guy cock blocking everyone else, the argument was different 08:27 < Emcy> but thats not the argument now 08:27 < BlueMatt> right, exactly 08:28 < bcman> Emcy: I've said who everyone I know is who has had involvement 08:28 < bcman> there are genuinely anons helping too - idk who they are 08:28 < BlueMatt> gets back to "carries significant risk, maybe is worth it sometimes, but lol at it being worth it today" 08:29 < Emcy> oh ok, i thought you were answering the other erroneous question, sorry 08:29 < BlueMatt> eh, there's like five arguments for why trying to push a UASF right now is just...dumb, gets confusing when there's so many arguments to make lol 08:30 < bcman> try steelmanning the other side 08:30 < belcher> it seems to me that the UASFers today in 2021 dont really care about taproot or privacy, they more care about "setting a precedent that miners dont control bitcoin's rules", is that a fair assessment? 08:30 < copumpkin> just because there's a contingent of folks who want something that takes technical skill to develop, doesn't mean someone with that skill should help them develop it. Users want all sorts of stupid stuff all the time, and this UASF feels premature and like a knee-jerk reaction to a past event that happened under vastly different circumstances 08:31 < bcman> maybe this is pedantry - but it's still a MASF? 08:31 < bcman> it's not stupid stuff, it's basically stuff everyone in here would be find with anyway 08:32 < BlueMatt> what is still a MASF? ST? ST isn't a MASF by any reasonable definition of "MASF or we walk away" its a "MASF or we do it some other way" 08:32 < belcher> if we're talking about bip8 LOT=true then its a MASF followed by a UASF... and the UASF is the part some people have concerns with 08:32 < BlueMatt> bcman: no, many people would very explicitly *not* be fine with a bip8 lot=true fork client even if core had a bip8 lot=false in a release. 08:33 < bcman> so you tell me - what is everyone fine with? 08:33 < belcher> speedy trail seems to have pretty good levels of support 08:33 < copumpkin> ST seemed like the least controversial thing we had, until certain folks decided that was too much human consensus and started NACKing that too :P 08:33 < bcman> agreed 08:34 < BlueMatt> copumpkin: its *still* the least controversial thing we have, by far, sadly 08:34 < BlueMatt> in spite of some people getting upset that they aren't getting exactly their way 08:37 <@michaelfolkson> compumpkin: The block height/mix of block height and MTP and BIP 8/9 thing has just been dumb. Even something with that much consensus (Speedy Trial) has created stupid battles, coin tosses and whatever other nonsense 08:39 <@michaelfolkson> I will personally defend me ACKing it on March 6th and rescinding that ACK a week ago 08:40 < copumpkin> yeah. To be fair, I'm not really qualified to opine deeply about the technical merits of all this either, but we could s/taproot/what tree to plant in the backyard/ and it would still be a set of stupidly frustrating patterns emerging in normal human behavior, where I think people get too focused on debate for its own sake, technical perfection, some notion of idealized formal structures (triumvirates, precedents, etc.) in a 08:40 < copumpkin> system that is patently not conducive to them. It's boiling down to a bunch of people trying to use taproot to advance whatever their pet cause was 08:40 < copumpkin> the coin toss was bad PR. It was folks saying it was a bikeshedding exercise and that they didn't care, but got portrayed as frivolous and caused more noise than it solved, so I regret saying I supported that 08:41 < belcher> doesnt it seems like a triviality? like who cares whether its MTP or height as long as we get taproot... curious on thoughts for why the MPT/height thing is even important 08:41 <@michaelfolkson> belcher: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 08:41 < belcher> tbh id rather bitcoin dev focused on good technical discussion rather than what is good or bad PR on social media... anyway back in the block size debates we had loads of twitter PR drama too and got through it 08:42 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has joined ##taproot-activation 08:42 < belcher> ty for the link michaelfolkson 08:42 <@michaelfolkson> I don't think it is NACK worthy personally but majority of reviewers so far prefer consistent block height 08:43 <@michaelfolkson> (including me) 08:43 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has joined ##taproot-activation 08:46 < bcman> i don't have a lot of availability between now and the scheduled meeting. 08:47 < copumpkin> belcher: I think we'd all prefer that, but if anything this process has shown that we can't just idealize dev work and devs are still people and split into factions over the dumbest shit, and pretending that doesn't happen just lets it implicitly happen 08:47 < bcman> exactly 08:47 < Yoghurt11411> belcher: as you know, UASFers are concerned about the MTP approach being perceptibly unfriendly toward the possibility of UASF (reinforced by comments here) should the need for it arise for whatever reason and deemed necessary by the community, which as we have seen in 2017 can occur unexpectedly - on a technical level it isn't so much about the 08:47 < Yoghurt11411> MTP/height distinction anymore 08:49 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has quit [Quit: Connection closed] 08:51 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 08:53 < bcman> gotta say BlueMatt statements like "lolol you think even 1% care about activation methods" are a terrible look. Maybe try working on showing the community some respect. Remember, you're trying to do what the community want, not tell them. 08:54 < BlueMatt> Yoghurt11411: the whole *point* of ST is to just do something, give taproot a chance to activate, and, if it doesnt work out, move on to something else to activate taproot, likely not involving hashpower. tryign to push a UASF into the few-month window of ST defeats the whole purpose, wtf. 08:54 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 240 seconds] 08:55 < roconnor> BlueMatt: the UASF proposal doesn't mandate signaling until October 2022. 08:55 < BlueMatt> bcman: please dont try to read so much into things just to project malice. saying that most people dont care != saying that we should ignore people who do care. 08:55 < BlueMatt> roconnor: right, but Yoghurt11411's comment was about the specific activation method for ST, which is unrelated. 08:55 < roconnor> (just stating facts, not meant as endorsement). 08:56 < Yoghurt11411> BlueMatt: right nobody is proposing to UASF on ST params 08:56 < BlueMatt> then why be concerned over MTP-vs-height. 08:56 < BlueMatt> that just sounds like an excuse to be upset more than anything 08:58 <@aj> roconnor: you mean block 758016, no some date thing ;) 08:58 < roconnor> aj: yes. October 2022ish. 08:58 < Yoghurt11411> because what this bikeshed has created is a generalized approach to activating upgrades, one where UASFs are deemed undesirable, which UASFers take a principled stance against 09:00 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-gkorissoqffbncih] has quit [Quit: Idle for 30+ days] 09:00 < BlueMatt> Yoghurt11411: noooo, now you're back to projecting here. ST came about because *some* people (including myself) indicating that UASFs as a default are highly undeseirely, and others felt strongly that they were the best way to land eventually. ST exists as a compromise where we can maybe get taproot without having to fight that battle, knowing that in the case of ST failure we will have some other form of activation that does not 09:00 < BlueMatt> hinge on miner signaling. 09:00 <@aj> Yoghurt11411: UASFs aren't undesirable; the risk of a consensus split is. if there are other ways of doing a UASF that have lower risks of a consensus split than bip8's LOT=true, why wouldn't we pursue that, especially if we can get taproot underway while we do so? 09:00 < BlueMatt> actually, what aj said, thats way better phrased :) 09:03 < roconnor> aj: the risk of consensus split due to manditory signaling? 09:03 < BlueMatt> Yoghurt11411: note that even my (one of the most vocal detractors of bip8 lot=true-in-separate-node-software-style deployments) initial proposal included a focus on "if we do a MASF and it fails, we can, and we should do something else to activate, some miner blocking a fork for their own gain is stupid and shouldn't be allowed" 09:04 < BlueMatt> roconnor: that, plus divergent consensus implementations on the network. 09:04 < BlueMatt> (at least absent other options) 09:04 < BlueMatt> roconnor: I keep going back to, but I really do think they were reasonably well-put, the explicit goals list on https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 09:05 < BlueMatt> #3 and #4 apply significantly here, we shouldn't just throw away great ways we have to de-risk upgrades if we don't have to 09:05 < BlueMatt> sure, if we have to, we can, but lets not suggest that its a good default 09:06 < Yoghurt11411> BlueMatt nobody except very few people are arguing for bip8 lot=true to be released in a Core binary (myself I prefer lot=false there) - i.e. by ignoring very few people will there be what is called consensus on that approach, while retaining compatibility with- and friendliness toward a later UASF should this be necessary and championed by the 09:06 < Yoghurt11411> community of users (which by all indication it won't, but, again, this possibility must not be precluded) 09:08 <@aj> roconnor: for example, deploying a BitcoinActivation node tomorrow, then taproot doesn't activate via speedy trial, and we find a horrendous bug so go back to the drawing board, then come oct 22 your node stops working. there's some theoretical risks with unupgraded miners potentially causing longish reorgs, too 09:09 <@aj> err, october 2022 09:13 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has joined ##taproot-activation 09:13 <@michaelfolkson> With respect aj, if you had just used consistent block heights when you opened your PR, Andrew wouldn't have needed to open a competing PR and all review could have been focused on your PR 09:14 <@michaelfolkson> Speedy Trial would have probably been finalized and released by now 09:15 <@michaelfolkson> A bit rich to complain about risks of competing UASF client 09:15 < BlueMatt> Yoghurt11411: I didn't imply anything about bip8-lot-true-in-core? All of the above points are entirely about bip8-lot-true-in-secondary-client 09:15 < harding> Yoghurt11411: I think acceptanec of LOT=false in Bitcoin Core was contingent on no meaningful number of users running LOT=true in parallel unless it really was necessary (and there are arguments that it's probably never necessary to mandate signaling when you can use a less disruptive flag day instead). Part of the problem is that we can assume people running LOT=false want taproot but we can't necessarily assume that they want their 09:15 < harding> economic weight to be vulnerable to being co-opted in a debate with miners. 09:15 < BlueMatt> Yoghurt11411: and, in fact, such a world presents the higest risk to both those users and the overall bitcoin system. 09:16 < BlueMatt> Yoghurt11411: note, again, that nothing about ST is hostile to, or favorable to, an eventual UASF. 09:16 < BlueMatt> Yoghurt11411: ST is a compromise pre-main-deployment proposal, which exists purely to avoid having to debate issues surrounding UASF's today, while still possibly getting taproot 09:16 < Yoghurt11411> so am I to understand here that the mere mention of a LOT=true effort as a separate binary strong armed the move away from BIP8-style heights and toward MTP? 09:16 < BlueMatt> Yoghurt11411: any attempts to read it as hostile to, or favorable to, an eventaul UASF is just over-reading and putting words in peoples' mouths. 09:17 < BlueMatt> Yoghurt11411: uhhhhh, what? Again, you're wayyyy over-reading into this whole thing 09:17 < BlueMatt> Yoghurt11411: it sounds like you just want to read hostility towards you or your views when no such hostility exists 09:18 < Yoghurt11411> "acceptanec of LOT=false in Bitcoin Core was contingent on no meaningful number of users running LOT=true in parallel" please help me understand how I am mistaken 09:18 < BlueMatt> Yoghurt11411: people have have highly divergent views on the issue, so trying to say that the eventaul conclusion of those many people is "hostile to an eventual UASF" is just...nonsense 09:18 < harding> Yoghurt11411: LOT=true|false has nothing to do with heigth or MTP, AFAIK. 09:19 < BlueMatt> Yoghurt11411: where did you get that quote, who did you get it from, and what makes you think the person making that statement speaks for at least twenty people who very strongly disagree with each other? 09:19 < Yoghurt11411> I have not used the word "hostile" once, to be clear 09:19 < Yoghurt11411> BlueMatt about 10 messages up 09:20 < harding> Yoghurt11411: that's my bad, I should've said "contingent for some people". 09:21 < BlueMatt> Yoghurt11411: the point harding was trying to make, I hope, and he is free to whack me over the head if I'm wrong, is that there were strong and divergent views on first steps here - many people (again, including myself) viewed a UASF with divergent consensus-incompatible clients as the *first step* being a really bad idea 09:21 < BlueMatt> Yoghurt11411: that should not be read as "everyone disagreed" nor should it be read as "people agreed that we must never do a UASF or that ST is a compromise to suggest that we shouldn't do one" 09:23 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has quit [Quit: Connection closed] 09:23 < BlueMatt> about the only thing anyone around here agrees on, is that ST is only a first trial (hence the word "Trial" in the name :p), its a compromise to avoid endless debate but it doesn't imply much about how things can or should occur in the case that it fails. 09:23 -!- mips_ is now known as mips 09:25 <@aj> doesn't really avoid endless debate, so much as make some of it irrelevant 09:25 < BlueMatt> right 09:26 < Yoghurt11411> BlueMatt: to be quite honest I doubt that is the case, in that should the trial end up failing, that this failure leaves strong implications for future action 09:26 < roconnor> I was about to say. The endless debate can still continue concurrently with ST development and running. 09:27 <@aj> roconnor: yes, parallelising the endless debate 09:27 < BlueMatt> Yoghurt11411: you're projecting, though, onto other peoples' views. I mean say what you want about what other people are going to do, but its usually best to ask them first :) 09:28 < BlueMatt> roconnor: heh, true. though it does seem like most of us are disinterested in endlessly debating things when we hope we don't actually have to come to a conclusion asap. 09:28 < BlueMatt> roconnor: most of us have jobs :) 09:28 < queip> (as bitcoin holders) 09:29 < Yoghurt11411> I certainly agree there is a whole lot of projecting going on. 09:34 < emzy> I also think ST is a way to activate Taproot. But it will not stop the activation discussion for future activations. 09:42 < Emcy> copumpkin the only 'bad pr' came from adam as far as i can see 09:46 -!- harding [quassel@newmail.dtrt.org] has left ##taproot-activation ["need to get stuff done today!"] 09:52 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 09:54 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 09:57 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 10:06 < Emcy> i will make one other point: really deep, painstaking debate on microscopic minutia IS an important part of bitcoin development, but naturally there is only so much finite capacity for people to engage in that, and i think that capacity gets burned needlessly by trifling shit like most of this mtp vs height debate, or even most of the speedy trial vs lot true chat thats happening right now, to the very unfortunate detriment of the bitcoin 10:06 < Emcy> project as a whole. I think some of you lose sight that bitcoin is a generational project that ideally should outlive all of us, literally. 10:07 < Emcy> and also, as a 'veteran' of the bip148 segwit uasf fuck-bitmain wars, i think a lot of yall still have some fuckin PTSD from 2017 playing on your minds 10:10 < emzy> UASF sould be be the last option. Not the first! 10:10 < BlueMatt> what Emcy and emzy said 10:10 < BlueMatt> also, y'all break my tab completion too much 10:11 < bcman> yes, miners or devs should make decisions 10:11 < bcman> completely agree 10:11 < bcman> can't trust plebs :) 10:11 < copumpkin> sigh 10:12 < BlueMatt> what does any of this have to do with "who decides"? 10:12 < BlueMatt> UASF is a separate thing from who decides on consensus rules 10:12 < bcman> uasf is users "deciding" 10:13 < emzy> bcman: It's about readiness not decisions. 10:13 < mol_> who's bcman? 10:13 < BlueMatt> especially when you get into concrete "uasf via forced signaling and bip 8 lot true/false in separate node implementations" thats a very concrete process and technical featureset that people are arguing against today, the general concept of users deciding and users being the ones to activate a soft-fork is, I'd think, and really hope, something that nearly everyone here strongly agrees with 10:13 < BlueMatt> mol_: someone really upset about....kinda unclear what? 10:13 < queip> bcman: I guess they say that *if* we can do it with miners "approval" without resorting to UASF then it is better that way while UASF still is a backup plan 10:14 < mol_> BlueMatt, must be the leader of the monkey circus? :D 10:14 < bcman> "Just read BIP148. Looks stupid." 10:14 < BlueMatt> bcman: note my last proposal for a way to activate taproot was straight up flag day. something that *only* makes sense when viewed as it being a UASF, just not the forced-signaling variety 10:14 < mol_> i told luke on slack that he was defeating himself but that didn't make him understand, he still keeps doing it :/ 10:15 < BlueMatt> mol_: yea, the sad part is all the noise to "deploy a uasf now" just detracts from anyone taking a later uasf movement seriously 10:16 < mol_> i would be behind luke 100% if luke just goes get a sanity pill for now 10:16 < Emcy> bcman the hell is that wuote from 10:16 < bcman> Jihan Wu 10:17 <@aj> https://www.reddit.com/r/Bitcoin/comments/6dikiq/jihan_wu_i_just_read_through_the_bip148_looks/ 10:17 < Emcy> listen 10:17 < Emcy> jihan wu was a madman 10:17 < Emcy> literaelly nutbar. he lost a billion literal dollars playing his games 10:18 < Emcy> he got fuckin rekt ok 10:18 < Emcy> jihan wu isnt all miners, and bitmain is mostly gone now anyway 10:18 < bcman> he had asicboost and wanted to preserve his advantage but miscalculated. 10:19 < Emcy> his miscalculation is that he was balls deep into bitcoin without truly understanding how it really wrosk, or what it even is or represents 10:19 < Emcy> thats why he thought he could take control 10:19 < Emcy> more to the point, jihan wu was irrational. 10:20 < Emcy> miners are rational, if they know wahts good for them. You dont think the rest of them saw how bad jihan flamed out? 10:20 < Emcy> miners are not enemies. theyre parts of bitcoin the same as anyone else is 10:21 < bcman> i'm not giving them veto power, sorry. 10:21 < Emcy> and another thing, the developers dont owe anyone jack shit, let alone 'respect' 10:21 < emzy> I agree with Emcy 10:22 < queip> bcman: are you against trying ST first? why not give them option to agree and do thing together right now 10:22 < bcman> are you against just using compatible params? there is little to no risk of running both at the same time 10:22 < Emcy> they dont have veto power now. they never did. if ST fails, they still wont and theyll find that out. 10:22 < BlueMatt> bcman: huh?! Please stop projecting here, yo, *no one* wants to, is suggesting, or in any way is proposing "giving miners veto power" 10:22 < Emcy> your understanding of bitcoin is as bad as jihans was if you think that is the case 10:23 < roconnor> Speedy Trial doesn't rely on miners being rational or otherwise. It only notes (just like every other proposal with an optional miner signalling phase) that if and when miners support activation we get a smoother and safer activation, so it is good to take advantage of that opportunity, should it occur. 10:23 < BlueMatt> what roconnor said 10:23 < Emcy> yes 10:23 < bcman> yup 10:28 < mol_> aj, there's a concern with some people that your "LAST_CHANCE" will not work for UASF in case we need it, can you elaborate on this? 10:29 <@aj> mol_: ? 10:29 < mol_> your PR.. will it allow UASF to work if we need it 10:32 <@aj> mol_: the scenario would be speedy trial fails; we realise this by start of Sept 2021; and decide that mandatory signalling is the best next step, and that we want to continue doing it via MTP, so merge the LAST_CHANCE patch, and set a new timeout of 2022-11-11. miners continue to not signal. 2022-11-11 arrives,... 10:32 < luke-jr> ^ empty 'promise' (if that) that will never happen 10:33 <@aj> mol_: ...and then <2016 blocks later we get to a retarget boundary. the state machine then transitions to LAST_CHANCE and mandatory signalling is enforced, so LOCKED_IN is reached at the start of the next retarget period, and ACTIVE is reached as of the following retarget period 10:34 < luke-jr> Emcy: ST was only ever acceptable running UASF at the same time 10:35 < jeremyrubin> TBH the whole "quick quick release UASF client before core release a ST client" reads to me like somone wanting their low adoption side project version of core to use an activation as a chance to grow userbase. 10:36 < luke-jr> jeremyrubin: your trolling reads to me like bad faith 10:36 < jeremyrubin> Trying to release a UASF client *today* reads like bad faith 10:36 < luke-jr> if Core did the right thing, there wouldn't even *be* a side project 10:36 < mol_> aj, ok thanks for your explanation :) 10:39 < BlueMatt> 🍿 10:40 < midnight> hey I can see that. I guess my custom font gets filled in where it doesn't report a glyph in its directory 10:40 < Emcy> 18:36 [luke-jr] jeremyrubin: i find your lack of faith disturbing 10:40 < BlueMatt> midnight: yea, I think thats normal, right? 10:40 < luke-jr> I had to copy/paste it to my phone 10:40 <@aj> mol_: you're welcome 10:41 <@aj> i just google the hex that comes up 10:41 < midnight> normally, yeah, on this terminal. often just square boxes on xterm, or I've made a mistake and included undrawn blank glyphs in the pixmaps and it's just blank. :( 10:42 < Emcy> midnight its just unicode 10:42 -!- bcman is now known as faketoshi 10:42 < midnight> like with those braille glyphs I needed to draw to properly/proportionally see the terminal pricecheck 10:42 < luke-jr> midnight: is your custom font by chance based on the old IBM bitmap font? 10:42 < Emcy> >computer screen 10:42 < Emcy> >braille font 10:43 < luke-jr> Emcy: braille has dedicated unicode positions 10:43 < midnight> luke-jr: No, I have a specific preference for font design which extends back to certain terminal characters from c-64 and c-128 days, then Amiga, and so on. I used the base .FON from an IBM font file but I've redrawn every glyph that was represented in it, and now include most of the common unicode that people use. Except not popcorn yet. 10:44 < luke-jr> XD 10:44 < midnight> I dislike not being able to differentiate iIlL|1 10:44 < luke-jr> IBM's font differentiates those 10:44 < luke-jr> I vs l is one pixel, but still 10:45 < achow101> they're all distinguishable to me, but perhaps I'm just not blind 10:45 < midnight> sort of. And not in the way that the pipe used to be represented on the c-64. Also I don't like the zero with the dot in the middle, I wanted the one with the slash. 10:46 < luke-jr> i c 10:46 < midnight> It's also the smallest possible bitmap which can successfully represent all those characters, properly aligned box-drawing, dithered, heavy-width line-drawing, partial-box-filled, greek letter, math symbols, etc etc. 10:46 < faketoshi> have fun staying bIind 10:47 < queip> during ST, if miners would signal support, is there anything at all enforcing it in anyway? what is the result of successful ST? 10:47 < midnight> And the caret is in the proper place. 10:48 <@aj> queip: everyone should upgrade to a version of the software that enforces taproot prior to min_activation_height being reached? 10:49 < queip> aj: no idea 10:49 <@aj> queip: sorry, "?" as in "<-- does that answer your question?" 10:50 -!- shinobious [shinobious@gateway/vpn/protonvpn/shinobious] has joined ##taproot-activation 10:50 < jeremyrubin> queip: EPISTEMOLOGY 10:50 < jeremyrubin> signalling is useless and doesn't actually tell us if miners *will* enforce a new rule 10:51 < jeremyrubin> only evidence would be application of those rules in practice, and even then not *proof* 10:51 < Emcy> has anyone though of just asking them 10:51 < luke-jr> false premise that miners decide rules 10:51 < jeremyrubin> to be more certain taproot is in effect would require e.g. mining two blocks with an invalid spend and trying to propagate them on the network 10:51 < queip> can prominent bitcoiners ask them on twitter? 10:52 < jeremyrubin> Signaling is a coordination tool 10:52 < jeremyrubin> It helps people who are trying to reach consensus, reach consensus 10:52 < shinobious> @queip: most mining pools (not actual hardware operators) have already voiced support for activating taproot 10:52 < jeremyrubin> false signalling is an issue with anything 10:52 < shinobious> but ruben's point is that miners could lie, say they will enforce, and not enforce 10:52 < shinobious> rubins* 10:53 < queip> so ST has no consensus-level effects? 10:53 < jeremyrubin> even e.g. a UASF with LOT=true, it could be the case they signal during LOT=true and then don't check taproot rules 10:53 < BlueMatt> queip: like every soft fork, the key is if users enforce the rules or not, whether miners enforce the rules or not isn't really the point, but signaling can allow miners to indicate that they are also enforcing the rules, de-risking the fork process from a network split pov 10:53 < luke-jr> jeremyrubin: no 10:53 < luke-jr> the signal coordinates between users what rules should be active, no matter what miners do 10:53 < midnight> .. also no or few serif touches, an b which is a correctly-spaced inverse of d, a correctly-proportioned O, a proportionally/spacing-animation-friendly .o0, extra-tall but equally-spaced []().. 10:53 * midnight mutters 10:53 < roconnor> queip: ST has consensus-level effects. 10:54 < BlueMatt> shinobious: sure, hopefully its also a statement of upgrade, ultimately. no signaling mechanism can capture if miners actually *have* upgraded, it exists only to de-risk the process some, and in this context it implies miners hopefully stating they are participating in enforcing the rules, helping that de-risk. 10:54 < queip> ok so if after <=3 months we will for sure know if they supported it (both singnal + otherwise invalid block at end), or that they rejected, then are there reasons to not ST first? 10:55 < shinobious> @BlueMatt: yeah I understand, miner signaling is just coordination 10:55 < BlueMatt> shinobious: its more than coordination imo, but, yea, sure. 10:55 < BlueMatt> queip: not really, unless you misread the statements of others as hostility towards your personal views. 10:55 < shinobious> I think the odds of miners falsely signaling over this is so low its not worth consideration personally 10:55 < luke-jr> queip: the MTP variant is spitting on community consensus, and creates all sorts of problems 10:55 < luke-jr> queip: if it was BIP8 ST, it'd be harmless 10:56 < jeremyrubin> the invalid block is unlikely to come queip because of standardness rules 10:56 < BlueMatt> shinobious: I think I agree if you look at it through the lens of "are going to upgrade by the time the fork activates, or intend to", but whether they are upgraded when they signal or not, I dunno - I mean it *is* a different setting entirely for them. 10:56 < jeremyrubin> and it does *matter* what miners do, because if 99% of hashrate doesn't activate we're kinda fucked 10:57 < jeremyrubin> Anyways I don't want to confuse you queip 10:57 < luke-jr> jeremyrubin: no 10:58 < jeremyrubin> the intent of signalling is for miners to use it honestly 10:58 < queip> what's MTP 10:59 < jeremyrubin> a way of measuring wall clock time in bitcoin 10:59 < BlueMatt> right, which is also why signaling is basically only valuable if there isn't some "force" applied to force signaling - miners can trivially lie, but as long as they have no material incentive to do so, its pretty useful, if you're trying to force them into it, it falls apart pretty quick. 10:59 < luke-jr> queip: BIP9 10:59 < queip> ah, Median Time Passed? I would called it Median Block Time but ok 10:59 < luke-jr> BlueMatt: no, it's still useful for user coordination 10:59 < Emcy> everyone warmed up? 10:59 < jeremyrubin> signature under duress 10:59 < BlueMatt> qubenix: its median time of the past even 11 blocks, but, yea :p 10:59 < faketoshi> *cracks fingers* 11:00 < luke-jr> it's just a consensus rule like any other 11:00 < luke-jr> refraining from mining theft "under duress" 11:00 < Emcy> you guys glad i already pregamed you or what 11:00 < shinobious> @BlueMatt: I don't see a distinction there worth disentangling, in either case if enough of the economy enforces something, whether they false signaled or not, miners have an incentive to start enforcing after activation 11:00 < jeremyrubin> Emcy: i thik it's in an hour 11:00 < BlueMatt> luckily I have an actaully useful meeting right now :) 11:00 < luke-jr> yep, 1 more hour before meeting 11:00 < shinobious> whether there is a required signaling or not, I don't see a material difference in the end incentives 11:00 < BlueMatt> shinobious: yea, thats fair, I guess. 11:01 < Emcy> oh yeah its bst 11:01 < shinobious> yeah sorry guys, I would say lets start early, but I don't want to start without anyone planning to come who isn't here 11:01 < jeremyrubin> https://en.wikipedia.org/wiki/Vi_coactus 11:01 < queip> luke-jr: to me height-based sounds better, but is there any critical flaw really in MTP? (I guess actual activations are happening later and based on height offset) 11:01 < BlueMatt> shinobious: maybe, but the forced-signaling suddenly loses a *lot* of value - if you're relying on miners to help de-risk the chance of forks, then miners signaling is a great way to communicate and corrdinate, if you aren't, then forced-signaling or signaling at all isn't really useful 11:01 < jeremyrubin> make your block message include 'VC' if you don't intend to enforce 11:02 < queip> VC? under duress? lol 11:02 < faketoshi> BlueMatt: please don't take part if you think this meeting isn't useful. 11:02 < luke-jr> queip: there is no *benefit* to MTP 11:02 < BlueMatt> faketoshi: oh, I think it *is* useful to point out the significant risks to people reading who aren't over-committed to some reckless approach. 11:03 < luke-jr> queip: and yes, there are flaws, but ones with hacks on top of hacks already proposed 11:03 < shinobious> @BlueMatt: at that point all you are relying on miners to do is coordinate users activating, and then letting the incentives for miners to start enforcing play out 11:03 < luke-jr> BlueMatt: it is the LEAST risky approach 11:03 < luke-jr> without a signal, you end up with divergent consensus rules long-term with no clear objective answer to what they should be 11:04 < jeremyrubin> if matt' 11:04 < jeremyrubin> s going to to be at the meeting I'll probbaly sit out 11:04 < BlueMatt> jeremyrubin: nah, I have actual work to do :p 11:04 < BlueMatt> shinobious: you aren't relying on miners coordinating, though? you're relying on users to coordinate forcing the miners to signal 11:05 < BlueMatt> shinobious: you're ignoring the step 1, and pretending it doesn't exist/is transparent itself 11:05 < jeremyrubin> if matt's not going to be at the meeting i'll probably sit out too 11:05 < BlueMatt> lol 11:05 < roconnor> luke-jr: Without any LOT=false nodes in operation the signal doesn't have to be a 2016 block set of version bits. What else would qualify? 11:05 < BlueMatt> shinobious: recall that forced signaling isnt a single fork - its two. first you do a flag-day soft-fork to force signaling, then you enforce ~whatever. 11:05 < shinobious> @BlueMatt: yes you are, miners still actually have to signal to not be orphaned, you are relying on an intentional action on behalf of miners 11:06 < luke-jr> roconnor: in theory, it would be fine to use 51%, but that adds complexity for no real gain 11:06 < BlueMatt> shinobious: why not just make them not violate the taproot rules? 11:06 < BlueMatt> shinobious: you aren't accomplishing anything 11:06 < luke-jr> BlueMatt: no signal harms user coordination 11:06 < shinobious> @BlueMatt: because that would be a hack requirement of some enforced invalid transaction versus a versionbit 11:06 < roconnor> luke-jr: like would one block having a coinbase message saying "taproot is active" qualify as a signal? for example. 11:07 < luke-jr> roconnor: too easy for miners to abuse? 11:07 < BlueMatt> shinobious: what? its no different from enforcing the version bits rules in a flag-day fork. except materially less disruptive to the ecosystem. 11:07 < BlueMatt> anyway, I've got work to do, this is such a waste of time. 11:07 < shinobious> thanks for the constructive feedback 11:08 < roconnor> luke-jr: Can you describe the distiction you are drawing between that and the 2016 consecutive blocks of version bit signaling? 11:08 < faketoshi> Ok can we kick matt? I'm sick of being told this meeting is a waste of time 11:09 < faketoshi> We get it bro the meeting you won't leave is wasing your time. 11:09 < luke-jr> faketoshi: sounds like he left 11:09 < shinobious> @faketoshi: no need to raise the temperature more than it already is 11:09 < luke-jr> roconnor: maybe another time; right now it would just disrupt things 11:09 < faketoshi> Sorry 11:09 < jeremyrubin> ^this shows about as much as y'all care to actually listen to the community on your UASF attempt 11:09 < faketoshi> I care to listen 11:10 < faketoshi> Let's continue 11:10 < Emcy> faketoshi why are you being like that? because matt is a developer? 11:10 < roconnor> luke-jr: um okay. But I was planning to bring up the type of manditory signaling in this meeting... Let me double check the agenda. 11:10 -!- Alexandre_Chery [9466b537@148.102.181.55] has joined ##taproot-activation 11:10 < shinobious> @Emcy: there are plenty of valid reasons people have issues with others in this space, I just ask that they don't have a part in this meeting 11:11 < shinobious> this is about releasing this proposal, not everyone's personal issues with each other 11:11 < luke-jr> roconnor: as I understand it, we are working with the premise that the activation was already finalised a month ago, and just ratifying the code implementing it 11:11 < queip> we (the users/community/etc) are designing change to one of most important tools in hands of humanity, doing that so fast is imo amazing. if it would be IBM W3C or WEF/FED, would take like 1 years x 1000 man, and anyway arrive at the bad conclusions ;)) 11:11 < Emcy> meeting isnt on yet 11:11 < shinobious> I would still ask for civility before it starts :P 11:11 < shinobious> it will still set the tone for the meeting itself 11:11 < faketoshi> +1 11:11 < Emcy> weve been setting the tone in here for 2 hours before you turned up 11:12 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-iahfijwyjnbwfhbz] has joined ##taproot-activation 11:12 <@michaelfolkson> As I stated earlier, the meeting organizer will issue warnings on trollish behavior or diversions from agenda. On the third warning the individual will be booted 11:12 < luke-jr> roconnor: if we let the perfect be the enemy of the good, we will never activate 11:12 < roconnor> luke-jr: hmm, that does seem to be what the agenda says. What does ratification exactly mean/entail here? And what (approximately) determines whether ratificaiton is successful or not? 11:12 < jeremyrubin> shinobious: I'm curious why the meeting isn't staged in ##uasf and here 11:13 <@michaelfolkson> In this case the meeting organizer has delegated shinobious as the meeting host 11:13 < luke-jr> jeremyrubin: this is taproot activation 11:13 <@michaelfolkson> Anyone is free to organize a meeting on this channel as long as a time slot hasn't already been booked 11:13 < roconnor> luke-jr: I'm asking because it seems that anyone can post any code they want and anyone is free to run any code they want. 11:13 < luke-jr> roconnor: yes, but ideally everyone will run the same rules 11:14 < luke-jr> there will always be dissenters, but success depends on at least a majority enforcing 11:14 < Emcy> just want to say for the record that matt has done more for bitcoin, for longer, than nearly anyone else here has, and for most of that time with no direct recompense 11:15 < Emcy> so if anyone wants to talk about 'respect', it goes both ways 11:16 <@michaelfolkson> Emcy: Agreed, doesn't mean all his views are right though (that goes for everyone) 11:16 < roconnor> luke-jr: So I should think of this ratification as a survey of who will be running this proposed code? 11:17 < luke-jr> roconnor: dunno; maybe also a last call for major objections that might be an issue? 11:17 < roconnor> luke-jr: BTW, can you link to this client? The mailing list doesn't have a link to it. 11:17 < Emcy> of course it doesnt. caling this a waste of time is clearly just his opinion 11:17 < luke-jr> roconnor: https://github.com/BitcoinActivation/bitcoin 11:17 < roconnor> ty 11:17 < luke-jr> spreadsheet overview here: https://docs.google.com/spreadsheets/d/1FJl9TrPsv6jZq6vB1bl2QQoQzezq3ufp27PXbIbUZvE/edit?usp=sharing 11:18 < jeremyrubin> michaelfolkson: w.r.t. your ACK summary, I would state my position as "99% satisified with using ffe33df for the deployment of Taproot (leaving 1% for further testing)" 11:18 < luke-jr> I agree the meeting is a waste of time for Matt. 11:18 <@michaelfolkson> jeremyrubin: You referring to this? https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 11:19 <@michaelfolkson> jeremyrubin: This is just views on block height vs mix of block height and MTP 11:19 -!- hiro58 [4c440db7@bras-base-maplon2305w-grc-47-76-68-13-183.dsl.bell.ca] has joined ##taproot-activation 11:19 <@michaelfolkson> jeremyrubin: Do you have a minor preference or NACK for either? Or entirely neutral? 11:20 < jeremyrubin> pre-registering my concern: the release should be set to be done a period after ST MTP, and the startheight should be picked to match ST's height. 11:20 < jeremyrubin> ^ for the meeting 11:20 < luke-jr> jeremyrubin: off-topic 11:20 < jeremyrubin> for the meeting? 11:20 < jeremyrubin> [4/13/21 11:17] roconnor: dunno; maybe also a last call for major objections that might be an issue? 11:20 < luke-jr> I'm not hosting the meeting, but IMO such "concern" should be outright rejected as legitimate 11:21 < luke-jr> besides, you said you weren't going to be here for it.. 11:21 < jeremyrubin> Ok, so you have a meeting to hear any concerns and then you say my raising a concern is illegitimate 11:21 <@michaelfolkson> I think those concerns should be able to be raised personally luke-jr as long as they don't dominate the meeting 11:21 < luke-jr> serious concerns, not concern trolling 11:21 < jeremyrubin> Pre-registering comments is useful and good 11:21 < shinobious> @jeremyrubin: I am personally open to discussing that during the meeting, but the consensus among everyone releasing the client is that concerns with that type of lock-step parameters compatability with a Core release is not a significant risk 11:22 < jeremyrubin> who is everyone? 11:22 < jeremyrubin> And everyone releasing v.s. everyone running? 11:22 <@michaelfolkson> (As I said though, shinobious decides on who and when people get warnings) 11:22 < luke-jr> if Core is going to violate community trust and release a ST/BIP9 to spit on consensus, then any compatibility issues are their responsibility 11:22 < shinobious> @jeremyrubin: well obviously anyone running makes that decision when they decide whether to run it or not 11:24 < shinobious> but as far as I read: 1) Core releases a ST release, that unless using a different versionbit, activates both Core and BIP8 clients 11:24 < shinobious> 2) Speedy Trial fails to activate, leading to the long period to LOT=true, with the ability for Core to release something else compatible with this BIP8 release 11:25 < shinobious> (or users simply switch to this client) 11:25 < luke-jr> the BIP8 release has already gone out of its way to ensure ST compatibility best it can 11:25 < jeremyrubin> I'm just not sure why the release has to be *before* the ST release 11:26 < shinobious> because the risks of any issues/chainsplit ressulting from these two releases in sync are so low it doesn't merit waiting and the potential of more delays 11:26 < faketoshi> ^ 11:26 < luke-jr> jeremyrubin: 1) there is no basis to assume a ST release will ever happen 2) people who want Taproot *should* upgrade to BIP8, NOT ST 11:27 < faketoshi> Yeah and I'd add to that that I am liking the direction less and less and I don't want to spend more time bikeshedding when we already have a proper activation all ready to go 11:27 < shinobious> @jeremyrubin: I have been very publicly running a node that has hardcoded enforcement of Taproot from the genesis block for over a month now, so have a few others 11:27 < shinobious> no miner has split me off the network with an invalid taproot spend yet 11:28 < roconnor> shinobious: what would you do if a miner did split you off the network? 11:28 < shinobious> 100% honestly, shut down my retard client and boot up Core again, but I see the odds of that as insignificant 11:29 < shinobious> look at one instance of mining incentives we can see empirically demonstrated over years, things like BCH and BSV 11:29 < faketoshi> meanwhile a miner has just shot themselves in the foot 11:29 < roconnor> okay, but then there is no observable difference between you running your custom client and running Bitcoin Core. It is an empty gensture. 11:29 < shinobious> I am personally aware of multiple individual miners with enough hardware to reorg either chain, who think it would be a good idea to do that 11:29 < shinobious> none of have done so, because of the risk to their investment 11:29 < jeremyrubin> shinobious: I don't think that would work BTW 11:29 < jeremyrubin> you'd prolly need to delete or reindex or something 11:30 < luke-jr> it should work 11:30 < shinobious> @jeremyrubin: it did work, and is still working, I synced it from scratch 11:30 < luke-jr> shinobious: not what he's saying 11:30 < jeremyrubin> shinobious: no if you mark a block invalid and then recompile with diff rules 11:30 < jeremyrubin> unclear to me you'd re-validate that block 11:30 < shinobious> aaah 11:30 < luke-jr> or maybe that's only working for LOT=True enforcement 11:31 < luke-jr> not sure how it would react with Taproot violation directly 11:31 < luke-jr> but hey, hopefully nobody actually thinks OPFULLRETARD is a good idea 11:31 < shinobious> @roconnor: my comments on the hardcoded client is just to make the point no relevant actor has done anything disruptive, because it is not in those actors interest 11:31 < Yoghurt11411> roconnor: I suppose that then they would be validated in the concern that miners will act contrary to the interests of users - which, yes, is a gesture first and foremost but not an empty one 11:32 < shinobious> but to your point of difference between running Core or not, you are correct, I am one individual with a custom node who will switch back if there are problems, however that changes when you talk about a release with a coordination mechanism for activating and more people than myself deploying it 11:33 < luke-jr> btw, if anyone is bored… current release notes draft is at https://docs.google.com/document/d/1Uhn1SEDMAqQkzkPZ4B5lPTSjUFEXKPndt_oBI4eUm7A/edit?usp=sharing 11:33 < luke-jr> mostly by shinobious 11:34 < luke-jr> once this gets merged into the repo & the whole thing tagged, gitian builds can begin immediately 11:34 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation 11:41 < Emcy> is meeting on yet or what 11:42 <@michaelfolkson> Emcy: 20 minutes 11:42 < Emcy> shinobious what investment did you mean 11:43 < shinobious> @Emcy: miners capital investments and the revenue from them 11:44 < Emcy> capital investments in what? why would ripping bch or bsv threaten it 11:44 < shinobious> ASICs, electricity, hosting facilities, etc. 11:45 < Emcy> you mean those chains own miners want to reorg it? 11:45 < shinobious> and it would threaten it by diverting hashrate to a non-profitable thing to attack it (and make even less profitable) while also losing the incomme they would make mining BTC 11:45 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation 11:45 < Emcy> they could just mine bitcoin instead 11:45 < Emcy> both those chains only have ideological miners left 11:45 < shinobious> putting the profitability of their overall operation at risk potentially, at the least losing a lot of profit 11:45 -!- zndtoshi [4f701126@79.112.17.38] has joined ##taproot-activation 11:45 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined ##taproot-activation 11:45 -!- mnk [050c0d3b@5-12-13-59.residential.rdsnet.ro] has joined ##taproot-activation 11:45 < shinobious> I'm speaking to BTC miners, who have the hashrate and desire to attack those chains 11:45 -!- satsyandiknowit [40621191@sp-id-f5d0cb6326-124741-1.tingfiber.com] has joined ##taproot-activation 11:46 < shinobious> who have not, specifically because all that accomplishes is losing money, whether it be profit you left on the table, the loss on mining a shitcoin, or in worst case the profitability of your whole mining operation 11:46 -!- gwj [5b848894@91.132.136.148] has joined ##taproot-activation 11:46 < Emcy> so youre saying they want to kill those shitforks but dont want to take the opportunity cost for doing so 11:46 -!- justan_observer [d1fafa29@209.250.250.41] has joined ##taproot-activation 11:46 -!- camarena [2f94a87e@47.148.168.126] has joined ##taproot-activation 11:47 -!- janoz [3ec30937@i9055.upc-i.chello.nl] has joined ##taproot-activation 11:47 < shinobious> all miners diverting their hashrate from BTC to other coins, or disrupt the BTC chain itself, all they accomplish is putting their income at risk 11:47 < shinobious> @Emcy: yes 11:47 -!- hiro58 [4c440db7@bras-base-maplon2305w-grc-47-76-68-13-183.dsl.bell.ca] has quit [Quit: Connection closed] 11:48 < Emcy> bch at least is easy to kill with relatively little hashrate, you just need to release a 11 block reorg on one side of their network on a <1% minority hashrate chain 11:48 -!- Gjejfjcjd [5ee381f6@94-227-129-246.access.telenet.be] has joined ##taproot-activation 11:48 -!- sk18 [6d3c05f4@cpe-109-60-5-244.st3.cable.xnet.hr] has joined ##taproot-activation 11:48 < shinobious> the point is though, none of these disruptive things are done because miners put a lot of capital in up front, they want a return 11:48 < Emcy> it cant even resolve a 11 block reorg automatically, it would be fucked and dead 11:48 < queip> you know what would be funny? reverse merge mining, where BTC can mine itself as part of mining any sha256 shitcoin, and effordlessly gaining like 50,000% more power than current forkcoins and reorging 11:48 -!- looking [63c7a337@d99-199-163-55.bchsia.telus.net] has joined ##taproot-activation 11:48 < shinobious> they don't want to disrupt that return on investment 11:49 -!- ethanF [4940e702@c-73-64-231-2.hsd1.pa.comcast.net] has joined ##taproot-activation 11:49 -!- D [54112b9b@84.17.43.155] has joined ##taproot-activation 11:49 -!- D is now known as Guest47060 11:50 -!- Decentralizedb [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has joined ##taproot-activation 11:50 -!- Trevor [4b9e785d@d75-158-120-93.abhsia.telus.net] has joined ##taproot-activation 11:50 -!- Gjejfjcjd [5ee381f6@94-227-129-246.access.telenet.be] has quit [Client Quit] 11:50 -!- Jackson [45895662@c-69-137-86-98.hsd1.tn.comcast.net] has joined ##taproot-activation 11:50 -!- privateidentity [31c0bbe7@n49-192-187-231.sun4.vic.optusnet.com.au] has joined ##taproot-activation 11:50 -!- Lurker26 [c43d521c@196.61.82.28] has joined ##taproot-activation 11:51 -!- camarena [2f94a87e@47.148.168.126] has quit [Ping timeout: 240 seconds] 11:51 -!- Dario2605 [5cb866e6@pop.92-184-102-230.mobile.abo.orange.fr] has joined ##taproot-activation 11:51 < roconnor> luke-jr: do you have a link to logs for the march 16th meeting? 11:51 < roconnor> or shinobious 11:51 -!- matthewjablack [2d29aab9@ip-45-41-170-185.fibre.fibrestream.ca] has joined ##taproot-activation 11:51 < luke-jr> http://gnusha.org/taproot-activation/2021-03-16.log 11:51 < luke-jr> in topic ;) 11:52 -!- matthewjablack [2d29aab9@ip-45-41-170-185.fibre.fibrestream.ca] has quit [Client Quit] 11:52 < faketoshi> Emcy: you can't 51% attack centralised networks. I hate that anyone gives bch the credebility of taking it that seriously. 11:53 -!- jamesg46 [620a2ce8@cpe-98-10-44-232.rochester.res.rr.com] has joined ##taproot-activation 11:53 < Emcy> i know, i just explained why thats the case elsewhere 11:53 -!- miladm [524c9645@82.76.150.69] has joined ##taproot-activation 11:53 -!- jamesg46 [620a2ce8@cpe-98-10-44-232.rochester.res.rr.com] has quit [Client Quit] 11:53 < Emcy> lol if you think i take that shitcoin seriously 11:53 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has joined ##taproot-activation 11:53 -!- HODLman [41b96fce@cpe-65-185-111-206.cinci.res.rr.com] has joined ##taproot-activation 11:53 -!- blahv [620a2ce8@cpe-98-10-44-232.rochester.res.rr.com] has joined ##taproot-activation 11:54 -!- pepe52 [54698b71@84-105-139-113.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation 11:54 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has quit [Client Quit] 11:54 < faketoshi> Ofc you don't, but thinking it could be attacked the malicious miners is giving it too much credit :P 11:54 -!- IamSNtoo [d466231a@212.102.35.26] has joined ##taproot-activation 11:54 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation 11:54 < Emcy> bch couldnt be permanently destroyed, but it could be disrupted in a very embarrasing way that would have to be manually fixed and that would be lols 11:54 -!- peterrizzo_1 [45ce133d@69.206.19.61] has joined ##taproot-activation 11:54 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has joined ##taproot-activation 11:54 -!- MBTC [3ea3edb2@a237178.upc-a.chello.nl] has quit [Client Quit] 11:54 -!- KevinL [49d6b032@c-73-214-176-50.hsd1.pa.comcast.net] has joined ##taproot-activation 11:55 -!- looking [63c7a337@d99-199-163-55.bchsia.telus.net] has quit [Quit: Connection closed] 11:55 < faketoshi> We'd love to see it ofc. But I mean no one cares. ETC gets 51%'d like monthly and market pays no attention. 11:55 < Emcy> you know about their stupid rolling checkpoint yes? 11:55 -!- mempoolguy [43a76109@c-67-167-97-9.hsd1.il.comcast.net] has joined ##taproot-activation 11:55 < faketoshi> yeah 11:55 -!- adfffdddsaeevv [2f9d7da2@47.157.125.162] has joined ##taproot-activation 11:55 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Client Quit] 11:55 < faketoshi> anyway, lets stop talking about shitcoins 11:55 -!- UltrA1 [689fd929@104-159-217-041.res.spectrum.com] has joined ##taproot-activation 11:56 -!- bitsharp [402bb298@64.43.178.152] has joined ##taproot-activation 11:56 -!- Dario23 [b2c5c1ee@178.197.193.238] has joined ##taproot-activation 11:56 < Emcy> yeah im not gonna be in the meeting, i was just here to hype yall up 11:56 < copumpkin> Emcy the hype man, like Flavor Flav! 11:56 -!- pleb42 [59244eb8@89.36.78.184] has joined ##taproot-activation 11:56 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation 11:57 * copumpkin starts wearing a block time clock around his neck 11:57 < UltrA1> ok whats up luke 11:57 -!- bmr [aef4b233@51.sub-174-244-178.myvzw.com] has joined ##taproot-activation 11:57 -!- pepe52 [54698b71@84-105-139-113.cable.dynamic.v4.ziggo.nl] has quit [Client Quit] 11:58 -!- camarena [2d5b1702@45.91.23.2] has joined ##taproot-activation 11:58 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has joined ##taproot-activation 11:58 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation 11:58 -!- bmr [aef4b233@51.sub-174-244-178.myvzw.com] has quit [Client Quit] 11:58 < pox> hi 11:58 -!- NickKnack [47ca0f80@c-71-202-15-128.hsd1.ca.comcast.net] has joined ##taproot-activation 11:58 -!- Wick [3eb2888b@62.178.136.139] has joined ##taproot-activation 11:58 -!- satsyandiknowit [40621191@sp-id-f5d0cb6326-124741-1.tingfiber.com] has quit [Quit: Connection closed] 11:58 -!- alibaba [563127e3@ip-86-49-39-227.net.upcbroadband.cz] has joined ##taproot-activation 11:59 < luke-jr> hi 11:59 -!- pepe9 [54698b71@84-105-139-113.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation 11:59 -!- Deadlef [3e759d00@62.117.157.0.dyn.user.ono.com] has joined ##taproot-activation 11:59 -!- hiro8 [4c440db7@bras-base-maplon2305w-grc-47-76-68-13-183.dsl.bell.ca] has joined ##taproot-activation 11:59 -!- averagepleb [5d88b209@93-136-178-9.adsl.net.t-com.hr] has joined ##taproot-activation 11:59 -!- umbrel [~umbrel@ip-45-41-170-185.fibre.fibrestream.ca] has joined ##taproot-activation 12:00 < faketoshi> Hi everyone 12:00 <@michaelfolkson> #startmeeting 12:00 <@michaelfolkson> Ok feel free to say hi even if just observing 12:00 < hiro8> hi 12:00 -!- Antoine46 [c80aa6ab@host-200-10-166-171.public.eastlink.ca] has joined ##taproot-activation 12:00 < shinobious> hello 12:00 < UltrA1> hi 12:00 -!- trent11 [18c17796@cpe-24-193-119-150.nyc.res.rr.com] has joined ##taproot-activation 12:00 < Yoghurt11411> hi 12:00 -!- velaiasan [80c7c90c@128.199.201.12] has joined ##taproot-activation 12:00 < averagepleb> hi everyone 12:00 < faketoshi> So we're all in agreement already? 12:00 < Decentralizedb> Hi 12:01 -!- sk18 [6d3c05f4@cpe-109-60-5-244.st3.cable.xnet.hr] has quit [Quit: Connection closed] 12:01 < emzy> hi 12:01 -!- Jakob [d40a7140@d40a7140.rev.stofanet.dk] has joined ##taproot-activation 12:01 <@michaelfolkson> I want to just explain some ground rules for meetings on this channel. Firstly anyone can schedule a meeting, just let me know and you can have a slot if it isn't already taken 12:01 -!- mempoolguy [43a76109@c-67-167-97-9.hsd1.il.comcast.net] has quit [Quit: Connection closed] 12:01 -!- jhhjnji [566a8f6c@86.106.143.108] has joined ##taproot-activation 12:01 -!- Jakob [d40a7140@d40a7140.rev.stofanet.dk] has quit [Client Quit] 12:01 -!- suntsu8 [d5c8ec17@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-activation 12:01 < zndtoshi> Hello! 12:02 -!- Rabbit100 [b9d975d5@185.217.117.213] has joined ##taproot-activation 12:02 <@michaelfolkson> To ensure discussion stays on topic the meeting organizer will be able to issue warnings to participants. On the third warning participants can be booted from the channel 12:02 < bitsharp> Hello! 12:02 -!- evankaloudis [424432b7@cpe-66-68-50-183.austin.res.rr.com] has joined ##taproot-activation 12:02 -!- malicious [d537f157@213.55.241.87] has joined ##taproot-activation 12:02 -!- blap [~gk@217.138.252.235] has joined ##taproot-activation 12:02 -!- GeraldineG [51886641@host81-136-102-65.range81-136.btcentralplus.com] has joined ##taproot-activation 12:02 -!- jhhjnji [566a8f6c@86.106.143.108] has quit [Client Quit] 12:02 -!- hickler [2e722383@dynamic-046-114-035-131.46.114.pool.telefonica.de] has joined ##taproot-activation 12:02 -!- HODLman [41b96fce@cpe-65-185-111-206.cinci.res.rr.com] has quit [Quit: Connection closed] 12:02 -!- hickler [2e722383@dynamic-046-114-035-131.46.114.pool.telefonica.de] has quit [Client Quit] 12:02 <@michaelfolkson> Today the organizer was faketoshi and he has delegated to shinobious. So shinobious will issue warnings (if needed, hopefully they won't be needed) 12:02 -!- grubles_ [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 12:02 -!- Tushar [46708bf5@cpe-70-112-139-245.austin.res.rr.com] has joined ##taproot-activation 12:02 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined ##taproot-activation 12:03 <@michaelfolkson> I'll handover to shinobious. Feel free to post links to agenda and relevant resources 12:03 -!- lukerob [4cb96f8d@cpe-76-185-111-141.tx.res.rr.com] has joined ##taproot-activation 12:03 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 12:03 < luke-jr> BitcoinTaproot.org is apparently down, so I've mirrored the draft page here for now: https://luke.dashjr.org/programs/bitcoin/files/BitcoinTaproot.org/taproot.html#details 12:03 < luke-jr> has the activation details 12:03 <@michaelfolkson> Agenda for meeting: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018769.html 12:03 -!- bitsharp [402bb298@64.43.178.152] has quit [Quit: Connection closed] 12:04 -!- pepe9 [54698b71@84-105-139-113.cable.dynamic.v4.ziggo.nl] has quit [Ping timeout: 240 seconds] 12:04 <@michaelfolkson> Draft release notes: https://docs.google.com/document/d/1Uhn1SEDMAqQkzkPZ4B5lPTSjUFEXKPndt_oBI4eUm7A/edit 12:04 < queip> hi 12:04 -!- Wick [3eb2888b@62.178.136.139] has quit [Quit: Connection closed] 12:04 -!- shib [499da07f@c-73-157-160-127.hsd1.or.comcast.net] has joined ##taproot-activation 12:04 -!- taprooooooot_wen [b9d59af1@185.213.154.241] has joined ##taproot-activation 12:04 -!- Anon-11123 [56343899@56343899.rev.stofanet.dk] has joined ##taproot-activation 12:04 <@michaelfolkson> Today's meeting will be on an alternative release to Core with Taproot activation code 12:05 -!- steepdawn974 [3e71c258@62.113.194.88] has joined ##taproot-activation 12:05 < shinobious> So pretty much the topic of discussion today is plans to release a BIP 8 LOT=true client to activate Taproot. The intent is to use signal bit 2 with a start height of 681408 (2021 Apr 29) with a lockin threshold of 90%. There is a minimum activation height of 709632 (2021 Nov 11), with a timeout height of 760032 (2022 Oct 27). 12:05 < luke-jr> rather, a release of Core w/ Taproot activation 12:05 -!- bitsharp [402bb298@64.43.178.152] has joined ##taproot-activation 12:05 -!- satsyandiknowit [40621191@sp-id-f5d0cb6326-124741-1.tingfiber.com] has joined ##taproot-activation 12:05 < shinobious> Best effort has been made to make this compatible with a Speedy Trial release during the ST signaling window 12:05 -!- Dario23 [b2c5c1ee@178.197.193.238] has quit [Ping timeout: 240 seconds] 12:05 -!- mempoolguy [43a76109@c-67-167-97-9.hsd1.il.comcast.net] has joined ##taproot-activation 12:05 < roconnor> luke-jr: what do you mean? 12:05 -!- CmdrPenetrant [62bfc08f@wsip-98-191-192-143.ok.ok.cox.net] has joined ##taproot-activation 12:06 -!- satsyandiknowit [40621191@sp-id-f5d0cb6326-124741-1.tingfiber.com] has quit [Client Quit] 12:06 -!- umbrel is now known as matthewjablack 12:06 -!- CmdrPenetrant [62bfc08f@wsip-98-191-192-143.ok.ok.cox.net] has quit [Client Quit] 12:06 < luke-jr> roconnor: it is Core, just with Taproot activation added 12:06 -!- Wick [3eb2888b@62.178.136.139] has joined ##taproot-activation 12:06 < roconnor> But it isn't Bitcoin Core right? 12:06 <@michaelfolkson> shinobious: So parameters haven't been finalized for Core. If they are finalized for Core say tomorrow, next week, next month will this particular release change? 12:06 < luke-jr> sure it is 12:06 < achow101> The currently proposed st release is expected to have the first signaling period be one after the height proposed here 12:07 -!- KevinL [49d6b032@c-73-214-176-50.hsd1.pa.comcast.net] has quit [Quit: Connection closed] 12:07 -!- Jackson [45895662@c-69-137-86-98.hsd1.tn.comcast.net] has quit [Ping timeout: 240 seconds] 12:07 -!- nskfih [566a797a@86.106.121.122] has joined ##taproot-activation 12:07 < roconnor> achow101: are there ST activation parameters PRd? 12:07 <@michaelfolkson> shinobious: Or is the plan for Core to follow these parameters? 12:07 < shinobious> michaelfolkson: I see no reason to have to alter the parameters for this release unless ST decides to use a different signal bit, or a release was somehow rushed with a full signaling period before the release of this client 12:07 < achow101> They're on the mailing list, no pr yet iirc 12:08 -!- blahv [620a2ce8@cpe-98-10-44-232.rochester.res.rr.com] has quit [Quit: Connection closed] 12:08 < shinobious> short those two cases, during the entire ST period both clients would activate in sync, and if ST fails to activate, there is a long enough window between timeout with LOT=true for Core to consider a compatible release 12:08 <@michaelfolkson> shinobious: So will this release use a mixture of block height and MTP for the ST? 12:08 -!- UltrA1 [689fd929@104-159-217-041.res.spectrum.com] has quit [Quit: Connection closed] 12:08 -!- CriptoLuis [ba46d2d5@186.70.210.213] has joined ##taproot-activation 12:08 -!- Alexandre_Chery [9466b537@148.102.181.55] has quit [Ping timeout: 240 seconds] 12:08 < roconnor> shinobious: you said there was a best effort to be compatible with ST, but wouldn't a better effort be to match the expected start height? 12:08 < luke-jr> michaelfolkson: any release of MTP/ST would be malicious in nature 12:09 -!- camarena [2d5b1702@45.91.23.2] has quit [Ping timeout: 240 seconds] 12:09 < shinobious> no, it is purely blockheight @michaelfolkson 12:09 <@michaelfolkson> luke-jr: So this is ST with block height followed by BIP 8 (LOT=true) right? 12:09 -!- poephol [3ec23d0b@h61011.upc-h.chello.nl] has joined ##taproot-activation 12:09 -!- mnk [050c0d3b@5-12-13-59.residential.rdsnet.ro] has quit [Quit: Connection closed] 12:09 -!- benthecarman78 [6b8a186e@107-138-24-110.lightspeed.austtx.sbcglobal.net] has joined ##taproot-activation 12:09 < queip> might I ask why depending on MTP is "malicious in nature" (if that's what you meant)? is it really so bad, why? 12:09 -!- jaenu [1f1809b6@182.9.24.31.ftth.as8758.net] has joined ##taproot-activation 12:09 < luke-jr> michaelfolkson: you could say that; technically, ST is just part of the overall activation 12:09 < shinobious> @roconnor: unless a ST release was done right now with a full signal period to potentially lock in prior to the release of a BIP8 client, I don't see what the potential issue would be without miners running the BIP 8 client or signaling without running ST 12:09 < jonatack> hi 12:10 -!- OtahMachi [ced9cd16@206.217.205.22] has joined ##taproot-activation 12:10 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has quit [Quit: Connection closed] 12:10 -!- Velocibeaver [43dfc867@67.223.200.103] has joined ##taproot-activation 12:10 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has joined ##taproot-activation 12:10 < luke-jr> queip: ST/BIP8 is strictly better; the only purpose of ST/MTP is to spit on community consensus 12:10 < CriptoLuis> So if ST succeeds we will point to another activation date for 2022 via BIP 8? 12:10 < queip> I still do not understand 12:10 < roconnor> shinobious: I guess I don't understand what you mean by "best effort" then. Maybe it is just a misunderstanding of phrasing between us. 12:10 -!- mal68 [b2c5e639@178.197.230.57] has joined ##taproot-activation 12:10 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has joined ##taproot-activation 12:11 <@michaelfolkson> luke-jr: I guess my point is that Core *could* release ST with block height and these parameters and it would be entirely compatible (the ST part anyway) 12:11 < luke-jr> queip: additionally, ST/MTP has less community support than BIP8(LOT=True), so if anything were merged in good faith, it would logically be the latter 12:11 -!- Alexandre_Chery [94668a79@148.102.138.121] has joined ##taproot-activation 12:11 < roconnor> queip: luke-jr is misrepresenting ST/MTP. 12:11 < luke-jr> michaelfolkson: sure 12:11 -!- IamSNtoo [d466231a@212.102.35.26] has quit [Quit: Connection closed] 12:11 < luke-jr> roconnor: no, I am not 12:11 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has joined ##taproot-activation 12:11 <@michaelfolkson> luke-jr: I'm not saying they will or not, I don't know 12:11 < shinobious> @roconnor: let me rephrase then, I do not see how the two different activation conditions could cause a disruptive conflict inevitably causing a chainsplit short those two situations 12:11 -!- ijac [31cfdf80@49.207.223.128] has joined ##taproot-activation 12:11 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has quit [Client Quit] 12:11 -!- sk92 [6d3c05f4@cpe-109-60-5-244.st3.cable.xnet.hr] has joined ##taproot-activation 12:11 < luke-jr> in any case, we're way off-topic IMO 12:12 -!- bitsharp2 [402bb298@64.43.178.152] has joined ##taproot-activation 12:12 < shinobious> 1) a full signal period locking in before release of this client, or 2) intentionally using a different signal bit 12:12 < luke-jr> this is about the Bitcoin Core w/ Taproot release, not ST nonsense 12:12 < queip> if question of MTP is offtopic then sure, we can other day 12:12 -!- malicious83 [d537f157@213.55.241.87] has joined ##taproot-activation 12:12 <@michaelfolkson> Anyone can organize a meeting queip, feel free to DM me if you want to 12:12 < shinobious> @luke-jr: can we try and just concentrate on pure compatibility issues for now? 12:12 -!- poephol [3ec23d0b@h61011.upc-h.chello.nl] has quit [Client Quit] 12:13 < shinobious> assuming a release of ST and BIP 8 LOT=true in tandem 12:13 < roconnor> luke-jr: I think it is deciptive marketing to call this Bitcoin Core. 12:13 -!- TAPROOTME [c879843b@200.121.132.59] has joined ##taproot-activation 12:13 -!- ijac [31cfdf80@49.207.223.128] has quit [Client Quit] 12:13 -!- Wick [3eb2888b@62.178.136.139] has quit [Quit: Connection closed] 12:13 < luke-jr> shinobious: they're compatible unless the hypothetical ST intnetionally breaks things. I don't see any reason to go into it further. 12:13 -!- stanstandard [~stanstand@ip68-104-2-250.lv.lv.cox.net] has joined ##taproot-activation 12:13 < luke-jr> roconnor: I don't. 12:13 -!- mempoolguy [43a76109@c-67-167-97-9.hsd1.il.comcast.net] has quit [Quit: Connection closed] 12:13 < shinobious> I just want to give a chance for people to voice concerns to that, and also better understand our reasoning there if they don't already 12:14 -!- mrchaddavis [621f28ab@cpe-98-31-40-171.columbus.res.rr.com] has joined ##taproot-activation 12:14 < Emcy> i have a request. could you please no call your forked client 'bitcoin core'. please 12:14 -!- Ehud [674ad3ed@103.74.211.237] has joined ##taproot-activation 12:14 -!- TAPROOTME [c879843b@200.121.132.59] has quit [Client Quit] 12:14 < achow101> shinobious: there could be a split if the threshold is reached in the uasf client in the first signaling period at that period is not a signaling period for st 12:14 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has joined ##taproot-activation 12:15 -!- nskfih [566a797a@86.106.121.122] has quit [Quit: Connection closed] 12:15 < mol_> roconnor, +1 12:15 -!- malicious [d537f157@213.55.241.87] has quit [Ping timeout: 240 seconds] 12:15 -!- UltrA1 [689fd929@104-159-217-041.res.spectrum.com] has joined ##taproot-activation 12:15 < shinobious> @roconnor: @Emcy for what its worth, I would not want to release anything under the label of Core 12:15 < luke-jr> achow101: so don't do that 12:15 < achow101> And if there is no signaling in further period 12:15 <@michaelfolkson> Emcy: Perhaps "Taproot activation" (and no mention of Core) 12:15 -!- NickKnack [47ca0f80@c-71-202-15-128.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 12:15 -!- GeraldineG [51886641@host81-136-102-65.range81-136.btcentralplus.com] has quit [Quit: Connection closed] 12:15 < Emcy> if you have your fork of the codebase with your own parameters, thats fine, but i dont think anyone really needs any naming confusion 12:15 < shinobious> @achow101: that would assume significant amounts of hashrate are running this client, or signaling for it 12:15 < luke-jr> Emcy: it is Bitcoin Core though. 12:15 < Yoghurt11411> I agree with roconnor, there is no reason to market a community fork as being related to Core - at least part of the point is to keep this effort at a friendly distance from Core 12:15 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has joined ##taproot-activation 12:15 -!- jesseposner [~jesseposn@2601:645:200:162f:1115:7fb7:49ec:d59b] has joined ##taproot-activation 12:15 -!- bitsharp [402bb298@64.43.178.152] has quit [Ping timeout: 240 seconds] 12:15 -!- janoz [3ec30937@i9055.upc-i.chello.nl] has quit [Ping timeout: 240 seconds] 12:15 -!- justan_observer [d1fafa29@209.250.250.41] has quit [Ping timeout: 240 seconds] 12:15 < shinobious> in which case maybe people should strive to be compatible with this? 12:15 -!- irmtn [566a797a@86.106.121.122] has joined ##taproot-activation 12:15 < Emcy> michaelfolkson i would be ok with that 12:15 < queip> shinobious: are you feeling like summarizing the big picture, what nodes will do what in what case? we have "your" code that will.. wait around 8 months and then hardly reject as invalid blocks that are not supporting taproot? and we have bitcoin core's vanilla client that will for now try for around X+3months to get miners signalling and if yes then it will lock in and also will start from that point rejecting blocks that would break 12:15 -!- GeraldineG [51886641@host81-136-102-65.range81-136.btcentralplus.com] has joined ##taproot-activation 12:15 < queip> taproot rules? 12:16 < achow101> shinobious: yes, and I think that scenario is unlikely, just letting you know it is possible 12:16 -!- nos [9a032c3e@154.3.44.62] has joined ##taproot-activation 12:16 < luke-jr> queip: vanilla Bitcoin Core has no activation at all 12:16 < shinobious> I think if we reach that point achow101 then this deployment was more successful than Core 12:16 -!- jason [444d9c25@68-77-156-37.lightspeed.rcsntx.sbcglobal.net] has joined ##taproot-activation 12:17 < queip> luke-jr: I thought it was just said that Bitcoin Core is planning to soonish merge the speed trials? 12:17 <@michaelfolkson> quiep: We don't know what Core will release for certain. The PR that looks most likely to be merged in Core at this point is #21377. Activation params would follow merging that 12:17 -!- jason is now known as Guest84501 12:17 < Emcy> luke-jr bitcoin core is the name of a client built from a specific repository, the one under the 'bitcoin' organisation on github. i would reiterate that no one needs or benefits from naming confusion 12:17 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has joined ##taproot-activation 12:17 < luke-jr> queip: if such a thing were to happen, it would be malicious 12:17 < faketoshi> there is no way there will be a separate core release that is incompatible. it would be NACKed to death. 12:17 < roconnor> shinobious: furthermore if you delay the start date to the exected ST activation height, then you eliminate that unlikely scenario entirely and 0 cost. Taproot still gets activated on the same schedule. 12:17 -!- zoglogdog [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has joined ##taproot-activation 12:17 < shinobious> @queip: the timeout will not be until October 2022 12:17 < luke-jr> queip: let's assume good faith that it won't 12:17 -!- Guest84501 [444d9c25@68-77-156-37.lightspeed.rcsntx.sbcglobal.net] has quit [Client Quit] 12:17 < luke-jr> Emcy: there is no confusion 12:18 < luke-jr> Emcy: Bitcoin Core w/ Taproot has taproot. Bitcoin Core w/o Taproot doe snot 12:18 -!- jimmysong [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has joined ##taproot-activation 12:18 < Emcy> yes there is luke. please dont be obtuse here. 12:18 < queip> luke-jr: bitcoin core rolling out client that might allow to "extra fast" (~3month) activate taproot, and also does NOT mean we give up even if miners say NO, is malicious? in what way? seems a step towards easily achieving TapRoot without giving up on other ways, no? 12:18 < Emcy> just call it bitcoin + taproot or something 12:19 <@michaelfolkson> queip: So Core may release ST (block height and MTP) on its own. This alternative to Core would release ST (block height) followed by BIP 8(LOT=true) 12:19 -!- btcomnivore [bc952833@c188-149-40-51.bredband.comhem.se] has quit [Client Quit] 12:19 < luke-jr> Emcy: call it what you want, but it's still Bitcoin Core. 12:19 < zndtoshi> luke-jr what is the Github repository that will release this "Bitcoin Core with Taproot"? 12:19 -!- Decentralizedb58 [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has joined ##taproot-activation 12:19 < luke-jr> zndtoshi: immediately, https://github.com/BitcoinActivation/bitcoin - eventually, hopeuflly also bitcoin/bitcoin 12:19 -!- Deadlef20 [3e759d00@62.117.157.0.dyn.user.ono.com] has joined ##taproot-activation 12:19 <@michaelfolkson> queip: I guess it is possible Core could still release ST (block height) but the PR doesn't have that currently 12:19 < queip> previous thing was rightly called like bip148, not "bitcoin core" [but mine]... that was imo good 12:20 < luke-jr> queip: it was called Bitcoin Core UASF 12:20 < pox> luke-jr it's confusing if it's a client built from the core repo not from the master branch and not signed by the same keys, and not downloaded from the same website. 12:20 < Emcy> luke-jr this is the same arguments that say, the bitcoin classic people made, and we [and you] railed against it then 12:20 < shinobious> @roconnor: assuming miners run ST, then no signaling will occur until the ST start window, assuming miners run BIP 8, then in all likelihood the BIP 8 client is the dominant client activating Taproot 12:20 < luke-jr> queip: and completely different in nature 12:20 < Emcy> the reasons why havent changed. please just dont call it 'core' 12:20 < queip> luke-jr: why not call this one bitcoin core UASF-taproot? 12:20 < shinobious> @roconnor: that issue could just as easily be solved by some small % of miners withholding signaling until the ST period starts 12:20 < luke-jr> Emcy: Classic was something different 12:20 < shinobious> can we table the release name for now? 12:20 < luke-jr> queip: it's not a UASF 12:20 -!- mrchaddavis [621f28ab@cpe-98-31-40-171.columbus.res.rr.com] has quit [Quit: Connection closed] 12:21 < luke-jr> shinobious: +1 12:21 -!- mal68 [b2c5e639@178.197.230.57] has quit [Ping timeout: 240 seconds] 12:21 < Emcy> it was a code fork with different parameters 12:21 < faketoshi> I think Luke's argument is that it's core because the community clearly want this activation method and not all the bikeshedding weirdness. That said it seems unimportant. I can happily have it called something else. 12:21 -!- danilo100 [b3da0337@179.218.3.55] has joined ##taproot-activation 12:21 -!- Majes [c0a1e550@192-161-229-192-161-229-80.cpe.sparklight.net] has joined ##taproot-activation 12:21 < luke-jr> faketoshi: that would be a mistake IMO 12:21 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has quit [Ping timeout: 240 seconds] 12:21 < Emcy> i would jsut implore, please, weve all sifference enough naming/brand confusion over the years, lets not crete the possibility for even more 12:21 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has joined ##taproot-activation 12:21 < luke-jr> anyway, shinobious says move on 12:22 -!- nos [9a032c3e@154.3.44.62] has quit [Ping timeout: 240 seconds] 12:22 < mol_> luke-jr, faketoshi is right, give it a different name, if you keep confusing the community you're defeating yourself 12:22 < shinobious> and @queip one moment and I'll type out a high view summary of compatibility issues/concerns from my POV 12:22 -!- shib [499da07f@c-73-157-160-127.hsd1.or.comcast.net] has quit [Quit: Connection closed] 12:22 <@michaelfolkson> I think we can move on from naming but I agree it shouldn't be called Core. Core+Taproot is still problematic. I prefer Taproot activation 12:22 -!- Tushar [46708bf5@cpe-70-112-139-245.austin.res.rr.com] has quit [Quit: Connection closed] 12:22 -!- nos [9a032c3e@154.3.44.62] has joined ##taproot-activation 12:22 < emzy> faketoshi: I don't see the the community clearly wants this activation method. 12:22 -!- i61 [ad31381f@pool-173-49-56-31.phlapa.fios.verizon.net] has joined ##taproot-activation 12:22 -!- Deadlef [3e759d00@62.117.157.0.dyn.user.ono.com] has quit [Ping timeout: 240 seconds] 12:22 -!- Tushar [46708bf5@cpe-70-112-139-245.austin.res.rr.com] has joined ##taproot-activation 12:22 < OtahMachi> just call it Taproot, at this point anyone running any of this knows what Taproot is 12:22 < mol_> "BitcoinMechanics" is a good name 12:22 < queip> (I propose to give it few days to cool down and hold simple 1-issue meeting on the name itself then) 12:22 -!- nos [9a032c3e@154.3.44.62] has quit [Client Quit] 12:22 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has quit [Quit: Connection closed] 12:23 -!- Decentralizedb [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has quit [Ping timeout: 240 seconds] 12:23 -!- Lurker26 [c43d521c@196.61.82.28] has quit [Quit: Connection closed] 12:23 < faketoshi> mol_: lol? 12:23 < mol_> emzy, shhhh :D 12:23 < mol_> faketoshi, :D 12:23 <@michaelfolkson> queip: Let me know if you do, we can book a time 12:23 < CriptoLuis> Call it Taproot, time to stop messing around with Bitcoin name 12:23 < shinobious> so, we have the release of this BIP8 LOT=true client, and the potential ST release from Core. as long as both releases utilize signal bit 2 for activation and have overlapping signaling periods during the ST period, miners running either client should activate both 12:23 < roconnor> shinobious: But why not just move the date and completely eliminate the issue? 12:23 < mol_> queip, there will be another taproot activation next Tuesday I think 12:24 < Majes> Taproot already kn own by those who want to know.... 12:24 < shinobious> (will address in one second @roconnor) 12:24 -!- i61 [ad31381f@pool-173-49-56-31.phlapa.fios.verizon.net] has quit [Client Quit] 12:24 < UltrA1> core stays core, real btc we all know it and are watching..+ taproot will confused many 12:24 -!- sam10 [dfbd246e@223.189.36.110] has joined ##taproot-activation 12:24 <@michaelfolkson> mol_: That meeting next week is hosted by Jeremy Rubin, I don't think he'll want to discuss this particular release in that meeting 12:24 <@michaelfolkson> mol_: Maybe he will, I don't know 12:25 -!- sam10 [dfbd246e@223.189.36.110] has quit [Client Quit] 12:25 -!- danilo100 [b3da0337@179.218.3.55] has quit [Client Quit] 12:25 < shinobious> so @queip during that ST trial period, as long as same version bit is in use with overlapping signal periods, miners running either client activates Taproot, if ST fails to activate, then without miners running the BIP8 client signaling stops, and neither client activates Taproot 12:25 -!- Dario2605 [5cb866e6@pop.92-184-102-230.mobile.abo.orange.fr] has quit [Quit: Connection closed] 12:25 < shinobious> but the BIP8 client will lockin and activate Taproot in October 2022, which should be a long enough window for a second Core release to activate that can be compatible with the BIP8 client 12:25 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has joined ##taproot-activation 12:26 < shinobious> @roconnor: personally, because I don't see any issues as long as ST doesn't begin before this client, without a massive amount of miners immediately running the BIP8 client 12:26 < roconnor> shinobious: I get that, but isn't moving the start date easy with 0 effect on the start date of taproot? 12:27 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has joined ##taproot-activation 12:27 -!- Guest47060 [54112b9b@84.17.43.155] has quit [Quit: Connection closed] 12:27 < shinobious> @roconnor: I feel like this opens the door to further delays or disagreements in Core de facto stalling the release of this client 12:27 < faketoshi> exactly 12:28 < faketoshi> it is compatible with what already exists 12:28 < shinobious> and the whole point of this client's release is to lockin this upgrade and be done with it, regardless of Core's decisions or actions 12:28 -!- D [54112b9b@84.17.43.155] has joined ##taproot-activation 12:28 < faketoshi> though i guess a modification to what achow101 mentioned could be done? 12:28 -!- andimacten [5a92d0a2@cpe90-146-208-162.liwest.at] has quit [Client Quit] 12:28 -!- steepdawn974 [3e71c258@62.113.194.88] has quit [Quit: Connection closed] 12:28 -!- D is now known as Guest20521 12:29 < roconnor> shinobious: That strikes me as a poor justification. Just because it move it now, doesn't imply you need to move it again. 12:29 -!- Deadlef20 [3e759d00@62.117.157.0.dyn.user.ono.com] has quit [Quit: Connection closed] 12:29 < roconnor> you can move the date, release a client, and then you are locked in. 12:29 -!- Ehud [674ad3ed@103.74.211.237] has quit [Ping timeout: 240 seconds] 12:29 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has joined ##taproot-activation 12:29 < Yoghurt11411> (some context on the branding topic: https://github.com/UASF/bitcoin/releases it appears that indeed the 2017 UASF was branded as Core. I hold this isn't necessary or desirable, but also seems not to be all too outrageous) 12:29 < GeraldineG> @roconnor what do you feel are the benefits of moving it now? 12:30 < roconnor> GeraldineG: completely eliminates the unlikely scenario described by achow101 above at essentially 0 cost. 12:30 < luke-jr> roconnor: current startheight is 2 weeks away 12:30 -!- benthecarman78 [6b8a186e@107-138-24-110.lightspeed.austtx.sbcglobal.net] has quit [Quit: Connection closed] 12:30 < luke-jr> roconnor: beign too early is much less bad than being too late 12:30 -!- irmtn [566a797a@86.106.121.122] has quit [Quit: Connection closed] 12:31 < luke-jr> roconnor: consider if there was a sane ST release, with the Apr 30 date, after we move +2 weeks… 12:31 <@michaelfolkson> Some draft release notes are here https://docs.google.com/document/d/1Uhn1SEDMAqQkzkPZ4B5lPTSjUFEXKPndt_oBI4eUm7A/edit 12:31 < shinobious> @roconnor: at that point though, it is clear a majority of miners are running the BIP 8 client 12:31 -!- pleb42 [59244eb8@89.36.78.184] has quit [Quit: Connection closed] 12:31 < shinobious> would it not follow so is a significant portion of the economy? 12:31 < gwj> ccccccngegijebclkdjenthurjrtguehujjjfifjfjnb 12:32 -!- jules73 [a027a24c@dyn-160-39-162-76.dyn.columbia.edu] has joined ##taproot-activation 12:32 < luke-jr> shinobious: the economy doesn't reall ymatter until Nov 12:32 -!- kgdub69 [566a797a@86.106.121.122] has joined ##taproot-activation 12:32 < roconnor> shinobious: To be honest miners just configure the bits in thier stratum thingy; the bits don't really tell you what clients they are running. 12:32 < luke-jr> and by then, the majority need to be upgraded either way 12:32 < shinobious> well his concern seems to be the UASF activating by miners before ST is even released 12:32 < shinobious> which would imply to me miners are custom bit signaling or running BIP 8 12:32 < luke-jr> shinobious: we still have the min activation height 12:32 -!- blap [~gk@217.138.252.235] has quit [Quit: Leaving] 12:32 < luke-jr> nothign activates until Nov 12:33 < shinobious> but if it locks in, and then stops signaling before ST is online to receive the signal 12:33 < roconnor> shinobious: my understanding is that in practice miners always run custom bit signaling. 12:33 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation 12:33 < luke-jr> if someone wants to say a period of 90% isn't active, they can fork off to block Taproot 12:33 -!- entropy5000 [4db58416@x4db58416.dyn.telefonica.de] has joined ##taproot-activation 12:33 < shinobious> @roconnor: good to know 12:33 < roconnor> though I could be minstaken. 12:33 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has quit [Quit: Connection closed] 12:33 < shinobious> well, then regardless of running, custom signaling, etc. 12:33 -!- OtahMachi [ced9cd16@206.217.205.22] has quit [Quit: Connection closed] 12:33 < shinobious> roconner's concern seems to be miners acting in a way that locks in BIP 8 client, but not he ST client 12:33 < roconnor> So I think you conclusion that the majority of miners would be running the BIP 8 client isn't correct. 12:34 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 252 seconds] 12:34 < shinobious> that fair enough of a boiling down? 12:34 -!- tra [c4f597d3@196.245.151.211] has joined ##taproot-activation 12:34 -!- evankaloudis [424432b7@cpe-66-68-50-183.austin.res.rr.com] has quit [Quit: Connection closed] 12:34 -!- averagepleb [5d88b209@93-136-178-9.adsl.net.t-com.hr] has quit [Quit: Connection closed] 12:34 < luke-jr> then people will abandon the ST client by November 12:34 < luke-jr> it's not like they don't have time to observe the situation and react 12:34 < roconnor> Right that is the concern. And I totally aknowledge the unlikeliness of this; However removing the issue entirely seems so easy. 12:35 -!- blap [~gk@217.138.252.235] has joined ##taproot-activation 12:35 < luke-jr> roconnor: it removes an unlikely scenario, and creates a much worse and more likely scenario 12:35 -!- solairis [bbbebae2@fixed-187-190-186-226.totalplay.net] has joined ##taproot-activation 12:35 -!- alibaba [563127e3@ip-86-49-39-227.net.upcbroadband.cz] has quit [Quit: Connection closed] 12:35 < queip> will your LOT=y client also signal by node's UserAgend? while sybill and everything, still it might be useful I guess 12:35 < luke-jr> queip: yes, that got merged 12:35 < CriptoLuis> So there will be two different clients running at the same time? 12:36 -!- gwj [5b848894@91.132.136.148] has quit [Ping timeout: 240 seconds] 12:36 < luke-jr> CriptoLuis: ideally not, but it's unlikely *everyone* will upgrade immediately 12:36 -!- camarena [2d5b1702@45.91.23.2] has joined ##taproot-activation 12:36 -!- Velocibeaver [43dfc867@67.223.200.103] has quit [Quit: Connection closed] 12:36 < luke-jr> CriptoLuis: this is the norm for any softfork 12:36 < faketoshi> we aren't trying to HF :P 12:36 < shinobious> @CriptoLuis: I forsee a high chance of both clients being run if Core releases ST timely 12:36 -!- Velocibeaver [43dfc867@67.223.200.103] has joined ##taproot-activation 12:36 < luke-jr> shinobious: it already chose not to 12:36 -!- hujgghj [6bb5bd37@107.181.189.55] has joined ##taproot-activation 12:36 < faketoshi> not to mention older clients running neither 12:37 -!- hodl_it [43b9f76d@c-67-185-247-109.hsd1.wa.comcast.net] has joined ##taproot-activation 12:37 < shinobious> but I do not believe at all anything would intentionally done to make any less compatible with the BIP 8 release than exists right now just because of the interactions 12:37 <@michaelfolkson> shinobious: I know Luke says it would be malicious but I think it is possible Core release ST (with mix of block height after MTP) after this is released 12:37 < shinobious> would be * 12:37 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has joined ##taproot-activation 12:37 < luke-jr> anyway, as I see it, the code is done; either we release it, don't release it, or shedpaint another 2 weeks 12:37 < luke-jr> does anyone see any problem with just releasing it? :P 12:37 < roconnor> I do. 12:37 < jaenu> nope. Just release it. 12:38 < shinobious> @michaelfolkson: as do I, but I don't see any new compatibility risks or issues due to that 12:38 < UltrA1> this should be a public vote for the world honestly but whatever 12:38 < luke-jr> roconnor: just the unlikely hypothesis of 2 weeks difference? 12:38 < roconnor> I did have another concern, but I didn't want to intrupt the current start date discussion. 12:38 < shinobious> unless I'm missing some real niche interaction, we've accounted for them all, and they are all incredibly unlikely to occur 12:38 < luke-jr> (and that only if some Core devs act maliciously) 12:38 -!- tra [c4f597d3@196.245.151.211] has quit [Client Quit] 12:38 < shinobious> @roconnor: DM it to me and we can move into that when this is settled? 12:39 -!- jules73 [a027a24c@dyn-160-39-162-76.dyn.columbia.edu] has quit [Quit: Connection closed] 12:39 -!- epson121 [d5953e5f@cm-2094.cable.globalnet.hr] has joined ##taproot-activation 12:39 < luke-jr> roconnor: do you understand my main point? too early = no big deal; too late = big deal, and more likely 12:39 -!- Tap2021 [63ff9090@cpe589630a45781-cm589630a4577f.cpe.net.cable.rogers.com] has joined ##taproot-activation 12:39 <@michaelfolkson> I do think attempting to finalize parameters before Core has some merit. But I would like this release to get more review ideally (or be marked as experimental) 12:39 -!- duringo [68c891e4@104.200.145.228] has joined ##taproot-activation 12:40 -!- Wordness [6335e23c@99-53-226-60.lightspeed.irvnca.sbcglobal.net] has joined ##taproot-activation 12:40 < luke-jr> can always benefit from more review ofc, but no reason that has to happen before a release 12:40 -!- hujgghj [6bb5bd37@107.181.189.55] has quit [Client Quit] 12:40 < proofofkeags> pretty sure the point of review is to happen before release 12:40 < proofofkeags> in general 12:40 < queip> so using this client is not going "against" the bitcoincore.org's version, and doesn't preclude their mechanisms like ST and such right? if yes I guess it could be good idea to use such client. Did you had concerns in that area, Emcy? 12:40 < luke-jr> proofofkeags: there has already been lots of review tho 12:40 < luke-jr> proofofkeags: any more at this point is nice-to-have extra 12:40 < proofofkeags> kk 12:41 -!- gwj [5b848894@91.132.136.148] has joined ##taproot-activation 12:41 < CriptoLuis> Core devs should be aware of everything happening here, so it will not be unlikely any coordinated activation procedure 12:41 < shinobious> and also we can do release candidates 12:41 -!- Tap2021 [63ff9090@cpe589630a45781-cm589630a4577f.cpe.net.cable.rogers.com] has quit [Client Quit] 12:41 -!- iamnick [aec68a2a@42.sub-174-198-138.myvzw.com] has joined ##taproot-activation 12:41 < luke-jr> yes, today's release would ideally only be rc1 :p 12:41 < luke-jr> final would be in a week assuming no issues 12:41 < shinobious> @queip: short a few cases where compatibility is intentionally broken more by Core, they should be generally compatible in most situations 12:41 < roconnor> luke-jr: I don't understand "creates a much worse and more likely scenario". 12:41 < faketoshi> exactly. all this is assuming core would foolishy ignore this client and make itself deliberately incompatible 12:41 < shinobious> or leave room for Core's next release to be compatible if ST fails 12:42 < luke-jr> and further later releases can always add features/etc 12:42 -!- Wordness [6335e23c@99-53-226-60.lightspeed.irvnca.sbcglobal.net] has quit [Client Quit] 12:42 < shinobious> and I do not believe anything would be merged into Core creating new compatibility issues 12:42 -!- bitsharp2 [402bb298@64.43.178.152] has quit [Quit: Connection closed] 12:42 < luke-jr> roconnor: the 2 weeks in question: if we don't activate, but ST does, that's an issue; and it's the ST startheight we're using 12:43 -!- Anon-11123 [56343899@56343899.rev.stofanet.dk] has quit [Quit: Connection closed] 12:43 <@michaelfolkson> I need to think more about the edge cases of this release having ST (block height) and Core potentially having ST (mix of block height and MTP) 12:43 <@michaelfolkson> I don't know why Core is going for mix of block height and MTP personally 12:43 < shinobious> @roconnor: I actually think that concern relates to the start height issue we're discussing now 12:43 < luke-jr> it's premature to say Core is 12:43 < shinobious> so if you want to bring it up now thats fine 12:44 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has quit [Quit: Connection closed] 12:44 < roconnor> luke-jr: The two weeks are pritor to ST's expected startheight. How can ST activate then? 12:44 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has quit [Quit: Connection closed] 12:44 < roconnor> shinobious: you mean my DM? 12:44 <@michaelfolkson> luke-jr: Agreed, my wording wasn't perfect there. That's my current expectation 12:44 < shinobious> @roconnor: yes 12:44 < luke-jr> roconnor: no, the startheight we are using, is the startheight proposed for ST; just not ST/BIP9 which uses times 12:44 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds] 12:45 < luke-jr> roconnor: ST/BIP9 is a hard NACK and releasing that would be malicious on Core's part; but in the possibility they release normal ST, we wouldn't want to miss the first period 12:45 < roconnor> luke-jr: That is not my understanding. 12:45 -!- Decentralizedb58 [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has quit [Quit: Connection closed] 12:45 < shinobious> @luke-jr: I'd like to hear roconner voice his other concern, because I think it relates to the start height issue 12:45 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has quit [Quit: Connection closed] 12:45 -!- Decentralizedb [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has joined ##taproot-activation 12:45 < luke-jr> roconnor: it's copy/pasted from the ST activation PR #21393 12:45 < shinobious> and is actually a factor in why I want this client starting a signal period as its set now, even if its before the ST period begins 12:45 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has joined ##taproot-activation 12:46 < luke-jr> shinobious: I ain't stopping him ☺ 12:46 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has joined ##taproot-activation 12:46 < roconnor> So my other concern is about the mandory signaling period. 12:46 -!- kgdub69 [566a797a@86.106.121.122] has quit [Quit: Connection closed] 12:47 -!- nicknack [543c9540@dslb-084-060-149-064.084.060.pools.vodafone-ip.de] has joined ##taproot-activation 12:47 -!- Tushar [46708bf5@cpe-70-112-139-245.austin.res.rr.com] has quit [Quit: Connection closed] 12:47 <@michaelfolkson> roconnor: At the end of BIP 8 (LOT=true)? 12:47 -!- lukerob [4cb96f8d@cpe-76-185-111-141.tx.res.rr.com] has quit [Quit: Connection closed] 12:47 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 12:47 -!- nicknack [543c9540@dslb-084-060-149-064.084.060.pools.vodafone-ip.de] has quit [Client Quit] 12:47 <@michaelfolkson> What's the concern? We only get there if Speedy Trial doesn't activate 12:47 -!- andhans [25c9c48f@ip-37-201-196-143.hsi13.unitymediagroup.de] has quit [Client Quit] 12:47 -!- nicknack [543c9540@dslb-084-060-149-064.084.060.pools.vodafone-ip.de] has joined ##taproot-activation 12:47 -!- nicknack [543c9540@dslb-084-060-149-064.084.060.pools.vodafone-ip.de] has quit [Client Quit] 12:48 -!- taprooooooot_wen [b9d59af1@185.213.154.241] has quit [Quit: Connection closed] 12:48 < roconnor> Yes, The design of the manditory signaling is taken from BIP148, where it was designed to have force signaling activating existing, let's call it LOT=false clients, to abuse terminology a little. 12:48 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-iuioqnqrhmkzxmtl] has joined ##taproot-activation 12:48 -!- Guest20521 [54112b9b@84.17.43.155] has quit [Quit: Connection closed] 12:48 < roconnor> But there are no compatiable LOT=false clients around anymore. As such I'm not convinced that this manditory signaling design is appropriate anymore. 12:49 -!- Rabbit100 [b9d975d5@185.217.117.213] has quit [Quit: Connection closed] 12:49 -!- gwj [5b848894@91.132.136.148] has quit [Quit: Connection closed] 12:49 < roconnor> I personally think a flag-day (BIP8=nomando) is more appropriate. 12:49 < luke-jr> some signal is needed for user coordination 12:49 < roconnor> But there may be other solutions, such as reverse signaling, that I haven't given a lot of consideration to yet. 12:49 < luke-jr> what kind of signal may be debatable, but IMO shedpainting this late 12:49 < shinobious> I think the mandatory signaling is a good point in making any chainsplits clean, but re: this specific proposal 12:49 -!- mutualp2p [~mutualp2p@ip-178-216.ists.pl] has joined ##taproot-activation 12:49 < luke-jr> someone mentioned an issue with reverse signalling a few weeks ago 12:49 < shinobious> this is why I do not want to adjust the start height, and think it starting early for BIP 8 client than ST is actually a safety benefit 12:50 < luke-jr> I forget the specific scenario 12:50 < shinobious> in that it guarantees ST cannot signal and activate early without locking in early activation for the BIP 8 client 12:50 < achow101> apparently I was incorrect about the startheight. see https://github.com/bitcoin/bips/pull/1104 12:50 < shinobious> which would eventually guarantee a chainsplit in October 2022 in that case 12:50 < roconnor> achow101: oh very good. 12:50 < achow101> i believe currently proposed mtp and uasf client are compatible 12:50 < shinobious> if the BIP 8 client signal window starts before ST, then that cannot happen 12:51 < roconnor> okay, my start height concerns were misinformed then. 12:51 -!- iamnick [aec68a2a@42.sub-174-198-138.myvzw.com] has quit [Quit: Ping timeout (120 seconds)] 12:51 -!- GV [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has joined ##taproot-activation 12:51 < GeraldineG> that's reassuring about the start height then :) 12:51 -!- Trevor [4b9e785d@d75-158-120-93.abhsia.telus.net] has quit [Quit: Connection closed] 12:51 < shinobious> alright, so shall we call that all concerns re: start height addressed? 12:51 -!- iamnick [aec68a2a@42.sub-174-198-138.myvzw.com] has joined ##taproot-activation 12:51 -!- GV is now known as GVac 12:51 < faketoshi> thanks achow101 12:52 < faketoshi> we spent half the meeting talking about that :P 12:52 < shinobious> (yeah, thanks, also please don't attack my node :P) 12:52 < GeraldineG> progress :) 12:52 < luke-jr> sigh 12:52 < UltrA1> dont make a mess of bitcoin 12:52 < shinobious> alright, unless there are any other concerns/issues relating to this, dare I say we have consensus? 12:53 < roconnor> huh 12:53 <@michaelfolkson> So that PR has startheight as April 24th (MTP of course rather than block height) 12:53 < luke-jr> so we're back to [19:37:37] anyway, as I see it, the code is done; either we release it, don't release it, or shedpaint another 2 weeks 12:53 < shinobious> (being cheeky a bit) 12:53 < UltrA1> on ph w my securities team.. 12:53 -!- jimmysong_ [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has joined ##taproot-activation 12:53 -!- auviks [50869264@p50869264.dip0.t-ipconnect.de] has joined ##taproot-activation 12:53 < luke-jr> michaelfolkson: unless miners manipulate it, it should be the same height 12:53 -!- eidnrf [566a797a@86.106.121.122] has joined ##taproot-activation 12:54 <@michaelfolkson> luke-jr: I don't like anything that isn't 100 percent certain 12:54 < luke-jr> michaelfolkson: complain to ST/MTP folks; it's inherent in their nonsense 12:55 < GVac> I'm late and all this is way over my head but I'm curious if someone will be summarizing what was discussed and publishing it somewhere for public consumption? 12:55 < GVac> discuss/decided... 12:55 < luke-jr> probably 12:55 -!- jimmysong [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has quit [Ping timeout: 260 seconds] 12:55 < luke-jr> most of the discussion was all based on a mistaken premise 12:55 <@michaelfolkson> luke-jr: I've complained all over the place. AJ is only one who has NACKed consistent block heights. But seems they're not going with it 12:56 <@michaelfolkson> (at least for now) 12:56 < shinobious> alright, for now, lets go back to the release name (and please keep it civil) 12:56 < GVac> lol - my life's savings - poof. ;) 12:56 < luke-jr> michaelfolkson: my point is there's nothing we can do about it outside that separate discussion 12:56 < faketoshi> a BIP8 Lot=True client is being released which is compatible with everything it can be compatible with. Suggested modifications turned out to be based on a misunderstanding. No one has any real concerns that have come up from what I saw. 12:56 <@michaelfolkson> luke-jr: Right, agreed 12:56 -!- Crash78 [5fd67ac7@95.214.122.199] has joined ##taproot-activation 12:56 < shinobious> personally, I am not of the mind that all UA, GUI, etc. references to "Bitcoin Core" should be removed, thats kind of silly 12:56 < shinobious> but I am also not comfortable colloquially referring to a release as "Bitcoin Core" 12:56 <@michaelfolkson> GVac: I will attempt to summarize for the bitcoin-dev mailing list 12:57 -!- Yoghurt11411 [888f01e2@226-001-143-136.dynamic.caiway.nl] has quit [Ping timeout: 240 seconds] 12:57 < luke-jr> "Bitcoin Core UASF" was clear enough to everyone in 2017; "Bitcoin Core with Taproot" is fine now 12:57 < GVac> thanks. 12:57 < Majes> agreed 12:57 < luke-jr> anything else is IMO flawed 12:57 < GeraldineG> "Bitcoin Core Taproot" 12:57 < shinobious> the ecosystem was much smaller then, much more informed, and people were not as prone to infer inaccurate things from little details 12:57 < UltrA1> Bitcoin Core + Taproot 12:57 < GeraldineG> or what Luke said ^^ :D 12:57 < luke-jr> (well, +/-) 12:58 < CriptoLuis> Bitcoin Core Taproot 12:58 < Crash78> + 12:58 < luke-jr> shinobious: Bitcoin's security relies on people being informed to a minimum degree 12:58 < shinobious> I'm not comfortable releasing something under a name that could implicitly be read as Core as a project endorsing/releasing something they did not 12:58 < CriptoLuis> I like Bitcoin Core + Taproot too 12:58 < roconnor> Using "Bitcoin Core" in the client name is whole inapropriate. 12:58 < faketoshi> But that's literally what it is :P 12:58 -!- Antoine46 [c80aa6ab@host-200-10-166-171.public.eastlink.ca] has quit [Quit: Connection closed] 12:58 < shinobious> it's a fork of Core, like I said expecting all mentions of "Core" to be scrubbed from the codebase is silly 12:58 < queip> - 12:59 < Crash78> Taproot is good! Like :) 12:59 < luke-jr> it's not really even a fork 12:59 < queip> other client will eventually also have TapRoot 12:59 < shinobious> but anywhere people get the client should not frame it as an official Core release 12:59 < luke-jr> it's just Core, but with Taproot activation 12:59 < eidnrf> TAC: Taproot Activation Client 12:59 < roconnor> Anyhow, given that there are no LOT=false clients, I don't think the manditory signaling period makes any sense anymore. 12:59 < roconnor> at least not as it is designed. 12:59 <@michaelfolkson> roconnor: There could be, we can't tell the future 12:59 < duringo> Unofficially Bitcoin Core + Taproot ;) 12:59 < queip> Taproot flagday? 12:59 < zndtoshi> If Bitcoin Core UASF was clear in 2017 (and not Bitcoin Core with Segwit) why wouldn't it be called "Bitcoin Core UASF" this time too? 12:59 < luke-jr> zndtoshi: it's not a UASF 12:59 <@michaelfolkson> roconnor: Core could release BIP 8 (LOT=false) after ST has failed 13:00 < queip> Bitcoin Core Taproot Flagday 13:00 < luke-jr> zndtoshi: and there was another "with Segwit" already 13:00 < faketoshi> Rootcoin Tore. 13:00 < roconnor> michaelfolkson: I don't find that plausible at all. 13:00 -!- iamnick [aec68a2a@42.sub-174-198-138.myvzw.com] has quit [Quit: Connection closed] 13:00 -!- epson121 [d5953e5f@cm-2094.cable.globalnet.hr] has quit [Quit: Connection closed] 13:00 < shinobious> @roconnor: I would have said last year I find it implausible Core doesn't release a BIP 8 LOT=true client 13:01 -!- auviks [50869264@p50869264.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 13:01 < eidnrf> TAC: Taproot Activation Client 13:01 <@michaelfolkson> roconnor: We don't know what Core will do in that scenario. It is pure speculation. BIP 8 (LOT=false) is an option 13:01 < queip> tbh desu I would say BitcoinCore TaprootFlag is the accurate name. or BitcoinCore-TRF / -TAC whatever 13:01 < luke-jr> it's not an alternative release; it's just activation that Core will hopefully merge itself 13:01 -!- malicious83 [d537f157@213.55.241.87] has quit [Quit: Connection closed] 13:01 < luke-jr> it doesn't need its own name 13:01 < Majes> Bitcoin Core Taproot is accurate 13:02 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has quit [Quit: Connection closed] 13:02 < shinobious> I think it does @luke-jr for colloquial distinction 13:02 < luke-jr> shinobious: Core+TR works if you want something short 13:02 < faketoshi> Ok well meeting is technically over. The release - at least rc1 will likely be out today. The website taproot.works has some info and will host the releases. I know luke-jr disagrees strongly with some of the characterizations made there. 13:02 < queip> luke-jr: since it has other consensus rules (coming to effect in future) than the Bitcoin Core, it should't have same name 13:02 < zndtoshi> IMO if ST fails the community will expect Core to merge Taproot for Oct 2022 activation. 13:02 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has joined ##taproot-activation 13:02 < roconnor> faketoshi: was it ratified? 13:02 <@michaelfolkson> faketoshi shinobious: Shall I formally end the meeting? 13:03 < luke-jr> queip: Bitcoin Core will have to enforce the rules too 13:03 < shinobious> @faketoshi: at the very list I still don't think the naming issue is resolved 13:03 < faketoshi> i'd like to continue 13:03 < shinobious> I really am not comfortable releasing as "Bitcoin Core" 13:03 < luke-jr> roconnor: should it be halted? 13:03 < jaenu> I like TAC: Taproot Activation Client 13:03 < roconnor> I mean I think so. 13:03 < faketoshi> Sorry I didn't mean to imply that we couldn't continue 13:03 < luke-jr> roconnor: why? 13:03 -!- gchain [gustafmatr@gateway/shell/matrix.org/x-iuioqnqrhmkzxmtl] has left ##taproot-activation ["User left"] 13:04 < jeremyrubin> hi 13:04 <@michaelfolkson> shinobious faketoshi: Please let me know when you'd like to formally end the meeting. Whenever is fine 13:04 < shinobious> welcome back @jeremyrubin 13:04 < faketoshi> Sure, for some reason I thought they were limited to 60 minutes by convention. 13:04 < jeremyrubin> Just want to raise awareness that Bitcoin Core is an unregistered wordmark/trademark so it should not be used 13:04 -!- Beatcoin [be0e005a@190.14.0.90] has joined ##taproot-activation 13:04 < luke-jr> jeremyrubin: no, it isn't. 13:04 < jeremyrubin> it's registered? 13:05 < shinobious> @jeremyrubin: I'm just not okay with releasing as Bitcoin Core on ethical grounds, as it might imply to some people support/endorsement from a group that did not give it 13:05 < luke-jr> jeremyrubin: you don't have a monopoly on it 13:05 < luke-jr> and in this context, it's referring to Bitcoin Core 13:05 < queip> there is large consensus what bitcoin core client is 13:05 < queip> it is not a client that has some modifications added to it 13:05 < GeraldineG> Core+Taproot says it all 13:05 < luke-jr> literally nobody is proposing calling this "Bitcoin Core" (until it gets merged formally) 13:06 < queip> without overwhelming consensus 13:06 -!- Alexandre_Chery7 [94668a79@148.102.138.121] has joined ##taproot-activation 13:06 -!- Crash78 [5fd67ac7@95.214.122.199] has quit [Quit: Connection closed] 13:06 < jeremyrubin> Just pointing out, like it or not, naming something "bitcoin core" for the purpose of creating the auspice of a false endorsement likely runs the risk of opening up anyone who releases it to trademark infringement suit 13:06 < luke-jr> "Bitcoin Core with Taproot" is clear and specific without giving it a name of its own (which it shouldn't have IMO) 13:06 -!- Alexandre_Chery7 [94668a79@148.102.138.121] has quit [Client Quit] 13:06 < queip> GeraldineG: no, Core+TaprootFlagday says it all, since there might be Core+Taproot[ST] or any of other methods proposed 13:06 < jeremyrubin> So it's best to come up with your own original branding 13:06 < luke-jr> no branding is needed 13:06 < proofofkeags> any "original branding" is more misleading though 13:06 < shinobious> @jeremyrubin: there's no intent to imply endorsement by anyone in favor of it 13:07 < queip> how will we differentiate it from other bitcoin core clients that want to activate taproot but in other way? 13:07 < shinobious> I think this is just a semantics disagreement here 13:07 < luke-jr> queip: there shouldn't be any others 13:07 < shinobious> I'm worried about how it might be perceived, I see no intent to make it perceived that way on purpose 13:07 < queip> luke-jr: welll is useful when telling ppl on media, or friends, to go and run.... run what? 13:07 < jeremyrubin> I'm just telling you that branding "Bitcoin Core + Taproot" is trademark infringement 13:07 -!- Alexandre_Chery9 [94668a79@148.102.138.121] has joined ##taproot-activation 13:07 < jeremyrubin> do with that what you will 13:07 <@michaelfolkson> I think having Core in the name is ok. As long as it is clear that it isn't signed off by the Core maintainers. I think Bitcoin Core with Taproot isn't pretending to actually be Bitcoin Core 13:07 < luke-jr> btw, note there logically should also be a "btcd with Taproot" etc 13:07 < luke-jr> queip: upgrade to Taproot 13:07 < luke-jr> jeremyrubin: it isn't 13:08 < queip> luke-jr: well... or "bitcoin core + flagday", if we follow logic that taproot IS bitcoin core 13:08 < jeremyrubin> I advise you at least consult with a trademark attorney 13:08 < jeremyrubin> IANAL, IANYL 13:08 < shinobious> I would be much more comfortable with simply "Bitcoin Taproot" or something similar 13:08 < shinobious> I do not like "Bitcoin Core" and the implications some less informed users might draw from that 13:08 < jeremyrubin> consult with or figure out who is the trademark holder 13:08 <@michaelfolkson> jeremyrubin: Agreed, me neither. I can only comment on what I feel is wrong ethically. 13:08 < proofofkeags> yeah calling it Bitcoin Taproot would be fine 13:08 < luke-jr> shinobious: less informed users would draw more correct implications 13:08 < queip> I mean, "flagday" is the shortest word that summarizes difference between the approach to taproot we have here, vs other approaches 13:08 < shinobious> I disagree luke-jr 13:08 < queip> (or acronyms like TAC or whatever) 13:08 -!- blap [~gk@217.138.252.235] has quit [Ping timeout: 240 seconds] 13:08 < zndtoshi> Bitcoin Taproot sounds good 13:09 -!- Alexandre_Chery [94668a79@148.102.138.121] has quit [Ping timeout: 240 seconds] 13:09 < proofofkeags> I think saying that it is a fork of Bitcoin Core though is not in any way an infringement as it is purely descriptive of the code provenance, but IANAL either. 13:09 < luke-jr> zndtoshi: that will get spun as forking off 13:09 < queip> zndtoshi: it sure does, but bitcoin core also is "taproot" (e.g. via ST) probably 13:09 -!- solairis [bbbebae2@fixed-187-190-186-226.totalplay.net] has quit [Quit: Connection closed] 13:09 < luke-jr> queip: no 13:09 -!- dg5egdgd [2fde397b@47-222-57-123.plptcmta02.res.dyn.suddenlink.net] has joined ##taproot-activation 13:09 < zndtoshi> but if they're in consensus how is this a fork? 13:09 < proofofkeags> code fork 13:09 < jeremyrubin> proofofkeags: that is correct, but titling it in a confusing manner can be infrining 13:09 < proofofkeags> not chain fork 13:09 < luke-jr> queip: ST/MTP trolls have no more claim to "Core" than we do 13:10 -!- eidnrf [566a797a@86.106.121.122] has quit [Quit: Connection closed] 13:10 < jeremyrubin> I'm not claiming I do either 13:10 -!- enrimagna [56c816f9@lfbn-ann-1-264-249.w86-200.abo.wanadoo.fr] has joined ##taproot-activation 13:10 -!- camarena [2d5b1702@45.91.23.2] has quit [Ping timeout: 240 seconds] 13:10 -!- trent11 [18c17796@cpe-24-193-119-150.nyc.res.rr.com] has quit [Quit: Connection closed] 13:10 < jeremyrubin> as best I can figure https://bitcoincore.org owns the wordmark 13:10 < luke-jr> zndtoshi: see Matt's trolling about forking off all the time 13:10 < queip> luke-jr: Im just a small user but anyway I do not fell ok with forcing ourselves as "the" bitcoin. please. I bet most users also have objection there 13:10 < luke-jr> queip: then there can never be Taproot 13:11 < roasbeef> luke-jr: you're really bordering on dogma these days dude 13:11 < luke-jr> softforks require coming to consensus on "the" bitcoin 13:11 < zndtoshi> for the SPIRIT of what we are doing here, it's more about "Bitcoin" than about "Bitcoin Core" 13:11 < queip> luke-jr: other ways are bitcoincore.org's ST, and if it fails than the other thing. 13:11 < luke-jr> queip: no such thing exists 13:11 < faketoshi> bitcoin core isn't "the bitcoin" either though 13:11 < mol_> luke-jr, MimbleWimble and LTC will have taproot too :D 13:11 < luke-jr> roasbeef: you may wish to look up what dogma means 13:11 < queip> luke-jr: as we known, difference source codes and different possible rules still hopefully will end in one same network, with TR ofc 13:11 < shinobious> well, I'm just gonna say, I have NACK releasing this as "Bitcoin Core" 13:12 < luke-jr> queip: no 13:12 < roasbeef> luke-jr: i'd invite you to do the same ;) 13:12 < shinobious> hard NACK* 13:12 < luke-jr> queip: if people aren't running the same rules, they should not be on the same network 13:12 < queip> luke is more luke than usual, today ;) 13:12 -!- Alexandre_Chery [94668a79@148.102.138.121] has joined ##taproot-activation 13:12 < queip> luke-jr: untill flagday they are. in case of success they are forever 13:12 -!- Alexandre_Chery9 [94668a79@148.102.138.121] has quit [Quit: Connection closed] 13:12 < faketoshi> shinobious: what about "Bitcoin Core with Taproot" 13:12 < jeremyrubin> i'd also suggest -- but not require -- that the name be UNAMBIGUOUS 13:12 < faketoshi> ? 13:12 < roasbeef> queip: heh yeh, lost count of the number of misrepresentations in the scrll back :p 13:12 < jeremyrubin> running a UASF client is a particular action that you want users to clearly pick 13:13 < luke-jr> "Bitcoin Core with Taproot" is unambiguous 13:13 < jeremyrubin> ST is also "Bitcoin Core with Taproot" 13:13 <@michaelfolkson> In the scenario of block height, mix of block height and MTP blowing up we might have to decide what is Bitcoin 13:13 < proofofkeags> it won't be if Core does an ST release 13:13 < proofofkeags> yeah 13:13 < luke-jr> BIP 8 is a MASF 13:13 < jeremyrubin> and you do not own the Bitcoin Core wordmark 13:13 < luke-jr> jeremyrubin: ST is non-existent 13:13 < jeremyrubin> #23177??? 13:13 < luke-jr> proofofkeags: that would bhe malice at this point 13:13 -!- calvz14 [1876257d@c-24-118-37-125.hsd1.mn.comcast.net] has joined ##taproot-activation 13:13 < luke-jr> 23177 is malice 13:13 < roconnor> luke-jr: pretending ST is non-existent is particularly disingenous, even for you. 13:13 < jeremyrubin> I would name it "Bitcoin + Taproot UASF" 13:13 < proofofkeags> luke-jr everything is malice to you 13:13 < queip> luke-jr: why Bitcoin Core + Taproot via ST would be not "Bitcoin Core + Taproot", if "Bitcoin Core + Taproot via flagday" is? 13:13 < shinobious> @faketoshi: I do not like anything including "Core" in the name 13:14 -!- eidnrf [566a797a@86.106.121.122] has joined ##taproot-activation 13:14 < jeremyrubin> Or if you prefer "Bitcoin Core fork with Taproot UASF 13:14 < luke-jr> jeremyrubin: that's dishonest 13:14 < queip> if you find my name too long than maybe acronym like TAC or TFD (T. FlagDay) 13:14 < roasbeef> in the end, 5 devs and 20 random ppl on twitter does not a softfork make, quite a bubble ppl are in to think companies/services that actually accept coin for the biz will run a diff client (then?) switch back to mainline? also see belcher's points from above re why things are different this time 13:14 < jeremyrubin> luke-jr: how is that dishonest? 13:14 < zndtoshi> luke-jr just go with Bitcoin Taproot. It's clear enough and no drama. 13:15 -!- jimmysong_ [~jimmysong@72-48-253-168.dyn.grandenetworks.net] has quit [Remote host closed the connection] 13:15 < eidnrf> TAC is taken. Taproot Activation Client 13:15 -!- Decentralizedb [2e1b465c@static-92-70-27-46.ipcom.comunitel.net] has quit [Quit: Connection closed] 13:15 < proofofkeags> roasbeef, I'm not sure what you're getting at there 13:15 < luke-jr> proofofkeags: he's trolling that nobody will use it 13:15 <@michaelfolkson> Ok I'm going to leave and formally end the meeting. Rules on warnings and being booted no longer apply. Feel free to continue the discussion 13:15 <@michaelfolkson> #endmeeting 13:15 < queip> zndtoshi: I would find it confusing as a "bitcoincore.org" user, to see your name implying TR code can not activate in other client - it can, and perhaps will sooner 13:15 < shinobious> yeah, probably a good call @michaelfolkson 13:15 < jaenu> Bitcoin Core TAC (Taproot Activation Client) 13:15 < zndtoshi> thank you michaelfolkson for moderation 13:16 < roconnor> what was the result of the meeting? Was anything ratified? 13:16 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 13:16 < luke-jr> faketoshi: 13:16 < faketoshi> roasbeef: i know companies/services who specifically want to run BIP8 clients and who would presumably switch back to mainline once taproot is active. 13:16 < shinobious> I believe the start height issues have been addressed in my opinion @roconnor 13:16 < roconnor> that is true. 13:16 -!- dg5egdgd [2fde397b@47-222-57-123.plptcmta02.res.dyn.suddenlink.net] has quit [Quit: Connection closed] 13:16 < luke-jr> faketoshi: you mean once mainline merges Taproot activation? 13:17 -!- enrimagna [56c816f9@lfbn-ann-1-264-249.w86-200.abo.wanadoo.fr] has quit [Quit: Connection closed] 13:17 < shinobious> thank you to everyone who came and gave feedback and criticism to the proposal 13:17 < luke-jr> faketoshi: otherwise they'd be hardforking Taproot out 13:17 < faketoshi> yes 13:17 < GeraldineG> the proposal looks great I'm excited to follow its progress 13:18 <@michaelfolkson> Oh I forgot. Also if anyone would like to schedule a meeting on a Taproot activation topic please contact me. If no one does, the next meeting will be Jeremy's meeting same time next week (Tuesday) 13:18 -!- gyuhhhcu [bc7fa5c9@188.127.165.201] has quit [Quit: Connection closed] 13:18 < faketoshi> We've literally been through all this, but in a way more chaotic fashion. There shouldn't be much contention, and it didn't seem like there was, except for the naming. 13:18 -!- zndtoshi [4f701126@79.112.17.38] has quit [Quit: Connection closed] 13:18 < eidnrf> No Core in the name. This is where we show that bitcoin does not belong to a single entity. Next battle may involve bigger privacy features. Need to show that bitcoiners will not bend the knee. 13:18 < roconnor> I'm pretty unhappy with the manditory activation. I'm also skeptical that this client has consesnsus behind it, despite luke-jr assurances that it is "obivous" to everyone. It isn't obvious to me at all. 13:18 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 13:18 -!- justobserving837 [44961646@S0106f8a097f03715.ed.shawcable.net] has quit [Quit: Connection closed] 13:19 < proofofkeags> in a world with no authority, naming is actually a hard problem trivial as it may sound 13:19 < roconnor> s/manditory activation/manditory signaling. 13:19 < luke-jr> roconnor: BIP8 has consensus, not all this 13:19 < roconnor> sorry 13:19 < roconnor> luke-jr: you keep saying that. 13:19 < luke-jr> LOT=True never did, and maybe never will 13:19 < roasbeef> proofofkeags: it's kind of a farce in the face of no true threat, those that accept coin in return of some service/product or custody aren't gonna run an altclient, just look at this as an example: https://github.com/bitcoin/bitcoin/compare/master...BitcoinActivation:0.21+taproot 13:19 < faketoshi> regarding ratification: if the name is all we're hung up on then this thing is basically good to go. 13:20 < shinobious> I would concur faketoshi but also think that is an important thing 13:20 < GeraldineG> it would be a shame to halt it progressing much longer over the release name 13:20 < shinobious> users choosing to run this should have no confusion or potential for confusion whatsoever about what they are running 13:20 < roconnor> faketoshi: for the record I don't think the manditory signaling is reasonable anymore, and I 13:20 < shinobious> and who it is endorsed by 13:20 < roconnor> and I'm skeptical the client has consensus behind it. 13:20 < proofofkeags> roconnor, I have been somewhat absent from the discussion but fwiw I've never been amped about mandatory signaling either as it doesn't seem to fix anything necessarily 13:21 < roasbeef> roconnor: lol right? "this has consensus" isn't really a falsifiable statement the way luke phrases it 13:21 < roconnor> proofofkeags: it made more sense in the expected presence of a compatiable LOT=false client. 13:21 -!- digital50 [1773cbf8@23-115-203-248.lightspeed.okcbok.sbcglobal.net] has joined ##taproot-activation 13:21 -!- hodl_it [43b9f76d@c-67-185-247-109.hsd1.wa.comcast.net] has quit [Quit: Connection closed] 13:21 < GeraldineG> @shinobious what was your favorite naming suggestion so far? 13:21 < jeremyrubin> shinobious: while I'm against a release of UASF at this point, I concur with the sentiment and commend you for a principled stance 13:22 < jeremyrubin> if you want to empower users don't lie to them 13:22 < shinobious> @GeraldineG: honestly anything that does not say "Bitcoin Core" 13:22 < duringo> shinobious the normie user is using whatever they've downloaded from bitcoin.org no? 13:22 < luke-jr> "Bitcoin Core with Taproot" is clear, unconfusing, and honest 13:22 < GeraldineG> @shinobious ah yeah I seen your hard NACK on that.. 13:22 < roconnor> proofofkeags: it's copying from BIP148 a design that just isn't applicable to this situation anymore. 13:22 < shinobious> I disagree luke-jr, average users will not disentangle the different semantic meanings of that in context, project, versus client, versus contributors, etc. 13:22 < proofofkeags> I'll take your word for it, I was brand new in Summer'17 13:22 < shinobious> it is too ambiguous 13:23 -!- peterrizzo_1 [45ce133d@69.206.19.61] has quit [Quit: Connection closed] 13:23 < luke-jr> shinobious: Bitcoin Core isn't an entity, just software 13:23 < proofofkeags> the important thing is to make it unambiguous primarily to the economic majority 13:23 < shinobious> @duringo: yes, but a lot of the people who ran BIP 148 were also normies 13:23 < duringo> the average user is using whatever client they downloaded from bitcoin.org, or whichever client umbrel or mynodebtc etc are using 13:23 < luke-jr> and this software is Bitcoin Core, with one change (Taproot activation) 13:23 < eidnrf> Normies are using bundled node. Specter or any of the other ones that can be flashed onto an SD and run on a Raspberry pi. 13:23 < proofofkeags> for better or worse that means technical users and professionals who work for larger institutions 13:24 -!- digital50 [1773cbf8@23-115-203-248.lightspeed.okcbok.sbcglobal.net] has quit [Client Quit] 13:24 < shinobious> @eidnrf: I don't think its totally out of the realm of possibility some of those bundles might offer this as an option 13:24 < roconnor> luke-jr: ( 2055 commits behind bitcoin:master. ) 13:24 -!- blap [~gk@217.138.252.235] has joined ##taproot-activation 13:24 < luke-jr> roconnor: it's not based on master 13:24 < luke-jr> roconnor: it's 0.21 13:24 < shinobious> really, I would advocate that, my only concern would be ensuring the user is made aware of the risks 13:24 < proofofkeags> I ran a poll of our users and it was split 50/50 split between advocating for a UASF outright, and going with whatever our recommendation was 13:24 < duringo> shinobious i was a normie that ran bip148 once i was "convinced" by people like you and others that i followed and trusted. otherwise whatever is on bitcoin.org is what i ran 13:25 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has quit [Quit: Connection closed] 13:25 -!- justan_observer [d1fafa29@209.250.250.41] has joined ##taproot-activation 13:25 < roconnor> luke-jr: and when Bitcoin Core relases 0.21.1 ? 13:25 < shinobious> well, this is a new client, it lives or dies like all of them based on how many people you convince to run it 13:25 < GeraldineG> proofofkeags I think people are just looking for leadership either way to progress this 13:25 < luke-jr> roconnor: merge it in? 13:25 < luke-jr> roconnor: if you mean a malicious 0.21.1, that should simply not happen 13:25 < roconnor> luke-jr: and if it does? 13:26 < proofofkeags> GeraldineG: exactly. But the problem is that there is basically gridlock around hard NACK'ing a UASF vs hard NACK'ing a MASF 13:26 < luke-jr> roconnor: then publicly denounce it 13:26 < roconnor> okay 13:26 < jeremyrubin> TBH I think trying to have confusing branding is a self-own that you don't think people want it enough to explicitly ask for it 13:26 < proofofkeags> personally I don't mind attempting MASF first time around, but I don't see a way where an MASF fails and it isn't followed up with a UASF 13:26 < luke-jr> proofofkeags: this IS a MASF 13:26 < duringo> i dont think anyone here is trying to have confusing branding 13:26 < luke-jr> jeremyrubin: you're the one trying to confuse 13:27 < shinobious> @roconnor: I know luke has been saying "malicious" a lot lately, but if Core went out of their way to release something that exacerbated compatibility issues, I would call that malicious 13:27 -!- justan_observer [d1fafa29@209.250.250.41] has quit [Client Quit] 13:27 < shinobious> its one thing to not go out of the way to bend Core into compliance with this release 13:27 < shinobious> its an entirely different matter to intentionally break Core's compatibility with this even more 13:27 < jeremyrubin> I also don't get why you don't just build on AJ's UASF patch 13:27 < faketoshi> it's also not going to happen 13:27 < eidnrf> I think not having BIP47 in Core is malicious. 13:28 < luke-jr> rather than whining about "Bitcoin Core with Taproot" as a "name", does anyone have any suggestions for a *better* alternative naming scheme? 13:28 < shinobious> Bitcoin Taproot 13:28 < luke-jr> keeping in mind a "btcd with Taproot" would probably be needed too 13:28 < luke-jr> and hypothetically a "Bitcoin Knots with Taproot" etc 13:29 < luke-jr> shinobious: that sounds like a scamcoin 13:29 < faketoshi> it really does lmao 13:29 < luke-jr> shinobious: and you can bet at least Matt will spin it as one 13:29 < shinobious> so it should be easier to get people to run :P 13:29 -!- gwj [5b848894@91.132.136.148] has joined ##taproot-activation 13:29 < luke-jr> shinobious: no 13:29 < duringo> Bitcoin Beetroot 13:29 -!- eidnrf [566a797a@86.106.121.122] has quit [Quit: Connection closed] 13:30 < Emcy> meeting over? 13:30 < hiro8> There's going to be a lot more context provided than just a name and nothing else. 13:30 < faketoshi> Where can i buy bitcoin taproot? 13:30 < luke-jr> any suggestion should work with more than just Bitcoin Core - also btcd and Bitcoin Knots ;) 13:30 < luke-jr> libbitcoin too 13:30 < Emcy> i think id remind some of you that this isnt a war council, alright 13:31 < luke-jr> Emcy: so? 13:31 < Emcy> 'core' has no desire to make enemies of any of you, or anyone else 13:31 < luke-jr> who said anything about war council 13:31 -!- UltrA1 [689fd929@104-159-217-041.res.spectrum.com] has quit [Quit: Connection closed] 13:31 < Emcy> i did 13:31 < luke-jr> oh, sure, that's my point 13:31 < shinobious> @Emcy: officialy yeah but we're still talking about naming 13:31 < shinobious> was no consensus on that 13:31 < Emcy> ive made my stance on naming clear 13:31 < Emcy> more people appeared to support my view than not 13:32 < Emcy> i cant make you do anything 13:32 < luke-jr> I don't see any reasonable way to avoid "Bitcoin Core" in the name 13:32 < faketoshi> No name doesn't have a tonne of issues with it. Nuance is required as hiro8 said, and it won't normally be presented without that. 13:32 < shinobious> @luke-jr: I do, just don't 13:32 < luke-jr> … 13:32 -!- suntsu8 [d5c8ec17@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Connection closed] 13:33 -!- WhyDoesLightning [566a797a@86.106.121.122] has joined ##taproot-activation 13:33 < luke-jr> shinobious: waiting for a suggestion that makes snese 13:33 < faketoshi> Just be insanely verbose about it then? Monty Python style? 13:33 < jeremyrubin> luke-jr: Bitcoin Core fork + Taproot UASF 13:33 < luke-jr> jeremyrubin: why are you pushing for a dishonest name? 13:33 < mol> Bitcoin Luke 13:33 < jeremyrubin> how is that dishonest? 13:33 < faketoshi> "Code from the Bitcoin Core repository forked to have Taproot Activation" 13:33 < GeraldineG> "Bitcoin Taproot Client" "Bitcoin Core Fork with Taproot" "Bitcoin+Taproot" "Core+TR" 13:33 < luke-jr> it's not a UASF 13:33 < luke-jr> it's a MASF 13:34 < jeremyrubin> LOT is a UASF? 13:34 < roconnor> luke-jr: why doesn't Knots just pull in your PR? 13:34 < mol> the more confusing the better for this coin 13:34 < jeremyrubin> for fuck's sake your development channel is named ##uasf 13:34 < luke-jr> roconnor: I have'nt given enough throught to how to handle t his in Knots 13:34 < faketoshi> jeremyrubin: no it's not 13:34 < luke-jr> jeremyrubin: no, it isn't. 13:34 < shinobious> Bitcoin Taproot Client is fine 13:35 < shinobious> like luke..in 2017, no one told anyone "Go download Core with..." 13:35 < shinobious> they said "Go download BIP148" 13:35 < luke-jr> GeraldineG: "fork" is not understood by n00bs 13:35 < shinobious> or go download "UASF client" 13:35 < shinobious> no one at all referred to that as "Bitcoin Core with BIP148" 13:35 < luke-jr> shinobious: that doesn't work for btcd/Knots 13:35 -!- Alexandre_Chery7 [9466bde6@148.102.189.230] has joined ##taproot-activation 13:35 -!- Alexandre_Chery7 [9466bde6@148.102.189.230] has quit [Client Quit] 13:35 < jeremyrubin> Maybe just define a BIP for the specific BIP8 LOT=true instance you're doing 13:35 < jaenu> go download "Taproot Activation Client" 13:35 < jeremyrubin> and call it "Bitcoin BIPXXX" 13:35 < shinobious> +1 jeremyrubin 13:36 < jeremyrubin> can be 344 or something? idk what the taproot range spans 13:36 -!- BTC_Bitcoin-Tapr [5ec62a6a@94.198.42.106] has joined ##taproot-activation 13:36 < proofofkeags> +1 jeremyrubin 13:36 < entropy5000> y, BIP seems like a good idea, that worked for Segwit 13:36 < proofofkeags> all marketing is disingenuous here 13:36 -!- jaenu [1f1809b6@182.9.24.31.ftth.as8758.net] has quit [Quit: Connection closed] 13:36 -!- Alexandre_Chery [94668a79@148.102.138.121] has quit [Ping timeout: 240 seconds] 13:36 < BTC_Bitcoin-Tapr> Bitcoin Taproot Client 13:36 < proofofkeags> a BIP can be maximally specific 13:36 < jeremyrubin> luke-jr: as BIP editor you can even pick the number you like best 13:37 < jeremyrubin> Bitcoin BIP666 13:37 -!- Majes [c0a1e550@192-161-229-192-161-229-80.cpe.sparklight.net] has quit [Quit: Connection closed] 13:37 -!- zoglogdog [45a175b8@d-69-161-117-184.nh.cpe.atlanticbb.net] has quit [Quit: Connection closed] 13:37 < queip> jeremyrubin: s/UASF/flagday 13:38 < queip> ok or MASF 13:38 < Emcy> luke-jr what happens when youce called your fork 'bitcoin core + taproot', and then bitcoin core itself merged taproot activation code? could be sooner than you think 13:38 < Emcy> there is large potential for naming confusion, even discounting that, and in think you know it 13:38 < luke-jr> Emcy: then the fork no longer has a purpose? 13:38 < luke-jr> if it gets merged in mainline 13:38 < jeremyrubin> I think "Bitcoin BIPXXX", "Bitcoin Core fork with BIPXXX", "Bitcoin Taproot LOT=True" etc 13:38 < jeremyrubin> all good names 13:38 < faketoshi> then it's just called bitcoin core :) 13:39 < GeraldineG> @Emcy i think that would be perfect, the goal is to get it in :) 13:39 < jeremyrubin> just make it clear what people are running 13:39 < Emcy> i dont see why it wont get merged at this point 13:39 < mol> GeraldineG, and i think we'll have it in soon 13:39 -!- arturogoosnargh [c263680c@194.99.104.12] has joined ##taproot-activation 13:39 < queip> still with merge it will be bc-TR-ST "vs" bc-TR-flagday 13:39 * shinobious beats head on desk 13:40 -!- Alexandre_Chery [9466bde6@148.102.189.230] has joined ##taproot-activation 13:40 < jeremyrubin> it's not a flagday, it's a UASF w/ MA Early Activation 13:40 < GeraldineG> @luke-jr what do you think about the BIP naming approach? 13:40 < queip> yeah then assign bip and call it by that? 13:41 < luke-jr> GeraldineG: stupid and doesn't get anywhere 13:41 < mol> luke-jr, does Bitcoin Knots have taproot yet? 13:41 < GeraldineG> @luke-jr bah 13:41 < luke-jr> mol: no, and TBD what I do with it 13:41 < luke-jr> mol: separate matter entirely 13:41 < queip> luke-jr: where a name should "get to", we just need a way to tell someone we mean "our client" when we discuss it "outside" or ask ppl to use 13:41 < mol> oh.. really? i was thinking it'd be perfect if Knots has taproot 13:42 < luke-jr> queip: there will likely be many "our client"s 13:42 < luke-jr> queip: if btcd won't add it, then we'll need a btcd fork too etc 13:42 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has joined ##taproot-activation 13:42 < luke-jr> mol: eventually, I'm sure something will get into Knots, but I have to think about *how* 13:42 < Emcy> luke-jr are you saying that youll cll off this fork if bitcoin core merges taproot activation code? 13:42 < jeremyrubin> luke-jr: I have a challenge for you 13:43 -!- WhyDoesLightning [566a797a@86.106.121.122] has quit [Ping timeout: 240 seconds] 13:43 < jeremyrubin> Why don't you try to pick a name you think would make me happy? 13:43 < mol> luke-jr, why is that? you have taproot in another client but not in knots? 13:43 < luke-jr> jeremyrubin: northing could 13:43 < jeremyrubin> I've put honest effort into trying to come up with one you'd like 13:43 < shinobious> @Emcy: no 13:43 < jeremyrubin> and I'm happy w/ what I've proposed so that's clearly false 13:43 < Emcy> luke implied this 13:43 < luke-jr> Emcy: not my call to make 13:43 < jeremyrubin> others have even +1'd bip naming 13:43 < shinobious> if Core releases something that is not actively malicious to this deployment, they should in almost all situations activate in lockstep 13:43 < luke-jr> Emcy: but I mean *this* activation code 13:43 < shinobious> (short a ST failure) 13:44 < jeremyrubin> so i'm just curious if you put an honest shot into something you accept that you think would make me happy what would it be? 13:44 < jeremyrubin> If you're not willing to do that then I can't help any further 13:44 < luke-jr> jeremyrubin: yes, but I haven't come up with anything 13:44 < luke-jr> jeremyrubin: and considering you don't want it to exist at all, I doubt something would ever 13:44 < jeremyrubin> I gave a bunch of solid suggestions earlier 13:44 < luke-jr> I don't agree 13:44 < shinobious> @jeremyrubin: my understanding here is not having Core creates ambiguity with multiple clients forked to implement this 13:45 < shinobious> and he seems set on "btcd with taproot, libbitcoin with taproot, etc" 13:45 < faketoshi> "Bitcoin BIP8 Lot=True Activation Client" 13:45 < shinobious> which is broken by not including "Bitcoin Core" 13:45 < luke-jr> shinobious: not "set on" so much as I don't see a reasonable alternative 13:45 -!- Alexandre_Chery [9466bde6@148.102.189.230] has quit [Ping timeout: 240 seconds] 13:45 < faketoshi> i'm gonna fork off with that name 13:45 < jeremyrubin> I'm happy with that name 13:45 < faketoshi> i can't be bothered arguing about it any more 13:45 < queip> .tgz fname will be fun 13:45 < jeremyrubin> Bitcoin Core fork BIP8 Lot=True Activation Client 13:45 < luke-jr> faketoshi: that doesn't even say Taproot lol 13:45 < jeremyrubin> if you like as well 13:45 -!- Alexandre_Chery [9466931b@148.102.147.27] has joined ##taproot-activation 13:45 < faketoshi> lol 13:46 < copumpkin> "faketoshi's awesomest client" 13:46 < faketoshi> good point 13:46 * queip forks that off into +taproot 13:46 < luke-jr> jeremyrubin: stop trying to present it as "fork" 13:46 < jeremyrubin> faketoshi: also feel free to add taproot 13:46 < luke-jr> you know "fork" has become "scamcoin" to normies 13:46 < jeremyrubin> ohhh 13:46 < jeremyrubin> I mean like github fork! 13:46 < luke-jr> normies don't 13:46 < queip> Taproot Frens 13:46 < shinobious> it will take five seconds to explain luke-jr 13:46 < hiro8> Bitcoin BIP8 Lot=True Taproot Activation Client 13:46 < luke-jr> wake me up in 2 weeks when you guys figure something out 13:46 < jeremyrubin> Bitcoin Core patched BIP8 LOT=True Taproot Activation Client 13:47 < shinobious> and I don't see the vast majority of Core developers doing anything to imply fork = scamcoin 13:47 < faketoshi> We just did 13:47 < faketoshi> Bitcoin BIP8 Lot=True Taproot Activation Client 13:47 < queip> Taproot-B8LT 13:47 < jeremyrubin> luke-jr: see if you told me why you thought it is dishonest I would have gotten that a lot faster 13:47 < luke-jr> faketoshi: that doesn't identify if it's Core or Knots or btcd or libbitcoin 13:47 < faketoshi> colloquially "the taproot client" 13:47 < jeremyrubin> I had no idea *that* is what you were triggered on 13:47 < faketoshi> Core is implied, not stated 13:47 < faketoshi> Sorry that works for me 13:47 < luke-jr> faketoshi: it's not implied anywhere 13:47 < faketoshi> And it is just not going to matter 13:48 -!- roconnor [~roconnor@host-45-78-202-80.dyn.295.ca] has left ##taproot-activation ["Konversation terminated!"] 13:48 < shinobious> @luke-jr: the instant someone opens it, and see's the client 13:49 < luke-jr> jeremyrubin: you didn't know normies consider "fork" to be "scamcoin"? 13:49 < shinobious> there will be zero ambiguity its a fork of core 13:49 < luke-jr> shinobious: … are you suggesting people run code to figure out what it is? 13:49 < jeremyrubin> No? I mean knots is a fork of core 13:49 < faketoshi> Not to normies 13:49 < luke-jr> jeremyrubin: "fork" is not used anywhere on Knots' site 13:49 < luke-jr> and what faketoshi said 13:49 < luke-jr> normies don't consider Knots a fork; they consider bcash a fork 13:50 < jeremyrubin> ok then use "patch" 13:50 < jeremyrubin> NBD 13:50 < luke-jr> "Bitcoin Core-based Taproot Client"? 13:50 < luke-jr> that might work? 13:50 < faketoshi> yes! 13:50 < GeraldineG> a boring suggestion, the "Bitcoin Core Taproot Proposal Client" 13:51 < duringo> getting warmer 13:51 < jeremyrubin> GeraldineG: nack; there are other things that fit the bill 13:51 < faketoshi> Bitcoin Core-based Taproot Client lfg 13:51 < jeremyrubin> the name should be unique-ish 13:51 < faketoshi> nah, Luke budged and it's reasonable now 13:51 < faketoshi> that is not misleading in any way 13:51 < luke-jr> shinobious: ? 13:52 < GeraldineG> Luke's "Bitcoin Core-based Taproot Client" sounds good to me :) 13:52 < faketoshi> 100% 13:52 < shinobious> luke-jr: this is such a silly thing to get hung up on 13:52 < jeremyrubin> you should make it clear that it's UASF/BIP whatever 13:52 < jeremyrubin> just let users know what they're running 13:52 < luke-jr> shinobious: does "Bitcoin Core-based Taproot Client" work for you or not? 13:52 < jeremyrubin> https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0 13:52 < shinobious> honestly my first thought looking at that is you're saying the client is "BASED" 13:52 < jeremyrubin> ST followed by 15m MASF followed by UASF 13:52 < shinobious> not that its based on Core 13:53 < faketoshi> client is based af tho 13:53 < faketoshi> that's silly man 13:53 < jeremyrubin> Those are the names you've already picked for your plan 13:53 < GeraldineG> "Unofficial Bitcoin Core Taproot Client" :P 13:53 < jeremyrubin> Bitcoin Core based Taproot ST followed by 15m MASF followed by UASF 13:53 < jeremyrubin> thereyago 13:54 -!- peterrizzo_1 [45ce133d@69.206.19.61] has joined ##taproot-activation 13:54 < queip> ---> https://www.strawpoll.me/42938334 myself:3,4,5,8,9 13:54 < faketoshi> why not just include all the code too :/ 13:54 < luke-jr> jeremyrubin: see, you're just trying to be disruptive 13:54 < jeremyrubin> I'm just saying understanding this to be a UASF client is not innacurrate 13:54 < jeremyrubin> BIP148 was a uasf client right? And still had early activation 13:54 < faketoshi> it actually is as it's a MASF? 13:55 < jeremyrubin> so just call it Bitcoin Core Based Taproot UASF 13:55 < faketoshi> Bitcoin Core-based Taproot Client 13:55 < shinobious> @luke-jr: he might be being a little cheeky, but I entirely agree with the reason why 13:55 < luke-jr> shinobious: does "Bitcoin Core-based Taproot Client" work for you or not? 13:55 < arturogoosnargh> "Core-based" could describe several clients, "Core" implies the brand name and consent/veto from Core Team 13:55 < shinobious> we shouldn't refer to this as Bitcoin Core in a way employing its part of the project, endorsed by them, etc. 13:55 -!- BTC_Bitcoin-Tapr [5ec62a6a@94.198.42.106] has quit [Quit: Connection closed] 13:55 < faketoshi> based fixes that shinobious 13:55 < luke-jr> it doesn't 13:56 -!- Velocibeaver [43dfc867@67.223.200.103] has quit [Ping timeout: 240 seconds] 13:56 < luke-jr> and it arguably is part of the project 13:56 < shinobious> I'm fine with -based 13:57 < faketoshi> phew 13:57 < queip> what do you mean "TAC is taken. Taproot Activation Client" ? 13:57 < queip> faketoshi: our client is based 13:57 < faketoshi> af 13:57 -!- ygrtiugf [6c549a0d@108-84-154-13.lightspeed.sntcca.sbcglobal.net] has joined ##taproot-activation 13:57 < jeremyrubin> I think based is accurate. You are building on a release. Patched marginally better, but still. 13:57 < jeremyrubin> You can even do Bitcoin Core 0.21 Based ... 13:58 < jeremyrubin> so it's clear which version it should be API compatible with (e.g. rpcs and crap) 13:58 < jeremyrubin> solves the issue for your backports as well 13:59 < luke-jr> eg https://luke.dashjr.org/programs/bitcoin/files/BitcoinTaproot.org/taproot.html#download 13:59 < luke-jr> still feels a bit long tbh 14:00 < queip> TAC is short 14:00 -!- leevancleef [8074ecf1@128-116-236-241.static.eolo.it] has joined ##taproot-activation 14:01 -!- taPrOOteD [566a797a@86.106.121.122] has joined ##taproot-activation 14:01 -!- leevancleef [8074ecf1@128-116-236-241.static.eolo.it] has quit [Client Quit] 14:01 < luke-jr> https://github.com/BitcoinActivation/BitcoinTaproot.org/pull/10 14:01 -!- Dario2605 [5cb866de@pop.92-184-102-222.mobile.abo.orange.fr] has joined ##taproot-activation 14:01 < faketoshi> merged 14:02 < jeremyrubin> maybe just add LOT to it? 14:02 -!- leevancleef [8074ecf1@128-116-236-241.static.eolo.it] has joined ##taproot-activation 14:02 < jeremyrubin> again, the ST release could also validly use that name 14:02 < jeremyrubin> you want an unambiguous name 14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 14:02 -!- Alexandre_Chery [9466931b@148.102.147.27] has quit [Quit: Connection closed] 14:02 < faketoshi> That means putting literally all of the codebase into the name 14:02 < jeremyrubin> No it doesn't 14:03 < jeremyrubin> if you want a trendy name don't make it confusing 14:03 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 14:03 < luke-jr> jeremyrubin: ST is dead 14:04 < luke-jr> doh, we forgot to aks for gitian builders 14:04 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 14:05 < jeremyrubin> luke-jr: ball in your court to prove that rather than just claim it 14:05 < queip> I guess most are ok with "Bitcoin Core TAC" or "Bitcoin Core-based Taproot Client" , are you ok with either, developers of it? 14:05 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 14:05 < jeremyrubin> it's actively receiving acks on github 14:05 < Emcy> what did you merge 14:05 < luke-jr> jeremyrubin: devs don't get to strong-arm Bitcoin 14:05 < faketoshi> +1 14:05 < faketoshi> name seems to be "Bitcoin Core-based Taproot Client" 14:06 < faketoshi> Any serious objection? 14:06 < queip> ok that is half joking but.. acronym is.. BC-BTC then 14:06 < Emcy> better than it was before i guess 14:06 < faketoshi> I have heard jeremyrubin suggest adding other (wrong) info such as UASF etc which obvs isn't right 14:06 -!- ygrtiugf [6c549a0d@108-84-154-13.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed] 14:06 < queip> that will be so confusing when people shorten it like that. I would go with TAC. *shrug* :) 14:07 < luke-jr> queip: anyone can call it anything 14:07 < luke-jr> can we move on yet? :P 14:07 < queip> obviously, but community will gravity to some name, probably one that we/you suggest 14:07 < taPrOOteD> TAC 14:08 < jeremyrubin> Not calling a UASF a UASF signals intesne dishonesty with your users 14:08 < jeremyrubin> beyond just the name of the client 14:08 < jeremyrubin> that you're representing that it's not a UASF client is very dishonest 14:09 < luke-jr> jeremyrubin: go read the FAQ on the site 14:09 < jeremyrubin> if it's truly what you beleive is right go for it 14:09 < jeremyrubin> burn your reputations on lying to users 14:09 < luke-jr> you're the one lying 14:09 < jeremyrubin> about? 14:09 < luke-jr> that it's a UASF 14:09 < luke-jr> the FAQ goes into full detail 14:09 < jeremyrubin> lulz 14:09 < shinobious> @jeremyrubin: semantically it isn't a UASF unless ST fails or miners don't activate 14:10 < shinobious> it is a UASF conditionally at the end of other activation mechanisms 14:10 < luke-jr> ok, jeremyrubin is just trying to sabotage us; I'm ignoring him 14:10 < jeremyrubin> shinobious: is a client that hard forks a block size increase if a soft fork doesn't activate a hard fork? 14:10 < faketoshi> it has a potential to be a UASF but it isn't just a UASF 14:10 < jeremyrubin> I would say yes since it has the potential 14:10 -!- ygrtiugf [6c549a0d@108-84-154-13.lightspeed.sntcca.sbcglobal.net] has joined ##taproot-activation 14:10 < queip> jeremyrubin: is it dishonest to use short name, I think not, users will read info what "TAC" or "-based taproot activation" means 14:11 < luke-jr> queip: TAC sounds like a scamcoin 14:11 < jeremyrubin> The reason this matters is actually relatively substantive 14:11 -!- gwj [5b848894@91.132.136.148] has quit [Quit: Connection closed] 14:11 < jeremyrubin> You're normalizing the idea of developers releasing potentially incomaptible software without clear intent 14:11 < jeremyrubin> today you agree with the impact 14:11 < jeremyrubin> tomorrow you might not 14:11 < faketoshi> "bitcoin core with taproot activation via MASF with emergency UASF as a backup" 14:12 -!- Beatcoin [be0e005a@190.14.0.90] has quit [Quit: Connection closed] 14:12 < faketoshi> otherwise it's inaccurate 14:12 -!- Trevor [4b9e785d@d75-158-120-93.abhsia.telus.net] has joined ##taproot-activation 14:12 < jeremyrubin> faketoshi: just give it a differerent name if you want i don't care 14:12 < jeremyrubin> Mine Accelerate User Mandated Soft Fork 14:12 < jeremyrubin> MAUMSF 14:12 < jeremyrubin> just make sure it's actually clear 14:12 < luke-jr> jeremyrubin: you are the one trying to release incompatible software 14:13 < jeremyrubin> lol 14:14 -!- V1Technology [49a63c73@c-73-166-60-115.hsd1.tx.comcast.net] has joined ##taproot-activation 14:14 <@michaelfolkson> Suggest two names and we'll do a coin flip 14:14 < queip> crypto poker! 14:14 < luke-jr> lol 14:14 < shinobious> jeremyrubin: this is compatible with anything Core releases using signal bit 2 until October 2022 14:14 < V1Technology> Can't flip a Bittcoin, silly! 14:14 < shinobious> the only compatibility issues would come from Core dragging their feet that long, or intentionally releasing something creating new compatibility issues intentionally 14:15 < jeremyrubin> Look IDGAF what y'all name it; just know that there will be hell to pay from more than just me if you don't correctly communicate what the choice users are making is 14:15 < queip> jeremyrubin: is "Bitcoin Core-based Taproot Client" honest enough would you say? 14:15 < jeremyrubin> No; because it's not clear that it fallsback to mandaotry signalled UASF 14:15 < shinobious> you should see by now @jeremyrubin I have no intention of doing anything of the sort 14:15 < jeremyrubin> it's burying the lede 14:15 -!- Whatsupppp [c1207ff0@193.32.127.240] has joined ##taproot-activation 14:15 < jeremyrubin> shinobious: yeah this isn't aimed at you 14:16 < luke-jr> jeremyrubin: it also doesn't mention it's 4 MB block size limit 14:16 < shinobious> luke is not trying to do anything of the sort either 14:16 < shinobious> BIP8, Lot=True: Guaranteed Activation 14:16 < shinobious> BIP8 with Lot=true activates a soft fork when one of two conditions is met. The first condition is whether a given threshold of mined blocks within one difficulty period of 2016 blocks, say 90%, signals in favor of activation. If this happens the soft-fork activates at the start of the following difficulty adjustment period. 14:16 < shinobious> If that first condition isn’t met by the Lot=true blockheight then all nodes reject any blocks that do not signal readiness. As a result, 100% of blocks accepted after the Lot=True blockheight must signal in favor of activation. This guarantees that the threshold is met and that Taproot activates in the following difficulty adjustment period. 14:16 < shinobious> thats directly off the site set up for this at taproot.works 14:17 < shinobious> nothing about LOT=true is being buried, or obscurred 14:17 < shinobious> or hidden 14:17 < duringo> that sounds pretty reasonable 14:17 -!- opalla [5ec62a6a@94.198.42.106] has joined ##taproot-activation 14:17 < faketoshi> yeah i'm 100% not concerned about being accused or found to be dishonest with this 14:17 < faketoshi> it's more concern trolling 14:17 < queip> mby add -UASF to in 4 letters communicate: look, this code MIGHT fork off from miners that do not like taproot activation our way (we hope we will win tho) 14:17 < faketoshi> if you're well intentioned with it jeremyrubin i apologise 14:18 < faketoshi> but i am happy to not discuss this any more and more forward 14:18 < shinobious> none of my concerns were over anyone's intent @jeremyrubin, solely how people could misconstrue things on their own, which people are prone to doing 14:18 < luke-jr> queip: that's misrepresentign what a UASF is too 14:19 < queip> luke-jr: detail are in FAQ pasted above.... I guess MAUMSF is really detailed tho hard to pronounce 14:19 -!- taPrOOteD [566a797a@86.106.121.122] has quit [Ping timeout: 240 seconds] 14:19 < jeremyrubin> "Mom SF" 14:19 < luke-jr> queip: it doesn't fork off 14:20 -!- Dario2605 [5cb866de@pop.92-184-102-222.mobile.abo.orange.fr] has quit [Quit: Connection closed] 14:20 < jeremyrubin> it absolutely won't be on the most work chain if miners decide not to use your client 14:20 < luke-jr> queip: https://luke.dashjr.org/programs/bitcoin/files/BitcoinTaproot.org/taproot.html#faq_uasf 14:20 -!- Vv [25db6ecb@37-219-110-203.nat.bb.dnainternet.fi] has joined ##taproot-activation 14:20 < shinobious> @jeremyrubin: where are you assuming a chainsplit, and from what cause? 14:20 -!- Vv [25db6ecb@37-219-110-203.nat.bb.dnainternet.fi] has quit [Client Quit] 14:21 < shinobious> unless ST intentionally uses a different signal bit, or drops literally right now and locks in before this client is released 14:21 -!- calvz14 [1876257d@c-24-118-37-125.hsd1.mn.comcast.net] has quit [Quit: Connection closed] 14:21 < shinobious> where is the chainsplit potential during ST? 14:21 < jeremyrubin> not during ST, at the mandatory signal point 14:22 < shinobious> if Core has not released something that locked in activating by that point, people are probably running this client 14:22 < luke-jr> then miners are required to signal in valid blocks. 14:22 < shinobious> or, Bitcoin has shown itself to be ossified 14:22 < luke-jr> if they make invalid blocks, THEY are forking off 14:22 < jeremyrubin> shinobious: latter seems more likely 14:22 < luke-jr> same as if they make invalid blocks today 14:23 < luke-jr> jeremyrubin: stop trying to centralise Bitcoin 14:23 < jeremyrubin> there's a reasonable contingent of people who think miners should be able to be running the exact same code forever 14:23 < queip> luke-jr: well I was not about the me/them war of "no u" who forks off, but to mention that "a fork" might happen 14:23 < jeremyrubin> your proposed activation breaks that 14:23 < jeremyrubin> convince BlueMatt that's safe 14:23 < jeremyrubin> I think the risk is acceptable personally 14:23 < luke-jr> queip: only under the same conditions miners could fork off today 14:23 < jeremyrubin> but it's not acceptable to miscommunicate what the risk is 14:23 < mol> so did luke come up with a name? 14:24 < luke-jr> did your mom? 14:24 < luke-jr> why is it on me to? 14:24 < queip> mine did 14:24 < luke-jr> XD 14:24 < faketoshi> Bitcoin Core-based Taproot Client 14:24 < queip> actually wait maybe I will in fact call her 14:24 < queip> nm too late today 14:24 < mol> oh that's the name, faketoshi ? 14:24 < jeremyrubin> shinobious: if it's not clear, assume 20% un upgraded miners, during LOT they'll produce invalid blocks once the 10% tolerance of bad blocks is surpassed 14:24 < luke-jr> XD 14:25 < jeremyrubin> so then they'd eventually come around back to the main chain 14:25 < faketoshi> Seems to be, jeremyrubin thinks it should have more info in it - but no one else has complained 14:25 < jeremyrubin> but if it were 51%, you could see a permament most-work chain divergence 14:25 < queip> mol: that, and other popular choice seem to be "TAC" but luke says it's bad 14:25 < jeremyrubin> faketoshi: this is a total bubble 14:25 < shinobious> @jeremyrubin: how? 14:25 < shinobious> if they are unupgraded, their mempools without customization will not accept taproot spends 14:25 < faketoshi> sigh 14:25 < mol> queip, i see :D 14:26 < faketoshi> it's a name 14:26 < jeremyrubin> the 51% of un-upgraded miners would mine on the first-seen rule and diverge 14:26 < queip> mol: question now is whether name must include some form of "UASF"(inaccurate) or "MAUMSF" to signal it has other consensus going possibly against miners and perhaps not compatible with "Bitcoincore.org's" client 14:26 -!- Trevor [4b9e785d@d75-158-120-93.abhsia.telus.net] has quit [Quit: Connection closed] 14:26 < mol> oh really.. 14:26 < queip> I dunno 14:26 < queip> Emcy: any hot or otherwise takes on this? 14:26 < shinobious> if 51% of miners are not enforcing new rules then they are acting maliciously 14:26 < jeremyrubin> shinobious: you should read what Matt's written on the mailing list 14:27 < jeremyrubin> he explains it better than I do 14:27 < shinobious> I do not care about any chainsplits that involve solely the miners 14:27 < jeremyrubin> shinobious: this is users too 14:27 < shinobious> I don't consider that a risk or a network issue at all, thats their issue, and they will pay for it 14:27 < jeremyrubin> you have to look at the network that just didn't run new code 14:27 < jeremyrubin> Read BlueMatt's writing 14:27 < mol> jeremyrubin, link? 14:28 < jeremyrubin> you don't have to agree with the conclusions ( I don't!) but his analysis is correct 14:28 < shinobious> @jeremyrubin: you think that almost half of miners would be running something, without indication a majority of the economy was? 14:28 < shinobious> I think that would be completely irrational, and at that point things much bigger are breaking in incentives 14:28 < jeremyrubin> shinobious: that sentence doesn't parse to me 14:29 < jeremyrubin> but conceivably if LOT period is hit, there's already not that many miners running it 14:29 < shinobious> 51% of miners not enforcing implies 49% are 14:29 < jeremyrubin> nope! 14:29 < shinobious> why would those 49% be enforcing if they did not have high confidence a large part of the economy was? 14:29 < shinobious> then just say all miners aren't enforcing jeremey 14:29 < jeremyrubin> 49% might be signalling, fewer could be LOT signalling 14:29 < shinobious> you're being pedantic 14:30 < shinobious> at that point, then only a slice of the economy is probably running it, and it wouldn't be safe to use anyway 14:30 < jeremyrubin> idk just go scan matt's mailing list posts 14:30 < faketoshi> NACK to this MAUMSF nonsense. It's a name and obviously just ridiculous. 14:30 < shinobious> and again: miners would have to intentionally modify mempool policy if they weren't enforcing taproot 14:30 < shinobious> their mempools would not accept taproot spends 14:30 < jeremyrubin> you misunderstand 14:30 < jeremyrubin> this isn't about mining invalid blocks 14:30 < jeremyrubin> it's about most work chain following for UASF-ing clients 14:31 < jeremyrubin> shinobious: the mempool stuff also only helps with non-attacked chains, SPV mining means the chain would be potentially unfollowable. Mandatory signalling ensures it is unfollowable 14:31 < luke-jr> jeremyrubin: no, Matt's analysis is not correct 14:31 < jeremyrubin> that's the whole point of mandatory signalling is to guarantee a split out of miners who don't want the new rule 14:32 < luke-jr> jeremyrubin: no, it isn't. 14:33 -!- xdrpx [18637513@c-24-99-117-19.hsd1.ga.comcast.net] has joined ##taproot-activation 14:33 < jeremyrubin> ¯\_(ツ)_/¯ 14:33 < queip> luke-jr: what is the point of mand. signil? 14:33 < luke-jr> queip: to coordinate activation between users 14:34 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/102585/what-is-the-benefit-of-forced-signaling-in-a-soft-fork-activation-mechanism 14:35 < Murch> shinobious: I think the point he is trying to make is that many miners have flagged with custom software in the past without actually enforcing the implied rules. 14:35 -!- entropy5000 [4db58416@x4db58416.dyn.telefonica.de] has quit [Quit: Connection closed] 14:36 < shinobious> @Murch: and my response to that is, if they aren't actively enforcing, then their mempool policy should be don't accept new rule spends 14:37 < jeremyrubin> no that's not what I'm saying 14:37 < shinobious> unless some miner intentionally goes out of their way to maliciously modify that, it can't happen 14:37 < Murch> I was responding to the claim that just because 51% are not signaling that it implies 49% are enforcing. 14:37 < luke-jr> it's not relevant during MUST_SIGNAL 14:37 < jeremyrubin> Murch: what I'm saying is they can signal during the LOT period without having the software to reject non signaled blocks 14:37 < jeremyrubin> they can still have code to enforce taproot 14:37 < shinobious> @Murch: and I'm saying 100% could be not enforcing, if they haven't modified mempool policy to be malicious there is not a split risk 14:37 < jeremyrubin> e.g. BIP8 LOT=false 14:38 < shinobious> because no miner will actually put any new spend TXes, valid or invalid, in a block 14:38 < jeremyrubin> shinobious: LOT=true creates the chainsplit itself 14:38 < Murch> But there is, because some nodes would reject non-signaling blocks and others would not. 14:38 < shinobious> well again, I come back to if some other compatible method hasn't locked in an activated by then, odds are most people are running this BIP 8 client 14:39 < jeremyrubin> shinobious: that's a crap null hypothesis 14:39 < Murch> That's conjecture at best. 14:39 < luke-jr> by the time we reach MUST_SIGNAL, it doesn't matter if miners enforce Taproot or not. If they don't, they're mining invaldi blocks. 14:39 < shinobious> if that is not the case, then this is utterly irrelevant, and what happens is some tiny group fork themselves off 14:39 < shinobious> and this doesn't matter at all except to that tiny group 14:39 < jeremyrubin> shinobious: well that's exactly the point 14:39 < jeremyrubin> people running your code should know that might be the boat they're in! 14:40 < shinobious> we had this exact same risk with BIP148 14:40 < shinobious> it was very clear 14:40 < shinobious> a lot of people and businesses took that risk 14:40 < duringo> jeremyrubin so that needs to be clear in the name? 14:40 < shinobious> like jeremyrubin I shared your concern with the name, but at this point you are just concern trolling man 14:40 < shinobious> if you really think that anyone involved here will not make that risk explicitly clear 14:40 < shinobious> then I don't think you're engaging honestly here 14:41 < faketoshi> +1 14:43 -!- blap [~gk@217.138.252.235] has quit [Quit: Leaving] 14:43 * Murch thinks it'll probably be sufficiently elaborated in public. 14:44 < jeremyrubin> I'm not concern trolling; I'm just telling you to make it absolutely clear 14:44 < jeremyrubin> shinobious: I think the taproot.works site is pretty good 14:45 < Murch> How about "Bitcoin Core-based Taproot forcing client"? 14:45 < jeremyrubin> shinobious: I agree BIP148 was clear because people said "run BIP148" (or 149?) 14:45 < queip> jeremyrubin: but what would be the shortest/nicest name, if not "Bitcoin Core-based Taproot Client"? imo -based makes it quite ok 14:45 -!- GVac [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has quit [Quit: Connection closed] 14:46 -!- CriptoLuis [ba46d2d5@186.70.210.213] has quit [Quit: Connection closed] 14:46 < jeremyrubin> Again, Bitcoin Core will also release something that could be titled as such, so it does a poor job of being unambiguous 14:46 < jeremyrubin> Murch's suggestion is fine 14:46 < queip> I like Murch's name more too 14:46 < luke-jr> Bitcoin Core should merge Bitcoin Core-based Taproot Client 14:47 < Murch> luke-jr: That sounds fleetingly unlikely 14:47 < faketoshi> <- shrugs 14:47 < luke-jr> most likely as things stand 14:47 -!- miladm [524c9645@82.76.150.69] has quit [Quit: Connection closed] 14:47 < luke-jr> unless somoene abuses merge access 14:47 < jeremyrubin> if ST fails, and there's decent data about installs/adoption, then i see no issue with merging post-hoc 14:47 < Murch> As far as I can tell #21377 seems pretty likely to get merged next week 14:48 < luke-jr> Murch: that would be abuse of merge access 14:48 < luke-jr> devs don't decide rules any more than miners do 14:48 < Murch> As far as I can tell nobody shares that position with you 14:48 < luke-jr> Murch: that would be horrific and make Core an enemy of Bitcoin 14:49 < luke-jr> if you think devs control the protocol, go use BCash 14:49 < luke-jr> or whatever scamcoin has that 14:49 < mol> lol luke lmao 14:49 < Murch> I don't understand what gave you the impression that there is a problem with speedy trial, but it seemed to have the most support by far from my perspective. 14:50 < Murch> I'm not sure why you're hung up on MTP being malicious, and having read all of the above meeting, I have the impression that most other disputants appear similiarly baffled 14:50 < luke-jr> BIP9 is not ST 14:50 < mol> luke-jr, create another softfork and make it use your bip8 :D 14:52 -!- xdrpx [18637513@c-24-99-117-19.hsd1.ga.comcast.net] has quit [Quit: Connection closed] 14:52 < Murch> I've not involved myself very deeply in the activation discussion, but I'd say I understand most arguments for one or the other activation method 14:52 < ygrtiugf> Be careful of setting precedents that can bite later 14:52 < Murch> I have found it difficult to follow your argument, though 14:52 < jeremyrubin> [4/13/21 14:43] * Murch thinks it'll probably be sufficiently elaborated in public. 14:53 < jeremyrubin> solid +1 on that Murch btw 14:53 < mol> i don't get it either why luke's so hung up on this 14:54 < Murch> ygrtiugf: This seems a bit non-sequitur. Would you elaborate whom you're responding to? 14:54 <@michaelfolkson> Murch: A number of arguments. Firstly most reviewers prefer consistent use of block height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 14:54 <@michaelfolkson> Murch: Secondly the arguments to NACK consistent use of block height were weak (imo) 14:55 <@michaelfolkson> Murch: Thirdly there are edge cases to worry about with MTP e.g. timewarp attack 14:55 < Murch> My last impression from yesterday evening was that AJ and achow101 had put their heads together and were proposing something together that used MTP but addressed achow's concerns with it. I guess I'll have to go back to reading. 14:55 <@michaelfolkson> Murch: Fourthly if this release goes with consistent block height and Core doesn't they may not be compatible 14:56 < queip> I do not get it why not simply use block height 14:56 <@michaelfolkson> Murch: Fifthly some people seem to be against consistent block height to avoid using BIP 8. BIP 8 had a lot of consensus earlier at community meetings 14:56 < BlueMatt> Murch: nope, that impression is accurate. I'm not sure *anyone* gets the hung-up-ness on mtp-vs-height. 14:57 < Murch> well, tbh, we tried the approach that is being propagated here before and it didn't get consensus. Now you rolling out a client for it while the majority wants to try ST seems and expecting that ST goes along with a prior proposal that didn't get consensus seems needlessly restrictive 14:57 < BlueMatt> Murch: all arguments in either direction are basically a wash, and basically all of them are largely irrelevant in the bigger picture. 14:57 < Murch> :s/ST seems/ST/ 14:58 <@michaelfolkson> In your view BlueMatt they are a wash. Other people disagree, either through slight preference or literal NACK 14:58 < BlueMatt> Murch: ISTM that a number of folks saw lots of views for height, and figured it was decided, then were confused when others had other views and ultimately there was a compromise that people aren't happy with. That's fair, no one is happy in a compromise, but...:shrug: 14:59 <@michaelfolkson> Murch: Oh and yeah and sixthly (if that is a word) we are in a mess with BIPs. Will probably need to do a new one because of this mix of block height and MTP 14:59 < BlueMatt> michaelfolkson: correct, and in further peoples' views mtp is much better, so there is no winning. 14:59 <@michaelfolkson> Six reasons seems a decent number 14:59 <@michaelfolkson> BlueMatt: Nope only AJ 14:59 < Murch> @michaelfolkson: I don't know what you're getting out of all this busy work, but personally this effort seems entirely pointless to me 14:59 < Murch> At least at this point 14:59 <@michaelfolkson> Unless you want to add your name to this https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 14:59 < BlueMatt> michaelfolkson: meh, I kinda prefer mtp-based in the abstract 15:00 < BlueMatt> but, also, I have a meeting, see ya 15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection] 15:00 < luke-jr> Murch: ST has no more support than BIP8/LOT=True 15:00 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 15:00 < luke-jr> with MTP* 15:00 < jeremyrubin> BlueMatt: +1 on "abstractly MTP is better". World runs on wall clocks 15:00 < Murch> luke-jr: I understand that this is your perception, but my perception does not line up with that 15:01 < faketoshi> wth. the gaslighting is unreal 15:01 < BlueMatt> right, what jeremyrubin said 15:01 < Murch> jeremyrubin: +1 15:01 < faketoshi> ethereum is better than bitcoin cos people drive cars and those use gas 15:01 <@michaelfolkson> So have the activation height as MTP if we like wall clocks. Oh wait that is block height 15:01 < Murch> faketoshi: You can do better if you are trying to make some sort of argument 15:02 < faketoshi> i'm obviously not and neither are you three 15:03 < Murch> michaelfolkson: Blocks are not issued like clockwork, so I'm not sure what you're trying to say. 15:03 -!- arturogoosnargh [c263680c@194.99.104.12] has quit [Quit: Connection closed] 15:04 <@michaelfolkson> Murch: "World runs on wall clocks" except it doesn't for activation height 15:04 < Murch> which is one of the reasons why people prefer MTP? 15:04 < jeremyrubin> height in general is a hack to make the height based signaling period design work better 15:04 < jeremyrubin> height based signalling periods I'm not sure on why it was chosen TBH? 15:05 < jeremyrubin> oh 15:05 < jeremyrubin> difficulty retargets? 15:05 < Murch> michaelfolkson, maybe I'm being dense, but I don't follow your point 15:05 < Murch> jeremyrubin yes 15:05 < jeremyrubin> Not sure why 2016 blocks v.s. blocks in a 2 week window? 15:05 -!- GeraldineG [51886641@host81-136-102-65.range81-136.btcentralplus.com] has quit [Quit: Connection closed] 15:05 < jeremyrubin> maybe there's some weird edges around that 15:05 < Murch> Someone could game MTP signaling windows by setting weird timestamps 15:05 < jeremyrubin> But in general wall clock time is the thing we care about above all else 15:06 < queip> is there ANY downside to block-height based? besides normies being a bit confused and asking pros "Are we there yet"? 15:06 <@michaelfolkson> Murch: jeremyrubin said abstract MTP is better because world runs on wall clocks. Except that for activation height even AJ's PR is block height rather than MTP 15:06 < jeremyrubin> activation height is used as a hack to ensure that the time window "narrows" as it gets closer 15:07 < jeremyrubin> so in that case it does a *better* job for the wall clock than wall clock threshold 15:07 < Murch> queip: I think the main point is that most people don't care and just would like to see one approach being adopted. #21377 seems to be getting some love lately, so it seems likely people will converge on that 15:07 <@michaelfolkson> queip: Just the reasons aj and jeremyrubin have given. Test networks prefer MTP and UASF marketing 15:07 < jeremyrubin> michaelfolkson: I think you are missing "abstract" 15:07 < jeremyrubin> like if you could wave a wand and have a perfect wall clock design you would 15:07 < Murch> since everyone _seems_ to want taproot, it'll likely activate with ST 15:08 < Murch> If it doesn't, "Bitcoin Core-based Taproot forcing client" seems like something that should be reconsidered after that 15:08 < Murch> so, tbh, not sure what this is trying to achieve. 15:09 < Murch> michaelfolkson: Interesting. So what part of it is MTP in the first place then? 15:09 < Murch> The signaling start? 15:09 < jeremyrubin> signaling start/stop 15:10 <@michaelfolkson> Yup https://github.com/bitcoin/bips/pull/1104 15:10 < queip> Murch: shitcoiners might try to bribe miners just to spite BTCif they don't realise they are sitting at (lower part) of same branch 15:10 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation 15:12 -!- opalla [5ec62a6a@94.198.42.106] has quit [Ping timeout: 240 seconds] 15:12 -!- Velocibeaver [43dfc867@67.223.200.103] has joined ##taproot-activation 15:14 < Murch> queip: I'm not sure I understand the proposed threat scenario 15:14 -!- adfffdddsaeevv [2f9d7da2@47.157.125.162] has quit [Ping timeout: 240 seconds] 15:16 < queip> Murch: just regarding "since everyone _seems_ to want taproot" - since among people actually using BTC and wanting to use it we probably almost all agree to have taproot, still miners could have motivation to be malicious, e.g. bcash sha256 miners if they want to lose even more money or something. Just a thought (probably obvious to everyone) 15:17 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has joined ##taproot-activation 15:17 <@michaelfolkson> @michaelfolkson: I don't know what you're getting out of all this busy work, but personally this effort seems entirely pointless to me 15:17 <@michaelfolkson> I'll give you some reasons why I care if you're interested Murch 15:18 <@michaelfolkson> Firstly this is consensus code, we should make sure we are all comfortable with it. Two people have NACKed it 15:18 < luke-jr> since everyone _seems_ to want taproot, it'll likely activate with "Bitcoin Core-based Taproot Client" 15:18 < Murch> queip: Well, then we would learn that via ST, why are you putting in the effort now before you know to kick something off that either is unnecessary or may need to get amended before it becomes relevant? 15:18 <@michaelfolkson> Secondly, I have been involved in the activation discussion for a while and I feel somewhat responsible it goes smoothly 15:19 <@michaelfolkson> Thirdly, we are discussing an alternative release today which could not be compatible with Core due to this MTP issue. That is something to worry about 15:20 <@michaelfolkson> Fourthly, I felt I've wasted a huge amount of time (and many others have) on this MTP thing and this shouldn't be how Core development goes. The only NACK for consistent block height had weak rationale imo 15:20 < Murch> michaelfolkson: I guess I don't agree with multiple assumptions you're making 15:21 <@michaelfolkson> Ok, just answering your question. You can disagree with any part of my answer 15:23 -!- wonderful [ad03fb1d@ool-ad03fb1d.dyn.optonline.net] has quit [Quit: Connection closed] 15:24 < luke-jr> Murch: so BIP9/ST is capitalising on your ignorance of the matter :/ 15:25 -!- phuzzzed [447a04f0@68.122.4.240] has joined ##taproot-activation 15:25 < Murch> luke-jr: The point being, that ST tests the assumption "everyone seems to want Taproot", yet you are releasing a client based on that assumption now before testing it 15:26 < luke-jr> Murch: what's the problem? 15:26 < luke-jr> ST doesn't test that either 15:26 < luke-jr> ST tests "do miners want taproot and quick about signalling so?" 15:26 < luke-jr> which is irrelevant 15:26 < Murch> It doesn't rely on the assumption for a smooth outcome though 15:27 < luke-jr> neither does Core+Taproot 15:27 < luke-jr> Core+Taproot is smooth so long as more people want Taproot than don't. 15:27 < luke-jr> (weighed by economic relevance ofc) 15:28 < Murch> Which is exactly what I said, thanks. 15:28 < luke-jr> no 15:28 -!- William [2d57d6ca@45.87.214.202] has joined ##taproot-activation 15:28 < Murch> You're relying on the assumption that Taproot has majority support for it to be a smooth experience 15:28 -!- William is now known as Guest2070 15:28 < Murch> whereas ST is smooth either if Taproot has majority support or doesn't 15:29 -!- Guest2070 [2d57d6ca@45.87.214.202] has quit [Client Quit] 15:29 < luke-jr> Murch: wrong 15:30 < Murch> Smooth being "not inducing a temporary or permanent blockchain fork" 15:30 < shinobious> @Murch: the reality is some % of users will run this, what that % is we will have to see 15:30 < shinobious> and as long as ST is not changed in details to exacerbate anything intentionally, the potential compatability issues here are absurdly unlikely 15:30 < shinobious> this should be compatible in almost all cases with ST, and beyond that, all we're doing is putting a foot down on what will happen eventually 15:31 < shinobious> with plenty of times and options to maintain compatibility with this 15:31 < Murch> shinobious: Right, but what's the point of releasing it now then, if you only start signaling and allowing activation after ST anyway? 15:31 < luke-jr> Murch: that is a false premise 15:32 < luke-jr> and the point of releasing now, is to ensure the economic majority has upgraded before activation 15:32 < luke-jr> it isn't enough for just miners to upgrade 15:32 < queip> can't speak for others, but I notice it often takes really long time to wind up people, movement, to do such things (eg as with segwit uasf), starting very long in advance is nice imo 15:32 < luke-jr> that's true no matter what activation mechanism is used 15:32 < Murch> luke-jr: It's really hard to follow your argument if you just say things like "wrong" and "false" but never actually explain the error in my thinking 15:32 < luke-jr> Murch: I suck at explaining, sorry 15:33 < shinobious> @Murch: to get it dealt with, out there, and have the option available to people who want to take it 15:33 -!- WilliamSantiago [2d57d6ca@45.87.214.202] has joined ##taproot-activation 15:33 < WilliamSantiago> Hi 15:33 < shinobious> my thinking is: 1) optimistically ST drops, both activate in sync, all fine, 2) if it doesn't, there is a line in the sand down the road to deal with 15:34 < shinobious> and not in the sense of rushing like with BIP148, but that line is known to be there, and there is plenty of time to deal with its existence 15:34 < luke-jr> yeah, rushing is dangerous 15:34 < queip> +1 15:34 < queip> (unless you're zerg and really want additional pylons) 15:35 < Murch> queip, luke-jr: Yes, it takes time to get people to upgrade, but why would people upgrade to BCBTFC half a year before it does anything. That seems like a weak incentive. 15:35 < luke-jr> Murch: startheight is Apr 30 15:35 < luke-jr> well, I guess it doesn't do anything even then 15:35 < luke-jr> if people want to wait 6 months , that's fine 15:35 < Murch> does it also lock in any time but only activate in November? 15:35 < luke-jr> some might rather just get it over with sooner 15:36 < luke-jr> Murch: November is earliest activation 15:36 < luke-jr> just like ST 15:36 < Murch> Right, but what happens if it gets activation quorum before then? 15:36 < luke-jr> even if ST's window is over, it won't activate sooner 15:36 < luke-jr> just lock in 15:36 < Murch> thanks 15:36 < WilliamSantiago> makes sense 15:37 < luke-jr> otherwise it'd create a perverse incentive to avoid signalling during ST 15:37 < luke-jr> and signal the next period after ST 15:37 < Murch> So basically before November it is almost equivalent to ST, but after it allows activation in any signaling period and then forces activation upon timeout 15:37 < luke-jr> right 15:37 < queip> Murch: eg because they look at their node once per few months eg on old computer, or have time to review patch etc only on holidays 15:38 -!- Whatsupppp [c1207ff0@193.32.127.240] has quit [Quit: Connection closed] 15:38 -!- phuzzzed [447a04f0@68.122.4.240] has quit [Quit: Connection closed] 15:38 -!- evankaloudis [424432b7@cpe-66-68-50-183.austin.res.rr.com] has joined ##taproot-activation 15:38 < Murch> queip: I've run the bitcoin backend of a company interfacing literally hundreds of Bitcoin businesses, I'm aware of the update patterns ;) 15:38 < Murch> *interfacing with 15:39 < queip> Murch: are they as long in your exp? keep in mind some users are stragglers 15:39 -!- Velocibeaver [43dfc867@67.223.200.103] has quit [Quit: Connection closed] 15:39 -!- evankaloudis [424432b7@cpe-66-68-50-183.austin.res.rr.com] has quit [Client Quit] 15:39 < Murch> yes 15:40 < queip> allright, so that's a reason 15:40 < Murch> We had a fortnightly release, and some clients were on versions older than 3 years… 15:41 < queip> yeap 15:42 < Murch> But frankly, I would not recommend an entity with such an update cycle to run BCBTFC, and they wouldn't 15:42 * jeremyrubin runs BTCBTFD 15:43 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has joined ##taproot-activation 15:43 -!- velaiasan [80c7c90c@128.199.201.12] has quit [Quit: Connection closed] 15:44 < Murch> shinobious: Yeah, makes sense to have it prepped, I guess 15:44 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has quit [Client Quit] 15:44 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has joined ##taproot-activation 15:45 -!- ygrtiugf [6c549a0d@108-84-154-13.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed] 15:45 -!- faketoshi [~quassel@static-198-54-131-123.cust.tzulo.com] has quit [Ping timeout: 246 seconds] 15:46 -!- bcman is now known as faketoshi 15:50 -!- hiro8 [4c440db7@bras-base-maplon2305w-grc-47-76-68-13-183.dsl.bell.ca] has quit [Quit: Ping timeout (120 seconds)] 15:59 < luke-jr> Murch: you'd advise they put their sales in jeopardy? why? 16:02 < Murch> luke-jr: I do understand that we disagree on that point, but I don't think it's clear at this time whether BCBTFC would be run by the economic majority at the ponit of the timeout. 16:03 < Murch> If it is only run by a small part of the network, it would be especially detrimental for people with low familiarity to be stuck on a stale BCBTFC chain-tip 16:03 < Murch> if they were running an old Bitcoin Core, they'd just follow the best chain 16:06 < luke-jr> less detrimental than getting reorg'd around like that 16:06 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 16:07 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation 16:08 < Murch> They'd be fairly susceptible to eclipse attacks or doublespend attacks at that point, especially if they had previously announced their support 16:08 < jeremyrubin> I think important is that none of these clients have wallet support for taproot anyways 16:08 < jeremyrubin> so it's not like they're persoanlly having funds on the line directly 16:08 < Murch> If they were doing it properly they'd be running both clients and shut down operations if there is a split, but again we are talking about people that update their software every few years 16:09 < luke-jr> jeremyrubin: doesn't work like that 16:09 < Murch> jeremyrubin: Not worried about Taproot transactions getting misinterpreted, although receiving from a P2TR input could still be a worry 16:10 < jeremyrubin> it's an argument for just following the most work chain 16:10 < Murch> More worried about someone leveraging the network split to doublespend 16:11 < luke-jr> jeremyrubin: welcome to bcash 16:21 < instagibbs> If it's unclear what economic majority is running exchanges will be cranking up required confirms at a minimum 16:23 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds] 16:24 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 16:26 < instagibbs> And they will likely not be running the "alternative" client. Speaking from experience myself as well. 16:27 -!- stanstandard [~stanstand@ip68-104-2-250.lv.lv.cox.net] has quit [Ping timeout: 260 seconds] 16:28 < instagibbs> It won't come to that I trust. Boring taproot activation is my expectation 16:35 -!- observer123 [5ec62864@94.198.40.100] has joined ##taproot-activation 16:36 -!- observer123 [5ec62864@94.198.40.100] has quit [Client Quit] 16:37 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds] 16:38 -!- shaunapps_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined ##taproot-activation 16:39 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has quit [Quit: Connection closed] 16:41 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 265 seconds] 16:44 -!- faketoshi [~quassel@static-198-54-131-107.cust.tzulo.com] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 16:45 -!- bcman [~quassel@static-198-54-131-107.cust.tzulo.com] has joined ##taproot-activation 16:45 -!- bcman is now known as faketoshi 16:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:46 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 16:48 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds] 16:49 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Ping timeout: 240 seconds] 17:01 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 17:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:30 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 17:41 -!- jesseposner [~jesseposn@2601:645:200:162f:1115:7fb7:49ec:d59b] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:44 -!- jesseposner [~jesseposn@2601:645:200:162f:4d2a:657e:53b7:fb7e] has joined ##taproot-activation 17:53 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 17:56 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:58 -!- peterrizzo_1 [45ce133d@69.206.19.61] has quit [Quit: Connection closed] 18:08 -!- WilliamSantiago2 [2d57d6ca@45.87.214.202] has joined ##taproot-activation 18:10 -!- ethanF [4940e702@c-73-64-231-2.hsd1.pa.comcast.net] has quit [Ping timeout: 240 seconds] 18:10 -!- GV [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has joined ##taproot-activation 18:10 -!- GV is now known as GVac 18:10 -!- dom3333 [c0de86e6@192-222-134-230.qc.cable.ebox.net] has joined ##taproot-activation 18:12 -!- WilliamSantiago [2d57d6ca@45.87.214.202] has quit [Ping timeout: 240 seconds] 18:13 < Murch> +1 18:17 -!- jesseposner [~jesseposn@2601:645:200:162f:4d2a:657e:53b7:fb7e] has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…] 18:25 -!- dom3333 [c0de86e6@192-222-134-230.qc.cable.ebox.net] has quit [Ping timeout: 240 seconds] 18:32 -!- WilliamSantiago2 [2d57d6ca@45.87.214.202] has quit [Quit: Connection closed] 18:33 -!- sk92 [6d3c05f4@cpe-109-60-5-244.st3.cable.xnet.hr] has quit [Ping timeout: 240 seconds] 18:38 -!- Nom4d3 [b362460a@179.98.70.10] has joined ##taproot-activation 18:39 -!- shaunapps_ [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 18:40 -!- jules37 [a027a24c@dyn-160-39-162-76.dyn.columbia.edu] has joined ##taproot-activation 18:42 -!- jules37 [a027a24c@dyn-160-39-162-76.dyn.columbia.edu] has quit [Client Quit] 18:44 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 18:44 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 18:56 -!- jesseposner [~jesseposn@2601:645:200:162f:4d2a:657e:53b7:fb7e] has joined ##taproot-activation 19:05 -!- mips_ [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 19:05 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 19:11 -!- Nom4d3 [b362460a@179.98.70.10] has quit [Quit: Connection closed] 19:16 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 19:17 -!- jesseposner [~jesseposn@2601:645:200:162f:4d2a:657e:53b7:fb7e] has quit [Ping timeout: 258 seconds] 19:20 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 19:22 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 19:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 19:48 -!- V1Technology [49a63c73@c-73-166-60-115.hsd1.tx.comcast.net] has quit [Quit: Connection closed] 19:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 20:23 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 20:26 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 20:41 -!- privateidentity [31c0bbe7@n49-192-187-231.sun4.vic.optusnet.com.au] has quit [Quit: Connection closed] 21:02 -!- commmon [~common@unaffiliated/common] has quit [Remote host closed the connection] 21:02 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation 21:05 -!- Rabbit82 [b9d975d5@185.217.117.213] has joined ##taproot-activation 21:06 -!- Rabbit82 [b9d975d5@185.217.117.213] has quit [Client Quit] 21:06 -!- mips_ [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection] 21:07 -!- mips_ [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation 21:10 -!- tomados [43aec8d4@c-67-174-200-212.hsd1.ca.comcast.net] has joined ##taproot-activation 21:11 < tomados> Hi. I’m here to listen 21:11 -!- tomados [43aec8d4@c-67-174-200-212.hsd1.ca.comcast.net] has quit [Client Quit] 21:14 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection] 21:15 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation 21:21 -!- gggg [4b9e785d@d75-158-120-93.abhsia.telus.net] has joined ##taproot-activation 21:21 -!- gggg [4b9e785d@d75-158-120-93.abhsia.telus.net] has quit [Client Quit] 21:26 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 21:33 -!- jesseposner [~jesseposn@2601:645:200:162f:90c1:a4aa:8084:778b] has joined ##taproot-activation 21:47 -!- pox [~pox@141.226.243.49] has quit [Quit: Textual IRC Client: www.textualapp.com] 21:49 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 21:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:54 -!- stanstandard [~standing@172.58.79.39] has joined ##taproot-activation 22:00 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox] 22:05 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 22:07 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Client Quit] 22:09 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 22:12 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection] 22:13 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 22:24 -!- GVac [4a698cdd@pool-74-105-140-221.nwrknj.fios.verizon.net] has quit [Ping timeout: 240 seconds] 22:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 22:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 22:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 22:34 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 22:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 22:39 -!- lukedashjr is now known as luke-jr 23:32 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation 23:34 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-iknxywtqwegwtadk] has quit [Ping timeout: 245 seconds] 23:34 -!- felixweis [sid154231@gateway/web/irccloud.com/x-hizsttpdglmlqbhs] has quit [Read error: Connection reset by peer] 23:34 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-lygjqreuntjwaahj] has quit [Read error: Connection reset by peer] 23:35 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-aqlohovkfuqlzkiw] has quit [Read error: Connection reset by peer] 23:36 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-pgjznmqnvkisbftf] has joined ##taproot-activation 23:36 -!- felixweis [sid154231@gateway/web/irccloud.com/x-rjfaljpefwtmhbry] has joined ##taproot-activation 23:36 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-zfbwbwxmnnrfwbrk] has joined ##taproot-activation 23:37 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-xnxvcvtpceedkggt] has joined ##taproot-activation 23:44 -!- Izi [51bb4485@133.68.187.81.in-addr.arpa] has joined ##taproot-activation 23:45 -!- Izi [51bb4485@133.68.187.81.in-addr.arpa] has quit [Client Quit] --- Log closed Wed Apr 14 00:00:25 2021