--- Log opened Thu Jul 23 00:00:27 2020
00:29 -!- keblek [~Thunderbi@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has joined ##taproot-activation
00:32 < keblek> hello
00:38 -!- keblek [~Thunderbi@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has quit [Quit: keblek]
00:38 -!- keblek_ [~textual@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has joined ##taproot-activation
00:38 -!- keblek_ [~textual@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has left ##taproot-activation []
00:46 -!- keblek [~textual@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has joined ##taproot-activation
00:59 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
01:00 < somethingsomethi> fanquake: yeah I know and I tried to post that yesterday, but it didn't show up. Maybe I'll try to figure out what the problem is, although it probably would be better if someone more technically competent would bring it up
01:03 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
01:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:36 -!- keblek [~textual@2001:1c04:2a13:2400:35c8:9db1:e33f:e902] has quit [Ping timeout: 260 seconds]
01:56 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
02:09 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##taproot-activation
02:13 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 260 seconds]
02:14 -!- jonatack [~jon@82.102.27.195] has joined ##taproot-activation
02:28 < harding> I think I'd prefer to see an early release of 0.21 shortly followed by a 0.21.x taproot activation release rather than a half-assed 0.20.x taproot backport.  We've done early release before, e.g. "we’re also not going to wait the normal six months before the next major update" from https://bitcoincore.org/en/2017/09/01/release-0.15.0/#the-future-p2sh-wrapped-segwit-addresses
02:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
02:35 < somethingsomethi> yeah, something like the segwit wallet releas sounds plausible
02:37 < somethingsomethi> I guess the only question would be if that leaves anything in a half-finished state (like descriptor wallets or the sqlite storage)
03:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:21 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has joined ##taproot-activation
03:22 < gmaxwell> per reports 0.20 apparently broken a bunch (most of?) the open source mining software, https://bitcointalk.org/index.php?topic=5253096.msg54839526#msg54839526 an example of miners not upgrading promptly to new .0 versions and for good cause.
03:22 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has left ##taproot-activation []
03:34 -!- jonatack [~jon@82.102.27.195] has quit [Ping timeout: 240 seconds]
03:35 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##taproot-activation
03:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
03:46 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has quit [Ping timeout: 260 seconds]
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
04:02 -!- cato_ [~cato@gateway/tor-sasl/alec] has quit [Remote host closed the connection]
04:02 -!- cato_ [~cato@gateway/tor-sasl/alec] has joined ##taproot-activation
04:57 -!- horst [~ckarl@ip5f5a0425.dynamic.kabel-deutschland.de] has joined ##taproot-activation
05:13 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 240 seconds]
05:26 -!- lowentropy [~lowentrop@unaffiliated/lowentropy] has joined ##taproot-activation
05:35 -!- Davterra [~Davterra@37.120.208.253] has quit [Ping timeout: 240 seconds]
06:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
07:18 < roconnor> harding: following 0.21 quickly by a 0.21.x taproot seems to defet the purpose of putting activation in a minor release.  If miners are unable to get onto 0.21, then they are going to be unable to get onto 0.21.x  In that sense a 0.20.x taproot activation just before 0.21 would be kinda idea.
07:18 < roconnor> but if a 0.20.x taproot activation is unfeasible, then it cannot be helped.
07:19 < harding> roconnor: my understanding is that the point of putting soft forks into minor releases is so people aren't forced to adopt them in order to get all the other upgrades available in a major release.
07:20 < roconnor> ah true.
07:24 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
07:24 < harding> (gmaxwell's point above about mining is well made, though.)
07:37 < harding> Related to miners being slow to upgrade, consider f2pool's response to segwit: “Since our system cannot build C++11, I would like put this on hold for a while, until we can get our new servers online up and running,” Chun said. “Next spring, maybe.”  https://bitcoinmagazine.com/articles/where-bitcoin-mining-pools-stand-on-segregated-witness-1480086424
07:43 < roconnor> harding: is 0.21 migrating to C++17?
07:45 < aj> 0.22 is migrating to c++17 i think?
07:45 < harding> roconnor: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md#compatibility says, "During this release cycle, work has been done to ensure that the codebase is fully compatible with C++17. The intention is to begin using C++17 features starting with the 0.22.0 release. This means that a compiler that supports C++17 will be required to compile 0.22.0."
07:47 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
07:49 -!- brg444 [uid207215@gateway/web/irccloud.com/x-eamzwkvbopkgfnrs] has joined ##taproot-activation
07:51 < roconnor> whew.
07:54 -!- Davterra [~Davterra@37.120.208.253] has joined ##taproot-activation
09:24 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has joined ##taproot-activation
09:41 -!- somethingsomethi [~parallels@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
10:01 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-qfulkzvxyqqpsmmm] has joined ##taproot-activation
10:02 < somethingsomethi> FYI I proposed the taproot backporting thingie as a topic for the bitcoin-core-dev meeting today. Starts in about two hours
11:10 -!- horst [~ckarl@ip5f5a0425.dynamic.kabel-deutschland.de] has quit [Quit: Leaving.]
11:13 < luke-jr> roconnor: 0.21.1 and 0.20.2 perhaps
11:14 < luke-jr> oh, just saw aj's comment on the wtxid relay issue
12:10 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##taproot-activation
12:12 < instagibbs> jeremyrubin, necro-ing the topic from looks like yesterday, BitMEX(100x group now) is really interested in funding ecosystem work, and very cautious in supporting softforks. Right now our stance is that there's enough non-consensus that needs work we'd rather focus on finding/funding those opportunities. Goes for taproot/CTV/decentralized sidechains/whatever.
12:13 < instagibbs> (I'm saying this to others, surely you know)
12:13 < instagibbs> re: 10:12 < jeremyrubin> I think they -- and really any excahnge -- would be unlikely to publish something about an activation
12:13 < instagibbs> 10:13 < jeremyrubin> best person to ask here is instagibbs most likely
12:26 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
12:35 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
12:37 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
12:37 -!- rottensox [~rottensox@unaffiliated/rottensox] has left ##taproot-activation []
12:50 < luke-jr> so in today's bitcoin core dev meeting, we discussed the issue of wtxid relay on the network being a possible blocker for Taproot
12:50 < roconnor> I was following along.
12:50 < luke-jr> 0.20 doesn't have it, and backporting could be difficult, but it's needed to relay Taproot transactions
12:51 < luke-jr> but it's also possible to deploy/activate Taproot consensus without allowing relay of Taproot transactions, so in theory that could proceed in parallel
12:53 < roconnor> Backporting libsecp256k1 to 0.20.x sound like it would be feasible.
12:54 < luke-jr> just a merge to a newer version I think
12:56 < instagibbs> libsecp should be super safe(I think?)
12:56 < instagibbs> (assuming the codebase itself doesn't have regressions)
12:56 < roconnor> Right. libsecp256k1 and wtxid relays were the things that were brought up regarding the difficulty to backport.
12:57 < luke-jr> roconnor: Gentoo has libsecp256k1 debundled, and mixing versions works fine for the most part
12:57 < instagibbs> Merging consensus and delaying policy to 0.21 doesn't sound like the worst idea....
12:57 < luke-jr> obviously for Taproot we'll need to bump a minimum version
12:57 < roconnor> So it sounds to me people who are eager to see the *possible* activation of taproot pre 0.21 should work towards creating a backport then?
12:58 < luke-jr> instagibbs: IMO it's a great idea
12:58 < roconnor> luke-jr: Facinating info regarding Gentoo.  Maybe I should enable that in NixOs...
12:58 < instagibbs> luke-jr, I thikn it's the only feasible idea
12:58 < instagibbs> without making wumpus ragequit :)
12:59 < luke-jr> roconnor: Knots is split into separate syslibs and functional patchsets, so it's easy to just use the former if Core is desired
12:59 < instagibbs> or waiting relatively forever(sipa couldn't even give an answer how long wtxid ability would have to stew before activation..)
12:59 < luke-jr> instagibbs: another bonus is that if there's disagreement on policy readiness, anyone can fork with their own policy changes ;)
13:00 < instagibbs> ah, your master plan unveiled!
13:00  * instagibbs maniacal laughter 
13:00 < luke-jr> nah, doubt it will be an issue
13:01 < luke-jr> (to the extent that I'm considering not bothering with wtxid relay in Knots 0.20.1)
13:02 < roconnor> Based on my limited understanding, I'm totally on board with the idea that rejecting non-conforming taproot blocks is way more important than relaying taproot transactions.
13:02 < luke-jr> otoh, including it could give more people a reason to switch in the near term
13:02 < instagibbs> So: Attempt to get consensus/policy merged into master, backport consensus to 0.20.X
13:03 < instagibbs> feature freeze is Oct 15
13:03 < luke-jr> instagibbs: ideally, we'd split the PR between consensus and policy upfront, but I don't know if sipa can be convinced
13:03 < instagibbs> for 0.21
13:03 < luke-jr> hopefully the commits inside the PR are divided evenly
13:04 < instagibbs> policy was quite simple IIRC
13:04 < instagibbs> https://github.com/bitcoin/bitcoin/pull/17977/commits/388b7df5cfe8731911587359017ab11bde43ef51
13:05 < instagibbs> yeah one additional witness standardness check, and upgrade hooks
13:07 < instagibbs> well either way, it's easy to split. The tests will break a bit but should just be commenting out the testmempoolaccept calls....
13:09 -!- somethingsomethi [~parallels@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
13:10 < luke-jr> or args to change policy
13:10 < luke-jr> surely acceptnonstdtxn would do it?
13:10 < instagibbs> yeah that was my assumption
13:10 < instagibbs> well it's checking standardness of taproot so it'd have to be some other value
13:11 < instagibbs> a hidden test only arg that is removed later?
13:11 < luke-jr> sounds like a bug
13:11 < luke-jr> acceptnonstdtxn should accept anything valid
13:11 < instagibbs> yes, but I'm saying th etest itself is checking for standardness
13:11 < luke-jr> ah
13:11 < instagibbs> so yeah change the test fixes it too
13:12 < instagibbs> not a big deal
13:12 < luke-jr> might actually be best to have an *additional* commit to disable the relay?
13:12 < instagibbs> "revert me" :)
13:12 < luke-jr> well, we'd only put it in the backports
13:14 < instagibbs> back to consensus, it would have to be split off from master, get 0.21.0 out, then once that's final, stick one more commit and do 0.12.1?
13:14 < instagibbs> (activation commit)
13:14 < instagibbs> obviously people can be testing both of these at same time
13:14 < luke-jr> no
13:14 < instagibbs> what was the conclusion then
13:14 < luke-jr> once it's merged to master, we can immediately backport, add the relay-blocker commit, then release 0.20.2
13:14 < luke-jr> let 0.21 continue on its own schedule
13:15 < luke-jr> the whole point of splitting is to get the consensus going sooner
13:15 < instagibbs> you're saying 0.21.0 would contain activation params?
13:15 < luke-jr> 0.20.2 would
13:15 < luke-jr> starttime could be 0.21.0 target Dec 1st or something
13:16 < luke-jr> well, depending on when 0.20.2 is ready
13:16 < instagibbs> so when would 0.21.X have it? Seems odd no one can update to descriptor wallets without making themselves unaware to taproot...
13:16 < instagibbs> or whatever other feature
13:16 < luke-jr> hmm
13:16 < luke-jr> well, you know my position is the main Core releases shouldn't have activation params anyway :P
13:17 < luke-jr> but if people insist, we could have a GUI option at first upgrade
13:18 < instagibbs> heh. Ok just feeling out opinions here. I think the choice (in releases) at a min can be given, which is sort of like a knob
13:18 < instagibbs> if people don't like knobs
13:33 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
13:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
13:43 -!- turbodroid [~androirc@178.197.228.78] has joined ##taproot-activation
13:44 < instagibbs> luke-jr, what's the state of bip8 in Core? I presume it's pretty simple to apply/backport
13:45 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
13:50 -!- turbodroid [~androirc@178.197.228.78] has quit [Ping timeout: 246 seconds]
13:53 < luke-jr> instagibbs: there's a reference implementation, I *think* based on 0.20
13:53 < luke-jr> no, looks like based on master from a few weeks ago
13:53 < luke-jr> maybe I should open a PR?
13:54 < roconnor> Isn't it okay to merge activation into 0.21 as long as we backport it to 0.20.X?
13:54 < jeremyrubin> luke-jr: the one thing I'd like to see analyzed is how well overlapping periods work with bip8 as is
13:55 < instagibbs> luke-jr, ack on PR
13:55 < roconnor> Presumably we'd have to if we want activation in 0.20.X?
13:55 < luke-jr> jeremyrubin: they basically don't I suspect
13:55 < luke-jr> I'll make it a WIP PR for now, since I expect changes
13:55 < instagibbs> great
13:55 < jeremyrubin> how does that impact the BIP8 false accelerate proposls?
13:55 < jeremyrubin> luke-jr: ack on PR
13:55 < instagibbs> you mean one deployment?
13:56 < instagibbs> I thought it would be two deployments, the 2nd just overriding the first?
13:56 < roconnor> there are at least two different methods of accelleration.
13:56 < roconnor> *potential methods.
13:56 < jeremyrubin> not sure what deployment means in this context, but it would be good to have the potential mechanisms well spec'd
13:56 < instagibbs> deployment is giving a bit meaning, pretty much
13:56 < jeremyrubin> The two methods I see are lowered threshold or earlier time
13:57 < luke-jr> instagibbs: depends on https://github.com/bitcoin/bitcoin/pull/19401
13:57 < jeremyrubin> The only safe way with BIP8 rn is to use a new bit and require that the new bit after lock in trip the old bit
13:57 < jeremyrubin> But then you can have a split brain thing where you have more support than it looks like
13:57 < jeremyrubin> e.g., new bit at 50%, old bit independently at 50%
13:57 < roconnor> jeremyrubin: by two methods I mean using a second bit to activate the first bit or just reusing the first bit and farcing it to activate (earlier).
13:58 < jeremyrubin> reusing the first bit is far simpler
13:58 < jeremyrubin> or at least seems to be
13:58 < instagibbs> bip91'ish?
13:58 < jeremyrubin> unless you decrease the threshold
13:58 < jeremyrubin> then the new bit people need 2 periods of lock in
13:58 < roconnor> instagibbs: yes bip91ish but I've tried to avoid saying that now because people think it means miner activated.
13:58 < jeremyrubin> so that the old threshold has time to lock in
13:58 < instagibbs> roconnor, got it
13:59 < instagibbs> so yeah that might be simpler actually
13:59 < jeremyrubin> but if you do two seperate bits, then you want to measure the total support for either
13:59 < roconnor> I might be better to see the total support for them separately.
13:59 < roconnor> *it might be
14:00 < roconnor> I'm not sure.
14:00 < jeremyrubin> yeah
14:00 < jeremyrubin> It's at least another design choice question
14:00 < instagibbs> either way I think bip8 PR would be a good first step
14:00 < jeremyrubin> +1
14:00 < roconnor> The start-now-improve-later philosophy is to figure that all out later. :P
14:00 -!- benthecarman [~benthecar@2600:1700:bb80:db0:5dfd:7bbc:9541:8ba6] has joined ##taproot-activation
14:00 < instagibbs> I've been reviewing/adding test cases for taproot, honestly it looks great.....
14:01 < roconnor> while I agree it would be better, of course, to spec it out now, I don't think it is a requirement.
14:01 -!- benthecarman_ [~benthecar@37.120.208.246] has joined ##taproot-activation
14:01 < instagibbs> hence bip8 nao...
14:01 < instagibbs> ;)
14:01 < jeremyrubin> roconnor: sure, I guess by spec out I mean "
14:02 < jeremyrubin> we reasonably suspect an acceleration BIP8 can work"
14:02 < luke-jr> https://github.com/bitcoin/bitcoin/pull/19573
14:02 < jeremyrubin> because I don't want to false advertise something can be done if we'll later discover a blocking reason
14:02 < roconnor> (not meaning to imply we necessarily are going with start-now-improve-later, though I think it has broad acceptance.)
14:02 < jeremyrubin> That also has an effect on your preference for 2 years vs 1 ear roconnor
14:02  * jeremyrubin 1 ear, van gough fork
14:03 < instagibbs> I'm fine with SNIL, and probably a better precedent for other proposals
14:03 < instagibbs> that maybe more risky
14:03 < roconnor> jeremyrubin: IMHO the longer the better. 4 years.  The only reason to go shorter is to cut off concern that it will actually take 4 years.
14:03 < roconnor> which is maybe a legitmate concern.
14:03  * jeremyrubin flees
14:04 < instagibbs> but in 4 years that means it'll be competing with ETH 2.0 Phase 1 release
14:04  * instagibbs ducks
14:04 < luke-jr> [20:57:53] <jeremyrubin> e.g., new bit at 50%, old bit independently at 50% <-- I just realise this would work
14:04 < roconnor> *lol* SNIL doesn't have a 1 year.  I think 2 years is aboslute minimum.
14:04 < roconnor> Segwit had 1 year and there wasn't time to IL.
14:04 < roconnor> (though we would maybe be better prepared this time around.)
14:04 < jeremyrubin> roconnor: yes that's my point, earlier the reason for 2 year you gave was that you'd have time for an accelerative deploy
14:05 < jeremyrubin> so hence wanting to make sure that that's acutally supported
14:05 < instagibbs> I mean if it's too close for improve it degrades to "just do another deployment?"
14:05 -!- benthecarman [~benthecar@2600:1700:bb80:db0:5dfd:7bbc:9541:8ba6] has quit [Ping timeout: 260 seconds]
14:05 < instagibbs> handwaving away choices again
14:06 < roconnor> jeremyrubin: It doesn't affect my preferences for 2 years because I think it is highly unlikely that there isn't an acceleration method available.
14:06 < luke-jr> the root problem with any re-deployment, is that people think they have Taproot when they don't
14:06 < luke-jr> BIP8's lockinontimeout fixes this by ensuring the false variant activates by the true
14:07 < roconnor> even a flag day forcing all blocks to signal the version bit is a plausble acelleration strategy.
14:07 < jeremyrubin> I guess I'll state my preference clearly which is that it will be easier if, before BIP8 is marked final, the code already has basic support for an acceleration path.
14:07 < roconnor> And even if we fail to come to an acceleration plan, cutting the time shorter doesn't seem to make things any better.
14:07 < jeremyrubin> I don't want to end up 6 months into a taproot deploy *and then* have a debate about acceleration plans
14:08 < roconnor> I mean I don't want to wait that long either, but if the alternative is to delay taproot activation for 6 months, that is even worse.
14:08 < jeremyrubin> Becuase then you're risking factionalization and different plans. Simpler if there's a sort of default option for acceleration -- altho it doesn't rule out a new method being used
14:08 < luke-jr> hmm
14:08 < luke-jr> I think it's *possible* to modify BIP8 such that we can just let users configure their own timeout ;)
14:09 < luke-jr> would still have to be consistent, but at least then it's non-devs sorting out what timeframe
14:09 < jeremyrubin> I guess the question is how much technical churn does that create and can we agree that we shouldn't accelerate with a decreased threshold
14:09 < roconnor> I'm not too concerned about factionalization of different accelleration plans.  I think the risks there are no worse that the current risks of factionalization of different activation plans.
14:09 < jeremyrubin> my feeling is that we can treat a priori measured support as a lower threshold in it of itself
14:10 < jeremyrubin> and just use BIP8 overlapping different timeouts default true
14:10 < jeremyrubin> and that should work as is
14:10 < jeremyrubin> except that at the end
14:10 < jeremyrubin> err I guess even the end works ok
14:11 < luke-jr> not as is no
14:11 < luke-jr> you would have the later ones transition to LOCKED_IN *after* the earlier ones *finish* it
14:11 < roconnor> ooooooh!
14:11 < jeremyrubin> Ah, yes
14:11 < jeremyrubin> THis is what I've been trying to point out
14:11 < jeremyrubin> newer releases need 2 signaling periods
14:12 < roconnor> Great, we are settled on accellerating with a separate version bit.
14:12 < roconnor> tada.
14:12 < luke-jr> maybe we should just have it so a period of 100% signal means it's ACTIVE immediately
14:12 < jeremyrubin> roconnor: no
14:12 < instagibbs> uh could I get that in writing :)
14:12 < roconnor> no?
14:12 < jeremyrubin> different bit has the same problem
14:12 < jeremyrubin> instagibbs: sure, let me try
14:13 < jeremyrubin> So suppose you have a deployment for 2 years
14:13 < luke-jr> we can get rid of FAILING state this way too
14:13 < jeremyrubin> then some scoundrels at 6 months say it's actually activating at 1 year
14:13 < roconnor> I don't think so.  Sure the second bit has to signal for two weeks(tm) and then the first bit has to signal for two weeks(tm) and then taproot gets activated.
14:13 < jeremyrubin> but even though a lot of people run the scoundrels software, miners don't signal still
14:13 < jeremyrubin> it reaches 1 year
14:13 < jeremyrubin> then there's a single locked in period
14:13 < jeremyrubin> and then it is active
14:13 < jeremyrubin> and signaling is required
14:14 < jeremyrubin> the miners fall in line
14:14 < jeremyrubin> and signal
14:14 < jeremyrubin> but then for the old clients
14:14 < jeremyrubin> they're expecting 2 signaling periods before active
14:14 < jeremyrubin> (locked in rule -- 1 period crosses, then it's mandatory signalling next)
14:14 < jeremyrubin> so then you have some clients incosistent with the others
14:14 < roconnor> jeremyrubin: I'm not following.  The accelleration BIP only forces the first bit to be signaled and nothing else.
14:14 < luke-jr> I think the email aj sent me had a complete fix for this
14:15 < roconnor> *accertation bit
14:15 < jeremyrubin> roconnor: i'm describing above for same bit signalling, we can go into different bit in a second
14:15 < roconnor> oh sorry.
14:15 < roconnor> I will reread.
14:15 < jeremyrubin> so the safe thing the scoundrels could do is to make the end period be an addtl lock in periods
14:16 < jeremyrubin> so then everyone will turn on taproot at the same time
14:16 < jeremyrubin> instagibbs: capiche?
14:17 < instagibbs> hmmm I might have to re-read bip8 I think I'm missing something
14:17 < jeremyrubin> after you hit 95% threshold
14:17 < jeremyrubin> the next 2016 must be 100%
14:17 < jeremyrubin> then taproot active
14:17 < jeremyrubin> if you don't hit 95%, but timeout to locked in
14:18 < jeremyrubin> then you'll look like the first 95% window
14:18 < jeremyrubin> hence luke-jr's perspective, that 100% locked in really means that it should be active right away
14:18 < roconnor> Ah I get it.
14:18 < jeremyrubin> because if you saw that, most likely someone else was locked in at a lower threshold
14:19 < luke-jr> I wonder if we should adjust below 95% too
14:19 < roconnor> SGTM, though it kinda makes me feel using a second bit is simpler.
14:19 < jeremyrubin> ok now for roconnor's point
14:20 < jeremyrubin> The thing you deploy with a second bit, is that the second bit active makes the first bit go to 100%
14:20 < jeremyrubin> And it's the same effect as having a 2nd timeout period
14:20 < jeremyrubin> just maybe less code complexity?
14:20 < luke-jr> more IMO
14:20 < jeremyrubin> But it doesn't actually get rid of the extra timeout period
14:20 < luke-jr> with a single bit, you never have more than one deployment in your node
14:20 < roconnor> Right.  It's just more robust againt this BIP8 design choices.
14:21 < roconnor> maybe a well-designed BIP8 is better.
14:21 < roconnor> by well-designed I mean any 100% activation period activates immediately.
14:22 < jeremyrubin> luke-jr: the nice thing is that with 100% you'll get pretty sure lock in is happening because the odds of not seeing a single 100/2016 signal false block is pretty low.
14:23 < jeremyrubin> so if you've reached e.g. 50% and haven't seen a single false signal, that's prettly likely that it's about to lock in
14:23 < instagibbs> ok I think I've got it. End of day, didn't drink nearly enough coffee
14:23 < jeremyrubin> it's non obvious but that's why I've been being a stick in the mud :p
14:24 < roconnor> thanks for persisting.
14:24 < jeremyrubin> a picture would probably help
14:24 < roconnor> I was thinking of a TLA+ implementation. :D
14:25 < jeremyrubin> the funny thing about tla+
14:25 < jeremyrubin> is that fewer people can be more sure it's absolutely correct :p
14:25 < luke-jr> so does anyone want to make a BIP PR and/or leave code PR comments? :P
14:26 < roconnor> *lol* True that.  But really the benefit is for the one writing the TLA+ to convince themselves it is correct.
14:26 < jeremyrubin> I already did https://github.com/bitcoin/bips/pull/944
14:26 < jeremyrubin> I think this also fixes the problem
14:26 < roconnor> Or rather find errors and let everyone else know about them by providing a derived counter-example.
14:26 < jeremyrubin> maybe not actually
14:26 < luke-jr> oh yeah
14:26 < jeremyrubin> it fixes the end problem
14:26 < jeremyrubin> but then breaks the BIP-9ness early of the early deploy
14:27  * luke-jr really needs to catch up on aj's and jeremyrubin's review comments <.<
14:27 < roconnor> go on.
14:27 < jeremyrubin> oh just that you can set an earliest date at 1 year + 2016 blocks
14:28 < jeremyrubin> but then if you deployed at 6 months, you'd rule out being active at 9 months
14:28 < roconnor> I'm lost.  What is BIP-9ness?
14:28 < jeremyrubin> so earliest date does fix this issue (in the way that a TLA+ spec could be happy), but does not preserve bip9-ness
14:28 < jeremyrubin> bip-9ness is the ability to activate earlier than the end of the period
14:29 < jeremyrubin> don't have a better name for it, but that's the whole idea of bip9 was to allow for earlier activation than a normal flag day
14:29 < roconnor> I get it.
14:30 < roconnor> The solution is at 100% signaling to activate now or at the earliest activation date (whichever is later).
14:30 < jeremyrubin> roconnor: actually a good test for your tla+ spec, that you should make sure to preserve early activation being possible
14:30 < jeremyrubin> that, or to add a +1 lock in period for all "stacked" activations
14:30 < roconnor> the scoundrels shouldn't move the earliest activation date.
14:31 < luke-jr> hmm
14:31 < jeremyrubin> no, they shouldn't, because it should be by default selected to be an earliest safe time
14:31 < instagibbs> err what how would you know 100% signaling is comign later?
14:31 < luke-jr> does LOCKED_IN have a purpose with mandatory signalling?
14:31 < instagibbs> roconnor,
14:31 < jeremyrubin> I personally prefer the +1 lock in because the 100% doesn't give enough warning
14:31 < luke-jr> I guess so, nm
14:32 < roconnor> I think you should never activate before the earliest activation date.
14:32 < jeremyrubin> except for the statistical "expected to see *some* counter signal by now"
14:32 < instagibbs> oh sorry was thinking backwards
14:32 < instagibbs> im gonna go get food instead
14:32 < jeremyrubin> roconnor: earliest activation isn't a part of the bip yet btw
14:32 < roconnor> a too early 100% signaling period just means we will activate then,
14:32 < jeremyrubin> just a proposal
14:32 < roconnor> jeremyrubin: understood.
14:32 < instagibbs> as long as you're in consensus with oether bip8 implementations it should be fine to always activate at 100%?
14:32 < luke-jr> jeremyrubin: sure it is, startheight
14:32 < jeremyrubin> sure. For the 100% I guess enforce that rule after the earliest height
14:33 < jeremyrubin> luke-jr: fair, that was my argument that you're effectively just splitting what's already there
14:33 < roconnor> instagibbs: I agree, and it is doable.  But the purpose of the earliest activation date is to allow time for nodes time to deploy and begin enforcement.
14:33 < jeremyrubin> or better yet, accept 100% before earliest
14:33 < jeremyrubin> but just never move the earliest active height across all acceleration props
14:34 < jeremyrubin> That seems to be safe
14:34 < roconnor> Right, I think it is fine to accept the early 100% activation.  move into a LOCKIN(?) state and wait for the early activation time.
14:35 < jeremyrubin> great
14:35  * jeremyrubin consensus has been reached?
14:35 < roconnor> I think all this greatly improves BIP8.
14:36 < jeremyrubin> especially if it's to be reused for the next thing
14:37 < roconnor> I mean, if for some reason people don't want the earliest activation parameter to be added, I would be okay with that.  But I think adding it is a good idea.
14:39 < luke-jr> roconnor: startheight IS earliest activation
14:39 < luke-jr> I don't get why we'd ever have anything more
14:39 < luke-jr> there is no point for a bit without it doing something
14:40 < luke-jr> if people want to virtue signal, they have blogs
14:40 < luke-jr> and twitter
14:40 < roconnor> hmm I need to reread my jeremyrubin logs.  I rember finding him pursasive.
14:40 < jeremyrubin> luke-jr: the signals still count towards lock in
14:40 < luke-jr> jeremyrubin: that doesn't make sense..
14:40 < luke-jr> lockin only looks at the immediate prior period
14:40 < jeremyrubin> luke-jr: recursion
14:41 < luke-jr> ?
14:41 < jeremyrubin> if the prior period is locked in, the next period is also locked in
14:41 < jeremyrubin> and the next
14:41 < luke-jr> …
14:41 < luke-jr> after 1 period of lockin, the softfork is active and the bit is released
14:41 < jeremyrubin> you can think of the bit like a mutex, and it isn't released until active
14:41 < luke-jr> but it's active after 1 period of lockin
14:41 < jeremyrubin> and earliest height determines the time when you can release the bit
14:42 < jeremyrubin> the code I PR'd to the bip changes that
14:42 < luke-jr> so basically turn startheight into a flag day in advance?
14:42 < roconnor> Mabye luke-jr is right and there is no point in a separate early activation time.  You should just set the start time later if you want that.
14:42 < luke-jr> well, startheight+period
14:43 < roconnor> Presumably if miners are willing to activate it early, they are also willing to activate it later.
14:43 < jeremyrubin> Well it does make it nice for overlapping bip8's
14:43 < luke-jr> I mean, I suppose I see *some* value in knowing a few months early that Taproot *will* be active as soon as we get to startheight
14:43 < luke-jr> but I'm not sure it needs consensus logic
14:43 < jeremyrubin> Anyways my proposal was more relevant when I figured it would be like 3 months + release date
14:43 < jeremyrubin> for the startheight
14:43 < jeremyrubin> as opposed to 30 days
14:44 < luke-jr> 30 days is too fast
14:44 < jeremyrubin> that's what it was for segwit
14:44 < luke-jr> was it? :/
14:44 < luke-jr> still too fast IMO
14:44 < jeremyrubin> yes
14:44 < jeremyrubin> fwiw I agree but you'll need to make that case
14:44  * jeremyrubin waves
14:44 < jeremyrubin> to a broader set of people
14:45 < roconnor> :D I'm the guy who wants a 4-year period.  I'm okay with a 3 month start height.
14:45 < roconnor> maybe blows try-and-see out of the water though.
14:45 < luke-jr> wut, it was actually like 2 weeks
14:46 < roconnor> BTW I lost harding's wiki page link.
14:46 < luke-jr> ?
14:46 < jeremyrubin> https://en.bitcoin.it/wiki/Taproot_activation_proposals
14:46 < roconnor> ty
14:47 < luke-jr> lol, not sure I realised it was a wiki page
14:47 < roconnor> maybe blows let's-see-what-happens out of the water though.
14:47 < roconnor> It's quite useful for a naming convention.
14:48 < luke-jr> I suppose the 2 week starttime for Segwit was probably due to not looking at miners adversarially, the same as the timeout issue was
14:48 < roconnor> luke-jr: That's what I'm presuming.
14:49 < roconnor> may harding needs to put an empty 3m prefix into all those deployment graphs.
14:50 < jeremyrubin> scan the logs for prior discussion, I expressed surpise people would accept 30 days
14:50 < jeremyrubin> seems risky to me, but you'll want to talk to those folks about it
14:50 < jeremyrubin> I think they would agree to earliestactive though
14:50 < roconnor> *lol* was I one of them?  It'd be embarassing if I was.
14:50 < jeremyrubin> roconnor: i think so???
14:50 < jeremyrubin> "it's what segwit did"
14:51 < jeremyrubin> is a pretty easy appeal to authority right
14:51 < jeremyrubin> :)
14:51 < roconnor> I don't recall saying that, but it sounds like a stupid thing I might do.
14:51 < jeremyrubin> ah not an exact quote
14:51 < jeremyrubin> scare quotes
14:52 < jeremyrubin> TBH I think that if you had to pick between 30 days + 4 year true and 3 months 1 year true the latter is safer
14:52 < jeremyrubin> the prospect of a 44 day lock in is tight to me
14:53 < jeremyrubin> Thurs july 16 11:53 pdt
14:53 < luke-jr> jeremyrubin: 30 days *might* be acceptable if we have reason to think people will upgrade quickly
14:54 < luke-jr> [21:51:12] <jeremyrubin> is a pretty easy appeal to authority right <-- more like appeal to precedent
14:55 < luke-jr> jeremyrubin: also, note 30 days start = 60 days active
14:55 < luke-jr> wait, no, 45 days
14:55 < roconnor> "the prospect of a 44 day lock in is tight to me" isn't in my logfile.  Are you quoting yourself from earlier?
14:55 < jeremyrubin> hang on finding more relevent logs...
14:55 < luke-jr> does it matter? :p
14:56 -!- slivera [~slivera@103.231.88.27] has joined ##taproot-activation
14:57 < jeremyrubin> I can't find people defending 30 days in the logs... maybe private convo
14:58 < luke-jr> maybe we should put all this urgency to good use, and tell people to review the code even fi they don't know C++
14:58 < roconnor> review the taproot code or the BIP8 code?
14:59 < luke-jr> sure :P
14:59 < jeremyrubin> ok yeah mostly a private convo with aj where I talked about it, aj would be the right person to make the case for 2.5 retargets safety for startheight
15:02 < jeremyrubin> benign enough I'll just paste here what we discussed
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:25:13 PM PDT] <jeremyrubin> I see. Generally my point is as follows, which I think I make in the PR: Let's say without this feature you would   do params +30 days, 1 year. You can replace that with +0 days, 30 days + 2 weeks, 1 year
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:25:36 PM PDT] <jeremyrubin> so it just gives you an extra two shots at signaling early safely
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:30:31 PM PDT] <jeremyrubin> The problem with extant BIP8 is that it's not clear we could reach consensus on what a safe minimum start time is
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:31:03 PM PDT] <jeremyrubin> E.g., if the start time param gets set to 6 months because people are worried about folks not upgrading.
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:31:15 PM PDT] <jeremyrubin> That's an additional 6 mos of uncertainty
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:31:34 PM PDT] <jeremyrubin> whereas earliestitme 6 months but signal immediately you can lock in
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:31:59 PM PDT] <jeremyrubin> And then be A-OK for building out wallets and stuff and getting other support ready
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:36:22 PM PDT] <aj>  i don't think it makes any sense to worry about people not upgrading for an activation that requires 95% hashpower is what  i'm saying -- that's how you choose the 95% number, it's whatever level makes things safe despite lots of users not having upgraded already
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:36:58 PM PDT] <aj>  the start time delay is just to ensure the release can come out first despite last minute hiccups
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:37:10 PM PDT] <aj>  and if it's a minor release, those hiccups shouldn't last very long
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:37:26 PM PDT] <aj>  delaying it 6 months would be crazy imo
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:37:29 PM PDT] <jeremyrubin> Gotcha. So you think 30 day start time is safe?
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:37:47 PM PDT] <aj>  2.5-3.5 retarget periods, yeah
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:38:15 PM PDT] <jeremyrubin> hm
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:38:24 PM PDT] <aj>  really, i think these days the chances of activation happening due to pre-release software is zero anyway
15:04 < jeremyrubin>  [Tuesday, July 14, 2020] [7:40:53 PM PDT] <aj>  i mean, all my opinion, i don't think it's especially harmful either, and if it turns out people are being (IMO) crazy and  it's needed to minimise the impact of that, no problem
15:05 < jeremyrubin> so I think more or less his point was that it's just extra technical complexity for a thing that's already supposed to measure overwhelming support.
15:09 < jeremyrubin> The benefit of collecting the signals earlier, is it's just free extra time to collect a positive signal, if we are doing a startheight at +6 months
15:17 < luke-jr> jeremyrubin: please don't post private conversations verbatim like that :/
15:18 < luke-jr> that being said, the false premise there is that miners make Bitcoin safe. They don't.
15:18 < luke-jr> (I also think that 95% figure might be deserving of reconsideration/reduction)
15:21 < jeremyrubin> aj: apologies if that was improper, I figured it was innocuous but I could have double checked.
15:23 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
15:24 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
16:02 -!- Davterra [~Davterra@37.120.208.253] has quit [Read error: Connection reset by peer]
16:03 -!- Davterra [~Davterra@37.120.208.253] has joined ##taproot-activation
16:07 < aj> luke-jr: per blockchain.info, the top four pools each have >10% hashrate, so you'd have to drop it a lot to make much difference i think?
16:10 < aj> bip9 says starttime should be a month away; but doesn't actually start until a retarget period begins, which averages another 7 days; then it takes at least one retarget period of signalling, and another retarget period of locked in, for around 65 days total from software release to earliest potential activation
16:11 < aj> luke-jr: don't forget the secp code
16:15 < aj> luke-jr: i suppose i should just PR a patch to bip8 rather than waiting for you to reply to email :)
16:17 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
16:18 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
16:24 < luke-jr> aj: "normal English" might be a bit too much of a claim for secp code? :P
16:26 < luke-jr> aj: PR to BIP8 welcome, though I'll get to your email [soon I hope] even if you don't ☺
17:20 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
17:20 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
17:40 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
17:42 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
17:49 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
17:52 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
17:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
17:56 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
18:01 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-qfulkzvxyqqpsmmm] has quit [Quit: Connection closed for inactivity]
18:01 -!- brg444 [uid207215@gateway/web/irccloud.com/x-eamzwkvbopkgfnrs] has quit [Quit: Connection closed for inactivity]
18:12 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds]
18:20 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##taproot-activation
19:38 < jeremyrubin> https://docs.google.com/presentation/d/1U2_qk5tWWnN3l1ehYZmfbQEg9KV5bXjvhJf2Skgsz-g/edit?usp=sharing
19:38 < jeremyrubin> That should help anyone trying to follow the BIP8 overlapping deploy issue(s)
19:41 < jeremyrubin> This helped me realize that there is also an issue not just of mismatching activation windows, but also unclarity around if blocks which don't signal are valid
19:41 -!- benthecarman_ [~benthecar@37.120.208.246] has quit [Ping timeout: 240 seconds]
19:41 < jeremyrubin> The "any period with 100% signal activates" rule fixes both issues I think
22:47 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]
23:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
--- Log closed Fri Jul 24 00:00:28 2020