--- Log opened Thu Mar 04 00:00:46 2021 00:28 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has joined ##taproot-activation 00:29 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-nimakvacfthwvsmg] has joined ##taproot-activation 00:29 -!- michaelfolkson2 [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined ##taproot-activation 00:29 -!- glozow_ [sid453516@gateway/web/irccloud.com/x-halahfbtacapjfun] has joined ##taproot-activation 00:29 -!- amiti_ [sid373138@gateway/web/irccloud.com/x-fwysclwpgofmexkv] has joined ##taproot-activation 00:30 -!- Abelian_ [sid2662@gateway/web/irccloud.com/x-aohpwcgvzdqxkchw] has joined ##taproot-activation 00:31 -!- achow101_ [~achow101@unaffiliated/achow101] has joined ##taproot-activation 00:43 -!- Netsplit *.net <-> *.split quits: glozow, amiti, @michaelfolkson, Abelian, brg444, ajonas, achow101 00:43 -!- brg444_ is now known as brg444 00:43 -!- Abelian_ is now known as Abelian 00:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 00:43 -!- glozow_ is now known as glozow 00:43 -!- amiti_ is now known as amiti 01:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 02:18 -!- mode/##taproot-activation [+o michaelfolkson2] by ChanServ 02:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 02:57 -!- belcher_ is now known as belcher 02:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 03:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds] 03:17 -!- michaelfolkson2 is now known as michaelfolkson 03:18 < AaronvanW> what would be the effect (benefits/risks) of an independent flag day UASF effort? (as opposed to an independent mandatory signaling UASF effort.) 03:18 < AaronvanW> I haven't thought about this very long, but I think it might keep the "intolerant minority" incentive for miners to upgrade, but minimize the "brinkmanship" factor? 03:45 < AaronvanW> I guess it would be too big of a risk in that case to send coins to Taproot outputs, because if only a minority of users enforce the upgrade, miners can steal, and UASFers end up on a minority Taproot-enforcing chain after all. 04:54 < belcher> AaronvanW anything is a problem if you dont have enforcement by enough of the economy 04:55 < belcher> an independent flag day thing wouldnt require miners to signal.... not sure that makes any difference 05:02 < AaronvanW> becher: yes. luke-jr's point (iiuc) is that mandatory signaling _would_ make a difference, but I'm still trying to understand why. 05:07 < aj> AaronvanW: if the rules don't activate, and you're the only person running lot=true, your node will stop and you'll discover you're out of consensus immediately, and can fix that. if you have a non-signalled flag day activation, your node will continue, until at some random point in the future, probably when you're asleep or sick or on your honeymoon, someone will mine a block that you think's 05:07 < aj> invalid, and you'll have to try to figure out what went wrong and fix it then. also, you might get tricked into relying on the soft-fork in the meantime (your node reports it activated, you're still in-sync with everyone else), and the reason your honeymoon was interrupted by your node stopping was that someone just stole all your savings because you used an address that was protected by a 05:07 < aj> soft-fork that no one else is enforcing 05:08 < aj> AaronvanW: all of that only matters if running "lot=true" or the unsignalled flag day code is something that only a few people do; if everybody's doing it for a year and a half, neither of those risks are plausible 05:14 < AaronvanW> aj: mandatory signaling means you'd notice if miners aren't on board with your fork. but it tells you nothing about whether the economy is on board with your fork. so, miners could signal support, but then "switch" and steal your coins regardless, and the economy will think it's fine. 05:15 < AaronvanW> I'm not sure the difference is that big, but please point out any potential errors in my thinking. 05:16 < AaronvanW> (the scenario here is one where Core doesn't include a MASF/LOT=false.) 05:25 < aj> AaronvanW: if you're the only one running lot=true (or one of a very small group who's not very aware of what's going on) seems unlikely 90% of hashpower would try to target you. maybe if you were coinbase? 05:26 < aj> AaronvanW: if there's 5% of the market running lot=true and nobody else will enforce the rules at all, then yeah, i think if you're part of that 5% you're probably asking for your coins to be stolen 05:28 < darosior> But right now that % is so small (arguably not even representable :p) i wonder how comes we even consider them to the point of going back to ship a hardcoded consensus change.. 05:29 < belcher> AaronvanW remember fake signalling is possible and has been done many times (like with bip66), so even if miners signal you dont actually know they're on the new rules 05:30 < belcher> signalling only makes sense to tell *economic nodes* when they should start enforcing 05:30 < belcher> its use in a MASF, miners put a signal in their block headers so that all the economic nodes start enforcing at the same time 05:33 < AaronvanW> yep 06:03 -!- jonatack_ [~jon@37.173.203.38] has joined ##taproot-activation 06:09 -!- jonatack_ [~jon@37.173.203.38] has quit [Quit: jonatack_] 06:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation 06:52 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 256 seconds] 06:55 -!- jonatack [~jon@37.173.203.38] has joined ##taproot-activation 07:44 < luke-jr> "if the rules don't activate, and you're the only person running lot=true, your node will stop and you'll discover you're out of consensus immediately, and can fix that." <-- hmm, good point, I think inverted signal breaks this 07:45 < luke-jr> [13:14:58] aj: mandatory signaling means you'd notice if miners aren't on board with your fork. <-- the economy enforcing it means the economy is onboard too 07:46 < AaronvanW> luke-jr: I think you meant to say something else? (your current statement is circular.) 07:53 -!- emzy [~quassel@2a01:4f8:192:628a::83] has quit [Changing host] 07:53 -!- emzy [~quassel@unaffiliated/emzy] has joined ##taproot-activation 07:54 -!- realname192 [~real@37.162.4.110] has joined ##taproot-activation 08:02 -!- realname192 [~real@37.162.4.110] has quit [Quit: Leaving] 08:03 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##taproot-activation 08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection] 08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##taproot-activation 08:35 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 08:41 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 08:48 < copumpkin> not sure if folks are already aware, but there's a small group of users who seem to be trying to start a "movement" they're calling OPFULLRETARD running this patch to turn on taproot unconditionally: https://gist.github.com/nothingmuch/2ef038fd4f4e88dfb75213527648bcd3. Some twitter guy made a stupid logo for it and is putting it in his name, and someone else did it too, and I've been getting frustrated arguing with a reddit 08:48 < copumpkin> thread with a few folks who seem sympathetic to the idea 08:50 < copumpkin> reddit thread: https://www.reddit.com/r/Bitcoin/comments/lx6k73/running_taproot_sick_of_waiting_for_core/ (if you follow the links to twitter you'll find a couple of different users and the stupid logo) 08:51 * copumpkin glares at nothingmuch ;) 08:54 <@michaelfolkson> Anyone is free to run whatever software they want (obviously) at their own risk. Personally I strongly recommend waiting for Core activation release or the UASF (LOT=true) release. This only works with coordination 08:56 < copumpkin> I know. I'm just saying they're trying to make this into "a thing" and the possibility of this attitude becoming more widespread is worth factoring into the overall discussion, is all 08:56 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds] 08:58 < roconnor> just more evidence that even the conservitve act of doing nothing doesn't "avoiding divergent consensus rules on the network". 08:58 <@michaelfolkson> You don't rush out releases if they're not sufficiently reviewed and tested. That goes for Core and a UASF effort 08:59 <@michaelfolkson> But yeah agreed roconnor 08:59 < yanmaani> roconnor: it does, but these guys are not being conservative. 09:00 < roconnor> Sure, but anyone who think that dropping taproot entirely would help save the network from divergent consensus rules is simply wrong. 09:00 < roconnor> I mean Core dropping taproot. 09:01 < roconnor> Not that anyone is quiet suggesting Core do this yet. 09:01 < copumpkin> I think their attitude is just "the devs are arguing over nothing and have been for years, so I'm taking matters into my own hands". I do think it's stupid, but there's several people now on different venues who have chimed in with similar sentiments and I could see it taking root in some corners of the community 09:02 < copumpkin> (I don't have a position on the actual discussion, I'm just frustrated with this new faction emerging :P) 09:02 < belcher> roconnor thats not evidence, because nobody with any economic weight has adopted it 09:03 < roconnor> I don't know. It is some weak evidence. 09:06 < AaronvanW> copumpkin: that sentiment has already taken root in some corners of the community, also see ##uasf 09:06 < yanmaani> copumpkin: If a big exchange does this, then you're gonna see big action. 09:07 < copumpkin> AaronvanW: ah :/ 09:07 < belcher> yanmaani thats a big if 09:07 < copumpkin> AaronvanW: ##uasf seems less hardcore than this patch? 09:07 < yanmaani> So, frankly, I don't get the controversy. Is anyone suggesting that you do LOT=true first? Couldn't you do LOT=false and wait and see? 09:07 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation 09:07 < belcher> yanmaani why would an exchange risk a huge amount of its customer's money, for no benefit, they dont even get lower miner fees from taproot 09:08 < belcher> if you dont get the controversy then maybe you should lurk more and then you'll understand the debate, there are logs in the topic... these meetings were announced on the mailing list weeks in advance 09:09 < yanmaani> belcher: PR reasons? Like, if say Binance does this, and then Taproot "wins", then Binance will go down in history as "the guys who forced taproot". But agreed it's a long shot. 09:09 < belcher> and if their forkclient doesnt work then binance loses an unlimited amount of money (their whole hot wallet for example) 09:09 < AaronvanW> copumpkin: I don't know how you define "hardcore". some (who are also in this chat btw) are pretty serious about it I think. 09:09 < yanmaani> no, i get the controversy because eventually you might have a hard decision down the line. But with >90% of miner support, then... 09:10 < yanmaani> belcher: No, Binance doesn't have to use taproot themselves, just refuse to follow blocks that spend taproot outputs incorrectly. Their loss is just that which comes from being on a non-main chain. 09:10 < belcher> yanmaani and that loss is the possibility of double spends because of the chain split 09:11 < belcher> alternatively they could halt all deposits and withdrawals, though thats basically the mtgox solution, it would piss off all their customers 09:15 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has joined ##taproot-activation 09:17 < maybehuman> I think the sentiment is a bit "this is getting silly" (as displayed by the name choice fullretard) 09:18 < maybehuman> people (on social media at least) seem to fear that this will turn into something like a UN climate conference that talks for twenty years without doing anything 09:19 < maybehuman> I mean I get that you have to be careful with a 1 trillion dollar network, but IMO it's not one trillion because of what it is now, but because of what it could become 09:19 < maybehuman> so stalemate/inaction also endangers it 09:20 < copumpkin> AaronvanW: no signaling at all, just pretending it's been on since genesis, screw compatibility with other nodes? :) that seems "hardcore" to me 09:22 < AaronvanW> copumpkin: I'd consider it really hardcore if they were to actually send their coins to Taproot addresses ;) 09:27 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has quit [Quit: Connection closed] 09:37 < copumpkin> AaronvanW: one of them posted a screenshot of his node syncing :P maybe in a couple of weeks we'll see some lost coins :) 09:51 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation 09:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds] 09:59 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation 10:12 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation 10:20 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-ztdgnajyshrfrcio] has quit [] 10:21 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vbqmiwqebvrkdcvc] has joined ##taproot-activation 10:34 < _andrewtoth_> Can BIP8 be modified to remove the timeout entirely? Or just make it infinite if it's easier to code? BIP8 infinite LOT=none? 10:35 < belcher> what does that achieve? 10:35 < _andrewtoth_> circumvents the LOT debate, gets activation code into core, preserves F7 10:36 < _andrewtoth_> users can begin upgrading. a uasf if miners don't activate will be more effective since the ecosystem is upgraded 10:36 -!- achow101_ is now known as achow101 10:39 < belcher> LOT=true supporters wont be happy because infinite timeout means miners can block taproot 10:39 < belcher> people opposed to MASF wont be happy because it allows for UASF brinksmanship 10:43 < darosior> belcher: hmm UASF code could set a timeout, 2 weeks before which they would force signaling and activate for everyone upgraded 10:43 < darosior> I like this option too 10:43 < belcher> thats just LOT=true isnt it? 10:45 < _andrewtoth_> LOT=true will happen outside of core. By not having any LOT it could be tenable to get that activation code into core. 10:48 < _andrewtoth_> We had consensus on BIP8 activation, so not sure who is still opposed to MASF 10:49 < belcher> Core dev who disagree with brinksmanship will see your plan for what it is, an attempt to get MASF into core so that later you can threaten the network with brinksmanship 10:49 < belcher> bluematt and suhas and a few others 10:49 < _andrewtoth_> the people opposed are opposed because of what could happen on timeout 10:49 < yanmaani> I don't get it why Core can't put in all the different activation methods, and then have the contentious debate be limited to which one is default 10:50 < belcher> no _andrewtoth_, they are opposed because the network would be a mixture of different consensus rules, which could lead to a chainsplit, and that risk can be used for brinksmanship.... theres a strong incentive to because if the brinksmanship is successful then taproot becomes activated 10:51 <@michaelfolkson> _andrewtoth_: BIP 8 could in theory be modified to remove LOT. In practice I don't think there would be consensus to do so. But obviously LOT=false code in Core doesn't need to have any LOT code 10:52 <@michaelfolkson> It is hardly brinksmanship. If Core wants to release LOT=false code it can. If it doesn't want to it doesn't have to release anything 10:53 <@michaelfolkson> It just seems such drama queen 10:56 < AaronvanW> michaelfolkson: the brinkmanship belcher refers to would (and they suspect could) only happen *after* they release Bitcoin Core with LOT=false. Not now. (I'm not sure if that was clear to you?) 10:57 <@michaelfolkson> AaronvanW: But what brinksmanship exists after Core releases LOT=false that supposedly doesn't exist before they release it? 10:58 <@michaelfolkson> AaronvanW: The act of releasing LOT=false suddenly opens the door for brinksmanship? 10:58 < _andrewtoth_> I believe Luke will NACK LOT=false in Core, that's why a LOT=none would circumvent this debate. 10:58 <@michaelfolkson> Luke will NACK everything in Core other than LOT=true which won't happen 10:58 < yanmaani> why can't you just make LOT=xxx settable by RPC command? That way everyone's happy? 10:59 < AaronvanW> michaelfolkson: brinkmanship is technically possible now, but it would be much harder to have an effect without a Core LOT=false release. 10:59 < yanmaani> have LOT=true or false be the default value, but make it settable by RPC. will be slightly unhappy with this, but will be more happy. So it reduces the total animosity. 10:59 <@michaelfolkson> yanmaani: Some people aren't happy with that. They want zero chain split risk (which is unattainable) 11:00 <@michaelfolkson> AaronvanW: Why? Because UASF will be unable to release code if Core doesn't? It makes no sense 11:00 < yanmaani> michaelfolkson: yeah, you'll always make some people unhappy, but it seems like for everyone the ranking is like this: 11:01 -!- jonasschnelli_ is now known as jonasschnelli 11:01 < yanmaani> LOT= && hardcoded > LOT= && configurable > LOT= && configurable > LOT= _andrewtoth_: LOT = none makes no sense. You either have a MUST_SIGNAL period or you don't 11:01 < _andrewtoth_> ok 11:01 < yanmaani> Or would some people say LOT= && hardcoded > LOT= && configurable? 11:02 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection] 11:03 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 11:03 < AaronvanW> michaelfolkson: UASF can release code, but it can't trigger MASF nodes (presumed economic majority), and therefore UASF nodes are more likely to just fork themselves of the main network. they could even have coins in their taproot outputs stolen on the majority chain, because the economic majority isn't enforcing the rules. 11:04 <@michaelfolkson> In July 2022 (or whenever timeout is) 11:04 < AaronvanW> yes 11:04 <@michaelfolkson> You proposing we wait until July 2022 after the UASF has failed before Core releases something? 11:05 <@michaelfolkson> That's a long wait to avoid this supposed "brinksmanship" 11:06 < AaronvanW> I'm not proposing, just trying to understand and explain myself. 11:06 <@michaelfolkson> But Core is perfectly in its rights to release nothing 11:06 < AaronvanW> right 11:06 < belcher> "ossification will continue until morale improves" :p 11:07 < belcher> this could last a lot longer than we think, the block size debates went on for ~2 years 11:07 < AaronvanW> yes 11:07 < yanmaani> Isn't LOT=false preferable then? Do LOT=false, and LOT=true iff it fails. 11:08 < belcher> LOT=false opens the door to brinksmanship threats of a chain split 11:08 < _andrewtoth_> yanmaani yes that would be ideal 11:09 < roconnor> A short LOT=false wouldn't. 11:09 < _andrewtoth_> belcher how does it open the door to that? there is consensus that if LOT=false doesn't activate users will run LOT=true no? 11:09 < _andrewtoth_> so anyone running LOT=true is brinksmanship? 11:10 < AaronvanW> but fwiw michaelfolkson, "You proposing we wait until July 2022 after the UASF has failed before Core releases something?" <- I don't consider this an entirely unlikely scenario 11:12 <@michaelfolkson> AaronvanW: Maybe. If that happens we need some big take up of the UASF client to get it activated before then 11:12 < roconnor> BIP8 LOT=false running for 3 months is too short of a period for brinkmanship, but long enough to likely activate taproot. 11:14 <@michaelfolkson> Core could do a BIP 8 (3 month, LOT=false) in parallel with a UASF BIP 8 (1 year, LOT=true) if they chose to 11:15 <@michaelfolkson> The consensus in the IRC meetings was to do BIP 8(1 year) so that's what we're planning with the UASF 11:17 < roconnor> I know that the consenus in the meetings was 1-year, but I suspect people won't be opposed to 3-months. 11:18 < roconnor> to start. 11:19 < _andrewtoth_> roconnor that's to derisk a successful uasf or brinksmanship? other nodes would timeout before a uasf could gain traction? 11:20 < roconnor> yes. More specifically to get those people who are concerned about brinksmanship on board with something I believe they would find acceptable. 11:20 <@michaelfolkson> Personally I wouldn't NACK the lot=false, 3 months in Core but I'm pretty sure Luke would. 11:21 <@michaelfolkson> It needs to be compatible with the UASF release (ideally) though 11:21 < roconnor> I think concurrently we should also do a flag day deployment. 11:22 < roconnor> I think both such PR should be accepted, but I'll be happy if at least one is. 11:23 < _andrewtoth_> roconnor i read your mailing list post fully agree 11:24 <@michaelfolkson> The flag deployment wouldn't be compatible with a BIP 8 (lot=false) or BIP 8(lot=true) 11:24 < roconnor> I mean, it wouldn't be incompatible. 11:25 <@michaelfolkson> Well a BIP 8 client wouldn't activate Taproot on the flag day. And it might activate it before the flag day 11:25 <@michaelfolkson> So yeah they're incompatible 11:26 < roconnor> A inactivate client is compatble with taproot. 11:26 < roconnor> plus I'm suggesting they be in both clients. 11:26 < roconnor> I mean both in the same client. 11:26 <@michaelfolkson> I just think this level of complexity isn't helpful :) It doesn't come with any benefits 11:27 < roconnor> it's not complex. 11:27 <@michaelfolkson> If you don't like a flag day do BIP 8. If you don't like BIP 8 do a flag day. A mixture of both is just becoming Frankenstein for no reason 11:27 < roconnor> it's not a frankenstein. 11:28 <@michaelfolkson> BIP 8 (lot=true) activates at the end. So why do you need a flag day? 11:29 < roconnor> to get people concerned about brinkmanship over the MUST_SIGNAL phase on board. 11:29 <@michaelfolkson> You can always create Frankenstein to keep people happy about bizarre concerns 11:29 <@michaelfolkson> I don't think it makes any sense to 11:31 < roconnor> It's not a frankenstein. 11:32 < roconnor> I'm not putting forward a proposal that I think is best. I'm putting forward a proposal that I believe will address all the concerns that I've heard and would be at least acceptable to everone, regardless of the merits I have about those various concerns. 11:33 <@michaelfolkson> A compatible BIP 8 (false, 3 months) avoids the so called "brinksmanship". A lot=true won't get merged and I don't think a flag day will either regardless of the existence of a UASF or not 11:33 <@michaelfolkson> But a mix and match of BIP 8 and flag days is the worst of all worlds 11:33 <@michaelfolkson> It makes no sense 11:34 < devrandom> (I just brought up a similar topic on ##uasf) 11:34 < devrandom> moving that here... 11:34 < roconnor> I'm unsure if a flag day would get merged either, but it can be pursued concurrently. 11:34 <@michaelfolkson> It wouldn't be compatible with a BIP 8 but sure it can be pursued 11:34 < devrandom> seems like BIP8(false) + flag-day that end on the same height are compatible 11:35 < roconnor> the merger of BIP8(3month,false) and a flag day appears to me to be less complicated that adding the MUST_SIGNAL state required for LOT=true. 11:35 < roconnor> but again, these PRs can be pursed independenly. 11:35 <@michaelfolkson> devrandom: They're not. The BIP 8(false) could activate in the first two weeks. The flag day wouldn't 11:35 < roconnor> I think merging one with the other won't be very hard. 11:36 < devrandom> I'm talking about doing both in the same client right now 11:36 <@michaelfolkson> But if you want it to activate at the end set lot to true. What do you need a flag day for? 11:36 < devrandom> politics 11:36 <@michaelfolkson> This really is nonsense (no offence) 11:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 11:37 < devrandom> I can see that it's not objectively the best thing, but if it doesn't increase risk and everybody can live with it, then it seems good enough 11:37 <@michaelfolkson> It is nonsense. But if Core wants to merge nonsense it can 11:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 11:38 < roconnor> while I htikn BIP8(3month, false) and a flag day should both be accepted, they are *not* a package deal. 11:38 < yanmaani> Why does Core have to merge *anything*?? 11:38 <@michaelfolkson> It doesn't 11:38 < yanmaani> Why can't Core just merge all the code, and then let users configure via RPC commands if they want LOT=true,false,green,purple,3.141592 11:39 < yanmaani> This keeps Core's exercise of "developer power" to a minimum. 11:39 <@michaelfolkson> It will get NACKs. Encouraging chain split and the like 11:39 <@michaelfolkson> But in theory it can 11:40 < devrandom> roconnor: would there be a preferred ordering to those two things merged? 11:40 < roconnor> devrandom: I think they can go in either order. 11:40 < yanmaani> michaelfolkson: If people go away from the defaults, that's on them 11:41 < roconnor> we can even have a full client release between either one. 11:42 < devrandom> I don't see downsides to that, and it parallelizes effort 11:42 < devrandom> roconnor: what's the advantage of a 3 month BIP8(false) over one that matches the timeoutheight of the flag day? 11:43 < devrandom> just so we can have news ideas after we see miner behavior? 11:43 < _andrewtoth_> ok let's just go with it 11:44 < brg444> there are an infinite number of activation methods that would get us taproot within 3 months if Core was to stop tergiversating 11:44 < roconnor> devrandom: some people are concerend over brinkmanship, but a 3month signaling period is too short to engange in brinkmanship. 11:44 < roconnor> however it is long enough to likely get taproot activated. 11:45 < devrandom> got it 11:45 < roconnor> But yes, we also get to see boht miner and user behaviour after a short period. 11:50 < AaronvanW> michaelfolkson: "But if you want it to activate at the end set lot to true. What do you need a flag day for?" <- isn't the opposite equally true? -> But if you want it to activate at the end set a flag day. What do you need LOT=true (mandatory signaling) for? 11:53 < AaronvanW> the benefit of a simple flag day is that lazy miners won't create a fork. they'd mine Taproot-valid blocks, except if they're mining on top of a previous invalid block, but that would at least require malicious behavior from some miner, not just lazy behavior. 11:54 < AaronvanW> (and even that potential malicious behavior could be countered fairly easily by running -- what I think was called -- "border nodes" to filter traffic to your own mining node. 11:56 < devrandom> I suppose it gives a bit of assurance to SPV nodes that miners are protecting them 11:56 < AaronvanW> michaelfolkson also see the paragraphs under BIP149 here: https://bitcoinmagazine.com/technical/bip-148-and-bip-149-two-uasfs-activate-segwit 12:15 <@michaelfolkson> AaronvanW: Yeah if they are that determined to ship a flag day and ignore the discussions and meetings of the previous weeks and months, sure go for it 12:16 <@michaelfolkson> And be incompatible with a UASF BIP 8 of course 12:17 <@michaelfolkson> Why did so many Core contributors show up to those activation meetings and express their view? They shouldn't have bothered 12:17 < AaronvanW> well I hope we agree that the best idea should be used, even if was only proposed late in the process. (I agree it wasn't helpful that some people with strong opinions didn't join the meetings :/ ) 12:18 <@michaelfolkson> It isn't the best idea. That's what people at the meetings decided 12:18 <@michaelfolkson> It violates F7 12:20 < luke-jr> AaronvanW: without signalling there are many problems 12:20 <@michaelfolkson> Tbh we are just playing ego games at this stage. For anybody who was interested we've had the weeks and months of discussion. If people want to play ego games and ignore that process so they can be the "ivory tower savior" I can't do anything 12:20 < luke-jr> as I've explained over and over 12:21 < AaronvanW> I'm not saying it's the best idea per se (although I think it might be), just that we should in the end use the best idea, even if it wasn't discussed at the meetings initially. 12:21 < luke-jr> AaronvanW: the best idea could become not-the-best after we start down another path 12:21 < AaronvanW> Yeah F7 is the main argument against any flag day in Core, I agree with that as well. 12:21 < maaku> AaronvanW: when it comes to activation parameters, using the best idea isn't really necessary 12:21 < luke-jr> ie, changing direction once we've started makes it worse 12:21 < maaku> it's transitory. once activated it doesn't really matter what activation parameters were 12:21 < luke-jr> keeping in mind we can always improve for future softforks 12:22 < maaku> it just has to be a not-completely-objectionable/dangerous choice 12:23 < AaronvanW> maaku: sure. I just think "it wasn't discussed at the meetings" is in itself really a compelling argument against a specific proposal. 12:24 < AaronvanW> *don't think 12:24 < maaku> AaronvanW: if we have 3 reasonable options that were discussed at the meeting, any of which would be fine, then bringing up a 4th is not helpful 12:25 < maaku> even if it were objectively slightly better 12:25 <@michaelfolkson> (which it isn't) 12:25 < maaku> yes, hypothetically better 12:26 < luke-jr> maaku: we got it down to 2 at the meeting ;.; 12:26 <@michaelfolkson> I guess I have to do this for a few days to massage some people's egos but it is pretty damn infuriating. 12:26 < luke-jr> well, only 1 was reasonable imo 12:27 < luke-jr> michaelfolkson: do "this"? 12:27 < belcher> maaku we dont have 3 reasonable options, we dont really have any reasonable options that everyone agrees to 12:27 <@michaelfolkson> Engage in all this brinksmanship and politics nonsense 12:29 < luke-jr> belcher: everyone doesn't need to agree 12:29 < maaku> belcher: you missed my point 12:31 < belcher> luke-jr the most of the economy needs to update to a new node software for the soft fork to be successful, so yeah many people need to agree or at least be neutral 12:31 < maaku> activations parameters aren't long-lived consensus rules, so they shouldn't require the same standard for unanimous approval 12:32 < AaronvanW> maaku: I think it's helpful if it can break the impasse. MASF + flag day (without forced activation) seems (or seemed) like something most people might be willing to agree on, since it satisfies many needs and concerns. if it doesn't break the impasse, it doesn't, but then we're still at an impasse. 12:32 <@michaelfolkson> belcher: By July 2022 (or later) yes 12:32 < maaku> pretty much any proposed bip8 setting would be acceptable, in the sense that it is unlikely to lead to network splits 12:32 < luke-jr> belcher: many people already agree on LOT=true 12:33 < belcher> luke-jr but many people disagree 12:33 < luke-jr> belcher: no, just an irrelevant minority 12:33 < brg444> maaku: +1. anyone comparing this to "emergent consensus" or user-configurable supply limit is beyond silly 12:33 < belcher> you are trolling 12:33 < luke-jr> (irrelevant due to size, not commenting on the people) 12:33 < belcher> maaku i agree, thats the tragic thing really 12:33 <@michaelfolkson> You are trolling too belcher imo. If it was up to you we would have another 5 years of circular discussion 12:34 <@michaelfolkson> Until this magical 100 percent emerged 12:34 < belcher> michaelfolkson do you think im intentionally blocking taproot? 12:34 < mol_> luke-jr, do you have your bitcoin client with "LOT=true"? 12:34 <@michaelfolkson> belcher: I don't know how you can see that the only thing you are achieving is delay 12:34 < luke-jr> mol_: the code isn't even merged yet 12:34 <@michaelfolkson> how you *can't 12:35 < belcher> michaelfolkson it takes two to tango, from my point of view its luke-jr and brg444 who are causing the delay 12:35 <@michaelfolkson> What do you think is going to happen in 6 months, 12 months, 18 months? 12:35 < luke-jr> belcher: and this is why I ignore you 12:35 < belcher> basically everyone was happy with LOT=false until they said "we'll run LOT=true regardless" 12:35 < maaku> the NACK-anything-that-isn't-my-preffered-activation-parameters stance nearly everyone seems to have is ridiculous. find another hill to die on. :shrug: 12:35 < belcher> then it all broke down 12:35 <@michaelfolkson> We'll have a hallelujah moment? 12:35 < luke-jr> maaku: I've tried to find a compromise with Matt at least 12:35 <@michaelfolkson> It has not broke down. I'm perfectly happy with the UASF plan 12:35 < belcher> well go for it, im not stopping you, its just obvious to me that it wont succeed 12:36 < belcher> you'll activate it just for yourselves, not for the whole of bitcoin 12:36 < mol_> luke-jr, i'm wondering... If you have Knots ready with "LOT=true", just put it out there and make announcements everywhere, let's see if users will adopt it then we know if the majority agrees to it? 12:36 <@michaelfolkson> belcher: We'll see by the time July 2022 swings around 12:37 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 12:37 <@michaelfolkson> belcher: Some people have got better things to do than engage in years of circular arguments 12:37 < belcher> michaelfolkson dont shoot the messanger 12:38 <@michaelfolkson> If you're speaking for someone else feel free to announce that. If you don't I'll assume you're speaking for yourself 12:38 < roconnor> BIP8(3months, false) doesn't have the brinkmanship concerns that BIP(1year, false) has. 12:38 < brg444> belcher: before we even got to put the bitcoinactivation repo up a bunch of users from reddit, to clubhouse, to twitter were going to "run LOT=true regardless" 12:38 < mol_> guys.. we are in this together, please tone down your voice and calm yourself down 12:38 < brg444> if we didn't get a sense that there would be some support for this we wouldn't have bothered 12:38 < belcher> brg444 interesting, so the divisions actually existed long before 12:39 < belcher> tbh ever since i thought segwit-via-UASF was a one-off, i didnt want every soft fork to be like that... now i realize some of you wanted evrey soft fork to go like segwit? 12:39 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed] 12:39 < belcher> ever since 2017* 12:40 < belcher> roconnor why doesnt 3 months suffer from brinksmanship when 1year does? 3 months is still enough time to do forced signalling, especially since the 3 months is actually measured in block heights so can be much longer if the hashrate drops 12:40 <@michaelfolkson> Ok time to mute this channel. Laying out a plan for a MUST_SIGNAL in second half of 2022 is same as SegWit? It is utter nonsense 12:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds] 12:41 < belcher> michaelfolkson a bit of humility wouldnt hurt you, you werent around in 2015-2017 afaik 12:41 < roconnor> belcher: UASF requires time for a super majorty of economic nodes to upgrade. 3 months isn't enough time to do that safely. 12:41 -!- lukedashjr is now known as luke-jr 12:41 < luke-jr> mol_: I can't do that anymore 12:41 < belcher> its not utter nonsense, whats of the point of talking to you if you take everything as aggressive? 12:41 < luke-jr> mol_: ##uasf has thrown startheight into question 12:41 < luke-jr> maaku: https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkejqt/ 12:41 <@michaelfolkson> belcher: Some people are just desperate to replay it it appears 12:41 <@michaelfolkson> belcher: While concern trolling about avoiding it 12:42 < belcher> michaelfolkson yeah, from my point of view its the UASFers, its almost as if they want to fight against something, anything 12:42 <@michaelfolkson> But you're free to do that, enjoy 12:42 < luke-jr> roconnor: just every other problem 12:42 < roconnor> luke-jr: It is only for 3 months. 12:42 < belcher> everything was going great with 90% of hashrate ready and willing to activate, then UASFs said they'd go for a mixture of consensus rules in the economy which made the whole thing unsafe 12:43 < roconnor> luke-jr: Even if you are sure it will fail, it is almost harmless. 12:43 < belcher> with the "miners have no control" circlejerk 12:43 < luke-jr> roconnor: a supermajority needs to upgrade before a MASF 12:43 < luke-jr> belcher: you're the one fighting 12:43 < nickler> roconnor: 3 months is very short; it takes a long time for users to adopt new versions of bitcoin core. Perhaps works if you set startheight far enough in the future, but then there's also opportunity to brinkman. 12:43 < roconnor> luke-jr: right, which is why we need an extended LOCKIN period afterwards. 12:44 < roconnor> Just need an extend LOCKIN period. 12:45 < darosior> belcher: +1 12:46 < maaku> belcher: I don't think that's a very charitable view of UASF advocates 12:46 < darosior> luke-jr: "belcher: you're the one fighting" but you are the one that started discord by trying to force an UASF once you saw the majority just wanted to move forward with LOT=false, which made everyone take a step back as prevention.. 12:46 < maaku> I think they see themselves as setting a flag day activation, precisely so that the community can cut past any lingering bs and constructively work towards safe activation 12:47 < maaku> it does help to set a firm deadline 12:48 < belcher> maaku safe activation requires almost everyone to agree, their unilateral actions of trying to push an alt-client just makes people more entrenched, their methods are to ignore everyone else and go ahead anyway... thats not the way to build agreement 12:49 < maaku> belcher: that's doesn't reflect what most uasf people are actually saying 12:49 < belcher> i think it does, i seem them saying "we'll just ignore the concerns of some people and go ahead with our own client" 12:49 < belcher> maybe im wrong, but thats the impression i get 12:49 < darosior> Do we know that any user with actual transaction processing is actually going to use their client ? Otherwise we could just go back to moving forward.. 12:49 < belcher> not just from this channel, but also slack and twitter 12:50 < AaronvanW> michaelfolkson: you're free to try a UASF, I don't think anyone wants to stop you, nor can anyone stop you. however, I personally do think it's unlikely to succeed, and you might instead end up wasting a lot of time and effort, perhaps even causing some Taproot delay in the progress. it would benefit everyone if there was another (potentially faster) path to taproot, and some think there is. (but like I said, if you d 12:50 < AaronvanW> on't think there is, you ARE free to try UASF.) 12:50 < maaku> belcher: I suggest not assessing a position based on what's trending on twitter. 12:51 <@michaelfolkson> AaronvanW: Let's catch up in July 2022 and we'll see if it has or not 12:51 < AaronvanW> ok 12:51 < maaku> I was involved in UASF in 2017. I uninvolved but watching UASF this time around. That doesn't to me reflect what usaf proponents actually believe. 12:52 < mol_> the UASF in 2017 was very different, we were at the different time with many different players and some of the big players aren't in the ecosystem this time afaik 12:53 < mol_> like Jihan, afaik, he's gone 12:53 < belcher> maaku so here's an example of what i mean (https://www.reddit.com/r/Bitcoin/comments/lrfm5b/lottrue_or_lotfalse_this_is_the_last_hurdle/gorjtwh/?context=1) , on reddit i talked about a concern posted by someone on the mailing list and brg444 comes in with a statement suggesting we just ignore those concerns 12:54 < belcher> brg444 isnt a twitter sockpuppet or sybil or someone who makes fake trends, iv known him online for years 12:54 < belcher> soon after that brg444 started the UASF alt-client github thing 12:54 < AaronvanW> yeah I mentioned this in ##uasf, BIP148 happened in the middle of a perfect storm. block size wars had been going on for years, NYA, covert AsicBoost scandal, Jihan acting like a villain on social media, MASF nodes widely deployed, fees rising while segwit would enable lightning, etc. It was a very different time. 12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in] 12:55 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##taproot-activation 12:56 < roconnor> TBH I'm pretty skeptical of a MAST activation, which is why I'd also like to see a flag day. But BIP8(3month, false) is so short, why not just do it. Worst that happens is it fails. 12:56 < maaku> belcher: I'm not sure what you're expecting me read into a one-sentience sarcastic comment on reddit... 12:56 < aj> roconnor: MASF ? 12:56 < belcher> maaku its one bit of evidence for my view that the UASF 2021 crowd is not driven by consensus-building 12:56 < roconnor> *LOL* 12:56 < roconnor> yes MASF. 12:56 < aj> roconnor: (why are you skeptical?) 12:57 < roconnor> Um there was a quote from Bitmain last year, which I recongize we some time ago. I'd have to dig it up. 12:57 < roconnor> *was some time ago. 12:57 < roconnor> but also other people assure me that it will be fine. 12:58 < maaku> belcher: he's replying to a comment in which you directly said UASF proponents are or are risk of becomming "circlejerky and irrational" 12:59 < aj> roconnor: news to me, would be interested in a url or best effort misquote 13:00 < belcher> if i did cause offence to them, thats still not a good enough reason to ignore the concerns of some core developer on the mailing list 13:01 < roconnor> aj: I'll see what I can do. 13:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 13:08 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 13:09 -!- belcher_ is now known as belcher 13:23 -!- Guest74062 is now known as pigeons 13:53 < luke-jr> darosior: the majority always favoured LOT=true 13:57 < belcher> luke-jr https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c prefer LOT=false first is 17, prefer LOT=true first is 14 13:57 < belcher> actually this other table with second preferences taken into account has LOT=false being 24, and LOT=true being 18 13:58 < luke-jr> belcher: that's just at that meeting 14:02 < achow101> the wiki I think has a slightly more updated table 14:03 < luke-jr> hi achow101 14:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 14:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds] 15:03 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 256 seconds] 15:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 15:15 -!- jonatack [~jon@37.173.203.38] has joined ##taproot-activation 15:28 -!- cguida [~cguida@2806:2f0:5020:433a:1fe9:7c7b:dd55:7e3b] has joined ##taproot-activation 15:34 -!- cguida [~cguida@2806:2f0:5020:433a:1fe9:7c7b:dd55:7e3b] has quit [Ping timeout: 258 seconds] 15:48 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##taproot-activation 15:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 260 seconds] 15:59 -!- jonatack [~jon@37.173.203.38] has joined ##taproot-activation 16:08 < Emcy> luke-jr i initially reflexively supported lot=true, having remembered what happened with the UASF in 2017 [i ran a bip148 node actually, i was one of ~1200 or so], but since then ive listened to some arguments against it and in particular the fact that there isnt any indication right now that any miners intend to or have reason not to signal for taproot/try to block it 16:09 < Emcy> and in fact 90% of them by hashrate already appear to support it 16:10 < Emcy> so now im lot=false......dont you think that rolling out the big guns at this juncture when theres nothing obvious to shoot is a little needlessly antagonistic? 16:11 <@michaelfolkson> Hey Emcy. I can't speak for Luke but I hope you have a BIP 8 (LOT=false) release to run if that's your preference. I'm not sure at this stage whether there will be one. 16:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 16:13 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Ping timeout: 245 seconds] 16:14 <@michaelfolkson> If Taproot hasn't activated by July 2022 you may be happy there is a LOT=true release to run 16:14 < Emcy> michaelfolkson why wouldnt there be? do you think people would just throw their hands up and give up if enough miners to cause problems did decide to be difficult? 16:15 <@michaelfolkson> Emcy: The problem at least at this point seems to be Core developer consensus rather than miners causing an issue 16:15 < luke-jr> Emcy: there are no "big guns" in LOT=True 16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 16:15 < Emcy> again theres no obvious reason they would be at this point. Remember last time the UASF only happened because of two factors that are no longer in play: jihan was being a bitch over losing his asicboost hack, and that he controlled enough hashpower to get his way. those things are not true anymore 16:15 < luke-jr> Emcy: LOT=True is just a properly working system 16:15 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-krmriswaghdawevi] has quit [Ping timeout: 246 seconds] 16:15 < luke-jr> Emcy: and that situation works out smoothly with LOT=True 16:16 < Emcy> luke-jr its antagonistic. Its indicating that we expect trouble with this, when theres no reason to at this moment. 16:17 < luke-jr> no, it isn't 16:17 < Emcy> did you consider that we might end up accidentally creating the kind of opposition you seem to fear? 16:17 < roconnor> It's more important to think about what sort of activations methods are acceptable rather than what is better than another. In that sense it is okay to find both LOT=true and LOT=false acceptable. 16:17 < luke-jr> Emcy: that's FUD 16:17 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation 16:17 < luke-jr> it's not antagonistic to simply not give someone a backdoor 16:17 < Emcy> i dont think it is fud. its basic monkey psychology. 16:18 < luke-jr> Emcy: the misrepresentation of LOT=True as "big guns" and "antagonistic" is FUD 16:18 < Emcy> jihan was bitcoins enemy, but 'the miners' are not 16:18 <@michaelfolkson> We're speaking to mining pools and although their preference is LOT=false currently, one has already said they are fine with LOT=true 16:18 < luke-jr> fine, then they should be okay with not getting a backdoor 16:19 < Emcy> luke-jr ok well im telling you that im not fudding, forgive my terms 16:19 < luke-jr> if miners have a problem with not adding a backdoor, they are "Jihan" 16:19 < Emcy> im not one important but you know ive been around since the beginning right 16:19 < luke-jr> Emcy: this is comparable to adding the inflation bug back in because we can trust miners not to use it 16:19 < luke-jr> LOT=False is* 16:20 < Emcy> its not about trusting miners. we dont have to trust them ever again. 16:20 < Emcy> bitcoin is not a system where you trust third parties 16:20 < luke-jr> LOT=False is adding a backdoor that you're saying is okay because we can trust them.. 16:20 < Emcy> we DID learn a lesson from 2017, it wont happen again either way. The worst they can do is delay taproot this time 16:21 < luke-jr> did we? LOT=True is the lesson we learned. 16:21 < luke-jr> LOT=False IS the same thing again 16:21 < roconnor> with BIP8(3m,false) + flag day, they cannot delay us at all. 16:22 < Emcy> whats the rush though luke? 16:22 <@michaelfolkson> BIP 8(3m, false) + flag day versus BIP 8 (flag day, true) 16:22 < luke-jr> Emcy: what rush? it's 2022 16:23 < Emcy> thats next year 16:23 < luke-jr> Emcy: my point exactly 16:23 < Emcy> why risk having a chainsplit for any prize with a time horison of only a year out 16:24 < Emcy> taproot could have been activated 2 years ago 16:24 < luke-jr> Emcy: LOT=False risks a chain split. LOT=True does not. 16:24 <@michaelfolkson> When would you say the risk of a chain split is acceptable? 2 years? 3 years? 10 years? 16:24 < Emcy> its no one fault that it wasnt other than the bitcoin communities. So i dont understand the sudden rush at this point. 16:24 < roconnor> I find both BIP(3m, false) + flag day and BIP8(flag day, true) accpetable. 16:24 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-iujwpawuwmlqcsdg] has joined ##taproot-activation 16:24 < luke-jr> Emcy: there has been a rush for a long time now 16:25 < roconnor> again, we don't need to compare activation methods against each other. We just need to find an intersection of acceptable methods. 16:25 < luke-jr> but 2022 is not rushed 16:25 < luke-jr> roconnor: anything without a signal is not acceptable 16:25 < Emcy> michaelfolkson the risk of a sustained chainsplit in bitcoin is unacceptable in just about any circumstances imo 16:25 < roconnor> luke-jr: so no flag day? 16:25 < roconnor> not even with witness signalling? 16:25 < Emcy> were trying to build a system that will outlive us all are we not? 16:26 <@michaelfolkson> Emcy: So never ever a LOT=true under any circumstances. We can only get soft fork activated if miners are willing to signal? 16:26 < luke-jr> roconnor: not absent a signal ("flag day" could just as well mean LOT=True) 16:27 < luke-jr> roconnor: witness signalling is meaningless in the UASF scenario (and I suspect in the MASF scenario too) 16:27 <@michaelfolkson> Emcy: Why did you support the UASF in 2017? (I'm presuming you did) 16:27 < Emcy> yeah i did. perhaps i just didnt think it through. 16:27 <@michaelfolkson> Ha 16:28 < belcher> Emcy wouldnt you go for LOT=true if the miners ended up blocking taproot for stupid reasons? 16:28 < Emcy> i would, but only if the rest of the community was mega pissed off with the miners too, which i expect they would be 16:29 < belcher> for example, one pool says they wont activate taproot because chainalysis told them not to... that would create a pissed-off-enough community wouldnt it 16:29 < Emcy> that way there wouldnt be a chainsplit in that case either. Miners have more incentive than anyone no to fork off onto their own chain, theyre balls deep in sunk costs and opex 16:29 <@michaelfolkson> Emcy: What if the community was mega p***ed off with developers for spending years to release activation code? Same deal or no? 16:30 < Emcy> belcher i would personally be fuming if a pool witheld and cited chainalysis, wouldnt you 16:30 < belcher> yup 16:30 < belcher> everyone would 16:31 < Emcy> michaelfolkson i see that as a lot less likely 16:31 < Emcy> like i said, if the community was really in that much of a rush this could have been done 2 years ago already 16:31 < yanmaani> if they did, chainalysis would probably begin to see some business disruption as big players start putting the incentives 16:31 < rusty> I would LOT=true (activating at last possible moment) if we hit 6 months with no good reason for not activating. This would include signalling for it in all media, ofc. But then it came time without being activated, I'd suspend economic activity around fork time, too. 16:31 <@michaelfolkson> Emcy: I wish I shared your confidence 16:31 < luke-jr> Emcy: again, LOT=True has a lower risk of chain split than LOT=False 16:32 < Emcy> can you explain how? 16:32 < yanmaani> luke-jr: Doesn't that depend on what you think people will do? 16:32 < luke-jr> Emcy: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html 16:32 < roconnor> Again, not important which methods are better than others. Just a question of which methods are acceptable. 16:32 <@michaelfolkson> rusty: If there was a LOT=true and a LOT=false client to choose from you would run the LOT=false client for 6 months and then switch to the LOT=true client? 16:32 < luke-jr> yanmaani: not really; all the other scenarios are also safer with LOT=True 16:32 < rusty> michaelfolkson: yes. 16:32 < belcher> roconnor acceptable to me is LOT=false, LOT=true and flag day... provided enough of everyone else also follows one of those 16:33 < luke-jr> rusty: why? 16:33 <@michaelfolkson> rusty: What if there was only a LOT=true client? No LOT=false client was released? Would you run the LOT=true client for the whole year? 16:33 < rusty> luke-jr: se my comment about "with no good reason for not activating". 16:33 < yanmaani> luke-jr: With LOT=true, if you're on the minority, you'll have a chainsplit. With LOT=false, if you're on the minority, you won't. 16:33 < luke-jr> yanmaani: wrong 16:33 < yanmaani> With LOT=false, you'll only get a chainsplit if (1) other people run LOT=true and (2) Taproot loses 16:34 <@michaelfolkson> rusty: I suspect you'd run an old version with no activation parameters and then LOT=true for the last 6 months (if no LOT=false client existed) 16:34 <@michaelfolkson> (From your answer) 16:34 < luke-jr> michaelfolkson: that wouldn't be logical 16:34 < luke-jr> LOT=True/False are identical for most of the duration; pre-Taproot isn't 16:35 <@michaelfolkson> Rusty said he wouldn't want to run LOT=true for first 6 months 16:35 < yanmaani> luke-jr: How is it wrong? LOT=false will bend to the will of the majority, as I see it. Is your concern that LOT=false would cause people to run LOT=true, but to be doomed to failure? 16:35 < luke-jr> LOT=False is essnetially just downgrading if you reach the end without MASF 16:35 < rusty> michaelfolkson: Yeah, or hack it in if I wanted other features. I strongly believe that we are approaching an ideal model: devs don't activate but provide users with tools for UASF, miners activate, users override. 16:35 <@michaelfolkson> I'm just trying to understand what he would do 16:35 < luke-jr> yanmaani: I linked my ML writeup on it. 16:35 <@michaelfolkson> rusty: Right, makes sense 16:36 < rusty> I really like the idea of activist users (though I expect that this time they'll be unnecessary), and I think enshrining their power explicitly in the process means it's more likely to be robust in practice. 16:37 -!- Aaronvan_ is now known as AaronvanW 16:37 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation 16:37 < belcher> rusty one problem with activist users for taproot is that most users really dont care... taproot doesnt affect them unless they maybe use multisig, its good because it enables new stuff that doesnt exist before 16:38 < yanmaani> luke-jr: yeah, I saw this. Hmm, your argument about upgrading to LOT=true is very convincing. 16:38 < belcher> i bet if you asked the exchanges they'd just shrug and say taproot doesnt make much difference to them 16:38 < roconnor> rusty: Do you think "adding tools for UASF" would pass core review? 16:38 <@michaelfolkson> Ha 16:38 < yanmaani> Basically, if you'd be doing LOT=false first and "only doing LOT=true if the miners object", that's functionally equivalent to doing LOT=true all the time. 16:39 < yanmaani> "I'll force you, but only if you say no" is basically equivalent to saying "I'll force you (unconditionally)". 16:40 < Emcy> rusty i might do the same as you, except id give it at least a year i think 16:40 < Emcy> after that if its not activated via signalling and theres no obvious reason why not, steps can be taken to override miner signalling 16:40 < yanmaani> In other words, if you do not wish for miners to be able to object, always going LOT=true is the only sensible choice. If you do wish for miners to be able to object, LOT=false is, but that does not seem to be a desideratum. 16:41 < rusty> belcher: any mechanism which is more inclusive risks people making the "wrong" choices, or apathy. But I don't think it's healthy for the long-term to protect users from these decisions, so we kind of have to do it anyway IMHO? 16:42 < belcher> rusty we dont have to, we could have Core release a LOT=true or flag day 16:42 < rusty> yanmaani: not at all. See my " no good reason: caveat. 16:42 < belcher> users still have control, because if they disagree they can run an alt-client which _requires_ that the first block after the flag day contain an invalid taproot spend 16:42 < rusty> belcher: sure, a less inclusive method is simpler. 16:42 < belcher> (or for LOT=true the alt-client can reject the signalling bit) 16:42 < yanmaani> rusty: What do you mean? There could be some issue detected? 16:43 <@michaelfolkson> I do think there is an argument too if there are two options, Core (LOT=false) and UASF (LOT=true) people will be more comfortable running the Core release. Until say 6 months pass and they really want that UASF release 16:43 < belcher> rusty importantly the "less inclusive" method still allows the users the final word 16:43 <@michaelfolkson> (That's assuming there is a Core (LOT=false) release) 16:43 < yanmaani> rusty: That's true. I had a proposal for a compromise, but it's basically too late as I understand it. 16:43 < rusty> belcher: to be fair, you don't need to have elections either, since people can rise up and overthrow the government if they're really unhappy. That's a bit extreme, but there is a major importance to Schelling points, and running an alt-client is a huge huge barrier. 16:44 < rusty> yanmaani: of cours.e 16:44 < yanmaani> ^ 16:44 < rusty> If core is saying "LOT=true is hard to review, let's exclude it" then what chance do other clients have to implementing it well? 16:45 < belcher> the analogy of electrons and overthrows is quite convincing 16:45 <@michaelfolkson> rusty: They aren't saying that. There are just many NACKs for LOT=true in Core. Bad precedent etc. 16:46 < rusty> michaelfolkson: it has been said though; review would be easier without that logic existing at all... 16:46 < mol_> if people don't want taproot, they can always run the older versions that don't have taproot code? 16:47 <@michaelfolkson> rusty: Because some people throw suggestions out on what to do if there is a chain split which don't seem very well thought through 16:47 < rusty> Miner activation is great, for weird reasons. I mean, they're easy for everyone to count, and if they actually activate then the feature is usable. But the real genius is that they're *uniquely* vulnerable to users. They're the only ones who have to make real time decisions about what chain to mine; most others can sit on the sidelines for a while. We saw this with UASF: miners are (justifiably!) terrified of transient f 16:47 < rusty> orks. 16:48 < rusty> Thus my preference for enshrining a triumverate model. Devs propose. Miners activate. Users override. 16:48 < roconnor> Again, not important what activation method is best; just what is acceptable. 16:49 < rusty> roconnor: but the good thing is that we are pretty close to this by precedent already. 16:49 < yanmaani> rusty: of course what? 16:49 < rusty> yanmaani: "there could be some issue detected?" <- of course. 16:49 < yanmaani> oh ok 16:50 < yanmaani> Yeah, my idea was if you'd just allow like 80% of miners combined to block, that should get rid of the worst aspects of "miner veto" while keeping the "oh fuck there's a bug bail out of everything" aspects. But alas, too late. 16:50 < rusty> roconnor: this is always true. But the only reason I'm spending time on this, not What I'm Supposed To Be Doing, is that I'd like to reuse the same model in future, which sets a higher bar. I honestly believe we could YOLO activate taproot. 16:52 < rusty> yanmaani: True. But I kinda like users having an actively specified role. I think if we don't explicitly recognize their fundamental power (if all Bitcoiners decide something dumb, we're probably fucked), it's more fragile and fundamentally less legitimate? 16:52 < roconnor> I beleive we would maybe YOLO activate taproot too. ... assuming that is like code for a flag day ... but what we need one or more activation proposal that will pass core review. 16:53 -!- jonatack_ [~jon@37.171.225.50] has joined ##taproot-activation 16:53 < yanmaani> rusty: I guess. Although users still use their economic majority, and it's understood that miners who maliciously veto will be overridden by a future LOT=true for real fork. But inasmuch as we want to keep the escape hatch, while not making it a door to the patio... 16:53 <@michaelfolkson> roconnor: BIP 8 (1 year, false) rather than your concoction of all the proposals merged together ;) 16:54 < roconnor> I'm fine with that. I'm worried it won't pass core review but definitely worth making a PR for. It has a fair chance. 16:54 < rusty> roconnor: yes. I think that LOT=false by default, a (hidden) option for -invalidate-blocks-to-require-activation=taproot (aj suggested trhat). 16:55 < roconnor> well hidden option require LOT=true to pass core review. 16:55 < rusty> roconnor: yeah, that's what it does (and changed UA string by default, which IMHO is *vital*) 16:55 < roconnor> I'm quite skeptical that would pass core review, at least in a first deployment. 16:55 <@michaelfolkson> Would not bet on it either 16:56 < roconnor> I guess I would help with such a PR if you are way more optimistic than I am. 16:56 -!- jonatack [~jon@37.173.203.38] has quit [Ping timeout: 264 seconds] 16:56 < belcher> rusty fwiw a huge amount of accessible nodes out there are actually run by surveillance companies, they aim to figure out the real IP address source of broadcast transactions, so theres an argument that UA strings are kind of useless 16:56 < mol_> roconnor, a flagday proposal has a better chance to be merged into core? since this is how things were done in the past 16:56 < belcher> though its a useful metric along with loads of other stuff 16:56 < rusty> belcher: sure, but kind of useless != completely useless. They're another signal. 16:56 < belcher> when combined with* 16:56 < belcher> yes 16:57 <@michaelfolkson> mol_: Flag day opposes Rusty's triumvirate and the F7 argument 16:58 <@michaelfolkson> Worse chance than BIP 8 (false) 16:58 < roconnor> mol_: I think flag day is about on par with BIP8(1y,false) on review passing chances. Probably flag day is a little less likely to pass review, but also something definitely worth making a PR for. 16:58 < mol_> michaelfolkson, it seems you're stuck in a box 16:58 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds] 16:58 < mol_> roconnor, would you be willing to make that PR for us then? 16:58 < roconnor> mol_: which PR? 16:59 < mol_> roconnor, flagday 16:59 < rusty> roconnor: I am optimistic. I understand that it's easier to defer difficult decisions, but I think it's important to explicitly recognize user power here. 17:00 < roconnor> rusty: Okay ... maybe you'd like to talk with Matt and Sjors first before working too hard on that ... 17:01 < rusty> roconnor: of course, I'm always happy to discuss with everyone :) 17:01 < roconnor> mol_: I suppose I'd be willing, but I think aj will probably make a flag day PR in a reasonable amout of time. He seems to know exactly how to do it. 17:02 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 17:04 -!- jonatack_ [~jon@37.171.225.50] has quit [Ping timeout: 246 seconds] 17:05 <@michaelfolkson> Surely rusty you would NACK a flag day PR? Maybe you wouldn't get involved 17:05 -!- jonatack_ [~jon@37.172.247.108] has joined ##taproot-activation 17:06 < rusty> michaelfolkson: I would oppose it, yes. I hope I've been pretty clear about my reasons, but I'm just some guy. 17:06 <@michaelfolkson> I'm sure there are others who have engaged that would NACK it too. 17:06 < roconnor> I haven't read your blog posts recently? Would you be willing to summerize them or link? 17:07 < roconnor> michaelfolkson: what were the reasons. 17:07 < belcher> fwiw someone on the mailing list also disagreed with flag day activation for the same reason as rusty... so i think that opinion is moderately common 17:07 < rusty> https://rusty.ozlabs.org/?p=620 https://rusty.ozlabs.org/?p=628 17:08 < roconnor> hmm, the word flag doesn't occur in those posts. :D 17:08 < roconnor> oh it is the developers shouldn't activate argument. 17:08 <@michaelfolkson> I'd summarize it as pass the parcel or pass the hot potato. Another couple of passes (miners and users) rather than Core developers releasing something that definitely activates 17:08 -!- jonatack_ [~jon@37.172.247.108] has quit [Read error: Connection reset by peer] 17:08 < roconnor> Did Matt ever address that in his ML post? 17:09 <@michaelfolkson> I don't think Matt has been following a lot of this unfortunately 17:09 < rusty> roconnor: this predates that proposal, though. 17:09 < roconnor> what predates what? 17:11 < roconnor> ah yes he does kinda address it in point (1) I don't believe we have or will see significant, reasonable, and directed objection. 17:11 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed] 17:11 < rusty> (My posts predate my awareness of a flag day proposal) 17:12 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Read error: Connection reset by peer] 17:12 <@michaelfolkson> But you dislike a flag day for same reasons as you dislike Core releasing LOT=true 17:12 < roconnor> oh yes, right; hence why I couldn't find flag. 17:12 < rusty> michaelfolkson: yes. 17:12 < roconnor> but I do remember your dev's don't activate argument. 17:12 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##taproot-activation 17:14 < roconnor> I think many of these particular object go apply only to LOT=true and flag day as a *first* depolyment set. 17:14 < roconnor> and after an observable period of users activately and observably updating to a core client with some taproot activation method, would be willing to later do a flag day, etc. 17:15 < roconnor> I could be off base here, but I think that a flag day etc. chance of passing Core review increases a lot after a (successful) first Core activation release. 17:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 17:17 < roconnor> um by successful I mean, that users upgrade, not that taproot necessary is activated. 17:17 < roconnor> bad choice of words on my part. 17:17 < rusty> roconnor: I suspect you're right, but there are problems: 1) in general upgrades pull in other things. (You should be doing due diligence on your upgrades, for example). 2) it's still devs decide, which is fuzzier to define. 3) with no precedent, who knows if it'll happen when/if needed? 17:17 < rusty> i.e. w 17:18 < rusty> we're kinda punting on the "how do devs enable a UASF" q to "we'll know when we need it". 17:18 < harding> Does somebody have the ability and interest to create a new mailing list for activation discussion? It's drowning out other discussion on the -dev mailing list. 17:19 < rusty> harding: bwahahaha.... yes, I could do that. I expect many posts in favor of all my excellent proposals :) 17:19 < roconnor> harding: I mean, it is hard enough to reach stakeholder for core review as it is ... 17:20 < harding> roconnor: posters are unlikely to reach many now that it's generating 20 posts a day. 17:21 < yanmaani> rusty: that's a good blog post, I was thinking along the same lines. It's regrettable that Core'll have to decide on one approach and force it for everyone. It'd be better should they let people configure it. 17:29 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds] 17:30 < luke-jr> [00:44:51] If core is saying "LOT=true is hard to review, let's exclude it" then what chance do other clients have to implementing it well? <-- but it isn't actually hard to revieqw, just certain people are abusing politics 17:31 < rusty> luke-jr: I somewhat agree. 17:32 < luke-jr> [00:56:40] roconnor, a flagday proposal has a better chance to be merged into core? since this is how things were done in the past <-- lol no 17:33 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 17:33 < Emcy> whos abusing politics? 17:33 < mol_> nobody 17:33 < luke-jr> there has never been an unsignalled flag day since P2SH, and even that was kindof signalled; excluding the 2013 emergency 17:34 < luke-jr> Emcy: Matt 17:34 < luke-jr> Emcy: he's adding additional hurdles to getting BIP 8 merged that have never been demanded of any other softfork much less activation method 17:34 < Emcy> what has he done 17:35 < Emcy> what sort of hurdles? 17:36 < luke-jr> demanding it needs to safely handle user toggling of LOT after activation, chain splits, and other such nonsense 17:37 < Emcy> well i mean, softfork code has never had a user toggle before afaik right? 17:37 < rusty> luke-jr: well, toggling LOT kinda makes sense, though TBH that can be done later. Handling chain splits does not: if it comes to civil war like this, I will totally release software which circumvents any attempts to nearly partition the network. 17:37 < rusty> s/nearly/neatly/ 17:37 < luke-jr> rusty: BIP 8 does not support toggling LOT though 17:37 < luke-jr> not that PR at least 17:37 < luke-jr> Emcy: neither does this 17:38 < rusty> luke-jr: agreed. It's a separate issue. 17:45 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-kyktlahynetpedic] has quit [Ping timeout: 265 seconds] 17:45 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-iujwpawuwmlqcsdg] has quit [Ping timeout: 240 seconds] 17:48 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-lwtlcrascsqipswp] has quit [Ping timeout: 240 seconds] 17:58 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-jamlgibvzxfqznqg] has joined ##taproot-activation 17:59 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-yxzngaxpgqqcgfbv] has joined ##taproot-activation 18:19 < Emcy> luke-jr have you ever watched or heard of the tv show 'the young pope'? 18:19 < luke-jr> yes 18:19 < Emcy> what did you think? i liked it 18:20 < luke-jr> it's not consistent with Catholicism, and includes porn 18:20 < luke-jr> so I can't recommend 18:20 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-xhsqoicdwuaiusux] has joined ##taproot-activation 18:20 < luke-jr> also, off-topic :P 18:20 < luke-jr> #eligius has turned into a movie channel tho 18:20 < luke-jr> lol 18:21 < Emcy> yeah #bitcoin-forks sort of organically changed topics too 18:21 < luke-jr> we group-watch stuff daily in #eligius 18:22 < luke-jr> well, almost daily 18:23 < Emcy> what kind of stuff 18:23 < luke-jr> just finished Travelers last night 18:23 < luke-jr> often anime 18:23 < luke-jr> talk more there so this channel doesn't get annoyed? 19:01 < jeremyrubin> get outta here with your movie talk 19:01 < jeremyrubin> this is real srs biz 19:03 < luke-jr> XD 19:22 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds] 19:26 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation 20:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 20:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 20:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds] 21:02 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation 22:08 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Ping timeout: 246 seconds] 22:13 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##taproot-activation --- Log closed Fri Mar 05 00:00:47 2021