--- Log opened Tue Apr 19 00:00:59 2022
00:55 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
00:55 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review
01:18 -!- Guest53 [~Guest53@213-147-161-58.nat.highway.bob.at] has joined ##ctv-bip-review
01:20 -!- Guest53 [~Guest53@213-147-161-58.nat.highway.bob.at] has quit [Client Quit]
01:46 -!- johnzweng [~johnzweng@zweng.at] has joined ##ctv-bip-review
01:47 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
02:36 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
03:19 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
05:00 -!- tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review
05:51 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Quit: tnull]
05:53 -!- tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review
06:23 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Read error: Connection reset by peer]
06:35 -!- tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review
07:46 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Quit: tnull]
07:50 -!- tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review
08:50 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Quit: tnull]
08:51 -!- tnull [~tnull@user/tnull/x-8645464] has joined ##ctv-bip-review
09:00 -!- tnull [~tnull@user/tnull/x-8645464] has quit [Quit: tnull]
09:01 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##ctv-bip-review
09:02 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
09:10 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##ctv-bip-review
09:30 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
09:31 -!- gue30 [~gue@137.97.69.178] has joined ##ctv-bip-review
09:44 -!- gue30 [~gue@137.97.69.178] has quit [Quit: Client closed]
11:09 -!- roconnor [~roconnor@coq/roconnor] has joined ##ctv-bip-review
11:33 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
11:46 -!- Guest73 [~Guest73@aputeaux-681-1-94-2.w90-86.abo.wanadoo.fr] has joined ##ctv-bip-review
11:49 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##ctv-bip-review
11:56 -!- Guest43 [~Guest43@fibhost-66-168-253.fibernet.hu] has joined ##ctv-bip-review
12:00 < jeremyrubin> #beginmeeting
12:00 -!- kaloudis [~kaloudis@cpe-98-26-57-16.nc.res.rr.com] has joined ##ctv-bip-review
12:01 -!- roasbeef [~roasbeef@104.131.26.124] has joined ##ctv-bip-review
12:01 < jeremyrubin> Hello all and welcome to the 7th BIP-119 Meeting!
12:01 -!- jamesob__ [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has joined ##ctv-bip-review
12:01 -!- Guest73 is now known as GuerillaV2
12:01 < jeremyrubin> today we have no strict agenda, but we intend to discuss possibilities for CTV activation in 2022
12:02 -!- kaloudis is now known as gkaloudis
12:02 < jeremyrubin> i've published some thoughts on, if we were to do that, what it would look like here https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
12:03 < jeremyrubin> let's have a few minutes free for anyone to review the post and we can begin discussion shortly
12:04 -!- ubba41 [ubba@gateway/vpn/protonvpn/ubba] has joined ##ctv-bip-review
12:05 -!- ubba41 [ubba@gateway/vpn/protonvpn/ubba] has quit [Client Quit]
12:05 -!- ubba [ubba@gateway/vpn/protonvpn/ubba] has joined ##ctv-bip-review
12:06 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review
12:06 < rgrant> hi
12:07 -!- laroberts [~laroberts@cpe-76-185-111-141.tx.res.rr.com] has joined ##ctv-bip-review
12:08 -!- mode/##ctv-bip-review [+o jeremyrubin] by ChanServ
12:08 -!- mode/##ctv-bip-review [+o jeremyrubin] by ChanServ
12:08 -!- jeremyrubin changed the topic of ##ctv-bip-review to: The topic is: The topic is: review for BIP-119 Check Template Verify, see https://utxos.org. Channel logged at https://gnusha.org/ctv-bip-review. Recurring meeting 12:00 PT every other Tuesday (starting January 11th). If you joined this meeting after the start time, please check the logs first :)  today's meeting: see https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ for context
12:09 <@jeremyrubin> hi rgrant
12:09 <@jeremyrubin> ok have folks had a moment to review the blog post? Maybe we can do a run through first of what i wrote and each of the 7 theses?
12:10 < jamesob__> mostly through it
12:10 <@jeremyrubin> will do another few mins
12:11 -!- jirigrill [~jirigrill@2a02:830a:b002:3900:8a5:5c19:a57a:f93f] has joined ##ctv-bip-review
12:12 -!- jirigrill [~jirigrill@2a02:830a:b002:3900:8a5:5c19:a57a:f93f] has quit [Client Quit]
12:12 -!- jirigrill [~jirigrill@2a02:830a:b002:3900:8a5:5c19:a57a:f93f] has joined ##ctv-bip-review
12:12 <@jeremyrubin> Ok
12:13 <@jeremyrubin> We'll start with a quick cover of what the post is offering
12:13 -!- Guest281 [~Guest28@151.34.153.116] has joined ##ctv-bip-review
12:14 <@jeremyrubin> A v23 and v22 (backport) BIP-119 compatible client  that can signal via ST for BIP-119 between May 5th and August 12th
12:14 -!- jirigrill [~jirigrill@2a02:830a:b002:3900:8a5:5c19:a57a:f93f] has quit [Client Quit]
12:14 <@jeremyrubin> and would activate in mid-early november
12:15 <@jeremyrubin> if we wanted to have a ST for CTV this year, this is sort of the only parameter selection that makes sense, unless we depart from traditional concerns
12:15 <@jeremyrubin> https://rubin.io/bitcoin/2021/12/24/advent-27/ this is described here
12:15 < rgrant> November reuses our prior ST parameters about the least disruptive time to soft fork.  Working backwards from there makes sense, as it did last time.
12:16 <@jeremyrubin> the period of US Thanksgiving - Chinese new year is sort of a "no man's land" for activations, where it'd not be good to have signalling or activation during that time
12:16 <@jeremyrubin> this is kind of like a launch window
12:16 <@jeremyrubin> which forces us to be spring/early summer for signalling, and fall for activation
12:16 -!- Guest281 [~Guest28@151.34.153.116] has quit [Client Quit]
12:17 <@jeremyrubin> it might be silly overall, but to me it makes sense that pragmatically it's harder to coordinate anything if we overlap the globally relevant winter festivals
12:17 <@jeremyrubin> anyone else have anything to chime in?
12:17 < GuerillaV2> Are you aware of the concerns that activating CTV this year would set a potentially dangerous precedent regarding the rate of changes to the protocol? I'm assuming yes, if so, what is the cost of waiting more time / being overly conservative? Thanks
12:18 < jamesob__> I think the timing is somewhat ambitious and so I would expect ST failure (given that there are not many large economic actors talking about CTV), but that said I will gladly run a node
12:18 <@jeremyrubin> Good question. This is separate from the goal of the preparation of a binary to 'get to the ball', and is more in line with a 'don't swing' concern
12:19 <@jeremyrubin> GuerillaV2 i am aware of the concerns, however I think generally the rate of changes is orthogonal to the latency of changes
12:19 < jamesob__> GuerillaV2: are you aware that prior to segwit we used to do about a soft fork a year?
12:19 -!- Guest8 [~Guest8@097-096-225-125.res.spectrum.com] has joined ##ctv-bip-review
12:19 <@jeremyrubin> E.g., if we only made changes after they'd matured for 10 years conceptually, we may still end up doing a change a year for things that are very mature concepts
12:20 <@jeremyrubin> In this case, CTV is (relatively) older already conceptually than forks like SegWit were at the time of their development AFAIU
12:20 <@jeremyrubin> and wrt spec changes, older than Taproot was AFAICT (changes in august, merge in september/october, activations tart in april) 
12:21 < rgrant> GuerillaV2: i'll argue that if we don't do safe soft forks, we forget how to and can't move forward safely when emergencies happen.
12:21 <@jeremyrubin> whereas CTV is no material changes since 2020 Jan
12:21 <@jeremyrubin> So if anything, CTV might indicate the opposite trend?
12:21 <@jeremyrubin> But if the concern is over the regularity of the use of the mechanism itself, that's a diff conversation.
12:21 < rgrant> GuerillaV2: what we're forgetting is how to form consensus without certain reputations chiming in.
12:21 < jamesob__> rgrant: agreed
12:22 < Guest43> slapping down a proposal that is overall solid without any identifiable problems only because "timing concerns" would also be a dangerous precedent.
12:23 <@jeremyrubin> the other cost i see is that users have real use for CTV, so waiting prevents people from using that sooner
12:23 < GuerillaV2> I'm concerned that trying to "force" CTV now *could* lead to unintended consequences.
12:23 <@jeremyrubin> assume we double the number of users between now and 1.5 years from now
12:23 < rgrant> GuerillaV2: nobody is forced in Bitcoin.  
12:23 < GuerillaV2> CTV is a very niche proposal and I'm not sure the community if fully prepared
12:23 <@jeremyrubin> what's the cost of fewer of them having self custody options?
12:24 < rgrant> GuerillaV2: no prior UTXOs are reassigned, and no old nodes cease to function.
12:24 < GuerillaV2> Then again, I agree that there's only one way to find out
12:24 <@jeremyrubin> GuerillaV2: wrt forcing, we have that in the post... no one is forced, there are ample ways to oppose
12:24 < jamesob__> GuerillaV2: I'm not sure what you mean by "niche," but there are a number of uses (vaults, delayed lightning openings) that have big value for a variety of users
12:24 < GuerillaV2> rgrant you get my point ^^
12:25 < GuerillaV2> Everyone was asking for Taproot, this feels different for CTV
12:25 < rgrant> GuerillaV2: the client side tooling is better than Taproot.
12:26 <@jeremyrubin> GuerillaV2: do you have an index of people who signalled desire, before Taproot was merged/slated for ST, to have taproot?
12:26 -!- jamesob__32 [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has joined ##ctv-bip-review
12:26 <@jeremyrubin> I've been looking for one personally because I do see the 'everyone wanter taproot claim' but i can't find any evidence directly 
12:26 < Guest43> users that are "unprepared" for ctv could only walk into it by their own damn fault. not likely you can do it by accident without some specific tooling.
12:26 <@jeremyrubin> OTOH, utxos.org/signals does exist, which has a good number of folks wanting CTV
12:27 < GuerillaV2> I don't, I don't think someone has an objective index. However, I think CTV would have more chances of getting activated if the community was more prepared and educated for it
12:27 -!- ubba [ubba@gateway/vpn/protonvpn/ubba] has quit [Changing host]
12:27 -!- ubba [ubba@user/ubba] has joined ##ctv-bip-review
12:27 <@jeremyrubin> i agree with that 100%
12:28 <@jeremyrubin> how do we measure what a prepared and educated community means?
12:28 -!- Guest53 [~Guest53@089144217247.atnat0026.highway.a1.net] has joined ##ctv-bip-review
12:28 <@jeremyrubin> E.g., i talk to people about taproot all the time and find most are unable to answer basic trivia about how it works, even amongst seasoned devs.
12:28 < rgrant> GuerillaV2: i think you're feeling the same feeling that other devs are, which is that some big names are missing.  the thing to keep in mind is that those big names have explicitly stated that they're not commenting on changes that they didn't personally work on for a while.
12:28 -!- jamesob__69 [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has joined ##ctv-bip-review
12:28 <@jeremyrubin> is taproot the bar? or are we seeking a new bar?
12:28 < GuerillaV2> By being overly conservative and taking the time to make sure that there's is significant support
12:29 <@jeremyrubin> how did we do that for taproot?
12:29 <@jeremyrubin> personally, as I proceed, i try to meet or exceed precendent \
12:29 -!- jamesob__ [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has quit [Ping timeout: 250 seconds]
12:29 < jamesob__69> Guest43: right, you have to opt into using the OP_CTV opcode. I've checked over the implementation for any "collateral damage" to non-CTV uses and couldn't find any.
12:29 < rgrant> GuerillaV2: this is all restatements of vague concern.  
12:29 <@jeremyrubin> where i struggle is that there isn't really a clear bar to pass
12:29 <@jeremyrubin> I think we should get into the the theses, since this is addressed in memorylessness
12:29 < rgrant> let's move on to the other points.
12:29 < GuerillaV2> Fully agreed, the bar is by definition impossible to define
12:30 <@jeremyrubin> kicking off, we have thesis 1, which is the 'checklist' of things true about CTV
12:30 < GuerillaV2> But there is a good argument for trying to surpass it by a large margin
12:30 < GuerillaV2> And avoid divisions
12:30 < GuerillaV2> (at least potential ones)
12:30 <@jeremyrubin> Does anyone contest any of the points made in that list?
12:31 <@jeremyrubin> Does anyone have other points (+ or -) that they think should be a part of any soft-fork checklist?
12:31 -!- jamesob__32 [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has quit [Ping timeout: 250 seconds]
12:31 < rgrant> looks good, but it's missing something that all other soft forks had, which is buy-in from one of the maintainers who would check it in.
12:32 <@jeremyrubin> rgrant: fair point, i think i address that later on
12:32 <@jeremyrubin> what i'd note is current maintainers are wladimir, sipa, andrew, marco, fanquake
12:33 <@jeremyrubin> of the 5, only waldimir and sipa have really been involved much in any prior soft forking, andrew marco and fanquake are not primarily working on those categories of thing
12:33 <@jeremyrubin> sipa has publicly commented that he's out of any soft fork discussion
12:34 < rgrant> i don't think that's a responsible stance from 20% of the maintainers.  it presumes that Bitcoin is not an organism that will adapt and incorporate the best ideas available.
12:34 <@jeremyrubin> privately (but afaict it's a public information), wladimir has noted to me he's staying out of soft fork discussions, but also couldn't give a concrete critereon on which he used previously to merge Taproot related stuff
12:34 <@jeremyrubin> we can revisit this on thesis 7
12:35 <@jeremyrubin> Are there other comments on the list on thesis 1?
12:35 < rgrant> (make that 40% of maintainers - sounds like the same story.)
12:36 <@jeremyrubin> ( GuerillaV2: i'd say that defacto whatever this notion of unanimity of the community is what wlad was measuring, but we don't exactly know what that means)
12:36 <@jeremyrubin> Ok, onto thesis 2
12:36 <@jeremyrubin> Getting to the ball
12:36 <@jeremyrubin> does the metaphor not make sense to anyone?
12:37 <@jeremyrubin> Restated, producing a usable binary does not compell anyone to use it
12:37 <@jeremyrubin> I think this answers 1/2 of GuerillaV2's criticism around forcing.
12:38 <@jeremyrubin> not putting together the binary/release is more close to the forcing behavior we don't want, because not having it available and 'coordinated (at least on parameters) is the thing that denies the community the option 
12:38 <@jeremyrubin> so having the option leads to more freedom for the community from developers decisions
12:39 <@jeremyrubin> perhaps counterintuitive?
12:39 -!- ubba [ubba@user/ubba] has quit [Quit: Client closed]
12:40 <@jeremyrubin> Ok, moving on unless anyone wants to inject any heat :)
12:40 < rgrant> one thing to address that i don't see in this document is that there are other possible balls on the way, but taking this swing does not preclude swinging at those (other ways to do covenants) as well.
12:40 <@jeremyrubin> 3) Whose job is <whatever this is> anyways?
12:40 < jamesob__69> i.e. all releasing a binary does is reduce switching cost of showing support for CTV, eh?
12:41 -!- Guest53 [~Guest53@089144217247.atnat0026.highway.a1.net] has quit [Ping timeout: 250 seconds]
12:41 <@jeremyrubin> jamesob__69 in theory, yes. also forming some consensus around that this is the thing that matches the spec, since core uses a de-facto spec (code is correct, BIPs inaccurate)
12:42 <@jeremyrubin> that's sort of part of point 3, which is that we're lining up the shot to be the smoothest one possible
12:42 <@jeremyrubin> it's sort of devs serving as facilitators rather than deciders
12:42 <@jeremyrubin> it's obviously worse if we have like chaos all the time
12:42 < rgrant> jamesob__69: i think it might require supporters to get good at understanding deterministic builds (GUIX), which they wouldn't have needed to do except for the UASF.
12:42 <@jeremyrubin> e.g., everyone releasing incompatible flag day clients overlapping at the same time
12:43 <@jeremyrubin> i think that maintainers have previously noted willingness to run a build process for something they disagree with
12:43 <@jeremyrubin> e.g. IIRC wladimir signed the UASF builds altho disagreed with them
12:43 <@jeremyrubin> but i could be misrememebering
12:43 < rgrant> jamesob__69: ...if they put more trust in the signatures from maintainers than from non-maintainers.
12:44 <@jeremyrubin> let's get into the NACKs a little bit
12:44 <@jeremyrubin> there are 3 nacks, 2 of which i consider to have a substantial comment
12:44 -!- Guest6561 [~Guest65@91.221.66.20] has joined ##ctv-bip-review
12:44 < rgrant> jeremyrubin: i had forgotten about wladimir's sig on UASF.
12:45 <@jeremyrubin> between the three of them, there is a thread of concerns similar to GuerillaV2's that things might be rushed & pacing of forks
12:45 <@jeremyrubin> there is also a thread on quality / relevance / importance of CTV
12:46 <@jeremyrubin> most of these sorts of things are, from my PoV, product management decisions v.s. a technical reason not to do CTV
12:46 <@jeremyrubin> E.g., in a year, 2 years, 10, their nack might be 'automatically vacated' because now we've waited 'enough' time
12:47 <@jeremyrubin> whereas 'this is insecure' would not be vacated similarly
12:48 <@jeremyrubin> moving on to the other-things to work on topic that rgrant brought up... thesis 4
12:48 <@jeremyrubin> as rgrant said "one thing to address that i don't see in this document is that there are other possible balls on the way, but taking this swing does not preclude swinging at those (other ways to do covenants) as well."
12:48 <@jeremyrubin> however, the inverse (or converse... can never remember my logic terms) is true
12:49 <@jeremyrubin> not taking this shot means that we continue down a path where we devote resources to CTV and the discussion around it without learning the acceptability of it to the community 
12:49 <@jeremyrubin> which might take resources away from investing in other efforts
12:49 <@jeremyrubin> so, in theory, getting to the ball and failing at the swing lets us better allocate in the future
12:50 <@jeremyrubin> does anyone have any thoughts on that dynamic?
12:50 < rgrant> i think silence is hard to parse.
12:51 <@jeremyrubin> i agree 
12:51 < rgrant> by doing something hopefully we can get some feedback from miners
12:51 < rgrant> however, i think devs are capable of thinking through these issues and just want to keep waiting.  i've noticed that the discussion has improved a lot during the CTV process.
12:52 < rgrant> in general, i expect better feedback by taking action.
12:52 <@jeremyrubin> well to be transparent i talked to a pretty large share of hashrate in miami and i think theres pretty substanital support for CTV in that community
12:52 <@jeremyrubin> it may be the case theres insufficient time for them to take action on it 
12:52 <@jeremyrubin> but i see -- from my PoV -- more bottleneck in developer community
12:53 < Guest43> people may not be motivated to be diligent in assessing long shots. but when it looks like something might actually happen priorities shift.
12:53 < rgrant> Guest43: +1
12:53 <@jeremyrubin> good observation.
12:54 <@jeremyrubin> one of the requests i had from someone who represents xx hashrate was (and dont try to guess who) that i needed to give them a binary and code sample to test
12:55 <@jeremyrubin> that if it's not at the point where they can run something and test it, it's not something they'll spend time thinking about
12:55 <@jeremyrubin> so process wise i found that informative and it biased me toward doing binary release since that process cant be engaged otherwise
12:56 -!- laroberts [~laroberts@cpe-76-185-111-141.tx.res.rr.com] has quit [Quit: Client closed]
12:57 <@jeremyrubin> (note: since they're a miner, this includes signalling logic)
12:57 < rgrant> sounds like there's no downside.
12:57 <@jeremyrubin> shall we get to point 5? (Consensus being memoryless)
12:57 <@jeremyrubin> this is something that has already happened with CTV 
12:57 <@jeremyrubin> <well known dev> said if i had pushed harder 2 years ago, the bar was lower for review, and now it's higher
12:57 <@jeremyrubin> on the whole, i think this is a good thing!
12:57 <@jeremyrubin> we should have a high standard
12:57 -!- Guest6561 [~Guest65@91.221.66.20] has quit [Quit: Client closed]
12:58 < rgrant> forward progress definitely is memoryless if not resulting in activation, but i'm not sure if we'd hold the symmetric opinion and forget a failed ST phase.
12:59 <@jeremyrubin> i think that's fair
12:59 <@jeremyrubin> people will read <preferred narrative> out of a failed activation
12:59 < jamesob__69> rgrant: yep, good point
12:59 <@jeremyrubin> so it's important to be clear that failure can be for multiple reasons
12:59 <@jeremyrubin> is there a way we can increase learning from a failed activation?
13:00 < rgrant> it's not clearly bad, but we haven't been that "distributed" before.
13:00 <@jeremyrubin> e.g., asking non-signalling miners "why", or drawing out more concrete nacks from devs?
13:00 <@jeremyrubin> personally i view a failure positively
13:01 <@jeremyrubin> since we would learn something, but if it's failure with no reason, that's a bit harder to work with
13:02 <@jeremyrubin> i guess another good question is what if we get 89% signalling 
13:02 <@jeremyrubin> what does that failure mode mean?
13:03 < rgrant> 89% is obvious: we need more time for education and for miners to finish their testing, so try again.
13:04 -!- Guest9720 [~Guest97@2605:a601:a71c:9400:f914:e6ce:b6d1:b643] has joined ##ctv-bip-review
13:04 < Guest43> failing ST would not please UASF fans because they want to disabuse any perception of miners having a decision in enforced rules, failing on dev support or maintainers will not please people who are worried about capture by hidden power structures in development.
13:04 < GuerillaV2> What if the failure is at the cost of splitting the community into two camps that would otherwise pretty much agree on most things. What is the cost of this? I think that this should be discussed even is this is just low probability. The failure might not be the one you think (ie not activating CTV) but rather damaging the governance process for
13:04 < GuerillaV2> years (again, not saying it will happen, but I want to make sure everyone here has thought of this)
13:04 <@jeremyrubin> so i think we've drifted a bit
13:05 <@jeremyrubin> let's revisit this in section 6
13:05 <@jeremyrubin> that's the fight against it section
13:05 <@jeremyrubin> for now, are there any other comments about memorylessness?
13:05 <@jeremyrubin> Or does that framework seem reasonable?
13:06 < GuerillaV2> Nothing wrong with 5
13:06 <@jeremyrubin> personally i think it's basically a constant struggle to get something to have the 'over the line' ness property. right now feels as close as it's ever been to awareness/acceptance, but in 1.5 years from now I (intuition based) don't think i'd be relatively closer without a shitload more work that I'm not sure i can pull off
13:07 < rgrant> GuerillaV2: if process was harmed in the experiment, that would be a bad thing.  however, if there is a damaged process already (as i'd claim a too-conservative process can be), then exposing that can help make positive change.
13:07 <@jeremyrubin> (my improvements feel linear over time, bar seems expionential)
13:07 <@jeremyrubin> ok, so 6. 
13:08 <@jeremyrubin> Guest43 and GuerillaV2 have queued up some good questions
13:08 <@jeremyrubin> let's just overview what people can do
13:08 < GuerillaV2> rgrant I would tend to agree with your conclusion if I believe that there is such a thing as "too-conservative". This is a hard one to figure out honestly
13:08 < rgrant> i'd ask if we have a definite failure - in which maintainers are not evaluating the code and the blocks don't show much support, what's planB?  
13:08 <@jeremyrubin> releasing a binary is not a forcing thing, and even if it were, everyone running the binary has choice.
13:09 <@jeremyrubin> You can signal or not, and you can also upgrade to UASF to activate, and you can invalidate an activating block to reject the activating chain
13:09 <@jeremyrubin> Does anyone take issue with those described roles and responses in light of people running a CTV client, in terms of accuracy?
13:10 <@jeremyrubin> Guest43 asks: failing ST would not please UASF fans because they want to disabuse any perception of miners having a decision in enforced rules, failing on dev support or maintainers will not please people who are worried about capture by hidden power structures in development.
13:11 <@jeremyrubin> personally, i think a failure would be positive for the UASF people since if they want CTV, which some of them have expresses to me either neutrality or pro, then it'd be a chance to do a UASF with the procedural blessing from the non-UASF-first camp
13:11 <@jeremyrubin> however, a lot of the UASF camp thinks of this as a game of chicken
13:11 <@jeremyrubin> and the ST shows that you are weak from the outset of the game and will veer
13:12 <@jeremyrubin> But IMO this seems more social than technical? it's not clear that the code has to have a commitment to it, v.s. me saying "my node flag days CTV on at block XXXXX here's the binary since we failed the ST"
13:13 < Guest43> no. i was merely commenting on that not everyone would see a failure positively.
13:13 <@jeremyrubin> fair -- I agree 
13:14 <@jeremyrubin> GuerillaV2 asks: What if the failure is at the cost of splitting the community into two camps that would otherwise pretty much agree on most things. What is the cost of this? I think that this should be discussed even is this is just low probability. The failure might not be the one you think (ie not activating CTV) but rather damaging the
13:14 <@jeremyrubin> governance process for
13:14 <@jeremyrubin> 13:04 <GuerillaV2> years (again, not saying it will happen, but I want to make sure everyone here has thought of this)
13:14 <@jeremyrubin> can you explain further on what you think this might look like? to me it sounds like an event which just reveals an existential preference earlier than it might come up otherwise
13:15 <@jeremyrubin> in either case all parties just have more information, but are discretionary on their future actions in light of it
13:15 < rgrant> i think if we get to UASF, it won't be with the support of current maintainers.  that's totally uphill.
13:15 <@jeremyrubin> or do you see people becoming entrenched?
13:16 < Guest43> i don1t think there is any issue the community is in 100% agreement i seen no signs of this. one may be surprised how many hates segwit for example for various reasons.
13:17 <@jeremyrubin> so traditionally i've thought of this as being a dichotomy between compromisers and absolutists, similar to intolerent minority stuff
13:17 < GuerillaV2> Going as far as UASF for CTV has been one of my worries since the beginning so I'm curious to hear people on this. I just do not believe in going to war over this, and I'm not sure of what it would look like
13:17 -!- josedrobles [~jdrobpar@9.red-88-20-23.staticip.rima-tde.net] has joined ##ctv-bip-review
13:17 <@jeremyrubin> e.g. the compromisers are OK with segwit being blockspace increase, OK with taproot  instead of mast/schnorr even though no CISA, OK with CTV even though not general
13:18 < Guest43> +1
13:18 < GuerillaV2> And I know this is just "what if" but this is important imo
13:18 <@jeremyrubin> and then the absolutists are convinced that e.g. segwit is perfect, taproot is perfect, and CTV is bad because it's not the best possible
13:18 <@jeremyrubin> so this is the first case where the compromisers diverge from the absolutists because CTV seems to be a good compromise
13:19 <@jeremyrubin> the unifying factor between the camp is "things that are clearly good for bitcoin, in the high level"
13:19 <@jeremyrubin> so big blockers were compromisers or absolutists who were willing to harm bitcoin in the process
13:19 < rgrant> GuerillaV2: if we focus on sides entrenching, then everyone is sure to lose.  perhaps that explains some of the maintainer reluctance - although it's their job as good maintainers to judge the technical consensus regarding competent proposals.  anyway, if we focus on improving process, then there's a win-win.
13:19 <@jeremyrubin> GuerillaV2: +1 on being importnat
13:20 <@jeremyrubin> i guess one question is does releasing a binary / ST make this better or worse?
13:20 < GuerillaV2> rgrant can't argue with that although not sure the process would be "improved" as a result
13:20 <@jeremyrubin> E.g., what does the CTV fork look like in +1 year (remember launch windows) when people are perhaps more disaffected with lack of progress or something else?
13:21 <@jeremyrubin> Or if we see a much increased need for vaults, congestion control, etc
13:21 <@jeremyrubin> remember: ctv is the only real 'bird in hand' proposal, the rest are still bluesky
13:21 <@jeremyrubin> so the most likely thing is no new tech is ready to go 1 year from now
13:21 < GuerillaV2> I've never argued against the tech side of CTV personally
13:22 < GuerillaV2> I would say exactly the same thing for any other proposal at this moment
13:22 <@jeremyrubin> hah i'd be right there with ya!
13:22 -!- jamesob__ [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has joined ##ctv-bip-review
13:22 <@jeremyrubin> no other proposal has had a PR opened, implementations, etc
13:23 <@jeremyrubin> nor any tooling, demo apps, etc
13:23 <@jeremyrubin> so anything else is certainly super premature
13:23 < jamesob__> there is no other serious proposal for covenants atm
13:23 < rgrant> GuerillaV2: i think at minimum we'd end up with more clear reviewing standards, more organizational stability for getting developer attention, some way to determine which proposals might conflict and require holding others back, and whether Bitcoin is actually headed for stasis.
13:23 < roconnor> APO has https://github.com/ajtowns/bitcoin/commits/202101-anyprevout
13:23 <@jeremyrubin> (reminder to read https://rubin.io/bitcoin/2021/12/24/advent-27/ which covers the maturity and viability of other things )
13:24 <@jeremyrubin> roconnor: aj needs to open it as a PR for review
13:24 < jamesob__> roconnor: can APO do e.g. vaulting?
13:24 <@jeremyrubin> yes you can do some similar stuff
13:25 <@jeremyrubin> you use the trick of <apo sig> <1||pk> checksig and it is ~close to CTV
13:25 -!- Guest43 [~Guest43@fibhost-66-168-253.fibernet.hu] has quit [Quit: Client closed]
13:25 < roconnor> sorry by "no other proposal" you are talking about "alterantives to CTV" or just bitcoin soft-fork proposals in general.
13:25 -!- Guest43 [~Guest43@fibhost-66-168-253.fibernet.hu] has joined ##ctv-bip-review
13:25 < jamesob__> roconnor: I was thinking "alternatives ..."
13:26 <@jeremyrubin> roconnor: ah GuerillaV2 said "I would say exactly the same thing for any other proposal at this moment"
13:26 <@jeremyrubin> and i said i'd say the same thing for any other proposal too!
13:26 -!- jamesob__69 [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has quit [Ping timeout: 250 seconds]
13:27 <@jeremyrubin> i think where APO is _ahead_ of ctv is this sort of ambiguous 'everyone wants it' claim... but even then, APO as an upgrade for LN has some dissent, so I think that's why it's stalled
13:27 < roconnor> okay.  To be clear I'm not proposing that APO is an alternative to CTV, even if it could be one in some technical sense.  I'm just saying that other bitcoin soft-fork proposal implementations do exist.
13:27 <@jeremyrubin> but i can't put my finger on what that is beyond better marketing 
13:27 <@jeremyrubin> Ah that reminds me, another checklist item is that there's been 7 IRC meetings over like 16 weeks :)
13:28 < GuerillaV2> So anyways, I personally think that waiting more time would actually harden the case for CTV, leading to real demand for its functionality and by default rendering the argument of "too close to taproot" invalid (thus avoiding a potential ""war"", hate this word)
13:28 < schmidty> Seems a valid argument to say partial features could crowd out "better" future alternative ones
13:28 < GuerillaV2> I do appreciate your patience with this as I think this is just a question of timing rather than your merit as a dev
13:28 < rgrant> schmidty: how so?  if you're a wallet developer, work on the ones you like.
13:29 <@jeremyrubin> roconnor: heard -- if you can encourage aj to open a PR i think it would help APO have a real shot
13:29 < jamesob__> schmidty: I dunno, that's like saying merging P2SH was "crowding out" taproot
13:29 <@jeremyrubin> my guess is that we should see a PR open for 6 mo - 1 year for testing, review, feedback, etc before merge, and then at least 6-9 months for SF coordination, so APO seems unlikely w/in a 2 year time horizon
13:30 < schmidty> rgrant: "oh we have CTV/covenants already, why do <future proposal> if it only adds a bit more?"
13:30 <@jeremyrubin> whereas i've presented a path for CTV by nov
13:30 < jamesob__> there was certainly a lot of practicality in merging P2SH in the intervening period while something like taproot was being thought about
13:30 <@jeremyrubin> so that's more what i'm saying about anything we can do now v.s. in like 2 years
13:30 < Guest43> lot of people will not start to seriously look at what they can do with an op_code that may never get activated. time is definitely working against the chances of activation. will raise the bar for difficulty to change the protocol especially if billionaires start campaigning.
13:30 <@jeremyrubin> schmidty: is this similar to what andytoshi said at TabConf?
13:31 < schmidty> jeremyrubin: I dont recall his talk on it
13:31 < jamesob__> jeremyrubin: I think that's the main objection to CTV at this point; the idea that it's somehow siphoning off momentum for a future covenants fork
13:31 <@jeremyrubin> https://btctranscripts.com/tabconf/2021/2021-11-05-jeremy-rubin-andrew-poelstra-covenants/
13:31 <@jeremyrubin> andytoshi: "It was a slightly related point that if we find in the future that there is a cool application for more general covenants, because we have like 90 percent of the functionality already in CTV it would be a harder sell to then come back and do it again for an extension. "
13:32 < Guest43> we have not seen organized media campaigns attempted to change bitcoin before this pos madness...
13:32 <@jeremyrubin> uhhh
13:32 <@jeremyrubin> Guest43: do you remember the blocksize wars LOL
13:32 <@jeremyrubin> Guest43: do you remember the blocksize wars LOL
13:32 < rgrant> schmidty: well, if the use cases are strong and the code is safe, then that "don't do anything" attitude can be exposed as fueling altcoins.
13:32 < schmidty> jeremyrubin: that’s in the ballpark of my thought, yes
13:33 <@jeremyrubin> schmidty: i think the more likely case is that we spend 10 years coming up with the ultimate thing no matter what happens in between
13:34 < rgrant> jamesob__: "we need CTV because it helps us learn how to do useful covenant forks"
13:34 <@jeremyrubin> CTV might crowd out a 91% or a 95%, but not a 99% 
13:34 < schmidty> jeremyrubin: could be
13:34 <@jeremyrubin> but I think the 99% looks like a Zero Knowledge Simplicity or something (cc roconnor ;) ) 
13:35 <@jeremyrubin> which i think is still on unknown time horizon for liquid (although I think andy said it would be about ready for release in 1 year from now)
13:35 <@jeremyrubin> ^ simplicity itself, not some ZKP version
13:36 < rgrant> i don't own any Liquid and i feel completely let down by the "sidechains" hype.
13:36 <@jeremyrubin> Ok, I'd like to spend a little time on the last thesis
13:36 <@jeremyrubin> (recap: we just spent time on "will we split the community and is that bad")
13:37 <@jeremyrubin> The last point is if this is the right precedent for how soft forks should proceed in general?
13:37 <@jeremyrubin> E.g., individual or group of individuals releases a friendly (ST?) client that can activate their rule, with reasonable effort to coordinate the community 
13:38 <@jeremyrubin> or do we stick with the model of bitcoin core releasing soft forks?
13:38 <@jeremyrubin> if so, does core currently have the "competency" and "will" to make such releases?
13:38 < jamesob__> I think relying on a single or small group of individuals to propose all changes to the protocol is an anti-pattern that we need to break out of
13:38 < Guest43> +1
13:39 < jamesob__> s/protocol/consensus
13:39 < rgrant> jamesob__: +1
13:39 <@jeremyrubin> how should it be, then?
13:40 < rgrant> i think we're moving away from the wrong model and towards the right one, but that maintainers of Bitcoin Core are not communicating their change in leadership and that it's confusing devs who generally just wait for nig-name ACKs.
13:40 < rgrant> * big name
13:41 <@jeremyrubin> yeah
13:41 < jamesob__> Right - people who don't follow bitcoin development closely (i.e. everyone who isn't doing bitcoin development) can definitely be forgiven for using the heuristic of "sipa has to bless this change for me to follow it" but I think that's antithetical to bitcoin
13:41 <@jeremyrubin> i mean ideally i'd love to see a more fomal standards body type of thing, but that's super hard to do without capture
13:41 < jamesob__> yeah I don't think you can formalize it
13:42 < jamesob__> formalization leads to gaming
13:42 < rgrant> ...and voting and other horrible things.
13:42 < jamesob__> right
13:42 <@jeremyrubin> i realize i completely misread jamesob__ original comment
13:43 -!- Guest9720 [~Guest97@2605:a601:a71c:9400:f914:e6ce:b6d1:b643] has quit [Quit: Client closed]
13:43 <@jeremyrubin> I think relying on a **single or small group of individuals** to propose **all** changes to the protocol is an anti-pattern that we need to break out of
13:43 < rgrant> i think we're missing something.  Bitcoin Core is still "the spec".  that's part of our roadblock.
13:43 < Guest43> one could even argue the 'market' dominance of core is an attack on bitcoin. could be multiple implementations with different maintainers need more weight. i'm fully aware how hard that makes things.
13:43 <@jeremyrubin> but relying on **multiple** small groups that form one-off around specific upgrades is maybe good?
13:43 <@jeremyrubin> jamesob__ am i reading you right, now?
13:43 <@jeremyrubin> sort of a working group model?
13:43 < jamesob__> yes
13:44 < rgrant> Guest43: great minds type at the same time.
13:44 <@jeremyrubin> i mean in theory, if i release the ST with CTV, i have my "own implementation"
13:45 <@jeremyrubin> but it's entirely designed to be downstream of core and get upstreamed, preferably 
13:45 < jamesob__> right - thought "your own implementation" is of course a spectrum; I have "my own implementation" by running an assumeutxo branch as my public-facing node
13:45 <@jeremyrubin> one question is if, e.g., 5 people out of this meeting are going to run my ST client, does that mean core should accept the patch/PR (after finalizing a higher bar of review?) 
13:46 <@jeremyrubin> what's the point where core can upstream something from a small working group?
13:46 < rgrant> i think the thing to replace big-names that might work would be an open committee process with a deadline (shaped around these November windows) for evaluating possible changes.  right now the scripting work has been going on for a very long time.  there is no end to the "one more idea" phase.
13:46 <@jeremyrubin> without core being the decider or defacto pocket veto
13:47 <@jeremyrubin> rgrant: noting the conflict with GuerillaV2's preference to avoid regularity, which i don't agree with
13:47 <@jeremyrubin> so, i think in this session, we're going to end with more questions than answers, which is good. maybe we should schedule a follow up meeting on tighter 1 week basis for meetin g #8?
13:48 -!- GuerillaV2 [~Guest73@aputeaux-681-1-94-2.w90-86.abo.wanadoo.fr] has quit [Ping timeout: 250 seconds]
13:48 <@jeremyrubin> what i'd like to cap off with, is less of a request for an endorsement, but a soliciation for NACKs that i should abandon the course described in my blogpost
13:48 <@jeremyrubin> even if you agree, please steelman the case to not do it, if you can
13:49 <@jeremyrubin> schmidty had the case around not wanting to exlcude maginally better features
13:50 < jamesob__> I think the only thing to be cautious of here is an overly ambitious timeline... I worry about what a ST failure would do for the narrative against CTV
13:50 <@jeremyrubin> guerillav2 had the case for not splitting the community over this
13:51 < jamesob__> but the other side of that is that you've been working really hard to educate about CTV for a long long time and to expect you to keep doing that is kind of crazy
13:51 < Guest43> if you avoid disagreements you ensure the smallest possible engagement and review effort possible.
13:51 < jamesob__> I'm planning on writing a blog post soon articulating my support, but ultimately I feel like more people need to show support for the ST to succeed
13:52 < jamesob__> perhaps the process of releasing the binary will raise awareness and cause more people to evaluate
13:52 <@jeremyrubin> jamesob__: personally i'm doubling down on sapio (with or without CTV, very useful) and i don't expect to keep it up either. what i might do is, given memorylessness, go for a much more ambitious path and try to close it on a longer timeline with something that's a 99% since i don't see myself being able to eclipse the memorylessness hurdle in 1.5
13:52 <@jeremyrubin> years with more probability than today
13:53 <@jeremyrubin> so if there are other ways to chip away at memorylessness, or a way a ST could be done e.g. with fall signalling, i'd be keen.
13:53 < jamesob__> I agree with that last point, which is sad. I think the whole discussion has shown an unfortunate amount of "ad hominem" in the bitcoin process, since this is a very strong proposal from a fundamental/technical point of view
13:53 < rgrant> the steelman is that with the silent change of guard, and lacking a new general understanding, we will veer towards a UASF.  education and a multi-client specification could counter this.
13:54 < rgrant> i have heard for years that it's too hard to judge which client is wrong if one out of several has a bug, but i believe the actual hard thing is getting past the first monopoly client.
13:55 <@jeremyrubin> one possibility wrt alternative launch window is august/septemeber/october then skip november december january february march april, and do a mid-may active time
13:55 <@jeremyrubin> (march april --> tax szn for the americans, which for the majority of american miners means i'ts no bueno too)
13:56 <@jeremyrubin> rgrant: 0 to 1, 1 to n, but in this case the 1 is the 'first real alt client'
13:56 <@jeremyrubin> anyone else have any closing comments
13:56 <@jeremyrubin> i thank everyone for their time and thought provocations 
13:57 < jamesob__> jeremyrubin: thanks for all your work, and I hope we have CTV or something like it soon. lot of coins could be a lot safer.
13:57 < rgrant> jamesob__: +1
13:57 < rgrant> jeremyrubin: thanks!
13:59 < puefix> +1, thank you Jeremy
13:59 < rgrant> another steelman is that the process we're describing sounds like the segwit2X "fire the devs", and would both instigate all kinds of bad memories as well as draw suspicious characters.  
14:00 <@jeremyrubin> closing soliciation from me
14:00 <@jeremyrubin> please review https://github.com/bitcoin/bitcoin/pull/21702
14:00 <@jeremyrubin> above all else, gotta make sure the code is correct
14:00 <@jeremyrubin> #endmeeting
14:02 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...]
14:02 -!- Guest43 [~Guest43@fibhost-66-168-253.fibernet.hu] has quit [Quit: Client closed]
14:03 -!- josedrobles [~jdrobpar@9.red-88-20-23.staticip.rima-tde.net] has quit [Quit: Konversation terminated!]
14:04 -!- jamesob__ [~jamesob__@cpe-65-189-27-252.cinci.res.rr.com] has quit [Quit: Client closed]
14:04 -!- gkaloudis [~kaloudis@cpe-98-26-57-16.nc.res.rr.com] has quit [Quit: Client closed]
14:11 -!- Guest8 [~Guest8@097-096-225-125.res.spectrum.com] has quit [Quit: Client closed]
14:35 -!- Guest26 [~Guest26@80.5.33.116] has joined ##ctv-bip-review
14:36 -!- Guest26 [~Guest26@80.5.33.116] has quit [Client Quit]
14:47 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
14:51 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##ctv-bip-review
14:51 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
15:11 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has joined ##ctv-bip-review
15:14 -!- puefix [~puefix@192-222-138-29.qc.cable.ebox.net] has quit [Remote host closed the connection]
17:21 -!- geyaeb2 [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Quit: WeeChat 3.5]
17:21 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined ##ctv-bip-review
17:52 -!- Guest3746 [~Guest37@2607:fb91:14aa:5dbc:ac39:6af7:6974:b91] has joined ##ctv-bip-review
18:00 -!- Guest3746 [~Guest37@2607:fb91:14aa:5dbc:ac39:6af7:6974:b91] has quit [Quit: Ping timeout (120 seconds)]
18:37 -!- b10c [~quassel@user/b10c] has quit [Remote host closed the connection]
18:37 -!- waxwing [~waxwing@193.29.57.116] has quit [Remote host closed the connection]
18:38 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has joined ##ctv-bip-review
18:38 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has quit [Changing host]
18:38 -!- b10c [~quassel@user/b10c] has joined ##ctv-bip-review
18:40 -!- waxwing [~waxwing@193.29.57.116] has joined ##ctv-bip-review
18:42 -!- _aj_ [aj@user/aj/x-5857768] has quit [Ping timeout: 272 seconds]
18:42 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##ctv-bip-review
18:42 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 272 seconds]
18:43 -!- _aj_ [aj@azure.erisian.com.au] has joined ##ctv-bip-review
18:43 -!- _aj_ [aj@azure.erisian.com.au] has quit [Changing host]
18:43 -!- _aj_ [aj@user/aj/x-5857768] has joined ##ctv-bip-review
--- Log closed Wed Apr 20 00:00:00 2022