--- Log opened Fri Jul 17 00:00:22 2020
00:40 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
00:46 < CubicEarth> Hi channel!
00:46 < zmnscpxj__> hello CubicEarth!
01:19 -!- jeremyrubin [~jr@2601:645:c200:f539:cc9a:b428:d53:347b] has quit [Ping timeout: 260 seconds]
01:22 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
01:27 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
02:09 < cato_> zmnscpxj__: just read your ML post. thanks for the summary. can you point out the differences of the proposed approach to BIP8/false (12 months), discuss, BIP/true + BIP91?
02:16 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:01 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined ##taproot-activation
03:18 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:20 < zmnscpxj__> cato_: my understanding so far is that they are not practically different
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:55 < roconnor> cato_: I think the difference is that with the ML post the waiting 1 year is a time period that isn't fixed in stone by activation rules and we sould deploy BIP91-ish stuff earlier than 1 year.
03:56 < roconnor> cato_: IMHO we should wait until we see a large uptake by users and miner appathy.
03:56 < roconnor> and I suspect that will actually take less than 1 year.
03:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
04:12 < cato_> roconnor: that's true. but not having a fixed one-year waiting period leads to the question of how much waiting is enough to do something against apathy
04:14 < cato_> not defining a deadline for miners might actually increase their apathy when we want the exact opposite
04:15 < zmnscpxj__> The BIP8 lockinontimeout=true is intended to be a guard against miner apathy
04:22 < cato_> zmnscpxj__: yes, I understand. I was just exploring the differences between BIP8/true (42mo) and BIP8/false (12 months), discuss, BIP8/true + BIP91
04:22 < zmnscpxj__> ok
04:23 < cato_> and that the latter could result in faster adoption since the one-year deadline is part of the code
04:24 < cato_> whereas in the former it's more "informat", if that makes sense. plus, the second option (to me) has the benefit of not starting out with /true (maybe I'm naive in thinking it's a chance for 'healing' after segwit)
04:25 < cato_> that's supposed to be "informal"
04:26 < aj> is there any reason not to try a bip8/lockinontimeout=false activation for ~3 months first, and then react based on what happens there?
04:28 < cato_> aj: some people were arguing that the process* should from the start guarantee activation absent the discovery of a problem so contributors can already start building on top of taproot.
04:31 < aj> we're only willing to "guarantee" activation because we've got a way of backing it out; is that really a guarantee?
04:32 < aj> we're only willing to "guarantee" activation because we've got a way of backing it out; is that really a guarantee that people thinking about building on top of taproot will/should rely on?
04:32 < cato_> aj: you're right. I believe this argument was not made to those people
04:33 < aj> alternatively, would it be enough to just be trying to activate it to get a similar level of development?
04:36 < aj> csv took 3 retarget periods to lock in if my maths is right (490248 was before the starttime, leaving 411264, 413280, 415296 as started; lockin at 417312, active at 419328). 7 retarget periods would be about 3 months and a week
04:36 < aj> 409248 even
04:38 < cato_> I think it's a sensible approach
04:39 < cato_> using a short BIP8/false period would both address the fact that miner apathy should be detectable in less than a year; and it offers more flexibility after the discussion period than a fixed BIP8/true(42m) approach
04:41 < cato_> though it should be made clear that the intention is to follow the discussion period in case of apathy with BIP8/true+BIP91
04:44 < roconnor> bip8(false) 3m is certainly better than bip8(false) 1y.
04:48 < cato_> is there some place that lists previous soft forks and their activation times?
04:49 < cato_> if empirical data suggests uncontroversial forks went through in <3m this would lend some objective credibility to the proposal
04:58 < aj> hmm, would make sense to write up the history rather than looking it up each time
04:58 < zmnscpxj__> yes
05:08 -!- cato_ [~alec@gateway/tor-sasl/alec] has quit [Quit: leaving]
05:10 -!- cato_ [~cato@gateway/tor-sasl/alec] has joined ##taproot-activation
05:44 < cato_> CSV took 2 months and 3 days (started 2016-05-01, active 04-07-2016)
05:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
05:50 < aj> 05-11 was the first signalling block though i think?
06:04 < cato_> I thought start to active would be more relevant. If you think first signaling block to active is better then I can do some digging
06:08 < zmnscpxj__> I agree, start to active seems more relevant in general
06:08 < zmnscpxj__> first signalling is just a sign of apathy IMO :P
06:08 < aj> core won't signal until the state changes to STARTED
06:09 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
06:09 < aj> sorry, not first block with a signal, first block where signalling has any effect on the state machine, ie STARTED
06:09 < cato_> aj: yes, that's what my 'started' refered to
06:10 < cato_> I used the timestamp from bitcoin core's consensus source code
06:10 < aj> cato_: it needs to be height%2016 == 0 and mediantime >= timestamp
06:11 < aj> so block 411264 on 11th may i think
06:11 < zmnscpxj__> ah
06:11 < zmnscpxj__> so the height%2016 rounds it off to the next highest change
06:11 < zmnscpxj__> difficulty adjustment
06:12 < somethingsomethi> One thing that just occured to me: The earliest release with activation params will probably be .21.1, which should come out around Feb. So if we decide on e.g. bip8(false, 3m), discussion, bip8(true, 24m) _today_, we'll get a second 6m discussion period for free
06:12 < cato_> aj: right, I didn't take that into account
06:13 < aj> https://0bin.net/paste/hs-neMl6HoFgbGMF#oABW4m3EeGF6atAas83GHl9oxauUndqf7tDM4obb+OS is where i'm up to so far
06:13 < cato_> aj: perfect!
06:14 < zmnscpxj__> aj: +!
06:19 < somethingsomethi> (as in: 3m sounds kind of short, but 3m announced 6m beforehand seems a lot more reasonable)
06:20 < aj> cltv (bip 65) activation params were committed 2015-10-23, first v4 block mined 2015-11-04, 950/1000 threshold on 2015-12-14, so just over a month
06:35 < instagibbs> aj please commit that somehwere ;P
06:45 < instagibbs> Aside from op_eval, what softfork attempts had to be aborted?
06:45 < instagibbs> h/t roconnor (IIRC)
06:49 < instagibbs> I find this idea so remote for taproot vs say segwit, and besides, I don't think we'd manage to discover it with some undefined more months of eyeballs.
06:50 < zmnscpxj__> not to mention that with enough months, those eyeballs will water and start to wander off
06:50 < instagibbs> You're way more likely to discover an issue *after* activation at this point
06:51 < instagibbs> vs whenever we add the initial deployment to activation
07:03 < instagibbs> Status quo has its own user risks(fee dumping attacks on segwit inputs whoops), and natives getting restless and putting UASF hats back on. I was pretty agnostic on the topic prior to this channel, now I think additional machinery/delay in locking in activation(if we've done our best on the bips themselves) is very likely a net harm. Cheers :)
07:03 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has left ##taproot-activation ["Leaving"]
07:13 < aj> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
07:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
07:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
07:47 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
08:35 -!- rdymac [uid31665@gateway/web/irccloud.com/x-sntryjqfbddjctpr] has quit []
08:36 -!- rdymac [uid31665@gateway/web/irccloud.com/x-twrdgyebajyhkrey] has joined ##taproot-activation
08:36 -!- _joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
08:39 -!- joerodgers [~joerodger@45.83.220.166] has quit [Ping timeout: 240 seconds]
08:40 < harding> Might be worth adding https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc to the /topic as I can see quite a few people wanting to reference that
08:41 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
08:42 -!- _joerodgers [~joerodger@45.83.220.166] has quit [Ping timeout: 240 seconds]
08:46 -!- jeremyrubin [~jr@2601:645:c200:f539:54be:4a55:2181:13cb] has joined ##taproot-activation
08:51 < waxwing> what do '750 threshold', '950 threshold' mean .. is that 75% 90% etc?
08:57 < jeremyrubin> somethingsomethi: is that "the earliest release with actgivation params.. will come out around Feb" a uncontroversial view? Is there any reason not to add Taproot as a point release on 0.20?
09:07 < aj> waxwing: those were rolling 1000-block, 750-of-the-last-1000 meant the rules got enforced in blocks with the new version, 950-of-the-last-1000 meant prior version blocks were invalid thereafter
09:08 -!- benthecarman [~benthecar@185.45.15.206] has joined ##taproot-activation
09:11 < waxwing> ah gotcha thanks
09:38 < harding> jeremyrubin: adding it to 0.20.x would run counter to the way the project did segwit, which was to include almost all the code in 0.13 (including running it by default when started with testnet) and then including just the activation parameters (and some other last-minute details) in 0.13.1.  See https://bitcoincore.org/en/releases/0.13.0/#segregated-witness and https://bitcoincore.org/en/releases/0.13.1/#segregated-witness-
09:38 < harding> soft-fork
09:40 < harding> jeremyrubin: it was my impression that people liked that arrangement and wanted to repeat it for taproot, but I don't know for sure.
09:40 < jeremyrubin> I think that makes sense for segwit because there were massive p2p changes, storage changes, etc all across the codebase
09:41 < jeremyrubin> I don't think the same logic applies for Taproot
09:46 < jeremyrubin> For example I think CheckSequenceVerify was done in a minor with no logic ahead of time
09:49 < jeremyrubin> (confirmed: 0.12.0 had no logic or activation, 0.12.1 had logic and activation)
09:52 < harding> jeremyrubin: hah, just confirmed it myself.
09:57 < harding> Personally, I think I'd prefer to have both logic and activation in a point release.  I didn't like how segwit made it hard to review the final diff.  So I can't think of a good reason not to do it as a 0.20.x point release.
09:58 < jeremyrubin> my view is mostly that if CSV is at one end, and SegWit is at another, Taproot is much closer to CSV than it is to SegWit. A big part of that being that SegWit particularly laid groundwork for making future changes like this much much much easier to deploy, which motivated having SegWit swallow a huge complexity pill for deployment. Now we don't have to do that again for script changes like Taproot :)
09:58 < harding> (Beyond the usual annoyance of backporting anything more than a few weeks after a branching.)
10:03 < jeremyrubin> another way to look at it is if this were the expectation, we probably would have merged taproot logic in 0.20 :)
10:08 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Ping timeout: 246 seconds]
10:08 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
10:10 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Read error: Connection reset by peer]
10:10 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
11:12 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
11:14 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
11:14 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
11:16 < somethingsomethi> jeremyrubin: I mean if you can convince Core to not only merge taproot (and update secp256k), but to also backport this into 0.20, more power to you!
11:21 < somethingsomethi> might be an idea to bring this up at the next IRC meeting actually, just to see how the reactions are
11:25 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
11:42 -!- jeremyrubin [~jr@2601:645:c200:f539:54be:4a55:2181:13cb] has quit [Ping timeout: 260 seconds]
11:56 < luke-jr> harding: both together seems best IMO - 0.21.0 with logic, 0.21.1 activating it, and 0.20.2 backport with logic+activation
11:56 < luke-jr> but that assumes people want to wait until 0.21 is released
13:06 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
13:07 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
13:08 -!- jeremyrubin [~jr@2601:645:c200:f539:80dd:c5af:615d:d30c] has joined ##taproot-activation
13:09 -!- jnewbery [~john@164.90.178.190] has joined ##taproot-activation
14:12 -!- benthecarman_ [~benthecar@185.163.110.69] has joined ##taproot-activation
14:15 -!- benthecarman [~benthecar@185.45.15.206] has quit [Ping timeout: 246 seconds]
14:26 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer]
14:48 -!- benthecarman_ [~benthecar@185.163.110.69] has quit [Ping timeout: 260 seconds]
14:54 < jeremyrubin> fwiw I did run the following 2 twitter polls, https://twitter.com/JeremyRubin/status/1283873417301639169 and https://twitter.com/JeremyRubin/status/1283879638435950594. By no means representative samples of all bitcoin users, but does indicate that there's probably some confusion around major/minor upgrades at least among the people likely to respond to a twitter poll of mine.
15:36 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
15:38 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
15:53 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
15:56 -!- orbital75 [6c06074e@pool-108-6-7-78.nycmny.fios.verizon.net] has joined ##taproot-activation
16:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:05 -!- orbital75 [6c06074e@pool-108-6-7-78.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]
16:05 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
16:06 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
16:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
16:35 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
16:38 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:00 -!- benthecarman [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has joined ##taproot-activation
18:06 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has joined ##taproot-activation
18:10 -!- benthecarman [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has quit [Ping timeout: 256 seconds]
18:15 -!- benthecarman__ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has joined ##taproot-activation
18:19 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has quit [Ping timeout: 256 seconds]
18:27 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has joined ##taproot-activation
18:31 -!- benthecarman__ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has quit [Ping timeout: 260 seconds]
18:41 -!- benthecarman__ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has joined ##taproot-activation
18:45 -!- benthecarman__ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has quit [Client Quit]
18:45 -!- benthecarman_ [~benthecar@2600:1700:bb80:db0:ed28:8484:f752:18c] has quit [Ping timeout: 256 seconds]
22:22 < cato_> I think if there has been precedent in the past, it is fine to bundle logic and activation if a sequential approach would cause unnecessary delays
22:23 < cato_> at least if the first activation is *not* bip8/true
23:08 < luke-jr> cato_: eh?
23:08 < luke-jr> current precedent is basically bip8/true
23:10 < cato_> luke-jr: yesterday the idea came up of doing a bip8(false, 3m) before the discussion period and another bip8(true, ?m)
23:10 < luke-jr> cato_: seems overcomplex for no gain
23:11 < luke-jr> and likely to confuse users
23:11 < luke-jr> "but I thought I had Taproot version already"
23:11 < cato_> luke-jr: aj created a list of previous soft forks and uncontroversial ones took <3m from signaling to activation
23:11 < luke-jr> when planning beyond the 3m point, it makes no sense to talk about experiences where it took ♥m :P
23:17 < cato_> IMO there's no harm in doing a bip(false, 3m) first. you'd be more flexible after the discussion period, even though the intended path of following up with a bip8(true) (+bip91) should be communicated from the start
23:21 < cato_> ideally, it goes through very quickly as previous hard forks, without the (controversial?) lockinontimeout=true
23:21 < cato_> if it doesn't, you could just subtract the three months from the final deadline. also it sends a clear signal to all users: either miners bring up objective reasons in the discussion period or we go ahead with lockinontimeout=true
23:24 < cato_> err.. soft forks
23:25 < cato_> and uncontroverial ones, I meant
--- Log closed Sat Jul 18 00:00:27 2020