--- Log opened Sat Jul 25 00:00:29 2020 00:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 01:37 -!- slivera [~slivera@103.231.88.10] has quit [Ping timeout: 240 seconds] 02:24 < luke-jr> not including activation in the main release of Core would also possibly counter the perceived responsiblity of devs 02:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 03:01 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has quit [Ping timeout: 244 seconds] 03:05 -!- Livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation 03:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 03:43 -!- roconnor [~roconnor@host-184-164-1-116.dyn.295.ca] has quit [Ping timeout: 244 seconds] 03:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 03:54 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-activation 03:57 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 04:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 04:20 -!- reallll is now known as belcher_ 04:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds] 05:22 -!- jonatack [~jon@213.152.162.5] has joined ##taproot-activation 05:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 05:37 -!- Davterra [~Davterra@193.32.127.227] has quit [Read error: Connection reset by peer] 05:37 -!- Davterra [~Davterra@193.32.127.227] has joined ##taproot-activation 06:57 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 07:07 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation 07:13 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:22 -!- jonatack [~jon@213.152.162.5] has quit [Ping timeout: 240 seconds] 07:32 -!- roconnor [~roconnor@host-192.252-166-24.dyn.295.ca] has joined ##taproot-activation 07:56 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 08:03 < roconnor> luke-jr: On the contrary, delibrately avoiding including activation into the release of Core actually plays into the narative that devs could change the rules if they chose to do so. 08:04 < roconnor> Really, you aren't going to quell these stupid and dangerous claims about devs power over the rules of Bitcoin this way. 08:04 < roconnor> Either you include activation in the release and they will falsely claim "see, the devs are deciding the rules of Bitcoin", 08:06 < roconnor> or you don't include activation in the relase and they will falsely claim "See, the devs can control the rules of Bitcoin, that's why they need to put the activation outside of Bitcoin Core." 08:07 < roconnor> And honestly, I think the second case is someone more worrysome because it really does look like the Bitcoin developers themselves are admitting that they do have this power (which the do not have). 08:09 < roconnor> MattC's recent email to the list suggesting that if we start with BIP8(true) it hard to argue against "the devs are deciding" actually made me pretty upset. 08:10 < roconnor> It's easy to argue. The devs have no control over the rules of bitcoin no matter whether they implement BIP8(true) or BIP8(false) or make any other changes to Bitcoin Core because it is simply a fact that developers have no power to make anyone run their software. 08:10 < roconnor> and without that power they cannot force changes in the rules of Bitcoin. 08:11 < zmnscpxj__> i.e. "all softforks are ultimately UASF" 08:11 < luke-jr> roconnor: I don't see why the second makes sense 08:11 < roconnor> And it is worrying when people suggest otherwise because, honestly, it puts the Bitcoin Core developers in danger. 08:11 < luke-jr> [15:06:00] or you don't include activation in the relase and they will falsely claim "See, the devs can control the rules of Bitcoin, that's why they need to put the activation outside of Bitcoin Core." 08:12 < luke-jr> with this scenario, devs are not putting _any_ pressure on anyone.. 08:12 < roconnor> luke-jr: Yes that is true. 08:12 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation 08:13 < somethingsomethi> Thinking a bit more about this idea of splitting consensus and policy,I came up with this scenario: 08:13 < roconnor> luke-jr: But the argument would be that the devs are admitting that the could force changes to Bitcoin if they wanted to, and are chosing not to. 08:13 < somethingsomethi> Let's say taproot consensus only gets released in 0.20.x first and by somemiracle quickly activates. Then the only way to get a taproottransaction on chain would be to talk to the miners directly, whichkind of makes them the gatekeepers of taproot temporarily 08:13 < roconnor> And that is what is dangrous. 08:13 < somethingsomethi> Is that something that could happen or am I missing something? 08:13 < zmnscpxj__> it is something that could be "spun" 08:14 < roconnor> Because if people start believing that it is even possible for Bitcoin Core devs to change the rules of bitcoin, then it means that they can be threated into doing so. 08:15 < roconnor> Whats worse is that even though Bitcoin Core developers cannot change the rules of Bitcoin, all it takes is for other people to believe that they do have that power for it to be dangerous. 08:15 < luke-jr> roconnor: I think that can be preempted 08:15 < luke-jr> somethingsomethi: it's not a problem 08:16 < luke-jr> somethingsomethi: miners could always just refuse to mine Taproot entirely if they wanted to 08:16 < somethingsomethi> luke-jr you might even consider it an incentive for them to upgrade 08:17 < somethingsomethi> a way to make an extra buck: Taproot early access 08:17 < roconnor> somethingsomethi: That's an argument. But ultimately I feel that the hard thing to coordinate is the agreement on when to enforce taproot inside blocks. And if we get taproot "activated" in that sense without realy working. Well at least the hard part is over. 08:19 < somethingsomethi> Yeah, I must say (at least for me as an outsider), it almost seems like that is the way softforks should be done in principle: Just have the validation related parts in the activation cycle, the rest is then just implementation specific engineering to make it useful 08:20 < somethingsomethi> i.e. look at softforks as pull requests against libconsensus (if that makes any sense) 08:25 < harding> Avoiding including mandatory activation in the first release of Bitcoin Core to implement a particular soft fork says, "devs won't give you defaults that could cause you to fork onto a minority chain and lose money just because devs misjudged the community support for that fork." 08:30 < harding> I think the best practical way we have to judge whether the community supports a change is to see if users accept the software implementing it, but until we have that assurance, it seems less than entirely safe to release software that can put users at risk because of those rule changes. 08:33 < luke-jr> harding: that can happen if devs judge the other way wrong too 08:33 < luke-jr> NOT enforcing the UASF is riskier than enforcing it 08:33 < harding> luke-jr: please elaborate? 08:34 < luke-jr> (assuming the support exists) 08:35 < harding> I don't think so. If a UASF has enough support to force miners into doing X, then nothing else is needed. If it's not that well supported, then it's important to learn why it lacks that support before blindly releasing software implementing it. 08:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation 08:55 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 09:07 < roconnor> harding: I do think that is a totally reasonable argument for not including manditory activation in the first release of Bitcoin Core. 09:08 < roconnor> I personally don't think it is neccesary to be that careful, because I don't think we have misjudged community support, but I can see why others would want to do it that way and I would definitely support it. 09:09 < roconnor> (Go SNIL!) 09:09 < zmnscpxj__> SNIL ?= 09:09 < roconnor> Start Now Imporve Later. 09:09 < zmnscpxj__> okthx 09:10 < roconnor> (part of the issue is that BIP8(false) doesn't preclude activation even if it somehow turns out we misjudged community support.) 09:11 < roconnor> (but it does help) 09:13 < harding> roconnor: agreed, but two weeks of signaling and two weeks of lockin is hopefully enough time for an emergency soft fork to kill segwit v1 spends, especially considering that the people who are most likely to use v1 spends early on are probably the same people paying attention to recent developments. 09:16 < roconnor> harding: totally agree. 09:31 -!- jeremyrubin [~jr@2601:645:c200:f539:45c6:b423:5c6a:9d2f] has joined ##taproot-activation 11:27 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation 11:29 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 11:38 < luke-jr> if merging activation into Core makes a political argument, that seems like yet another reason to do side releases with it 11:39 < luke-jr> spare wumpus, sipa, et al (who don't want the stress) the stress 11:57 -!- ryanthegentry [8831d538@136.49.213.56] has joined ##taproot-activation 12:07 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Ping timeout: 240 seconds] 13:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 13:08 -!- ryanthegentry [8831d538@136.49.213.56] has quit [Remote host closed the connection] 14:07 -!- grubles_ [~grubles@gateway/tor-sasl/grubles] has joined ##taproot-activation 14:44 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation 18:14 -!- cdecker [~cdecker@mail.snyke.net] has quit [Ping timeout: 258 seconds] 18:14 -!- cdecker [~cdecker@mail.snyke.net] has joined ##taproot-activation 19:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 19:58 < rusty> FWIW: I support classic BIP 8 because the likely case is battle tested (BIP9) and it slightly simplifies the failure case. I don't support the idea of an Emergency Activation via 100% setting the bit, because (1) it's complexity for a corner case, (2) if we accidentally get 100% consensus we skip the grace period. I also believe that deciding to lock in or not should be decided initially (I propose: yes, lock in, because 19:58 < rusty> we can SF it out if we find a flaw, by burning that witness form), because otherwise we're just postponing decisions. (Anyway, adding a force actvation is simpler than adding YA BIP8 overlap: it simply needs to be "At block X to X+2015, if taproot not activated or locked in, taproot activation bit must be set". 20:00 < rusty> I believe we have consensus, and if I was/became convinced we didn't I would be urging its activation at all. If consensus changes, we SF to burn the v1 <32 byte> witness form. 20:00 < rusty> s/would/wouldn't/. 20:03 < rusty> I am happy with anywhere from 12 to 24 months activation, too, though my preference is the shorter end of that. This derives from my belief that we have widespread consensus, and I am persuaded by gmaxwell's belief that too much delay is corrosive. 20:30 < zmnscpxj__> classic BIP8 == BIP8(true) 20:31 < rusty> zmnscpxj__: and no failing state, yeah. 21:15 < jeremyrubin> Calling BIP-9 battle tested is funny. Yes it has been tested in battle. But there are differening opinions on what that test showed (tho battle tested usually implies battle tested & approved). Many look at BIP9 as a failure 21:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 21:38 < luke-jr> the failing state only exists with false.. 22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation 22:36 < rusty> jeremyrubin: I was referring purely to the code. 22:41 < aj> luke-jr: https://github.com/bitcoin/bips/pull/950 -- there, now you don't have to reply to your email :-P 22:43 < luke-jr> aj: thanks :p 22:52 < luke-jr> aj: nice idea using graphviz 22:53 < rusty> aj: OK, that solves the surprise activation, which is nice. But I disagree with the complexity: if you want to force a BIP8, just do so explicitly. 22:53 < luke-jr> rusty: ? 22:55 < rusty> luke-jr: I didn't grok all the details of the MUST_SIGNAL prior to reading, so I had an invalid complaint. 22:55 < jeremyrubin> rusty: icymi https://docs.google.com/presentation/d/1U2_qk5tWWnN3l1ehYZmfbQEg9KV5bXjvhJf2Skgsz-g 22:57 < rusty> ... jeremyrubin not sure that helps :) 22:59 < jeremyrubin> sorry thought it might 23:23 < aj> luke-jr: i guess it must be possible to create graphs without using graphviz, but i'm not peter todd with his bachelor of arts or whatever 23:25 < luke-jr> aj: I made it in a text editor :P 23:36 -!- grubles_ [~grubles@gateway/tor-sasl/grubles] has quit [Ping timeout: 240 seconds] 23:46 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined ##taproot-activation --- Log closed Sun Jul 26 00:00:08 2020