--- Log opened Fri Nov 20 00:00:24 2020 01:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:52 -!- jonatack [~jon@213.152.162.79] has quit [Ping timeout: 260 seconds] 05:16 < murch> Six mining pools have already had themselves put on the site, all in support: Poolin, Slush, BTC.com, F2Pool, Antpool and Luxor 05:52 < michaelfolkson> Should we be getting feedback not only on preferences but what they'd be comfortable with outside of their expressed preference? 05:53 < michaelfolkson> The way it is going there isn't consensus on first preference 05:55 < michaelfolkson> Or if there is no consensus on activation method but supermajority signaling support for Taproot we just do BIP 9? 06:16 < murch> It would probably be the easiest to err on being more inclusive. 06:17 < murch> I.e. if some want BIP8(false), others want BIP8(true), start with BIP8(false) and amend as we learn more 06:17 < murch> Not sure all preferences cluster that cleanly 06:17 < murch> thouhg 07:13 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##taproot-activation 07:25 < waxwing> the only thing about miners that matters is that they have fair warning and are able to upgrade in a timely manner, the opinion of pool operators on taproot shouldn't be of special interest. 08:01 < harding> waxwing: I think it's of interest in choosing an activation mechanism. 08:04 < luke-jr> no, miners have no right to dissent from the community based on their opinion 08:05 < harding> Also, although I agree their opinion isn't of special interest, I think it is good to hear their concerns. E.g., if we had know that segwit was going to break covert ASICBoost and affect some miner's profitabliity, maybe we would've done things differently in the design stage. 08:05 < luke-jr> their practical actions matter, but only in the sense that the network needs to be prepared to defend against malicious blocks 08:06 < luke-jr> I missed the link, but if it's the one I'm thinking of, it misportrays miners as relevant to deciding 08:06 < luke-jr> if there is any chance miners will refuse to cooperate, that's an extra reason for BIP8(true) 08:06 < harding> luke-jr: what do you mean "no right to dissent"? I think they have an absolute right to using their mining equipment as they want, just as we individually have a right to ignore any blocks they create that violate our desires. 08:07 < luke-jr> harding: mining invalid blocks is an attack on Bitcoin; I don't think they have that right 08:07 < luke-jr> likewise, trying to sabotage activation of community-decided rules 08:08 < harding> luke-jr: who decides what's an invalid block? 08:08 < luke-jr> harding: the community 08:09 < luke-jr> or economy, rather 08:10 < luke-jr> hmm, I wonder if aj's recent BIP 8 revisions break the ability for those who disagree to fork off cleanly 08:12 < harding> luke-jr: how do you measure economic decisions without attempting to sell something that people might choose not to buy? 08:12 < luke-jr> anyway, practical concerns are practical; but when it comes to support for the change itself, miners do not particularly matter 08:13 < luke-jr> harding: that's beside the point 08:14 < luke-jr> miners do not in any sense measure economic decision 08:14 < harding> luke-jr: if they can't measure economic decision, then they can't be morally bound to follow it. 08:16 < luke-jr> harding: my point is that miners are relevant only at a practical level, not a decision-making level.. 08:16 < harding> I don't know what that means. 08:18 < luke-jr> it means if they aren't going to deploy Taproot, the correct course of action is to treat it as malice and mitigate it 08:18 < luke-jr> if miners are right that the commuinity doesn't support Taproot, and we are wrong, then attempts to mitigate will fail, and miners will prevail 08:18 < harding> I'll agree that we should mitigate it. I think I'd need more information before treating it as malice. 08:19 < waxwing> " if they can't measure economic decision, then they can't be morally bound to follow it." <-- yes good point; they are economically incented to follow it, though. isn't that the point. 08:20 < waxwing> i don't think anyone ever argued that bitcoin rests on morality of miners :) 08:21 < harding> waxwing: I agree; I was taking issue with luke-jr's moralizing about invalid blocks being an attack on Bitcoin. I don't think things are that clear cut. 08:21 < luke-jr> harding: my problem with the website is that it portrays miners as decision-makers 08:22 < waxwing> yeah that's my problem with it as well, except it more *hints* than portrays, and i think we should be careful not to see it as a good thing if we happen to agree with what it says. 08:22 < luke-jr> harding: well, part of the point of the mandatory signalling was to make it clear-cut: if miners signal Taproot, but don't enforce it, that's pretty clearly malice; but I think we might be losing that with aj's changes 08:22 < harding> luke-jr: I think the text has been improved in the past few days, it looks basically ok to me: https://taprootactivation.com/ 08:22 < luke-jr> (maybe not, it needs more thought) 08:22 * luke-jr looks again 08:23 < luke-jr> it's still wrong XD 08:23 < luke-jr> (there's no MAST in Taproot) 08:24 < luke-jr> I think it's still too strong on miners… we really shouldn't care what activation method they prefer 08:24 < luke-jr> the only difference is what it does if they refuse to cooperate… 08:25 < luke-jr> (I mean, if it was coinbase vs versionbits, I could see miner opinion having merit on that - but that's not what is in question right now) 08:25 < harding> I think if we want to use their signaling as an activation mechanism, it would be nice to use something that both we and they can agree on. 08:25 < luke-jr> we have that whether or not we lockinontimeout 08:26 < luke-jr> IMO the site might not be bad, if they remove the false MAST claim, and miner talk (perhaps replace with a link to a wiki page on support in general, which might include miners) 08:26 < harding> Anyway, I think it's nice that some miners took the time to indicate that they're willing to signal support for taproot when we're ready. 08:27 < waxwing> i'm on the fence, i agree harding that there's nothing wrong with canvassing opinion about activation methods, but i also slightly worry that we are using this as our schelling point of how we decide to start the activation process .. 08:27 < waxwing> general public (and maybe more importantly miners) may see it as, miners are deciding to activate taproot. 08:27 < luke-jr> something like https://en.bitcoin.it/wiki/Bech32_adoption 08:28 < harding> waxwing: I think that's partly our own fault; I find it frustrating how much time we've spent on trying to decide an activation method among ourselves. 08:35 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation 08:35 < luke-jr> harding: fair 08:38 < roconnor> luke-jr, harding: MAST has been renamed to Merklized Alternative Script Tree. 08:39 < harding> roconnor: yeah, that's what we use for Optech, and we even have a note about the name change: https://bitcoinops.org/en/topics/mast/ 08:42 < luke-jr> -.- 08:42 < luke-jr> that's just going to make confusion 08:47 < luke-jr> https://twitter.com/LukeDashjr/status/1329827478672728065?s=20 08:49 < aj> roconnor: "merkle branches" is how it's described in the bip 08:52 < harding> luke-jr: I think you can start at least a month earlier because there will be at least one 2-week signaling period and one 2-week lockin period. 08:58 < luke-jr> harding: good point 09:00 < aj> luke-jr: "I wonder if aj's recent BIP 8 revisions break the ability .. to fork off cleanly" -- shouldn't do; afaik it's only activation without any period having >threshold signalling which would risk doing that 09:02 < aj> luke-jr: "we really shouldn't care what activation method [miners] prefer" -- i think we care about miners only in so far as we care about a soft-fork activating quickly (a few months rather than a few years), with miner support we can do things faster, without it, we have to do it a lot slower 09:02 < luke-jr> aj: but if there's a niche of users+miners who actually want a Taproot-free chain, how would they do that? 09:03 < harding> luke-jr: can't they just soft fork in a rule that any v1 segwit spends are invalid? 09:04 < aj> luke-jr: ensure they mine a series of blocks where no retarget period has >threshold setting the versionbit during the signalling period. lockinontimeout=true nodes will consider that chain invalid, everyone else will consider it valid with the soft-fork not activated 09:05 < luke-jr> harding: that could end up on a Taproot-signalling chain with uncertainty until Taproot is used on Bitcoin 09:05 < luke-jr> aj's solution probably works though 09:05 < luke-jr> a softfork to forbid the Taproot bit I guess 09:05 < aj> yeah 09:06 < luke-jr> might be an overwrite risk to that chain tho 09:06 < luke-jr> I mean, overwriting Bitcoin until lockinontimeout is met 09:07 < aj> i imagine both groups would want that, to try to force the other group to join them 09:09 < luke-jr> forcing others is bad 09:09 < luke-jr> with this scenario, it would also only be one-way: the Taproot chain would never overwrite the anti-Taproot chain 09:09 < aj> yeah, but people do/want bad things sometimes :-/ 09:10 < luke-jr> we should make the right thing easier :P 09:10 < aj> you'd only go from taproot active to taproot inactive with a >2017 block reorg 09:12 < aj> prior to the endheight, if the anti-fork miners have enough hashpower to do that, i'd expect them to do a <100 block reorg to undo any successful signalling first; and i don't see how you'd get successful signalling anyway 09:13 < luke-jr> ? 09:15 < aj> how do you do a >100 block reorg of the majority chain, with less than the 10%-15% hashpower you'd need to block a soft-fork from activating prior to endheight/lockinontimeout=true? 09:21 < luke-jr> consider miners defecting 09:22 < luke-jr> there might not be a solution to make this better 09:30 < aj> luke-jr: miners defecting and reorging their own blocks is already possible, but pretty costly (needs to be a long reorg for them to have been able to cash-out the block-reorgs they're reorging, which makes it a lot harder to succeed, tc) 10:51 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 10:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 10:56 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 265 seconds] 10:57 -!- jonatack [~jon@213.152.162.181] has joined ##taproot-activation 10:58 -!- jonatack [~jon@213.152.162.181] has quit [Client Quit] 10:58 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 11:03 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds] 11:03 -!- jonatack [~jon@213.152.162.181] has joined ##taproot-activation 11:41 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 12:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 12:28 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds] 12:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 12:34 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 13:48 -!- belcher_ is now known as belcher 14:14 -!- ksedgwic [~ksedgwic@192-184-134-31.static.sonic.net] has quit [Ping timeout: 260 seconds] 14:14 -!- ksedgwic [~ksedgwic@192-184-134-31.fiber.dynamic.sonic.net] has joined ##taproot-activation 16:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:47 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] 17:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 17:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 17:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 18:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 19:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 19:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 19:54 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 20:47 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##taproot-activation 21:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:11 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 21:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 23:11 -!- jonatack [~jon@213.152.162.181] has quit [Ping timeout: 260 seconds] 23:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 23:13 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation 23:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 23:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] --- Log closed Sat Nov 21 00:00:23 2020