--- Log opened Wed Jul 15 00:00:21 2020
00:32 -!- maaku [~quassel@ec2-54-186-10-232.us-west-2.compute.amazonaws.com] has joined ##taproot-activation
00:36 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-sofhgbgipqnwccsq] has joined ##taproot-activation
00:45 -!- rdymac [uid31665@gateway/web/irccloud.com/x-jhjshgzomxfhhudn] has quit [Quit: Connection closed for inactivity]
01:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds]
01:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:02 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
02:07 -!- rdymac [uid31665@gateway/web/irccloud.com/x-sntryjqfbddjctpr] has joined ##taproot-activation
02:22 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has joined ##taproot-activation
02:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:45 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:09 -!- jonatack [~jon@static-176-139-55-163.ftth.abo.bbox.fr] has quit [Ping timeout: 258 seconds]
03:27 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
03:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
05:01 -!- roconnor [~roconnor@host-45-58-208-39.dyn.295.ca] has quit [Quit: Konversation terminated!]
05:04 -!- roconnor [~roconnor@host-45-58-208-39.dyn.295.ca] has joined ##taproot-activation
05:09 -!- Ed0 [~edouard@137.ip-193-70-113.eu] has joined ##taproot-activation
05:24 < pinheadmz> BIP8 question: I don't understand the FAILING state: if the threshold has not been reached before timeout, under what circumstances would 100% of the hash rate suddenly start signaling unanimously?
05:27 < roconnor> The most likey circumstance would be another simulatenous depolyment of a soft fork that requires the orginal version bit to be signaled for all blocks.
05:29 < pinheadmz> interesting. say a social compromise was mostly agreed to tighten taproot rules after deployment but before activation... like a soft-fork of a soft-fork. Then the newest rule set could force the base rule set to lock in
05:29 < roconnor> such a second soft fork, which activates the first soft fork, not only achieves node activation for those supporting the second soft fork, it also achieves activation for nodes supporting the original soft fork.
05:30 < roconnor> I'm not certain I understand you, but yes a second soft-fork could not only activate the original softfork, but also layer its own new rules on top of the original taproot rules, if needed.
05:31 < pinheadmz> yeah i gotcha tnx
05:31 < roconnor> The taproot-abort mechinism of enabling a soft-fork to disable all segwit v1 outputs could be viewed as an extreme case of this.
05:32 < pinheadmz> why would taproot need to be force-activated to disable sw v1 outputs?
05:32 < roconnor> (Not that I have any reason to believe that such a tapoot-abort would end up being needed, but the option is always there in case of extrodinary circumstances)
05:33 < pinheadmz> this is a fast move too right? the decision to deploy the second fork must be made in the final retarget period, after enough blocks fail to signal that a FAILING state is certain
05:33 < roconnor> It's mostly a thought experiment that shows that even for BIP8 activate-on-default, the effect of BIP8 fail-on-default can still be simulated by deploying a second soft fork that disables segwit v1.
05:34 < roconnor> It would be used if there is some sort of unknown catostrophic reason to not deploy taproot, although it is basically unfathomable to me that such a reason would appear.
05:35 < pinheadmz> Schnorr's heirs renew the patent :-)
05:37 < roconnor> Right, such a catostrophic reason would need a fast deployment.  While not a great time line, we have had what I guess you might call catastrophic failures that needed urgent upgrades in the past.  And such a depolyment to disable taproot would be less dangrous than that.
05:38 < roconnor> Again, I have no reason to suspect that there is anything wrong with taproot or even that there is room for anything to go wrong.  Taproot is far more benign than segwit was, in that it just touches less things: no P2P logic, no blocksize increase, etc.
05:39 < pinheadmz> I still don't see why a second soft fork `bit 2 -> invalidate SW v1` would require the "all blocks signal (bit 1 -> activates taproot)" mechanism describe in BIP8
05:39 < roconnor> Not that there was anything wrong with SegWit either.  Just that I think it is safe to say it was a bit riskier.
05:40 < roconnor> That's true, it probably doesn't require the underlying first version bit to activate.
05:40 < pinheadmz> ok yeah
05:40 < pinheadmz> but perhaps like `bit 2 -> only leaf version 0xc0 is valid`
05:40 < pinheadmz> like "we agree taproot is good, but we want to tweak it"
05:41 < roconnor> Right, and in fact if there is some significant problem with taproot discovered, we probably don't have to go as far as invalidating all v1 outputs, that's just the worst case option.
05:41 < roconnor> we can probably fix whatever the problem is with a soft-fork on top of taproot.
05:41 < pinheadmz> excellent cool
05:42 < roconnor> Again taproot has gone through quite a review process, https://bitcoinops.org/en/schorr-taproot-workshop/, and I don't think there is reason to expect any significant problems.
05:43 < pinheadmz> +1 been there :-) reviewed, contributed :-)
05:44 < roconnor> In that case, thank you for helping move taproot forward!
06:14 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]
06:15 -!- ChadBitcoiner [54113f0b@84.17.63.11] has joined ##taproot-activation
06:23 -!- tiagocs [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has joined ##taproot-activation
06:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
06:50 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
06:51 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
06:53 < instagibbs> is anyone interested in buffing the test cases for the Core PR? I think that's one practical thing to be done that precedes any sort of merge to Core effort/deployment
06:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
07:21 -!- _joerodgers [~joerodger@45.83.220.165] has quit [Read error: Connection reset by peer]
07:21 -!- joerodgers [~Thunderbi@45.83.220.165] has quit [Quit: joerodgers]
07:23 -!- joerodgers [~joerodger@141.98.255.147] has joined ##taproot-activation
07:24 -!- joerodgers1 [~Thunderbi@141.98.255.147] has joined ##taproot-activation
07:28 < aj> instagibbs: tests could also be added as a separate pr; would be great either way
07:44 < roconnor> Perhaps a broadly acceptable activation plan would be something like a 2 year BIP-8 with default-fail and then after 6 or 9 months if we observe a broad takeup in the community, then deplying a 1 year BIP-8 default-activate to force activation of the previous version bits.
07:45 < roconnor> While I personally feel this is overly conservative, I think it might enjoy broad support.  And if it means getting started sooner that would be super great.
07:47 -!- tiagocs [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has quit [Ping timeout: 245 seconds]
08:01 -!- benthecarman_ [~benthecar@185.45.15.222] has quit [Quit: Leaving]
08:03 -!- benthecarman [~benthecar@185.45.15.222] has joined ##taproot-activation
08:08 < instagibbs> aj, right, I more meant getting a concerted effort together to note what needs to be tested and checking off boxes. I did a high-level review of the PR, now thinking about zooming in and don't want to duplicate work with others
08:23 -!- tiagocs [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has joined ##taproot-activation
08:25 < tiagocs> I like the idea of a decreasing threshold for activation: https://github.com/ajtowns/bips/blob/202007-activation-dec-thresh/bip-decthresh.mediawiki
08:28 < tiagocs> I think the signaling for activation shouldn't be done with just one bit: either yes or no; there should be three options: yes, no or abstain (the default). This way it would be easier to distinguish abstentions from votes against and activation could be based on the ratio (votes for)/(votes for + votes against)
08:30 < benthecarman> I think segwit showed us that miners shouldn't have a vote, users should decide and the activation process is just to allow miners time to upgrade
08:33 < roconnor> tiagocs: activation bits are not a vote.  They are supposed to be a signal that you are ready to start enforcing the new rules as soon as everyone else is ready.
08:33 < roconnor> it is a coordination mechanism.
08:35 < instagibbs> miners only have a vote, so to speka, in helping reduce reorg risk, which is in their interest hopefully
08:36 < instagibbs> considering mining on a pre-sf chain has risk of wipeout
08:36 < roconnor> I don't think it is useful to call that voting.
08:38 < instagibbs> sad!
08:41 < tiagocs> I am just throwing the idea out there. people have been talking about 'mining apathy', having three signaling options could solve that. The problem with segwit IMO was that the 95% threshold was too high. I like new decreasing threshold BIP because it lowers the threshold to 60% without forcing anything. Actually just changing BIP9 threshold from
08:41 < tiagocs> 95% to 60% would be fine I think.
08:42 < roconnor> Right I think the lowering the threshold has some merit.
08:42 < roconnor> Although activate-on-timeout is an even stronger option for dealing with mining apathy.
08:43 < roconnor> argubly that is simply lowering the threshold down to 0%.
08:43 < benthecarman> I agree, but I think just doing bip 9 with 60% threshold could cause problems, a couple pools could implement quickly and drop off a big chunk of the hashpower
08:43 < roconnor> Right, we'd want to lower it down to 60% over time.
08:43 < instagibbs> this is why start date matters too
08:43 < benthecarman> Yeah
08:44 < instagibbs> regardless of what miners do, we want people updated
08:44 < roconnor> The lower the threshold the more users need to be upgraded.
08:44 < roconnor> Of course, all users should upgrade.  But I respect that it takes more time for some than it does for others.
08:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
09:03 -!- tiagocs [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has quit [Remote host closed the connection]
09:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
09:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
09:35 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
09:40 < jeremyrubin> instagibbs: if you lower the threshold, then my suggestion around min activation time makes more sense
09:43 < jeremyrubin> Because all following blocks after locked in must also signal until activated, longer time of mandatory signaling after lock in gives time to shake out the chain
09:48 < jeremyrubin> But maybe this doesn't actually help users detect invalid chains...
09:49 < jeremyrubin> light clients...
09:52 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
10:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:34 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 260 seconds]
10:46 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined ##taproot-activation
11:14 < cato_> takinbo: I didn't do the math but I saw claims that by chance a much lower percentage of hashpower might reach a particular number of blocks in a window
11:15 -!- pinheadmz [~pinheadmz@mobile-107-107-62-99.mycingular.net] has joined ##taproot-activation
11:15 < cato_> so 60% might be achieved even significantly less than half of the hashpower is signaling. don't know whether this is worth paying attention to. just wanted to put it out there
11:40 < jeremyrubin> well I'm still not sure on the math, but this would appear to be incorrect if binomial is the correct model for this process.
11:40 < jeremyrubin> np.sum((np.random.binomial(2016, 0.58, (26, 1000)) > 2016*0.6).any(axis=0))/1000.0
11:41 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
11:45 -!- brg444 [uid207215@gateway/web/irccloud.com/x-sztihtzvkpicjxct] has joined ##taproot-activation
12:02 -!- joerodgers [~joerodger@141.98.255.147] has quit [Read error: Connection reset by peer]
12:02 -!- joerodgers1 is now known as joerodgers
12:02 -!- joerodgers [~Thunderbi@141.98.255.147] has quit [Quit: joerodgers]
12:04 -!- joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
12:04 -!- joerodgers1 [~Thunderbi@45.83.220.166] has joined ##taproot-activation
12:13 -!- joerodgers [~joerodger@45.83.220.166] has quit [Quit: Leaving]
12:13 < cato_> jeremyrubin: I agree. assuming that binomial is correct
12:13 -!- joerodgers1 [~Thunderbi@45.83.220.166] has quit [Read error: Connection reset by peer]
12:14 -!- _joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
12:14 < cato_> but the propability also seems zero for reaching 95% of blocks with 80% of the hashpower, something you mentioned earlier. or am I missing something?
12:15 -!- _joerodgers [~joerodger@45.83.220.166] has quit [Client Quit]
12:21 < cato_> at least variance biasing the measurement of the actual hashpower should no longer be a concern if your math is correct
12:23 -!- joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
12:24 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
12:53 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
12:56 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:58 -!- pinheadmz [~pinheadmz@mobile-107-107-62-99.mycingular.net] has quit [Ping timeout: 265 seconds]
13:37 < jeremyrubin> There are a few reasons why I'm skeptical of binomial, but BIP8 addresses those by making the start and end times both in blocks rather than MTP.
13:37 < jeremyrubin> So for BIP8 vs BIP9 logic is different because of MTP
14:04 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
14:27 -!- ChadBitcoiner [54113f0b@84.17.63.11] has quit [Remote host closed the connection]
14:59 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:c53f:e110:26a8:7389] has joined ##taproot-activation
15:01 -!- benthecarman [~benthecar@185.45.15.222] has quit [Ping timeout: 258 seconds]
15:05 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:c53f:e110:26a8:7389] has quit [Remote host closed the connection]
15:05 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:e1e8:cf7f:3a20:9fa9] has joined ##taproot-activation
15:10 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:e1e8:cf7f:3a20:9fa9] has quit [Remote host closed the connection]
15:10 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:1cca:a26b:8e8:edd8] has joined ##taproot-activation
15:15 -!- _joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
15:17 -!- joerodgers [~joerodger@45.83.220.166] has quit [Read error: Connection reset by peer]
15:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds]
15:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
15:20 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:1cca:a26b:8e8:edd8] has quit [Remote host closed the connection]
15:20 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:58dd:276c:82ea:692] has joined ##taproot-activation
15:27 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
15:29 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:58dd:276c:82ea:692] has quit [Remote host closed the connection]
15:29 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:dc1b:9dfc:bf6a:5176] has joined ##taproot-activation
15:34 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:dc1b:9dfc:bf6a:5176] has quit [Remote host closed the connection]
15:34 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:1415:882:3070:7ec1] has joined ##taproot-activation
15:36 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:1415:882:3070:7ec1] has quit [Remote host closed the connection]
15:36 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:f90d:1afa:d44a:5ae0] has joined ##taproot-activation
15:44 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:f90d:1afa:d44a:5ae0] has quit [Ping timeout: 260 seconds]
17:13 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.7.5 - https://znc.in]
17:14 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined ##taproot-activation
17:20 -!- brg444 [uid207215@gateway/web/irccloud.com/x-sztihtzvkpicjxct] has quit [Quit: Connection closed for inactivity]
18:59 -!- jeremyrubin [~jr@2601:645:c200:f539:6825:208:c554:712b] has quit [Ping timeout: 256 seconds]
19:47 -!- cato_ [~alec@gateway/tor-sasl/alec] has quit [Remote host closed the connection]
19:47 -!- cato_ [~alec@gateway/tor-sasl/alec] has joined ##taproot-activation
23:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
--- Log closed Thu Jul 16 00:00:23 2020