--- Log opened Mon Jul 20 00:00:26 2020 00:20 < jonatack> cato_: https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d 00:22 < cato_> jonatack: thanks 01:11 -!- slivera [~slivera@103.231.88.27] has joined ##taproot-activation 01:56 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation 01:57 < somethingsomethi> for decthresh, can we add as a Con that the code for this would still have to be written? 01:59 < somethingsomethi> (also I wonder: If you're ok with it activating at 60% eventually, why not just set that as the threshold for the entire second period?) 02:00 < zmnscpxj__> The assumption is that when it is initially deployed there are 0 actual users running it, so the lower threshold may trigger with only low number of users with that specific software 02:00 < zmnscpxj__> I mean the version with the lower threshold 02:01 < somethingsomethi> so the ones running the software from the first period are disregarded? 02:07 < zmnscpxj__> there will be users running the software from the first period still, which have not upgraded to the second-period software 02:08 < zmnscpxj__> and will not impose the rules of the second-period software 02:08 < zmnscpxj__> so they will not activate on the lower threshold 02:08 < zmnscpxj__> but if a few miners run the lower threshold 02:09 < zmnscpxj__> they could end up forking themselves off because they activated before the users do 02:09 < zmnscpxj__> I think 02:09 < zmnscpxj__> I might be misunderstanding the mechanism 02:19 < somethingsomethi> I mean, since the code for this method still has to be written anyways, maybe that scenario can be taken into account 02:38 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 02:39 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Ping timeout: 240 seconds] 02:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 02:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 03:09 -!- Netsplit *.net <-> *.split quits: roconnor, _joerodgers, luke-jr, belcher_ 03:09 -!- Netsplit over, joins: _joerodgers, roconnor, belcher_, luke-jr 03:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Max SendQ exceeded] 03:11 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 03:14 -!- lukedashjr is now known as luke-jr 03:31 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation 03:53 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-activation 03:55 -!- reallll is now known as belcher 03:56 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 04:38 < roconnor> aj: It's not a matter of dumping coins. Bitcoin Core cannot force taproot on anyone beccause developers cannot force users to download an update to enforce taproot. 04:43 < roconnor> Users do not blindly download whatever Bitcoin Core puts out. Users are not sheep that are shepparded by developers wishes. Users are active participants in the Bitcoin system and they ultimately bear their own responsibility when downloading and running the software that they chose to run. 04:44 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 04:44 < cato_> other CON of decthres: possibly incentivizes apathy (no need to get active, adoption of other miners might be enough); 60-40-ratio of hashpower increases likelihood of forks 04:46 < roconnor> cato_: miners must take action if there is a risk of a new rule coming into effect. A lower ratio increases this risk and thus incentivizes them to take earlier action. 04:47 < roconnor> Miners sitting back and relaxing while other miners or users activate a soft-fork is not a thing that they can do without risking their blocks from ending up invalid. 04:48 < cato_> maybe they're hoping for apathy, opposition of other miners or even think their inaction will lead to other miner's inaction 04:48 < cato_> that's all speculation, though. assuming rational miner action as given could be dangerous, though 04:49 < roconnor> Sure that is a thing. Which is why BIP8(false) all by itself is potentially useless. 04:50 < cato_> agreed 04:50 < cato_> is there consensus on whether taproot activation should set a precedent for future activations? 04:53 < roconnor> We probably should strive for a method that is resuable. That said some soft-forks are of a different nature, and could merit different activation, though nothing specific comes to mind. 05:09 < harding> (Just FYI, I will update that document for feedback received, I just have a very busy day today so there's a good chance I won't get to it until tomorrow.) 05:29 < cato_> harding: +1 05:48 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 05:56 < cato_> I like how start now, improve later offers flexibility about the forced activation time frame 05:59 < cato_> something similar would be nice as third period in Modern Soft Fork Activation. especially since there's an explicit 6m period during to get rough consensus for one of the options 06:00 < zmnscpxj__> *third* period. oh no 06:00 < zmnscpxj__> (unless you are counting the 6m discussion as 2nd period?) 06:03 < cato_> zmnscpxj__: yes 06:03 < zmnscpxj__> okay 06:04 < cato_> if there's a 6m discussion period and no solid opposition, an option to fast-track using BIP(true,1y) could make sense 06:27 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection] 06:45 < belcher> harding iv read your document https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d heres a few comments: 06:48 < belcher> this argument "if a problem is discovered with taproot while lockinontimeout=false, the attempt can safely fail without further intervention." is mentioned a lot but it doesnt seem like a good point to me, because surely core devs would carefully review the code before it ever gets released, a longer or lockontimeout=false activation is a bad solution in the case where theres any doubt about the code's correctness 06:49 < zmnscpxj__> one could argue that core devs are not perfect and so we should give leeway for the possibility of mistakes, and thus a way to reverse things 06:49 < belcher> also, i remember reading in this channel that a lockontimeout=true activation can be soft forked out if theres a problem discovered, this is done by making that segwit script version invalid... that isnt mentioned anywhere in the document i think, and it should be 06:49 < zmnscpxj__> though "with enough eyes..." 06:49 < zmnscpxj__> I agree 06:49 < belcher> even so, a longer activation or lockontimeout=false isnt a good solution, the best solution is just more review before any release 06:49 < zmnscpxj__> agree as well 06:50 < belcher> also that argument doesnt give us any end date, you could use the same argument to wait 10 years... because after all in those 10 years we'll have loads of time to review 06:50 < zmnscpxj__> and I think the ability to softfork-out (salt the earth? uproot?) the softfork by invalidating outputs to SegWit v1 should be sufficient backout for us 06:50 < roconnor> belcher: fully agree as well. Though to be fair harding is just documenting things and not passing judgement on merits. 06:50 < belcher> the duration has to be related to how quickly we think users will upgrade, not related to how we think devs will review 06:51 < zmnscpxj__> yes, but would be nice to document as well the ban-SegWit-v1 killswitch option 06:51 < zmnscpxj__> belcher: because the duration starts after the devs have reviewed 06:51 < belcher> agreed roconnor, im not blaming harding i just noticed the argument was mentioned many times and (because its a Pro of many possible activation methods) but the argument itself just seems bad to me 06:51 < roconnor> zmnscpxj__: I did comment on that, and I believe harding will update when he gets time. 07:32 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation 07:34 < somethingsomethi> isn't the difference that the uproot variant needs to be developed & deployed (i.e. everyone needs to update their nodes) while in the false case it'll go away on its own? 07:38 < zmnscpxj__> yes 07:38 < harding> belcher: I think there's a concern that many people who aren't contirbutors to Bitcoin Core don't seriously evaluate a proposal until after it's been merged into Bitcoin Core (or even been released in a Bitcoin Core version). We've seen this before with changes to the P2P protocol or standard relay rules where people didn't complain about X breaking one of their usecases until after X was RC'd or released. To some degree, an 07:38 < harding> example of this at the consensus layer was segwit breaking covert ASIC boost; that isn't a great example because, if some claims about that are true, the affected parties probably knew about the breakage well before the segwit merge---but it's also an example of something the proposal broke which wasn't anticipated by Bitcoin Core contributors. On top of those technical concerns, some of the reasons an attempt can fail is 07:38 < harding> because of information that wasn't available before its release, e.g. someone could describe something better (as I believe Maxwell's description of taproot in early 2018 was better than the previously-proposed BIP116/7 OP_MERKLEBRANCHVERIFY/tail-call), or there could appear a problem from outside Bitcoin which rendered the proposal moot (e.g. a QC capable of effectively running Shor's). Finally, there's always the chance that 07:38 < harding> the Bitcoin Core contibutors overestimated the level of user support for a protocol and so it'd be nice to just let it fail rather than tell users "oh, you didn't support taproot, so now you need to upgrade to enforce an extinguishment soft fork or it'll activate any and people will be confused abouth which protocol rules really apply.") 07:40 < zmnscpxj__> somethingsomethi: the argument is that we expect taproot-to-deploy-successfully to be more likely than taproot-to-fail, so we should make it easier for it to deploy than to fail 07:40 < zmnscpxj__> somethingsomethi: uproot requires more effort in the case taproot fail, whereas BIP8-false reuires more effort in the case taproot should succeed but is just blocked by miner apathy 07:48 < zmnscpxj__> *secret* mining algorithms are secret and parties interested in *secret* mining algorithms do not want to talk about it. 07:48 < somethingsomethi> zmnscpxj__: Still, I'd say that "makes it easier to deal with unexpected problems" is a pro for the false case. The con you mention seems to be covered by "Unnecessary failure risk" in the gist 07:48 < zmnscpxj__> So it seems to me there is always a chance, for any softfork, that it interferes with *secret* mining algorithms, but we cannot learn it 07:49 < zmnscpxj__> I am not so sure we would not want to uproot anyway in the false case. 07:49 < zmnscpxj__> what if activation is *almost* reached when a problem is discovered 07:50 < zmnscpxj__> and miners continue signalling because reasons? 07:50 < zmnscpxj__> then sheer variance may trigger activation anyway and we still need to uproot 07:50 < somethingsomethi> it's good to have the option to uproot for sure 07:50 < zmnscpxj__> though admittedly, this may be a contrived case 07:51 < somethingsomethi> better if it can be avoided I guess 07:51 < roconnor> Indeed I think that is a worrying argument. I cannot tell if it is contrived or not. 07:51 < harding> zmnscpxj__: then we uproot anyway, as best as we can while minimizing losses. It's sort of like the value overflow incindent: the rules weren't working as expected, so the rules were changed immediately to what was expected. 07:51 < somethingsomethi> well, you could make the same argument by saying "what if the problem is discovered 3 days after activation" 07:59 < roconnor> harding: the real question is if prior to activation we woud uproot anyways rather than rely on miners to not activate? 08:01 < harding> roconnor: I think it's "hope for the best (miners stop signaling), prepare for the worst (miners blithly keep signaling)". 08:02 -!- benthecarman [~benthecar@185.45.15.206] has joined ##taproot-activation 08:08 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 08:37 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 08:42 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation 09:19 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 09:19 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 09:45 < jeremyrubin> [7/20/20 02:09] they could end up forking themselves off because they activated before the users do 09:46 < jeremyrubin> no quite because BIP8 activating requires that signaling be 100% in the LOCKED_IN period 09:46 < jeremyrubin> The move would be to make descending theshold guarantee 2 periods rather than 1, in order to activate at the same time as prior releases 09:53 < zmnscpxj__> ok 10:16 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds] 10:31 -!- joerodgers [~joerodger@141.98.255.147] has joined ##taproot-activation 10:33 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has quit [Ping timeout: 240 seconds] 11:44 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ddbe:6186:98b2:59ac] has joined ##taproot-activation 11:47 -!- benthecarman [~benthecar@185.45.15.206] has quit [Ping timeout: 264 seconds] 11:48 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ddbe:6186:98b2:59ac] has quit [Remote host closed the connection] 11:49 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0::44] has joined ##taproot-activation 11:56 -!- benthecarman__ [~benthecar@185.120.144.110] has joined ##taproot-activation 11:58 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0::44] has quit [Ping timeout: 256 seconds] 12:01 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation 12:53 -!- benthecarman__ [~benthecar@185.120.144.110] has quit [Ping timeout: 240 seconds] 13:06 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined ##taproot-activation 13:09 < harding> FYI, I've updated the document for what I think is all feedback to date; please tell me if I missed anything. Document: https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d ; diff: https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d/revisions#diff-e0ff3461e7d6448c94069d2264c6e46f 13:12 < roconnor> harding: Cool graph! I'd like to see the commit to accelerated activation starting at the 6m mark (with the understanding that the start time for such a deployment is not actually fixed) 13:13 < harding> roconnor: so BIP8(1y, true) bar drawn from month 6 to monh 18? 13:13 < harding> roconnor: graph was jeremyrubin's idea. 13:14 < roconnor> harding: yes from 6m to 18m. 13:14 < harding> Ok, updating. 13:14 < roconnor> I think that would better convey the idea. 13:15 < jeremyrubin> I think also the timeout can be set as like <1 year or something, just because 1 year is represented elsewhere, and it's safe with that deployment to use shorter times because older clients will follow along fine 13:16 < jeremyrubin> But idk roconnor do you particularly feel in the accelerated case it should be 1 yr? 13:16 < roconnor> jeremyrubin: I do feel that 1y is the minimum time needed for any BIP8(true) / flag day deployment of anything. 13:16 < jeremyrubin> roconnor: really? 13:16 < jeremyrubin> Even if there's a preceding overlapping bip8 false? 13:16 < roconnor> well I can probably be convinced for less. 13:17 < roconnor> jeremyrubin: I think so. I probably could be convinced otherwise 13:17 < harding> roconnor: better? https://dtrt.org/tmp/activation-timeline.png 13:18 < roconnor> harding: I know this is litterly bikeshedding, but how do you feel about "Abandon" with some sort of (light?) red text on white background. I feel like the bright red box is overly attention grabbing for that case. 13:18 < harding> roconnor: sure. 13:18 < jeremyrubin> Also could just add abandon to the other TL's too, as there is issues discovered for anything with a bip8 false start 13:19 < jeremyrubin> chart kinda makes it look like mSFA/DTSFA are the only ones that are safe if reason to abandon 13:19 < roconnor> I wonder if it is even worth putting the abandon lines in the chart at all. 13:19 < harding> I'd rather remove them than add them to bunch of things. 13:19 < roconnor> But my views might be coloured by my own prejudice. 13:20 < roconnor> I feel like abandoing is such an edge case that it is only worth decribing in the text. 13:21 < jeremyrubin> Interesting -- so just remove issues discovered row? 13:21 < harding> Ok, removed from my working copy. Any other changes? 13:21 < roconnor> I'll let harding judge. 13:21 < roconnor> harding: sorry I mostly looked at the graph so far. It is so compelling! 13:22 < jeremyrubin> +1 thanks for putting in the effort off of my lazily lobbed idea :) 13:23 < harding> Graph updated. 13:25 < jeremyrubin> I think it looks great overall! The only quibble I have is that for many of the timeout parameters they're still under discussion, e.g., MSFA with total time 24 or 36 mo, SNIL with acceleration 1 yr or not, etc. I'd be happy with a note that said "the final timeouts for each proposal may be adjusted downwards or upwards with community input" 13:26 < jeremyrubin> I think this document is a fantastic systemitization of the balls in the air. Nice work! 13:26 -!- _joerodgers [~joerodger@141.98.255.147] has joined ##taproot-activation 13:29 -!- joerodgers [~joerodger@141.98.255.147] has quit [Ping timeout: 246 seconds] 13:32 < roconnor> harding: Looks reasonable. I have no issues at with it at the moment. 13:32 -!- _joerodgers [~joerodger@141.98.255.147] has quit [Read error: Connection reset by peer] 13:38 < harding> jeremyrubin: note added, "Precise time parameters are still under discussion, with some people advocating moderately longer durations and some advocating moderately shorter durations. The entries below are examples meant to reflect the general idea behind a class of proposals." 13:39 < jeremyrubin> perfecto 13:40 < harding> I'll be afk soon, but anyone please let me know if there are any other suggestions. I'll try to add links and references to finish up the document tomorrow and then covert it to wiki syntax and put it on the Bitcoin Wiki. 13:41 < jeremyrubin> Is the plan to have a checkboxes thing for people marking what things they like? 13:41 < jeremyrubin> Or just put it out there first and see what people say 13:45 < harding> Maybe put it out there first and see if anyone adds any other classes of proposal to it that have the potential for significant traction. If not, then I think we can conclude the idea-formation part of the proposal process and use a checkboxes thing to see which ideas have broad support. 13:52 < jeremyrubin> I do think there are some people who are still in the 'just do a flag day' camp... I wonder if they'll come forward 14:08 < luke-jr> harding: the "issue discovered" thing seems to assume it's safe to deploy activation with issues; but that means miners could see an issue and decide to activate *because* they want it 14:08 < luke-jr> IMO we need to ensure and assume there are no issues before proceeding with activation at all 14:48 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation 15:08 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection] 15:33 <@moneyball> harding: fantastic summary! thank you 15:52 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection] 15:53 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation 17:06 -!- brg444 [uid207215@gateway/web/irccloud.com/x-ufeyungvvjpkpzbb] has quit [Quit: Connection closed for inactivity] 17:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:21 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation 17:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 17:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 18:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 19:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 19:44 -!- brg444 [uid207215@gateway/web/irccloud.com/x-zxjgezlttfypjotl] has joined ##taproot-activation 20:50 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has quit [Remote host closed the connection] 20:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 21:05 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has joined ##taproot-activation 21:08 < gmaxwell> I wanted to make a point I hadn't noticed before: https://www.reddit.com/r/Bitcoin/comments/hrlpnc/technical_taproot_why_activate/fyqbn8s/ Namely segwit went from initial public discussions to merged in _6 months_. You could perhaps debate some of the specifics (e.g. backdating segwit a bit to where we realized it could be softforked). The result remains the same: taproot has taken 21:08 < gmaxwell> multiple times longer in spite being a simpler, narrower change. It's also the case that segwit has gone reasonable well. I'm aware of two engineering shortcomings that might have been resolved with more time (at least one of which was known before it was merged), and I don't think anyone feels any particular regret about them. 21:09 < gmaxwell> I think without looking up the dates I was fasely feeling that segwit took longer than it did because the activation was delayed a lot. But when it comes to taproot activation what can be decided is mostly the earliest point. Sure, bip8 timeout=activate decides the latest point, but most proposals for that have had it pretty far out. 21:10 < gmaxwell> I just thought that might be useful fodder for people's thinking about how reasonable it is to add additional delays. 21:10 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has left ##taproot-activation [] 21:11 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-riveqdoqonlrguth] has joined ##taproot-activation 21:22 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 21:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 21:24 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation 21:26 -!- lukedashjr is now known as luke-jr 21:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 21:37 -!- rdymac [uid31665@gateway/web/irccloud.com/x-fasvjyjtbkoqaehj] has quit [Quit: Connection closed for inactivity] 22:32 -!- brg444 [uid207215@gateway/web/irccloud.com/x-zxjgezlttfypjotl] has quit [Quit: Connection closed for inactivity] 23:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 23:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 23:18 < sanket1729> What do people think of having the deployment code together with schnorr/taproot code under same release? 23:22 < luke-jr> sanket1729: that contradicts the goal of having activation in a .1 23:24 < sanket1729> Why is that goal important? 23:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation --- Log closed Tue Jul 21 00:00:25 2020