--- Log opened Fri Mar 05 00:00:47 2021
00:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
00:42 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vtakzzjunnrxyedh] has quit [Ping timeout: 264 seconds]
00:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:46 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ttsnhkjhgyervsge] has joined ##taproot-activation
00:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
00:55 -!- jonatack_ [~jon@37.167.227.177] has joined ##taproot-activation
01:25 -!- jonatack_ [~jon@37.167.227.177] has quit [Quit: jonatack_]
01:25 -!- jonatack [~jon@37.167.227.177] has joined ##taproot-activation
03:24 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: I'm out.]
03:24 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation
05:13 -!- jonatack [~jon@37.167.227.177] has quit [Ping timeout: 265 seconds]
06:17 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has joined ##taproot-activation
06:18 < maybehuman> michaelfolkson Luke will NACK everything in Core other than LOT=true which won't happen <--- yes, probably. But that's not as fatal as you seem to think. I've seen multiple PRs get merged over a NACK by luke
06:19 < maybehuman> I think in general a single NACK doesn't mean a proposal is dead
06:27 <@michaelfolkson> maybehuman: Agreed, LOT=false stands a chance (even though it will be NACKed by Luke). LOT=true doesn't stand a chance (though people are free to try)
06:28 < roconnor> I don't think luke-jr's objections apply to BIP8(3m, false) (with extended lockin period).  3m is too short for running a LOT=true varient.  And while it still may contain the "miner veto bug", It only takes 3 months to resolve.  If the miners do veto it, we can move on to other activation methods.  A flag day or LOT=true is going to be more likely to pass core review after a successfull demonstration of users upgrading to
06:28 < roconnor> some taproot activation client.
06:29 <@michaelfolkson> Yeah you'd have to ask him, I'm not sure.
06:30 < maybehuman> I guess someone should just open a PR for that
06:30 < roconnor> he did say that 3m is too short to get the enconomic nodes behind the activation, which is true and why we would want an extra long lockin period.
06:30 <@michaelfolkson> There are two scenarios there. One is that Core releases BIP 8(3m, false) with no parallel UASF BIP 8 (1 year, true). The other is Core releases BIP 8(3m,false) at the same time as a a parallel UASF BIP 8(1 year, true)
06:30 < maybehuman> depends also on the startheight, no?
06:31 < roconnor> maybehuman: I'm waiting for the current PR to be split up.  Then I'll have a look at seeing about making the lockin period a parameter.
06:31 < maybehuman> I mean 3m starting in half a year is different from 3m starting right now
06:31 <@michaelfolkson> Startheight will be July at the absolute earliest (and most likely later)
06:32 < roconnor> right, there could be a UASF BIP8(1year, true) at the same time even with the same bit, but it won't activate the BIP8(3m,false) at the forced signaling time.
06:32 <@michaelfolkson> Yup
06:34 <@michaelfolkson> And many people who chose to run the Core BIP 8(3m, false) would most likely switch to the parallel UASF BIP 8(1 year, true) if the Core attempt failed to activate. Or Core could release a LOT=true then (but I think that is very unlikely with NACKs)
06:35 < roconnor> Maybe I actually think there is a decent chance core would release a comptable LOT=true client.
06:35 < roconnor> Though it would be more likely if the UASF people started with 1.5 years.
06:35 < roconnor> not that I have any control over that.
06:36 <@michaelfolkson> I don't think Core would release LOT=true but I could be wrong
06:36 < roconnor> I think most of the argument against LOT=true goes away after a failed BIP8(3m,false).
06:37 < roconnor> Not entirely certain though.
06:37 <@michaelfolkson> I think F7 still applies. Miners didn't want it so Core developers are allowed to force it through the second time?
06:37 < roconnor> the difference is having a graph showing the enormous uptake of core upgrades to taproot.
06:38 < roconnor> I think that graph makes a difference.
06:38 <@michaelfolkson> Ok yeah maybe, good point
06:39 < roconnor> like sure, if that graph doens't materialize and miners don't activate taproot, then it is a problem.
06:39 < roconnor> But if that happens, maybe we all should take a step back because that is so far off our current expectations.
06:39 <@michaelfolkson> That graph can be sybilled
06:39  * michaelfolkson shrugs
06:40 < roconnor> I know, the graph isn't perfect.
06:40 < roconnor> you can spin up nodes, but that is observable too.
06:40 < willcl_ark_> Would it make sense to release a client which included the entire """LOT=false (x months) AND an intermission period AND a LOT=true""" all in sequence? Might need two bits in nVersion, but otherwise could also appease all parties? Everything is "commited to", but we take a conservative path towards it
06:40 < roconnor> It's hard to spin down other peoples nodes though.
06:41 < roconnor> willcl_ark_: without a graph of user uptake in hand, any LOT=true is likely to have a difficult time passing core review.
06:41 <@michaelfolkson> willcl_ark: In theory maybe. But it wouldn't get merged (imo)
06:41 < roconnor> like even with the graph in hand, it might be hard.
06:41 < willcl_ark_> I guess the main danger would be if "we" aborted (due to a security flaw for example), and some people were still running this version of the client with LOT=true...
06:42 < roconnor> The only way to get such a graph is to do some trial activation.
06:42 <@michaelfolkson> To be running a LOT=true client you are most likely a user following everything. You should (in theory) be able to get a message out to them
06:42 < willcl_ark_> roconnor: michaelfolkson: hmmm,  OK.
06:42 < harding> roconnor: is somebody proposing BIP8(3m, false)?  I mentioned that the other day but I didn't see any responses.
06:43 <@michaelfolkson> If you weren't following everything you'd be running an old version or whatever Core put out
06:43 < roconnor> I have had shower thoughts of core releasing a point relase who's only different is a relase note item that reads "Do not upgrade to this version if you don't want taproot". :D
06:43 < willcl_ark_> Amusingly, I was just thinking to myself that, vs this, the SegWit activation was actually pretty straightforward: simply a LOT=false and if it fails a UASF.
06:43 < maybehuman> it's funny, "let's see what happens" (i.e. false, 3m) was a poular choice right at the beginning of this channel iirc
06:44 < roconnor> harding: I think I am.  I don't know how much that is worth.  Mostly I think it would be a widely acceptable configuration based on my understanding of everyone's concerns.
06:44 < willcl_ark_> maybehuman: becuase everybody actually wants this, even miners reckoned they could upgrade in about two weeks (or at least f2pool said that)
06:44 < roconnor> harding: BIP8(3m,false) with an extended lockin-period.
06:45 < harding> roconnor: oh, good.  It's been my favorite option since I first summarized the options on the wiki like seven months ago.
06:45 <@michaelfolkson> UASF wouldn't release (true,3m) but yeah Core could release (false, 3m)
06:45 < willcl_ark_> harding: It certainly seems like a good approach to me. _if_ that fails, then you can try an understand why, without wasting too much time
06:45 < maybehuman> extended lockin period means there would be 2*2016 blocks (or more) until it activates?
06:45 < roconnor> harding: like all the other options are "better" in my opinion, but this one is good too.  And I don't care about the best activation; just one that can pass core review.
06:45 < harding> roconnor: extended lockin sounds reasonable to me and a good way to let miner voting start earlier.
06:46 < roconnor> I'm flexable on extact numbers but I'd roughtly do start time 2 weeks after release, 3 months of signaling, 3 months of lockin and then activation.
06:46 < harding> +1
06:46 < roconnor> all in blocktime of course.
06:47 < maybehuman> 3m lockin sounds pretty generous, but sure, why not
06:47 < willcl_ark_> Is anyone actually working on a PR for this btw? I thought I heard Andrew or someone might have been...
06:47 < roconnor> actually I mean that lockin should happen in up 6 months after the client release.
06:49 <@michaelfolkson> will_clark: Andrew said he'd work on a BIP 8 (false, 1 year) PR for Core at some point
06:49 <@michaelfolkson> *willcl_ark_
06:49 < roconnor> I think andy is going to split up PR 19573.  I'm personally willing to take a stab at the extended lockin time after that.
06:49 < willcl_ark_> fair enough.
06:49 < harding> Extending lockin to allow earlier signaling is a parameter change I don't think we evaluated earlier.  I wonder if that'd change things for other proposals too.
06:49 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
06:49 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
06:50 < maybehuman> the nice thing about a long lockin is that it gives interested parties the time to prepare some marketing event or something
06:51 < maybehuman> similar to what someone wrote about the flag day proposal recently
06:51 < roconnor> and also keep in mind that if signaling fails, then there is no lockin period and we can move right into more endless debating. :D
06:51 < maybehuman> maybe there could even be some releases with day 1 taproot support
06:51 < maybehuman> exactly. In the failure case you only los 3m
06:52 < harding> roconnor: right, that's the really nice thing about it for a quick "let's see what happens" approach.
06:52 < roconnor> heck we don't even need to stop endless debating while signalling is going on.
06:52 < roconnor> we can multitask.
06:52 < maybehuman> oh good, so I don't need to find a new series to watch
06:54 <@michaelfolkson> It depends on how long it takes to get out the Core BIP 8(3m, false) release out. If it took ages, it would almost certainly be in parallel with a UASF BIP 8(1 year, true)
06:54 < harding> roconnor: are you planning to write this up for the mailing list?  If not, I'm willing.
06:54 < roconnor> harding: If you are willing to do that, it would be fantastic.  I'm terrible at writing.
06:55 < harding> roconnor: you are not.
06:55 <@michaelfolkson> Ha no one is as good as you harding :)
06:55 < harding> michaelfolkson: pretty sure that's also untrue.
06:55 < roconnor> harding: I'm a little torn because you just said yesterday that you wanted to make a new ML. :D
06:56 < harding> But thanks for the complements.
06:56 < roconnor> Anyhow, I wasn't planning to write up something for the ML myself.
06:57 < roconnor> It is already breifly mention in my comments to Matt.
06:58 <@michaelfolkson> If harding is happy to do it, I think he'd be best
06:58 < aj> harding: having locked_in not last for a single retarget period is a marginally annoying change to the versionbits code -- you probably want to change the cache to cache "how long" as well as the state itself
06:59 < harding> roconnor: I want an end to the noise.  I feel like I have to read through every post to the ML so I can write summaries for Optech, so a flood of messages (even when everyone is well intentioned) is something of a DoS on my time.
06:59 < roconnor> aj: I understand. I think it will be doable, but I'll have to get my hands dirty to really find out.
07:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:00  * harding starting to write now.  It'll probably be a few hours, as I do have other things I need to get done today.
07:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
07:01 < roconnor> aj: and probably I get to do a pretty deep review of the BIP8 LOT=false PR while working on it, so that is a bonus.
07:07 < aj> roconnor: i tried something like that when playing around with MASF implementation, https://github.com/ajtowns/bitcoin/commits/202004-modern-soft-fork.1 i think was the code at one point fwiw
07:07 < harding> Does the basic idea even need BIP8?  It should be possible to do a tweaked BIP9, right?  That'd be a smaller diff to the current Bitcoin Core codebase.  (Although I do think BIP8's usage of block heights rather than times is an improvement by eliminating the chance miners could extend the activation window.)
07:09 <@michaelfolkson> UASF would use BIP 8. If Core wanted to release something incompatible with UASF then it could do BIP 9.
07:10 <@michaelfolkson> I think BIP 8(3m, false) would be superior personally (sample size of 1 obvs)
07:10 < aj> roconnor: MSFA not MASF; the acronyms in this discussion are the worst
07:13 < harding> michaelfolkson: if we're going to use BIP8 in the future, it certainly makes sense to get it in now, and I do think it BIP8(false) is superior to BIP9 just from its usage of heights rather than times.  I was just thinking about how to minimize code review so that deployment can happen quickly.
07:13 < roconnor> harding: I think Aaron might also be an avocate for BIP8(3m,false)
07:13 < roconnor> harding: reviewing the blocktime change is probably easier than reviewing the extended lockin change.
07:14 <@michaelfolkson> Again sample size of 1, but I don't think Core should be freaked out by UASF. If F7 holds for all future LOT=true releases (which I suspect it could) then UASF could be useful in future for Core
07:15 <@michaelfolkson> If it isn't freaked out by it BIP 8 makes most sense for Core
07:18 < harding> michaelfolkson: I think BlueMatt is the only person I've seen who seems completley opposed to BIP8, and he hasn't been an active contributor to Bitcoin Core for a couple years now, so I'm not sure what you're basing "Core [...] freaked out by UASF" on.
07:19 < harding> I do think lots of people don't want to start with UASF brinkmanship, but that seems independent from BIP8 concerns to me.
07:19 < brg444> Well suhas is another, at least
07:19 < harding> (Mostly independent)
07:19 <@michaelfolkson> harding: There was talk yesterday about politics and brinksmanship. Matt has talked about a game of chicken too
07:20 <@michaelfolkson> harding: I don't think it is helpful personally but it was raised yesterday
07:20 < harding> brg444: I read sdaftuar's post and I didn't see it as opposed to BIP8 in general as to just BIP8(true) as a starting point.  Happy to be corrected, though.
07:21 < harding> (His posted seemed to use "LOT" as a synonym for "LOT=true", which I think made it a bit confusing.)
07:21 -!- jonatack [~jon@37.167.227.177] has joined ##taproot-activation
07:22 <@michaelfolkson> I think it is as simple as just not referring to LOT or MUST_SIGNAL in the Core codebase
07:22 <@michaelfolkson> Semantics
07:23 < harding> michaelfolkson: not sure what you're saying.
07:24 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
07:24 <@michaelfolkson> Well there are two extremes if Core effectively implements LOT=false. One extreme would be the LOT=true code is in there in case it is ever needed in future. The other extreme is LOT and MUST_SIGNAL isn't even referred to in the Core codebase
07:24 <@michaelfolkson> But they are both BIP 8 (LOT=false)
07:25 <@michaelfolkson> A UASF would have to implement the LOT=true logic
07:25 < maybehuman> I mean lot false is basically the same as bip9 with block heights. so couldn't you argue that a prospective PR just fixes/improves that? the game of chicken is more a consideration for choosing timeouts and such, so not directly related to this particular change
07:25 < harding> Ah, ok, I understand now.  Thanks.  I don't particularly care either way.  Code can always be added later.
07:26 <@michaelfolkson> From what I understand from what Suhas has said he just wants no reference to LOT and MUST_SIGNAL in the Core codebase
07:26 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]
07:26 <@michaelfolkson> (Which is fine. It won't be taken out of the BIP but Core can ignore it)
07:27 < harding> OK.  Like I said, I read him as just using "LOT" as a synonym for LOT=true, so he didn't want LOT=true in the codebase.  I'll go re-read the post now to see if your explanation changes anything in my interpretation.
07:29 <@michaelfolkson> Well a MUST_SIGNAL phase (included in a BIP 8(true)) is on top of a BIP 8(false) implementation. A BIP 8(false) implementation doesn't even need to refer to LOT (I don't think)
07:29 <@michaelfolkson> It is semantics but if semantics make people more comfortable, whatever
07:30 < roconnor> my understanding is that separating PR 19573 implies creating a PR without MUST_SIGNAL.
07:30 < harding> Yeah, I stand by my original interpretation.  https://medium.com/@sdaftuar/on-taproot-activation-and-consensus-changes-in-bitcoin-5b3453e91c4e
07:31 <@michaelfolkson> roconnor: You could have a commit that implements the MUST_SIGNAL logic
07:31 <@michaelfolkson> And that MUST_SIGNAL logic could only be in the UASF codebase and not in the Core codebase
07:31 < harding> MUST_SIGNAL should just be dead code in a LOT=false implementation.
07:32 <@michaelfolkson> harding: Right, but if Suhas, Matt etc didn't want that dead code in there, fine, whatever
07:32 <@michaelfolkson> That code could be the UASF responsibility to write and review
07:32 <@michaelfolkson> If Core doesn't want to touch it, it doesn't have to
07:33 < roconnor> whatever reviewers opinions of dead code are, the PR can be split up in such a way to satify them.
07:33 <@michaelfolkson> Yup
07:33 < harding> Sure, not having that code would make review of the PR for Bitcoin Core less work.  Like I said, I think Matt is the only person I know who opposes BIP8 in general.
07:40 < luke-jr> michaelfolkson: BIP8(false) requires code that BIP8(true) doesn't
07:41 < luke-jr> michaelfolkson: as things stand, all activation code is dead in Core
07:41 < luke-jr> michaelfolkson: BIP9 has been dead there for a while now; they are hypocrites
07:41 < luke-jr> (or rather, that isn't a real reason, just an excuse)
07:42 < luke-jr> roconnor: letting it be split in such a manner will later be used as an excuse to use it with LOT=False
07:45 < luke-jr> [14:28:04] <roconnor> I don't think luke-jr's objections apply to BIP8(3m, false) (with extended lockin period). <-- at the very least, it still creates bad precedents and user confusion
07:46 < roconnor> luke-jr: user confusion can be address by lowering expectation.  Call it a taproot trial baloon.  The nature of 3m try-and-see is a consession to the fact that it might not activate.
07:46 < harding> luke-jr: who are hypocrites?  Adding dead code is not the same as retaining dead code.
07:48 < roconnor> luke-jr: but yes, I understand there may be NACKs of BIP8(3m,false) of the form "This won't activate taproot and there is no point in adding code to Core that won't work".
07:50 < maybehuman> both adding and reatining dead code happens all the time. I don't see what's wrong with that
07:52 < luke-jr> roconnor: it most likely would activate Taproot; but the bigger danger is the timeline around it
07:52 < luke-jr> roconnor: IIRC you were suggesting a startheight very soon - but that has not enough time for nodes to upgrade
07:52 < roconnor> nodes only need to upgrade before the end of lockin.
07:54 < aj> roconnor: oh, adding a minimum_activation_height parameter and having locked_in state continue if the height is lower than that would be easy
07:54 < luke-jr> roconnor: yes, that's just 4 weeks after startheight..
07:54 < roconnor> aj: right that is what I mean.
07:55 < roconnor> sorry for phrasing it badly.
07:55 < luke-jr> aj: purpose?
07:55 < aj> roconnor: (as opposed to a locked_in_must_last_x_retarget_periods parameter which was what i was thinking)
07:55 < luke-jr> oh, so the 3 month window is immediate, and we know for sure further in advance too?
07:55 < roconnor> Right, I did phrase it badly.
07:55 < roconnor> harding: "minimum_activation_height"
07:55 < aj> roconnor: i might just not have read carefully enough *shrug*
07:56 < luke-jr> but it doesn't solve the usual problems with LOT=False, and I'm not sure it makes sense in the context of True
07:56 < roconnor> it probably doesn't make sense in the context of True.
07:57 < luke-jr> roconnor: also, it might take away from people running Core+Taproot
07:57 < roconnor> well, not as much as Core+nothing. :D
07:57 < luke-jr> yes, at least as much O.o
07:58 < harding> roconnor: got it.  That also makes my description easier.
07:58 < roconnor> the "usual problems" with LOT=False are addressed by the 3m.  It removes the mixed network and simply conceeds that it might not activate taproot.
07:59 < roconnor> but even that is partially addressed by "it's only 3 months".
08:01 < luke-jr> it doesn't remove the mixed network
08:01 < roconnor> no one has proposed BIP8(3m,true).
08:02 < luke-jr> BIP8(True) is already happening no matter what Core does
08:02 < roconnor> and BIP8(1y,true) doesn't have the same issues.
08:02 < roconnor> because the forced activatoin of BIP8(1y,true) lies outside the window of BIP8(3m,false).
08:03 < roconnor> or at the very least the issues of BIP8(1y,true) are the same verus Core does nothing and Core does BIP8(3m, false).
08:03 < luke-jr> roconnor: but what happens if the 3m,false activates before 1y,true startheight?
08:04 < luke-jr> I suppose the 1y,true might be idiots to not switch, but many care more about LOT=True than Taproot, so I'm not sure if that's true
08:04 < roconnor> then core users will be using taproot, and BI8(1y,true) users won't be.  Miners may inlcude taproot transaction, but that is acceptable by BIP8(1y,true) nodes.
08:05 < aj> lot=true people will fork themselves off the network at timeoutheight
08:05 <@michaelfolkson> luke-jr roconnor: UASF users can be assumed to be more informed
08:05 < roconnor> However, IF BIP8(3m, false) does overlap with BIP8(1y,true) then they will both activate.
08:05 < luke-jr> michaelfolkson: yes, but there's still a question of whether it's in their interests to switch
08:06 < luke-jr> roconnor: but isn't that impossible?
08:06 < luke-jr> roconnor: 1y,true startheight isn't for like 5 months
08:06 < luke-jr> so if you want a 3m window soon, they won't overlap
08:06 <@michaelfolkson> luke-jr: If Taproot has successfully activated everyone will surely be happy to ditch the UASF
08:06 < luke-jr> even with the delayed activation
08:06 < roconnor> depends on the start height of the BIP8(1y,true).  IAFAIU it could be retoractive.
08:06 < luke-jr> michaelfolkson: not those who want LOT=True over Taproot
08:06 < luke-jr> michaelfolkson: I don't know how they will react
08:06 <@michaelfolkson> People might prefer LOT=true but the more important thing is to get this activated
08:07 < luke-jr> roconnor: ?
08:07 < roconnor> I think you can set a startheight prior to client release date.
08:07 < luke-jr> michaelfolkson: that is true of some LOT=true supporters, but not others
08:07 <@michaelfolkson> luke-jr: Fair enough
08:07 < roconnor> a lot of this depends on the exact order of client release and developments.
08:08 < roconnor> like if UASF client is released first, Core might choose to use a different Bit.
08:08 < roconnor> I don't know.
08:08 < roconnor> if Core can complete activation before the UASF client is released, maybe it will be abandonded.
08:08 < luke-jr> roconnor: that would be gratuitously incompatible
08:09 < roconnor> Look I don't get to decide for Core what bit they will use.
08:09 < roconnor> I just mean it is a logical possibility that I cannot rule out.
08:09 < luke-jr> right, but I would sure hope Core doesn't go out of the way to cause chain splits; that would be pretty undeniably malice
08:09 < roconnor> And I would even support using a different bit if that is what it takes to pass core review at the time, even if I perfer the same bit.
08:10 < roconnor> I think there would be no reason not to use the same bit though.
08:10 <@michaelfolkson> roconnor: Yeah as long as Core moves forward I think that would be fine. If Core takes ages to get it out then there is uncertainty
08:10 < roconnor> the primary goal is to not have the BIP8(3m,false) signaling period overlap with the BIP8(whatever, true)'s manditory signaling period.
08:11 < luke-jr> roconnor: that's a harmful goal tho
08:11 < roconnor> well, if it has a shot at getting taproot activated I guess I don't find it harmful.
08:12 < luke-jr> overlapping has a better shot
08:12 < roconnor> BIP8(3m,false) doesn't preclude core releasing another BIP8 afterwards that does overlap.
08:12 < maybehuman> I'm almost afraid to ask, but what is the rationale for "wanting lot true more than taproot"?
08:13 <@michaelfolkson> If no overlap, the UASF release would have to be ready to go by the end of the failed Core (3m,false) activation period
08:13 < aj> roconnor: "the primary goal is to not overlap" ? huh?
08:13 < luke-jr> maybehuman: not reintroducing the miner veto vulnerability
08:13 < roconnor> aj: that is Matt's objection right?
08:14 <@michaelfolkson> maybehuman: It isn't wanting anything more than Taproot. It is about getting to something that can work to activate Taproot
08:14 <@michaelfolkson> maybehuman: Something that won't get NACKed to death
08:14 < luke-jr> maybehuman: that is, they don't really care about Taproot itself; but they do care not to lose the current LOT=True precedent
08:15 < maybehuman> well, it takes all kinds I guess...
08:15 < aj> roconnor: i think matt's goal is more along the lines of avoiding "we'll fork you off the network brinkmanship" ; it's not clear to me how much overlapping with a third-party client's activation params affect that
08:16 < roconnor> BIP(3m,false) nodes cannot be used as leverage for BIP8(1y,true) nodes if the manditory signalling period doesn't intersect.
08:16 < roconnor> hence no brinkmanship.
08:16 < roconnor> or at least no more brinkmanship than Core + nothing.
08:16 < luke-jr> aj: that misses the point that BIP8(1y,True) is already decided.. doing anything else just creates more brinkmanship
08:17 < aj> roconnor: yes, but perhaps including/using bip8/false code at all goes too far on that score at this point
08:17 < roconnor> I don't see what the objection is.
08:17 < aj> luke-jr: you speak as if you're the only economic node in the network
08:17 < luke-jr> aj: you speak as if I'm the only one doing this
08:18 <@michaelfolkson> luke-jr: As long as there is a timetable I would be shocked if UASF community wanted LOT=true precedent more than Taproot activated
08:18 < luke-jr> aj: and creating incompatible alternatives just increases the risks involved
08:18 < luke-jr> michaelfolkson: it would split us
08:19 <@michaelfolkson> luke-jr: I don't think so. We could discuss at a meeting and see what people think
08:19 <@michaelfolkson> I could be wrong
08:19 <@michaelfolkson> The lack of timetable and lack of certainty is p***ing everyone off
08:21 <@michaelfolkson> A UASF release would never release LOT=true. That's for sure
08:21 <@michaelfolkson> Sorry LOT=false
08:21 <@michaelfolkson> ;/
08:21 <@michaelfolkson> A UASF release would never release LOT=false. That's for sure. But UASF can't force Core into doing things
08:22 < luke-jr> michaelfolkson: not doing something is one thing; but fracturing the network actively is another
08:23 <@michaelfolkson> luke-jr: It isn't fracturing it. If Core BIP 8(3m, false) fails UASF is ready to go
08:24 <@michaelfolkson> UASF doesn't wait around then for Core to release LOT=true (because I don't think it would)
08:25 <@michaelfolkson> I think this is fine. But we should confirm that with people who have got involved with UASF thus far
08:25 < roconnor> for the record I think Core might relase LOT=true after a BIP(3m,false), or a flag dag.
08:26 < roconnor> day
08:26 < mol> i was with UASF, im not going to run any client other than core until i see there is logic to go with UASF
08:26 < roconnor> though michael is probably better informed than I am. ...
08:26 < mol> at the moment pushing UASF is committing suicide
08:26 < luke-jr> I doubt 3m,false would fail, though; which would set a bad precedent
08:26 < luke-jr> mol: just more FUD..
08:27 < mol> negative
08:27 < roconnor> I acknowledge that (3m,false) might have NACKs of the form "this will set a bad precedent", but if we can get that far, I'll be pretty happy.
08:27 < maybehuman> luke-jr so your problem with false, 3m is really that it will probably work?
08:28 <@michaelfolkson> luke-jr: Why bad precedent? A UASF is a lot of effort. If it isn't needed and will activate speedily, UASF isn't needed
08:28 <@michaelfolkson> luke-jr: The precedent with UASF is being there if small group of individuals intentionally block activation for no reason
08:28 < roconnor> "this will set a bad precident" is even better than "this won't work".
08:29 < luke-jr> michaelfolkson: UASF does not need to be any more effort than any other option
08:29 <@michaelfolkson> luke-jr: It is if you want to get entire economy to run it
08:30 <@michaelfolkson> luke-jr: Requires a lot of communication if nothing else
08:30 < luke-jr> michaelfolkson: that's not unique to LOT=True
08:31 <@michaelfolkson> luke-jr: Everyone is used to a process of updating Core. Running a UASF release is a lot more work
08:32 <@michaelfolkson> luke-jr: If it was plausible that Core would merge LOT=true then I agree. But it just isn't plausible
08:33 < harding> aj: do you have a link to that gist or pastebin you made with the time it took to lockin/activate various soft forks?  My notes say BIP68/etc took one month, but I'd like to link to an actual source if I mention that.
08:33 <@michaelfolkson> Economic majority running UASF release is possible. But it is more work
08:36 < aj> harding: https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
08:36 < harding> aj: thanks!
08:41 < maybehuman> btw, I think people who believe lot=false means miner veto are confused. Some tried to use it that way in 2017, and it did not end well for them. So I would argue there's empirical proof that it's not a veto
08:45 < maybehuman> lot=true otoh is a bit like a justice transaction in Lightning. It provides security because you _can_ use, but that doesn't mean you have to
08:47 <@michaelfolkson> maybehuman: Semantics. If you set lot=false you are allowing miners not to activate. That sounds like a veto to me
08:48 < maybehuman> yeah, let's not get into that discussion again..
08:48 <@michaelfolkson> maybehuman: But I don't think a 3 month veto is harmful
08:48 <@michaelfolkson> maybehuman: I can see why some people don't like the idea of a 1 year veto
08:49 < maybehuman> but no, for me it doesn't. For me it means core is off the hook mostly. And if miners play stupid games, we know that can be dealt with
08:50 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation
09:03 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed]
09:15 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
10:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 245 seconds]
10:47 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
10:49 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Ping timeout: 240 seconds]
10:54 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Ping timeout: 272 seconds]
11:03 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]
11:03 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
11:06 -!- cguida [~cguida@2806:2f0:51c1:5cee:4183:71f4:847c:b4d9] has joined ##taproot-activation
11:45 -!- jonatack_ [~jon@37.170.241.200] has joined ##taproot-activation
11:48 -!- jonatack [~jon@37.167.227.177] has quit [Ping timeout: 260 seconds]
12:02 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation
12:08 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:15 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation
12:32 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:47 -!- jonatack_ [~jon@37.170.241.200] has quit [Quit: jonatack_]
12:47 -!- jonatack [~jon@37.170.241.200] has joined ##taproot-activation
13:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
13:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
13:13 < harding> roconnor, aj, michaelfolkson, anyone else: here's a draft of the email I'd like to send to the mailing list.  The FIXMEs left should all be specific references, so they shouldn't take away from the point.  Comments welcome; I have to go shopping but I'll be back in about an hour.  https://gist.github.com/harding/d64ac8dbd79303404cca793a722f7674  (If you have a better name thas "S4DE", I'd be happy to hear it.  I think giving the proposal a
13:13 < harding> name rather than a BIP8(blah, blah) description might help it gain traction.
13:14 < roconnor> I'm not opposed to S4DE.  I've been thinking of taproot trial balloon myself.  I'm terrible at naming things.
13:16 < roconnor> actually I was thinking mimumum activation of 6m, but I'm not married to any specific value.
13:18 < roconnor> Minimum activation height is a activation parameter that is a fixed value decided in avance.
13:18 < roconnor> oh I misread what you wrote.  Yes it is correct.
13:20 < CubicEarth> I skim this every other day or so. Are we making progress? Or are we endlessly debating whether the glass is half empty or half full?
13:21 < roconnor> harding: was the earliest activation of the previous proposal 3 months or so from client release?
13:25 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
13:26 < maybehuman> out of curiosity: Why a fixed min activation height instead of an offset?
13:26 < maybehuman> i.e. x periods after threshold was reached
13:27 < roconnor> Both factors are in effect.
13:27 < roconnor> one parameter is to give time for users to install clients, which is a minumum time from client release to activation.
13:28 < roconnor> the other parameter is to give time to miners (and like really users, now it's time already), which is relative to the end of the signaling phase.
13:28 < roconnor> the activation needs to be after both of them.
13:29 < luke-jr> harding: 3m is way too soon
13:29 < nickler> How likely is it that this will work? 3 months is short for 90% signalling.
13:29 < maybehuman> It's just that while I was reading the draft I thought it would be nice if instead of "we could get up to three months advanced notice" it would be "we will get three months advanced notice"
13:29 < luke-jr> I mean for activation
13:30 < roconnor> nickler: https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc suggest many activations have occured in less time.
13:31 < luke-jr> oh, that's 3m+3m
13:31 < luke-jr> or is it? no I guess not
13:31 < maybehuman> currently it's 3 + up to 3
13:32 < maybehuman> but I agree 3+3 would be better
13:32 < roconnor> luke-jr: I was thinking min activation at around 6 months from start-date
13:32 < luke-jr> maybehuman: no, it's just 3 now
13:32 < nickler> roconnor: I'd think those were very different times
13:33 < roconnor> nickler: I don't know if it will work, but it might and we will be able to gather some statistics on users actively upgrading the Core client to taproot.
13:33 < roconnor> which I believe will make a follow up LOT=true or flag day more likely to pass core review.
13:36 < nickler> roconnor: seems more likely that the hashrate that updates will be close to the 90% threshold. So no miner veto that'd need to be obviously overridden with lot=true.
13:36 < roconnor> I don't quite understand your comment.
13:37 < nickler> roconnor: if it fails and signalling hashrate was 85%, that's just miners updating slowly, not a miner veto.
13:37 < luke-jr> I think LOT=True folks could be convinced to add this on to the current activation.
13:37 < luke-jr> but it's important that any release with just it be clear that it's experimental, not a final Taproot release
13:38 < luke-jr> (experimental in the sense of "hey, it might fail - that's okay")
13:40 < roconnor> nickler: That's okay, if Core is convinved to try again, they can do another 3 month trial or whatever.  Either way I think LOT=true or a flag day will be more likely to pass core review after this trial balloon.
13:40 < roconnor> luke-jr: I'm fine with lowering expectations.
13:41 <@michaelfolkson> How about "trial balloon" for the name instead of S4DE? :)
13:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
13:42 < roconnor> you can thumbs up my comment I just added.
13:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
13:43 < nickler> roconnor: I doubt it, but I like the idea of normalizing activation failure. Perhaps add another softfork for the next trial to make it more appealing (sighash_anyprevout anyone?)
13:44 < maybehuman> how about "Taproot Express" or something?
13:44 < copumpkin> all aboard!
13:44 < maybehuman> if the fast one doesn't work, we'll got with a slower one next
13:44 < luke-jr> XD
13:45 <@michaelfolkson> Prefer trial balloon, it is exactly what it is
13:45 < luke-jr> nickler: trial ok, two trials NACK ;)
13:45 <@michaelfolkson> roconnor: I don't think I can thumbs up on a gist :)
13:45 < luke-jr> I do think regardless current discussions on activation methods can be helpful to the next softfork
13:45 < maybehuman> it would make for great train wreck comments if it fails :-)
13:45 < luke-jr> maybe we can have two in parallel finally
13:46 <@michaelfolkson> https://en.wikipedia.org/wiki/Trial_balloon
13:47 < aj> harding: T=early april, 679392 ~= mid-april = startheight, 693504 = timeoutheight, why not just set 695520 = earliest activation = latest activation?
13:47 < maybehuman> miner activated flag day?
13:48 <@michaelfolkson> maybehuman: Why are so desperate to pop the trial balloon? :)
13:48 < nickler> luke-jr: s/next trial/next whatever(???)/
13:50 <@michaelfolkson> I don't think it makes sense to do a second trial balloon if it fails. We go back to where we were yesterday with potentially parallel Core and UASF deployments
13:50 < roconnor> Probably.  I mean a lot depends on the specifics of the trail outcome.
13:51 < maybehuman> michaelfolkson I'm not overly serious, but to me trial baloon kind of has the connotation of a dry run
13:51 < aj> harding: unless you figure don't even do block heights, just tweak bip9 with the delayed locked_in to active param
13:53 < luke-jr> is there a word that suggests fast and unsure?
13:54 <@michaelfolkson> maybehuman: "Let's see what happens" wasn't exactly a confident name. I think trial balloon is in same spirit. It could work, it could not
13:54 <@michaelfolkson> luke-jr: Reckless? :)
13:54 < copumpkin> luke-jr: hasty/hurried often have that sort of connotation
13:55 <@michaelfolkson> luke-jr: A leap of faith
13:55  * michaelfolkson will get his coat
13:55 < luke-jr> hmm
13:55  * luke-jr grabs a thesaurus
13:55 < roconnor> ##taproot-activation-name
13:56 < roconnor> j/k
13:56 <@michaelfolkson> I will die on the "Trial balloon" hill
13:56 < luke-jr> Audacious?
13:57 < luke-jr> nah, too unusual a word
13:57 < luke-jr> oooh- breakneck?
13:58 <@michaelfolkson> Ok I know I encouraged this but let's focus on the details rather than the name
13:58 < luke-jr> XD
13:59 < luke-jr> May 1 - Aug 1 duration, min activation Oct 31? :P
14:00 < maybehuman> michaelfolkson my concern was rather that someone might think it's just a test run, i.e. it can't actually activate even if the threshold is reached
14:01 < maybehuman> which in turn might lower uptake
14:02 <@michaelfolkson> maybehuman: Same criticism could be leveled at "Let's see what happens". It won't be referred to widely (like say "Taproot"), just in dev circles. But let's leave the name for now
14:03 < maybehuman> agreed
14:03 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
14:03 < waxwing> so we all get in the trial balloon but then it actually takes off and starts flying over the atlantic :)
14:04 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
14:05 <@michaelfolkson> Details waxwing details. You can plan what snacks you take with you nearer the time lol
14:06 <@michaelfolkson> We have no idea how this will be received. It could be popped within a day on the mailing list
14:07 < nickler> The "trial" part is imo the most important to convey. Otherwise, it asks for mixed network but now with shortened timeline. There would certainly be lunatics forcing MUST_SIGNAL after 3 months or try to flag day activate after 6 months.
14:09 <@michaelfolkson> nickler: Right it avoids this awkward Core and UASF dance but is short enough so that it doesn't really matter if it fails
14:11 < maybehuman> and we're confident 3m is enough for everyone to update?
14:11 < maybehuman> I mean if it was only miners and not nodes that wouldn't be great, right?
14:11 < roconnor> I've commented my original thought was a 6m min activation height.
14:11 < roconnor> I'm not married to any particular value.
14:12 < maybehuman> why not 3m after threshold is reached? Too wide a range of possible outcomes?
14:12 < roconnor> I mean, if it activates super early, maybe we still want 6 months from the client release to activation.
14:13 < roconnor> we need to make sure the economy is in place as well as the miners.
14:13 <@michaelfolkson> maybehuman: You don't need "everyone". Personally I think 3m is fine as long as the release isn't rushed and everyone knows what's coming
14:13 < roconnor> whatever parameter passes review. I'm fine with.
14:14 < roconnor> I think it will be easy to accomidate.
14:14 <@michaelfolkson> roconnor: As long as it doesn't get immediately shot down I'll ask Alejandro to try to get feedback from mining pools
14:14 < maybehuman> so in a way min activation height replaces lot
14:14 < maybehuman> which is nice, because it's not binary, so there's room for compromise
14:15 < roconnor> well min activation height lets us move the signalling phase upfront.
14:15 <@michaelfolkson> maybehuman: No LOT was a parameter that either enforced MUST_SIGNAL or didn't
14:15 <@michaelfolkson> *is
14:15 < maybehuman> yes, sorry, I didn't mean literally
14:16 < roconnor> *lol* yes it is another parameter to fiddle with.
14:16 < roconnor> but just taking the smallest value that all reviews can agree to is probably going to be okay.
14:16 <@michaelfolkson> A trial balloon has to be fast. It has to be 3 months, just with a lot of advance warning and preparation
14:17 < roconnor> well the signalling is fast, it is still 3 months.
14:17 < roconnor> if the signaling fails, there is no lockin phase at all.  It is just over.
14:17 <@michaelfolkson> Ok, yeah
14:18 < roconnor> so the trail balloon is only maybe a little slow after success.
14:18 < roconnor> but, I think everyone will be willing to wait after great success.
14:18 <@michaelfolkson> Yeah I think that's good
14:19 <@michaelfolkson> harding has described it as "fail fast"
14:19 < roconnor> exactly.
14:19 < roconnor> which is the benefit of moving the signalling phase upfront.
14:22 < belcher> just read the backlog, good job everyone with trail balloon bip8(3m, false)... it didnt occur to me that reducing the time period would help reduce the controversy with lot=false
14:33 < mol> roconnor, if i understand it correctly, in other words, this is to give the community to veto Taproot in 3 mos, and if they fail to veto it, we can move forward to activate taproot?
14:43 < harding> Thanks for the comments everyone!
14:44 < harding> I based 3 months on a slight misremembering of https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 , which many of us agreed upon, and which gives about 4.5 months from latest estimated release to earliest activation (assuming 10 min/block).
14:46 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
14:46 < belcher> as a native english speaker id never heard of the phrase "trial balloon" before this, i know it can be called bikeshedding, but the name is very important so that people can read it and immediately know what the idea is (especially on places like twitter), so id suggest the name "try-and-see activation"
14:47 < belcher> its inaccurate to say that the name only matters for devs and not the general public, because the general public have already gotten involved on twitter/reddit/other places
14:48 < belcher> (however im not willing to die on this hill, the concept is pretty great for reducing the controversy around bip8(1y, false) regardless of how its named)
14:49 < harding> I think keeping the expiration at 3 months but increasing the minumum activation to 6 months is fine.  I think we'd be ok with both being 3 months (or I wouldn't have put that in my email) but I don't see any significant harm to the appeal of the proposal by playing it safe in that area.  Is there anyone who wants to argue for a different value?
14:50 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 268 seconds]
14:50 < harding> belcher: also a native speaker (American English) and, although I've heard the term before, I didn't know what it meant until I read the Wikipedia page michaelfolkson linked.
14:51 < harding> "Speedy trial"?
14:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
14:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
14:53 <@michaelfolkson> mol: 3 months of miner signaling basically. If it fails, it fails fast. If it succeeds, it activates after a pause
14:54 < harding> nickler: miners can begin false signaling even before there's a release.  I believe that idea was mentioned here a few days ago.  I don't think we want to encourage that, but evidence from the BIP68 activation (false signaling support) and segwit (using Bitcoin Core transaction selection while not signaling support) indicates that miners are willing to signal their preferences without the work of changing software.
14:54 < belcher> regarding the 6m vs 3m minimum_activation, it seems the main value-add of 3m is that the activation and possible failure is *fast*, thats what makes the point that we can try other stuff afterwards and that we havent lost much time... so because of that using 6m instead isnt a good idea (however im not part of the crowd you have to convince, as i was happy with 1y, lot=false)
14:55 < belcher> following on from the idea that its fast, how about making the activation period be just 2016 blocks or maybe 4032 blocks, i.e. miners get just 1 or 2 attempts to activate it, then we set minumum activation to 6m or 3m or whatever to give miners and many users time to get ready
14:56 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
14:56 < maybehuman> belcher: the fail case would stay at 3m
14:56 < maybehuman> the additional 3 would only apply if it locks in
14:57 < belcher> oh yes, derp... we're actually talking about the time after a successful signalling period
14:58 < mol> michaelfolkson, ah i see..
15:02 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
15:08 < nickler> harding: good point. Not sure how much that distinction matters for the slowest percents of hashrate.
15:23 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
15:26 < harding> aj: I think I would prefer a tweaked BIP9.  I think it'd be the smallest diff.
15:28 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
15:41 -!- jonatack [~jon@37.170.241.200] has quit [Read error: Connection reset by peer]
15:46 < achow101> there's too much backlog, any tl;dr?
15:46 < achow101> or anyone want to write an email to the mailing list?
15:47 < belcher> yeah they'll be an email most likely
15:48 < achow101> from my brief skim, the suggestion is essentially modern soft fork activation on an accelerated timeline?
15:48 < achow101> *very accelerated
15:49 < belcher> yeah, bip8(3m, false), with the reasoning being that the accelerated timeline means that if miners block they can only block for a really short time... and that appears to have removed the controversy about bip8(1y, false) from those who previously supported a UASF alt-client
15:51 < belcher> the name used is something like "speedy trail", to get the point across that this is just one attempt, and if it fails no big deal we can do something else (a LOT=true most likely), regular users would know that they're not guaranteed to get taproot this time and might have to update again depending on what happens
15:52 < achow101> wouldn't 3m be the fastest soft fork deployment ever?
15:53 < belcher> aj had a list somewhere showing that some other soft forks were also pretty fast, sec i can try to find
15:53 < belcher> https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
15:54 < achow101> huh. I guess 3 months is longer than I think it is
15:54 < belcher> also we have that fact that ~90% of hashrate said it would activate taproot
15:55 < achow101> the other difference in this "speedy trial" is an extended lock in
15:55 < achow101> ?
16:00 < belcher> it seems the purpose of that is to give miners a chance to really update their full nodes when they know the taproot rules are coming, and that should help avoid accidental chain splits such as after bip66, apparently in miner pool software signalling and the full node are separated
16:05 < achow101> I was going to implement bip8(1y, false) w/ lot config option on my stream on monday, but if the speedy trial is agreeable with everyone, I might implement it instead
16:07 < harding> belcher: to me, the purpose of the six month delay (as currently proposed) is to ensure the main economy (e.g, you, me, coinbase) have a chance to upgrade so that, if miners pull a 4 July 2015 accidental chainsplit (or a deliberate version), they're forced to take the loss---not us.
16:09 < belcher> achow101 it me it seemed everyone in this channel agreed with it including people who supported LOT=true
16:12 < achow101> I like the idea of it
16:13 < achow101> msfa on an accelerated timeline has been what I've been advocating for
16:13 < harding> achow101: I'm editing the email now and it'll go out by the end of my day, so you should have at least the weekend's worth of ML feedback on it by monday.
16:13 < achow101> great!
16:28 < proofofkeags> as a L=T proponent myself, I'm prepared to back off in favor of this
16:30 < proofofkeags> It still is somewhat strange to me that this is resonating better than a hypothetical BIP8(15mo, true) proposal. But I'm not one to look a gift horse in the mouth. If this appeases those who are starkly in favor of trying BIP8(_, false) first, with the recognition that there will be UASF movement after the fact (if needed), then yeah. Ship it.
16:36 < harding> proofofkeags: I think we're all a bit mystified at each others' preferences towards activation.  :-)
16:37 < proofofkeags> if that's the case, then clarifying the reasons behind said preferences could accelerate consensus
16:39 < proofofkeags> my understanding of the L=F crew was that they didn't want to do an "unnecessary show of force" with a UASF from the getgo, even though an expectiation of BIP8(3mo,false) >> BIP8(1y, true) is semantically identical to BIP8(15mo, true)
16:41 < harding> I don't think it's equivilent.  There's a chance to learn something during the 3m period that can inform the later attempt.
16:43 < harding> Also, there's the chance to just get something done now while debate about long term concerns continues.
16:46 < roconnor> There are a couple of things this achieves, (1) is we get to gather concrete data about users being willing to upgrade.  I think this data would be helpful for getting LOT=true or flag day into Core if speedy trial fails.
16:47 < roconnor> (2) LOT=true is less likely to be running in parallel.  Generally people are okay for a 3 month wait an see, and BIP8(3m,true) has never been anything anyone has advocated for.
16:48 < luke-jr> roconnor: (2) sounds malicious; a spite LOT=True just for the sake of it
16:48 < roconnor> I don't mean it that way.
16:49 < belcher> harding a possible concern with 6m is that its 12 times the amount previously, and theres some weak evidence that a longer delay makes it less safe because it kills urgency (but i dont care either way, 6 months is much better than debating it forever)
16:50 < belcher> (2) seems to deal with the objection that "we shouldnt do bip8 because there would be a mixture of consensus rules", i dont see it as motivated by spite but more about getting everyone to agree
16:52 < harding> 4 months (so 14 days + 4 months = 4.5 monhs) based on https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 suggesting 4.5 months as a minimum?  I don't have a real strong preference here; I think 2 months is awfully short, 3 months would be my lower bound, and 6 months is the most I want to wait (I can wait for longer, but I don't *want* to).
16:52 < luke-jr> BIP8(True) is not a mixture of rules
16:53 < luke-jr> harding: IMO the 4-5 months proposed was pushing the limit of what might be safe
16:55 < luke-jr> roconnor: well, it may be a good idea to work on how you say that, since presumably the goal is consensus ;)
16:55 < roconnor> luke-jr: I will.
16:55 < luke-jr> how it's phrased I mean
16:55 < roconnor> I understand.
16:55 < harding> luke-jr: you realize that's longer than every other soft fork than BIP34 and 143?  https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc
16:55 < roconnor> sorry
16:55 < roconnor> I think 6 months is a bit conservative, but I'm still happy with it.
16:56 < roconnor> I was trying to err on the conservative side.  I'm not married to this number.
16:56 < roconnor> I also think it is the least important value.
16:57 < luke-jr> harding: if so, I am okay with that being true. even if we weren't careful before, we should be going forward
16:57 < jeremyrubin> I think that 3 months is best for this -- at 6 months I think idle hands will become the devil's tools
16:57 < roconnor> jeremyrubin: 3 months from the start date?
16:57 < jeremyrubin> Ah -- 3 months timeout
16:57 < luke-jr> harding: also, the actual activations were not so rapid IIRC
16:58 < roconnor> right, this value is the time between client release and minimum activation time.
16:58 < roconnor> approximately
16:58 < jeremyrubin> I have previously noted on the mailing list that I think that enabling new rules should be done at fixed dates as opposed to relative dates
16:58 < luke-jr> maybe just segwit was longer
16:58 < luke-jr> (bip91 does not count - that was a miner attack complying with BIP148, not a softfork)
16:58 < roconnor> jeremyrubin: I think this proposal would effectively give a fixed block time for activation
16:58 < jeremyrubin> Yeah +1 that
16:59 < jeremyrubin> picking an exact height is very good IMO
16:59 < roconnor> maybe a fixed date if people want to work on BIP9 for expedience.
16:59 < jeremyrubin> roconnor: no, I meant height by date
17:00 < jeremyrubin> date is more confusing
17:00 < roconnor> okay.  I'm in favour of height based as well.
17:00 < roconnor> But I'll probably accept either.
17:00 < harding> What's the reason for the preference with heights?
17:01 < jeremyrubin> v.s. dates?
17:01 < jeremyrubin> or v.s. relative times
17:01 < harding> I added a section about that to my draft (not pushed) and I couldn't see a reason for using heights if there's no potential of LOT=true with this proposal.
17:01 < roconnor> you can more easily count blocks for signaling IIRC.
17:01 < harding> jeremyrubin: absolute dates MTP vs heights.
17:01 < roconnor> I mean technically it matters somewhat less for min-activation, but if everything else is height based.
17:02 < roconnor> also miners could in theory play games wiht MTP, but that is nearly impossible with height.
17:02 < jeremyrubin> height is also not gameable whereas time is if you want to get infinite difficulty
17:02 < jeremyrubin> roconnor: +1
17:02 < roconnor> the only advanagate of dates is that we don't have to implement BIP8.  But we should probably implement BIP8.
17:03 < jeremyrubin> heights are also better IMO for burried deployments
17:03 < jeremyrubin> Also context-free validation of blocks
17:03 < luke-jr> jeremyrubin: buried deployments use height regardless..
17:03 < jeremyrubin> MTP requires the header chain right?
17:03 < roconnor> oh that's a good observation.
17:04 < roconnor> while the blocktime is in the header, the MTP isn't.
17:04 < jeremyrubin> height is in the header :)
17:04 < jeremyrubin> or in the block rather
17:04 < luke-jr> not quite, but close enough
17:04 < jeremyrubin> right? in the coinbase
17:04 < luke-jr> right
17:04 < roconnor> also I think the height isn't far away in the data structures used in Bitcoin Core.
17:05 < harding> jeremyrubin: coinbase can be 100,000 bytes, though, but you can validate MTP in 11*80 bytes of previous headers.
17:06 < luke-jr> roconnor: well, we cache height in the index
17:09 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 260 seconds]
17:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
17:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
17:33 < harding> Updated draft: https://gist.github.com/harding/d64ac8dbd79303404cca793a722f7674  I think I addressed all feedback from the gist and most from this room.  I'm adding references now, will update it after that, and hope to email it about an hour after that.  Feedback welcome up until that point.
17:54 < harding> kanzure: when does your log bot update its logs?  I thought it was near real-time, but I don't see a log for today.
18:12 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:16 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds]
18:26 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:28 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
18:28 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 256 seconds]
18:40 < kanzure> harding: seems your question made it into the logs? http://gnusha.org/taproot-activation/2021-03-05.log
18:42 < harding> kanzure: argh.  Sorry. PEBKAC.
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
19:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
19:45 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
20:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
20:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
20:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
20:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
20:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
21:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
21:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 276 seconds]
22:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
22:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
22:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
22:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
23:27 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
23:56 -!- cguida [~cguida@2806:2f0:51c1:5cee:4183:71f4:847c:b4d9] has quit [Ping timeout: 272 seconds]
--- Log closed Sat Mar 06 00:00:48 2021