--- Log opened Sun Mar 28 00:00:09 2021
00:31 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
00:31 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
01:02 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
01:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:08 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
01:15 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
01:15 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
01:47 -!- CARO2 [~Cesar@201.86.222.14] has joined ##taproot-activation
01:49 -!- CARO1 [~Cesar@2804:7f4:c19f:cde8:6dcd:1541:a0e5:3f45] has quit [Ping timeout: 258 seconds]
02:39 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
03:00 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
03:09 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
03:39 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
03:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
03:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
04:19 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
05:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
05:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
05:43 <@michaelfolkson> I'm certainly going to have some recommendations for future soft fork activations if we ever get Taproot activation code merged in Core. How this has become such a mess when mining pool community has been this helpful and supportive I have no idea
05:50 <@michaelfolkson> I was expecting a slog to get community consensus around a particular activation mechanism. I was not expecting a slog to get code into Core once we got that community consensus. Over block height versus block height and MTP. Farcical
05:58 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Quit: Leaving]
06:59 <@michaelfolkson> Once we can get a decision on a particular Speedy Trial PR (e.g. a merge) I'll personally be recommending a push back of the start height a couple of weeks. The best way for bugs to slip through is to have farcical arguments about things like block height versus block height and MTP and spread review over multiple PRs. But a decision on choosing (or merging) a specific Speedy Trial PR has to come first. Otherwise the start height
06:59 <@michaelfolkson>  just keeps getting pushed back over and over again by those who would prefer endless delays
07:10 < roconnor> Andy wrote what I was just thinking: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-808901334
07:11 < roconnor> It is no longer the case that the MTP approach is simpler than the height based approach, which was largely what it had going for it.
07:14 -!- stortz [b1982ea0@unaffiliated/stortz] has joined ##taproot-activation
07:43 -!- stortz [b1982ea0@unaffiliated/stortz] has quit [Quit: Connection closed]
08:41 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has joined ##taproot-activation
09:17 <@michaelfolkson> Just have to remember to Approach NACK an activation mechanism for the ANYPREVOUT soft fork because MTP is better for testnet. What a mess
09:17 <@michaelfolkson> I wish someone had told me two months ago there would be this kind of BS. That's two months of my life I'll never get back
09:22 < luke-jr> IMO it's time to stop waiting on this nonsense, and just release Bitcoin Core w/ Taproot
09:24 -!- darosior [~darosior@194.36.189.246] has quit [Quit: ya vps net disruption]
09:25 -!- darosior [~darosior@194.36.189.246] has joined ##taproot-activation
09:34 <@michaelfolkson> I don't think there's a route for Core if a Speedy Trial PR can't be picked. Maybe roconnor or harding have another rabbit to pull out the hat. If they don't I think that's it
09:36 <@michaelfolkson> Regardless we can't keep doing all this BS for future soft forks. This is nonsense
09:37 < roconnor> I don't think this testnet argument against height based activation has any legs.  Activation by date on testnet is even more unreliable than height; the entire activation date range can easily be skipped over.
09:38 < luke-jr> moving forward doesn't require giving up on a Core mainline release, just doesn't wait for it
09:44 <@michaelfolkson> Once we're in agreement that Core efforts are dead the majority will gather round UASF. I don't think we have to be patient for much longer
09:47 < roconnor> I don't quite get why you are so sour at this point in time.  All we need to do is get Andy's work past review and then select some specific dates.
09:51 <@michaelfolkson> If people are going to Approach NACK based on testnet (when they don't even care about testnet, they set up signet and activated Taproot on signet) this is close to dead
09:51 < jeremyrubin> actually the changes suggested by AJ are pretty minimal all things considered (it's like +3 loc) so I don't think it's that bad
09:51 < jeremyrubin> michaelfolkson: I beleive AJ worked on this to lift your NACK on mixed MTP/heights
09:51 < jeremyrubin> his PR is now pure MTP
09:52 < luke-jr> roconnor: it IS past review. 6 ACKs
09:52 < roconnor> luke-jr: oh good, then we just have to have it merged.
09:53 < luke-jr> and now with 6 ACKs, it's begun to get shedpainting and absurd concept NACKs..
09:53 < jeremyrubin> it can't be merged it's not even passing CI
09:54 < luke-jr> jeremyrubin: it is
09:54 <@michaelfolkson> Can you Approach NACK Andrew's PR so we can get this torture over with please jeremyrubin? We get enough Approach NACKs on both PRs and we can move on with UASF
09:54 <@michaelfolkson> I'm sick of the dumb games
09:54 < luke-jr> I am ignoring the new Android CI for now
09:55 < luke-jr> afaict it's just plain broken at the CI level, not a PR issue
09:55 < jeremyrubin> I'm approach NACK UASF, so if you think that me approach NACKing something else is required for a UASF, then I will not NACK
09:56 <@michaelfolkson> I'm looking for a sufficient number of Approach NACKs on both Speedy Trial PRs and then I think no one can criticize us for moving on with UASF
09:56 < luke-jr> it's not even a UASF, just a normal deployment
09:57 < luke-jr> UASF is only a fallback at the end of 2022 that won't happen because it's there
09:57 < roconnor> jeremyrubin: I think the issue with MTP is that is does and always has mixed heights and times due to needing to sync up with retargetting periods.  This makes all modifications to MTP deployment difficult to reason about, which is why https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221 ended up being a problem in the first place.
09:57 < jeremyrubin> michaelfolkson: I think you should unplug for a week. You're not doing a good job of arguing your case when you're clearly sound-byting developers and I think you are introducing a lot of anxiety into the process where there is not need for it.
09:58 < roconnor> Andy's PR's end point is simpler to reason about, but does produce a bigger diff.
09:58 < luke-jr> roconnor: which shouldn't matter since it's well reviewed
09:59 <@michaelfolkson> jeremyrubin: I appreciate the advice but I'd rather not
09:59 < luke-jr> we've merged bigger stuff
09:59 < jeremyrubin> michaelfolkson: they're your bridges to burn
10:00 < jeremyrubin> so do whatever pleases you
10:00 <@michaelfolkson> jeremyrubin: Again I appreciate the advice but I'd rather not when people are playing games
10:01 < luke-jr> jeremyrubin: don't be a jerk
10:02 <@michaelfolkson> If I have to burn all my bridges to get Taproot activated that's fine by me. I'm not sure I want to be involved after that, this is BS
10:03 < luke-jr> michaelfolkson: all this can be avoided next time by just not trying to activate via the main core repo
11:12 < harding> michaelfolkson: I echo jeremyrubin's advice about taking some time off.  If you don't take time off, would you be terribly offended if I put you on /ignore for a while?  You may be willing to burn your bridges with other people, but I'd like to throw some water on to my bridge with you.
11:16 <@michaelfolkson> harding: Is there a personal /ignore setting? If so feel free. I'd rather I wasn't silenced on a channel
11:17 < luke-jr> /ignore is a personal setting, yes
11:17 < harding> michaelfolkson: yeah, /ignore just means my IRC client won't display any messages from you.  Everyone else will see your messages.
11:17 <@michaelfolkson> harding: Sure go ahead
11:17 <@michaelfolkson> Don't need to ask my permission for that
11:17 < harding> michaelfolkson: Thanks.  I'll set a reminder to take it off next Sunday.
11:40 -!- carboncarlo [900263cd@bbcs-99-205.pub.wingo.ch] has quit [Quit: Connection closed]
11:59 < roconnor> harding: regarding your PR comments: I don't think the goal here is to chose the simpler to review PR, but rather to choose the better PR.  The fact is that height based activation simply cannot ever have a reorg that moves the boundary of one state transition forward or backwards by a retargeting period ever, and is why Andy's PR is just better, and we should direct people's review effort towards Andy's PR.  If it take a
11:59 < roconnor> littles longer to review Andy's PR (and I don't think it will) then so be it.
12:01 < harding> roconnor: first, my note about simplicity was a response to achow101's comment about MTP being more complicated.  I agree the goal is to choose the better PR overall.
12:02 < harding> roconnor: I don't understand what you mean that a reorg can't move a state transation forward or backwards.  I thought a reorg could do anything except affect checkpoints and buried deployments.
12:03 < roconnor> The problem noted in https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221 is caused by the possibility of a state transition being moved by 1024 block due to a reorg.
12:03 < harding> Assuming you have six available retargetting periods and lock_in occurs in period #4, a reorg can move lockin to period #3 or #5, right?
12:03 < roconnor> These problems simply do not exist at all in height based activations.
12:04 < roconnor> not 1024. 2016.
12:04 < harding> roconnor: sure, but those problems don't exist in aj's current PR either, nor its version from last week, right?  It was only in the initial version.
12:05 < roconnor> Sure AJ address the immediately problem, but the larger problem remains: review of MTP activation code is burnded by these considerations.
12:06 < harding> Ok, but height has the fundamental problem that it's not as predictable as time, and time is the thing that activation enforcement needs, not height or even accumulated PoW.
12:08 < roconnor> There should be enough slack put into the min-activation-height that this isn't a serious concern.  It isn't like 6 months is a magic number that if we are below that value, deployment will fail, and if we are above that number, deployment will succeed.
12:08 < roconnor> and 14 activation periods is nominally 196 days, well above 180 days dictated by 6 month.
12:09 < harding> I completely agree, and I think I explicitly said that in my PR comment.
12:10 < roconnor> then I don't see what the fundamental problem is.  The only thing we need to do is give adequtate time for users to upgrade their software.  Even with height based activation no one is going to realistically end up in a time crunch for upgrading.
12:10 < harding> I'm just saying that time is the thing we really want to measure; height is just a rough proxy for it.  If we can measure time directly (or close enough with MTP), it seems reasonable to try that.  Yes, there are tradeoffs, but I don't think MTP adds a necessarily greater burden than time-by-proxy-heights does.
12:11 < harding> Who said there was a fundamental problem?
12:11 < roconnor> [15:06] <harding> Ok, but height has the fundamental problem that
12:11 < harding> Ha, got me.
12:12 < harding> Sorry, I didn't mean to imply a fundamental problem to achow101's PR; I meant to imply that height has a problem which can't be evaded of not actually being a time.
12:13 < harding> MTP has similar problems, including being manipulateable.
12:14 < roconnor> I think the reorg issue with MTP is moderately severe.  The fact that https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221 was missed in the first pass illustrates this.  Now I don't think that it isn't insurmoutable, and if we didn't have an alternative then we could get through it.  But we do have an alternative that is "fundamentally" simpler in that it has an entire class of considerations that are simply
12:14 < roconnor> eliminated from being a concern.
12:21 < harding> roconnor: there's definitely merit to that argument.  https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221 is only one instance where MTP has caused problems; another was the reason BIP148 had to be moved up precipitously, leading to BIP8 being rewritten to use heights in the frist place.  I guess I just have this intuition that most of those class of problems arise from deliberate miner-caused problems, which shouldn't be a
12:21 < harding> problem when using miner signaling.
12:21 < harding> opt-in miner signaling*
12:23 < harding> And, if all things were equal (which I'm not claiming), MTP seems clearly better to me in the sense of communication and managing user expectations, which is the area I focus in.
12:31 < harding> I wonder if it'd be useful to create one of those TLA things Dmitry Petukhov makes for MTP and height based activations.
12:33 < roconnor> The reorg thing can occur in perfectly innocent situations, so it doesn't fall into the class of delibrate miner-caused problems.
12:33 < roconnor> A TLA thingy for height based activation would be simpler to create.
12:35 < roconnor> And, frankly, we appear to be in a situation where reviews might be holding of review of both proposals because they don't want to waste their time doing review work on the PR that isn't where everyone else's effort is.
12:36 < roconnor> I used to be agnostic about the two apporaches but I now see that we are in the starving donkey paradox where we are trapped between two equidistant bales of hay.
12:37 < roconnor> There seems to be slighly more support for height based activation and I also happen to think it is superiour owning to the fact that reorgs cannot cause large changes in state transition occurances.
12:38 < roconnor> So it is probably better to wander over in that direction.
12:38 < harding> Yes, the initial reorg thing could've happened accidentally.  The current code does a much better job of replicating BIP9's original activation assurances.
12:42 < roconnor> The primary purpose of doing MTP over height-based was that it would be simpler to review.  But that purpose is defeated if the MTP approach isn't simple to review.
12:43 < roconnor> Turns out it isn't simple to review.
13:12 < harding> I think it's quite simple in its current version where the only enforced state transitions happens after a relative delay of 2016 blocks.  I'm having trouble seeing how that's more work to review than a pure height implementation.
13:14 < roconnor> It's more work because you have do the consideration in the first place.  But my larger worry is that reviewers aren't going to review either PR at this rate.
13:17 < harding> roconnor: sure, but I think the question is whether it's enough more work to justify an Approach NACK.  I don't think it is.  (For completeness, I also don't find aj's Approach NACK of #21392 to be satisifying, which is why I explicitly said this morning that I'm still fine with either approach.)
13:18 < harding> roconnor: GitHub says they colectively have over 300 comments, much of which seem to me to be reasonable review comments (not noise).
13:19 < harding> Both authors have also been making changes due to feedback, e.g. #21377 gained a feature that was originally in #21392 and that I found useful during my review of that PR.
13:19 < harding> gained a feature a few hours ago*
13:19 < roconnor> I'm definitely not NACKing either approach.
13:20 < harding> I'm not sure where these fears of stalled progress come from.
13:21 < roconnor> I got the impression from the last core-dev meeting that some potential reviewers (sipa in particular) are frusterated by the existance of two approaches and would like there to be 1 so they don't have to review both.
13:21 < jnewbery> harding: +1. There certainly seems to be a lot of review activity to me
13:21 < jnewbery> roconnor: sipa has reviewed both
13:21 < roconnor> Are my worries unfounded then?
13:22 < harding> roconnor: I got the impression from that meeting that the concern was about setting deadlines while there's still two approaches being considered.
13:23 < harding> s/deadlines/target dates for releases/
13:23 < roconnor> I see.  Well if I'm off base here, I'll just keep quite for a bit longer then.
13:29 < jeremyrubin> roconnor: +1 about "selecting the best PR"
13:29 < jeremyrubin> The issue was around time sensitivity of release; people wanted a mid-april RC1
13:29 < jeremyrubin> so there was a tradeoff around best v.s. fastest to be able to release in that window
13:30 < jeremyrubin> Unclear if that timeline is still realistic, but I think if we can get a rc1 by mid-may we're probably still good with the timelines discussed
13:30 < jeremyrubin> roconnor: I'm curious if you think something like https://github.com/ajtowns/bitcoin/pull/5 fixes the issue you have with reorging?
13:31 < jeremyrubin> it's basically time + a min # of signal periods
13:31 < jeremyrubin> the issue still exists I guess with the start MTP?
13:32 < jeremyrubin> I think overall start MTP would be fine to be a height
13:32 < jeremyrubin> so start height, # periods, and stop time would maybe be the best combo of things?
13:33 < jeremyrubin> that way you have both a known amount of wallclock time to upgrade & reorgs cannot reduce the # of signal periods below a threshold
13:33 < roconnor> The issue is that it is reorging any MTP time across regargeting periods is something that simply has to be always be considered when touching the MTP code in any way.
13:33 < roconnor> I don't think AJ's code is broken.  I just think it is no easier to review than Andy's.
13:34 < roconnor> (which is a polite way of saying I think Andy's code is probably easier to review.)
13:35 < roconnor> But my larger concern of people wanting to wait for these two PR's to resolved before starting to do any review does seem to be unfounded.
13:35 < roconnor> So that is good.
13:35 < harding> I still don't understand why that's a concern when there's now a 2,016 block lock_in period between the last time MTP is used and when any rule changes become enforced.
13:36 < harding> That would seem to imply to me that you'd need a reorg of 2,016 blocks to cause problems, and a reorg of that length would be a problem irrespective of activation mechanism.
13:36 < jeremyrubin> roconnor: is there a scenario where the issue can be triggered and Bitcoin consensus isn't fucked?
13:36 < roconnor> Again, I have no issues with AJ's code.  I just think it is harder to review.
13:37 < roconnor> It's hard to review because you need to inspect it carefully in order to come to the conclusion that, "ah yes, this works fine in the cases of theses reorgs across retargeting boundaries".
13:38 < roconnor> Indeed, I do beleive AJ's code is safe in these circumstances.  It just isn't "obviously safe" in the same way that Andy's code is under these circumstances.
13:39 < roconnor> I'm good with either approach, and think either can pass review.
13:42 < harding> Oh, so your concern now is that `if (mtp > x && height % 2016)` requires more analysis than `if (height > y && height % 2016)`?
13:42 < harding> er, height % 2016 == 0
13:43 < roconnor> that is the concern that I've been raising.
13:45 < harding> (Sorry, adding "now" to that sentence was accidentally inflammatory.)
13:45 < roconnor> (whew)
13:46 < roconnor> I raised it because I though we were a starving donkey between two bales of hay.  But it seems that the donkey is um, nibbling at both bales of hay.
13:50 < harding> I think I understand the concern better phrased that way; before I was overly focused on the transition to ACTIVE, but phrasing it in pseudocode reminds me that the other transition points need attention to, which is something I didn't test when reviewing both PRs last week.  (And, in hindsight, you were saying "state changes" (plural) throughout the convestation, so it's only my own obtuseness to blame.)
13:51 < jeremyrubin> harding: yeah all state changes are important
13:51 < jeremyrubin> [3/28/21 13:31] <jeremyrubin> the issue still exists I guess with the start MTP?
13:51 < jeremyrubin> ^ if you review that in the scrollback that's what I meant
13:52 < harding> I'm sure we'd be closer to activation if we only had one PR to look at.  Of course, we'd probably also be closer to activation if we were all a bit less imaginative this past half year.  :-)
13:54 < harding> jeremyrubin: I knew they were all important; I guess I discounted the the ones besides LOCKED_IN to ACTIVE because in #21377 they were part of the existing BIP9 code.
13:54 < roconnor> It's not really that I think we are moving too slowly by having two PRs.  My concern was that we were stalled and reviewers, such as sipa, weren't going to review anything until we picked one.  But it seems my concerns were misplaced.
13:55 < roconnor> If reviews are reviewing, then I'm happy.
13:55 < roconnor> *reviewers are reviewing.
13:55 < harding> I'd like to see the first way, actually.
14:36 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
14:47 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 265 seconds]
14:48 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation
15:34 -!- belcher_ is now known as belcher
15:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
15:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
16:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
17:00 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:01 -!- b10c [~b10c@2a01:4f8:200:1036::1] has quit [Quit: ZNC 1.8.1 - https://znc.in]
19:19 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has joined ##taproot-activation
20:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
20:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
20:26 -!- BenPrentice [49eec8c3@c-73-238-200-195.hsd1.ma.comcast.net] has quit [Quit: Connection closed]
20:59 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
23:00 <@aj> roconnor: the fuzz testing is provided to make things simple to review -- you can only reach ACTIVE after precisely one period of LOCKED_IN, and each period is 2016 blocks. the reason i was working on heights up until this month was because i didn't realise they were such a problem for testnet or that a solution with MTP was possible; if you're using "aj didn't immediately notice a problem" as a
23:00 <@aj> show-stopper, it applies to heights as well
--- Log closed Mon Mar 29 00:00:10 2021