--- Log opened Tue Jan 25 00:00:40 2022
02:10 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has quit [Remote host closed the connection]
02:10 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has joined ##ctv-bip-review
02:15 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has quit [Remote host closed the connection]
02:24 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has joined ##ctv-bip-review
02:37 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has quit [Remote host closed the connection]
02:38 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has joined ##ctv-bip-review
02:38 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has quit [Remote host closed the connection]
02:39 -!- bob_x1 [~bob_x@gateway/tor-sasl/bobx1/x-26457072] has joined ##ctv-bip-review
02:47 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
11:06 <@jeremyrubin> Meeting in ~55 minutes, reminder :)
11:42 -!- josedrobles [~josedrobl@24.red-83-34-107.dynamicip.rima-tde.net] has joined ##ctv-bip-review
11:45 -!- josedrobles [~josedrobl@24.red-83-34-107.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]
11:47 -!- iamzensored [~iamzensor@user/iamzensored] has joined ##ctv-bip-review
11:51 -!- lightlike [sid521075@user/lightlike] has joined ##ctv-bip-review
11:52 -!- prayank [~Prayank@45.64.9.48] has joined ##ctv-bip-review
11:57 -!- lightlike [sid521075@user/lightlike] has left ##ctv-bip-review []
12:00 <@jeremyrubin> #startmeeting
12:00 <@jeremyrubin> hi everyone!
12:00 <@jeremyrubin> Reminder, these meetings are moderated to keep things respectful and on topic :)
12:00 <@jeremyrubin> #topic Update on Bounty Program & Feedback (10 Min)
12:00 <@jeremyrubin> We have a draft doc for how the bounty program will be operated https://docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoEdTegt88w6gJzCkcA_a4IXpKAo/edit
12:01 < _0x0ff> hey
12:01 < prayank> hi
12:01 <@jeremyrubin> it's designed to make the bounty system general for other BIPs and stuff too in the future, as well as be tax deductible 
12:01 <@jeremyrubin> tried to incorporate feedabck from previous week's stuff 
12:02 < prayank> tax?
12:02 <@jeremyrubin> feel free to log in / suggest edits or changes!
12:02 <@jeremyrubin> prayank: yeah, it helps some donors to get a tax benefit :)
12:02 < prayank> ok
12:03 <@jeremyrubin> prayank: e.g. if I bought BTC at $15k and gave to bounty 1 btc at $50k, I'd "owe" an additional ~ 20% on 50-15k
12:03 < _0x0ff> it's great how it's getting extended, hopefully this will be successful with other bips
12:03 -!- bucko [~bucko@136.49.111.169] has joined ##ctv-bip-review
12:03 <@jeremyrubin> but if 501c3, then for americans/others you can deduct the full 50k from your taxes and not owe any gain
12:03 <@jeremyrubin> so it's really helpful / people can afford to give more 
12:04 <@jeremyrubin> american centric, but I think 501c3s are recognized in most countries whereas america doesn't recognize any other countries non profits
12:04 < prayank> jeremyrubin: Can unit of account in bounty be BTC instead of USD?
12:04 -!- josedrobles [~josedrobl@24.red-83-34-107.dynamicip.rima-tde.net] has joined ##ctv-bip-review
12:04 <@jeremyrubin> prayank: it is mostly in BTC, yes
12:04 < prayank> The example you shared is USD
12:05 <@jeremyrubin> ah, no they are giving 1 BTC but they have a cost basis in <local currency>
12:05 -!- NotASithLord [~NotASithL@170.250.22.245] has joined ##ctv-bip-review
12:05 <@jeremyrubin> I can't control for people wanting or not wanting to follow local regulations wrt tax
12:06 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review
12:06 < rgrant> hi
12:06 < prayank> Okay anyway I dont have strong opinions on this but I would love if no tax and such things were involved and I think it is possible for bug bounty of an open source project. Maybe not everyone would be able to contribute in that case.
12:06 < josedrobles> Hi
12:07 <@jeremyrubin> prayank unfortunately thats not how the world works ;)
12:07 <@jeremyrubin> mildly off topic for here, people have to pay taxes esp if they're e.g. corporate donors
12:07 <@jeremyrubin> working with a 501c3 makes a lot of this simpler because it makes things tax-exempt
12:07 < prayank>  jeremyrubin: it works for some projects :)
12:08 <@jeremyrubin> personal choice -- minimizing legal risk for devs seems like a Good Thing
12:08 <@jeremyrubin> mod: 2 mins remain
12:08 <@jeremyrubin> any other questions about the bounty?
12:08 <@jeremyrubin> feel free to just leave comments in the doc after the meeting too
12:08 < NotASithLord> ^^^
12:09 < _0x0ff> prayank: for people that want to donate anonymously i dont think it matters ... it's likely different for people who claim the bounty as they'd probably need to be identified before paying out
12:10 <@jeremyrubin> #topic  Feedback Recap (20 Min)
12:10 <@jeremyrubin> so we have had some good feedback since last meeting. here I'd like to highlight 3 substantive feedabcks
12:10 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
12:10 <@jeremyrubin> #subtopic Luke Dashjr's feedback
12:11 <@jeremyrubin> reminder, agenda is here with summary of feedback https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019807.html
12:11 <@jeremyrubin> does anyone have any thoughts about Luke's feedback?
12:11 < prayank>  jeremyrubin: awesome feedback
12:12 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
12:12 <@jeremyrubin> I guess a particular question is should activation mechanism / bip discussion be completely separate?
12:12 < prayank> I dont think we can discuss all the details but lot of points he said I agree with
12:12 < iamzensored> It's good, but the suggestion is that CTV needs BIPs for potential CTV applications first? Has any other improvement required this?
12:13 < rgrant> are we agreeing to defer activation logic?  (oh i type slowly)  i'd prefer to defer that question.
12:13 < iamzensored> Yes, activation and BIP discussion are completely separate topics (except for BIP 8/9 lol)
12:13 <@jeremyrubin> my personal feeling is it's not a bad idea to have more concrete applications, but i think something like e.g. llfourn's post is sort of a 'sufficiently descriptive' application
12:13 < bucko> I do think it's an interesting, though off-topic point. Might be cool to have something like blips is doing for lightning, where proposals for applications are somewhat formalized. 
12:13 <@jeremyrubin> It's not clear that there would be benefit to making a BIP for DLCs on CTV when DLCs does not have a BIP now either
12:14 < iamzensored> Link to llfourn's post?
12:14 < _0x0ff> re activation: i think it's best to have activation discussion separated... let's get a consensus on BIP first and discuss activation later
12:14 <@jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
12:14 < bucko> Maybe there should be something like a BIP for something like DLCs though. Especially when there are going to be multiple projects working on it.
12:14 < iamzensored> Ahh the DLC one
12:14 < bucko> It also might help gather and encourage more formal research. 
12:14 < rgrant> i think asking for applications kind of misunderstands the potential.  but i respect that people learn from concrete examples.
12:15 < prayank> Not BIP but we can have better documentation, code, flowcharts for usecases
12:15 < iamzensored> In the case of DLC's we have the benefit of live applications today that would simply get more efficient and flexible with CTV
12:15 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
12:16 <@jeremyrubin> maybe it's a nice-to-have but non-blocking issue?
12:16 < bucko> Yeah, I was just going to type that
12:16 <@jeremyrubin> like it's 100% in scope to work on these things and people should
12:16 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
12:16 < NotASithLord> I agree it's a really nice to have, but non-blocking. Also agree activation discussion should be kicked down the road.
12:16 <@jeremyrubin> but it's not something that if there isn't a fully working gui app it's premature
12:16 <@jeremyrubin> mod: 1 min till next feedback
12:17 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
12:17 < bucko> Especially since it's potentially boundless. No limiting principle to what would be enough. Though I think having a more formal process could help. And I think on an individual level it's not unreasonable for someone to personally feel like usecases need to be more specced out before they want to ACK
12:17 <@jeremyrubin> i think this meeting will help too since we're going to talk more abt use cases :)
12:17 < rgrant> as far as working out details like an application would, Sapio is a good complete concrete thing.
12:17 <@jeremyrubin> i agree that the BIP use cases are a bit lite on detail
12:17 < bucko> Definitely don't think a GUI app should be blocking. More formalized spec, maybe some PoCs, etc. does help solidify ideas in people's heads
12:18 <@jeremyrubin> i think it's a process question on where things should live
12:18 <@jeremyrubin> and sapio makes that kinda unique
12:18 < bucko> ^ 
12:18 <@jeremyrubin> #subtopic James O'Beirne's feedback
12:18 < prayank> He mentioned coinjoin so I would if someone could really share how it would improve coinjoin. Nonbody cares about BIP. BIPs are memes anyway that we could write later if we know enough about something.
12:18 < iamzensored> In fairness the requests have never been for GUI-complete apps
12:19 <@jeremyrubin> James mostly has a code-review feedback that the CTV caching strategy is too aggressive and has a mild cost for all txns, and requests that be addressed
12:19 -!- Guest16 [~Guest16@c-69-181-194-70.hsd1.ca.comcast.net] has joined ##ctv-bip-review
12:19 <@jeremyrubin> in code, i have offered patches that reduce the caching to be lazily computed on first use of CTV
12:20 < rgrant> (previous topic) I think it's legit for someone to ask for examples in script, without having to learn Sapio.  they might get a large dump of transactions, but it's useful to help people to learn from what they know.
12:20 <@jeremyrubin> this keeps CTV non-dosable, but adds some complexity in interfaces because sync/pthreads are not available in the interpreter but are needed to cache on first use 
12:20 -!- Guest16 [~Guest16@c-69-181-194-70.hsd1.ca.comcast.net] has quit [Client Quit]
12:21 <@jeremyrubin> privately, jamesob provided me some additional feedback on performance that the extra allocations still slow things down a little. One difficulty is in maintaining multiple interfaces for validation imposes some performance overhead, but it's solvable by making the code a little more spaghetti-y
12:21 < rgrant> yeah i found the comments in that patch required me to load a lot of context into the caching issues.  however, 3% seems worth it.
12:22 <@jeremyrubin> I think it's down to 1.5% now with the changes shown
12:22 < rgrant> (eh, load context into mind, to understand the comments and the code.)
12:22 <@jeremyrubin> and by fixing some allocations it could end up at 0%
12:22 -!- Guest16 [~Guest16@c-69-181-194-70.hsd1.ca.comcast.net] has joined ##ctv-bip-review
12:22 <@jeremyrubin> these are mostly things that aren't inherent, they can be sped up at the cost of a bit worse interfaces
12:23 -!- Guest16 [~Guest16@c-69-181-194-70.hsd1.ca.comcast.net] has quit [Client Quit]
12:23 <@jeremyrubin> do folks care about something like 1.5% reindex slowdown if it seems fixable in the future?
12:23 < bucko> > I think it's down to 1.5% now with the changes shown
12:23 < bucko> shown where?
12:23 < iamzensored> Not anywhere up to speed on this but my question would be similar here, have other soft forks caused a slowdown in IBD and if so by how much?
12:23 <@jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21702#issuecomment-1019003673
12:24 <@jeremyrubin> iamzensored: taproot and segwit certainly contribute to some slowdowns because the PrecomputedData has to be computed and scanned for use on all txns
12:24 <@jeremyrubin> IDK what the magnitude of that is, but it is a thing
12:24 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
12:25 < bucko> So that is imposed even on pre-activation txs once that's applied? It would be interesting to see what that difference is to use as a baseline
12:25 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
12:25 <@jeremyrubin> i also think that 1.5% may be just within noise on the testing environment, altho it seemed repeatable 
12:25 <@jeremyrubin> bucko yeah it's simplest to just have that logic always on
12:25 <@jeremyrubin> ok we're gonna move on in a sec
12:25 <@jeremyrubin> had my eye off the clock
12:26 <@jeremyrubin> #subtopic Peter Todd's Feedback
12:26 < rgrant> let's ask another question: how can reviews of this code feel confident that the 1.5% would be addressed later if they thought it was important and if that offer was on the table?
12:26 < bucko> Did @jamesob mention what deviation/slowdown he considers reasonable?
12:26 -!- josedrobles [~josedrobl@24.red-83-34-107.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]
12:26 <@jeremyrubin> Does anyone have any thoughts on Peter's feedback?
12:27 < rgrant> i was really surprised that Peter Todd didn't appear to understand the finite precomputation versus recursive covenant issue.
12:27 < prayank> Peter had 2 major issues: 1. Doesn't like use cases 2. DoS
12:27 <@jeremyrubin> bucko, jamesob told me more or less that he's going to look at testing generally before wanting me to spend time over-optimizing. 
12:27 < prayank> 1 cant do anything 2 was answered
12:28 <@jeremyrubin> mod: i'm going to add a few minutes to this section since i messed up on timing the subtopic switch
12:28 <@jeremyrubin> he also reviewed outdated (2 years old) tests, there are more tests now
12:28 < bucko> @jeremyrubin that's an awesome set of eyes and coverage to be getting either way. 
12:29 < iamzensored> Sure is
12:29 <@jeremyrubin> DoS section has been added to the BIP, was never an issue in the code though (it was part of CTVs design to be cheap to validate)
12:29 < prayank> https://github.com/bitcoin/bips/pull/1272
12:29 < bucko> I guess w/ major issue 1, to steel man the argument, it can be viewed as a problem if you consider all use cases to be under explored.  
12:30 <@jeremyrubin> i think it's an issue with generality; the more general an upgrade is the less you can explore all uses
12:30 < prayank> bucko: we need to explore them and cant expect everything from the author. 2 smart devs did it yesterday: DLC and Pathcoin
12:31 <@jeremyrubin> ctv happens to be relatively general, so it can be used for many things. i think some depth first v.s. breadth first tradeoffs are clear
12:31 < bucko> I've seen some reviews that almost run into a kind of paradox of choice and are turned off by all the different potential applications. This isn't necessarily a bad thing. As we've seen with Taproot and now even CTV with the DLC post, there are going to be use cases and standards nobody's thought of yet, but having them out there all at once can be difficult for some to digest
12:31 < prayank> Pathcoin isn't altcoin in case someone is confused it was an idea by waxwing
12:31 <@jeremyrubin> but things like https://github.com/kanzure/python-vaults seem like a "we built the thing" kind of depth answer
12:31 <@jeremyrubin> #mod 1.5 mins
12:32 <@jeremyrubin> bucko: and also "optimal for one" v.s. "general enough to do many"
12:33 <@jeremyrubin> #topic What is Sapio / How to think about Programming with CTV (15 Min)
12:33 <@jeremyrubin> Sapio is a framework for making CTV applications.
12:33 <@jeremyrubin> When you make something like https://github.com/kanzure/python-vaults
12:34 <@jeremyrubin> or the original C++ CTV Vault wallet RPC i showed at the SF Workshop, you need to do a ton of stuff by hand
12:34 <@jeremyrubin> Sapio is a toolkit for the common things you might do, being able to stitch things together 
12:34 <@jeremyrubin> Sapio can be used *today* on mainnet if you pre-sign instead of CTV
12:35 <@jeremyrubin> however, with CTV, things become non-interactive (more on that...)
12:35 -!- josedrobles [~jdrobpar@24.red-83-34-107.dynamicip.rima-tde.net] has joined ##ctv-bip-review
12:35 <@jeremyrubin> Sapio targets building WASM modules for contracts / reusability of components for composability. E.g., a backbone vault contract that you can plug in any cold storage module into
12:35 <@jeremyrubin> Does anyone have any basic questions to start? then we can talk about non-interactivity
12:36 < iamzensored> Sapio can do non-CTV applications too right? IIRC it can do anything miniscript can so if you're careful with your coding you can write applications today that run on Bitcoin right?
12:36 <@jeremyrubin> iamzensored: 100%
12:36 -!- josedrobles [~jdrobpar@24.red-83-34-107.dynamicip.rima-tde.net] has quit [Client Quit]
12:36 <@jeremyrubin> if you want, you can even emulate CTV with a multisig federation.
12:37 <@jeremyrubin> (potentially, an ephemeral federation too)
12:37 <@jeremyrubin> Those applications would work more or less as expected
12:37 < prayank> Sapio Studio would be helpful as well for some users/devs
12:37 -!- josedrobles [~jdrobpar@24.red-83-34-107.dynamicip.rima-tde.net] has joined ##ctv-bip-review
12:37 <@jeremyrubin> right; sapio studio is a UX tool for interacting with Sapio based contracts
12:38 <@jeremyrubin> it's still heavy alpha, but one day may evolve to a full functioning wallet
12:38 <@jeremyrubin> #subtopic non-interactivity
12:38 < prayank> +1
12:38 <@jeremyrubin> so often times when i say 'non interactive' for ctv people get upset
12:38 <@jeremyrubin> i dont have a better term for it
12:39 <@jeremyrubin> what it means is that CTV contracts can be constructed by an untrusted third party and proven later
12:39 <@jeremyrubin> this is in contrast to e.g. pre-signing whereas all parties must interact somewhat synchronously to create it
12:39 <@jeremyrubin> For example, a service could collect 1000 lightning channel open requests throughtout the day
12:39 < rgrant> so lots of things go over the wire still, but later parties didn't need to be there at the same time to verify it.
12:39 <@jeremyrubin> and then create 1000 channels unilaterally
12:39 <@jeremyrubin> and then email them a proof 
12:40 <@jeremyrubin> this is still "interactive", but in the same way a snark is still interactive (you need the input data? you need to receive the proof?)
12:40 <@jeremyrubin> does anyone have any questions about this?
12:41 < iamzensored> so independently verifiable, and the interaction is just one way/unidirectional?
12:41 < iamzensored> non-interactive construction?
12:41 <@jeremyrubin> it can be, yes
12:42 <@jeremyrubin> in some cases you still may need to interact somewaht (e.g., multiple payers into the contract)
12:42 <@jeremyrubin> but as with DLCs example llfourn showed, the interaction can also be much lesser 
12:43 <@jeremyrubin> since you get rid of e.g. N presigned transactions with N parties signing them, you could save like N^2 communications
12:43 < iamzensored> yeah i can see why people would take issue with the term, but can't think of a better one
12:43 < rgrant> it sounds like the distinction you're making is that subsidiary parties can't block the transaction by stalling.
12:43 < rgrant> so, maybe "non-stallable"?
12:43 <@jeremyrubin> i think non-blocking asynchronous?
12:43 <@jeremyrubin> but idk if that helps build intuition sufficiently...
12:43 <@jeremyrubin> #subtopic composability
12:44 <@jeremyrubin> a related topic is composability
12:44 <@jeremyrubin> given a non-interactive contract, I can get an address for it and an amount expected
12:44 <@jeremyrubin> I could then "plug that in" to another contract, and then the results typically cleanly compose
12:45 <@jeremyrubin> Sapio takes it a level higher; instead of just addresses you can compose the modules as functions emitting addresses and amounts too (e.g., ColdWallet(Amount) -> Address)
12:45 <@jeremyrubin> and the results can still be verified later
12:45 -!- CubicEarth [~CubicEart@2603-6080-6b00-03b1-b4b0-a833-7fe8-0110.res6.spectrum.com] has joined ##ctv-bip-review
12:45 <@jeremyrubin> Does anyone have any questions about comoposability?
12:45 <@jeremyrubin> It's sort of "why sapio+ctv lets you build cool stuff well"
12:47 < rgrant> i think the community isn't layering strongly enough to make use of this feature, yet.
12:48 <@jeremyrubin> yeah. 
12:48 < rgrant> but it's certainly a big deal to have modules over in the other blockchains.
12:48 <@jeremyrubin> e.g, i think llfourn's dlcs are non-interactive
12:48 <@jeremyrubin> which means you can do partially funded options over dlcs on chain
12:48 <@jeremyrubin> which is kinda crazy
12:48 <@jeremyrubin> ok we gotta move on!
12:49 <@jeremyrubin> #topic - Vaults (20 Min)
12:49 < prayank> community :)
12:49 <@jeremyrubin> Who likes vaults?
12:49  * rgrant wohoos
12:49 < prayank> Michael Folkson
12:49 <@jeremyrubin> The "original" "vaults" paper iirc was from Gun et al
12:50 <@jeremyrubin> it proposed something where it's a vault that you can make withdrawals infinitely stallable 
12:50 <@jeremyrubin> as p.todd points out, practically, you can do this with CTV by unrolling it like a million years
12:50 <@jeremyrubin> but i personally never found the delayable vaults, although game theoretically sound, that compelling
12:51 <@jeremyrubin> instead, for CTV i focused on showcasing time-release vaults
12:51 <@jeremyrubin> where you can withdraw some portion of a coin on a fixed schedule
12:51 <@jeremyrubin> The way it works is that every PERIOD you can pull X btc out of a utxo, and then have another PERIOD before you can take more
12:52 <@jeremyrubin> if the vault is compromised, you can 'cancel' the future withdraws to a cold-storage contract/address
12:52 <@jeremyrubin> because CTV is non-interactive, it's possible to send to a vault without having any vault keys exist/be online
12:52 < iamzensored> I love the vaults. I think they're an absolutely killer feature of CTV and make HODLing much more accessible. I imagine there will be all sorts of timelocked recovery methods that make it easier for a regular person to deal with losing a key
12:52 <@jeremyrubin> Does anyone have any basic questions about this?
12:54 <@jeremyrubin> One contrast useful to draw is why 1 vault v.s. N outputs maturing at different dates. a vault guarantees that the vaults actions happen in sequence instead of possibly all at once.
12:54 <@jeremyrubin> it also makes it simpler that when you do the cancel transaction, it sweeps all the funds v.s. N independent utxos to cancel
12:56 <@jeremyrubin> Another topic that's interesting to think about is the cold-wallet. The cold wallet could be e.g. a 2-3 multisig, not just an address. It also could be itself a transaction (using CTV) that splits the funds into, say, 3 different 2-3 backups. Or even a recursive second instance of a vault (maybe too much?)
12:57 <@jeremyrubin> I think one of the tensions on BIP v.s. PoC is that CTV/Sapio doesn't have just one way to do it; these things can all be customized per-organization
12:57 < rgrant> Can you remind us what's the benefit of using CTV instead of presigned transactions in these constructions?
12:57 <@jeremyrubin> rgrant: sure, with presigned transactions you have a 'toxic waste' key that needs deleting
12:58 <@jeremyrubin> you also have to store O(N) signature data, v.s. O(1) "vault creation instructions" + code
12:58 < rgrant> so if i've been generating my keys from a seed, and use one of those, then the vault could be compromised when the seed is.
12:58 < prayank> jeremyrubin: re: these things can all be customized per-organization. Thats a feature IMO
12:58 <@jeremyrubin> (although I think practically you'd want to save all the things for redundancy)
12:58 < iamzensored> Toxic waste keys also don't scale well to less than fully trusted parties
12:58 <@jeremyrubin> rgrant: correct
12:59 <@jeremyrubin> iamzensored: correct
12:59 <@jeremyrubin> you can do a multisig/musig, but then sending to vault requires a MPC
12:59 <@jeremyrubin> and then you can't also e.g. tell coinbase to send funds to your vault
12:59 <@jeremyrubin> whereas with CTV you could give specific instructions of "exactly this many coins to this addr"
12:59 < rgrant> ...which means i need a random number generator that i trust at the moment i make a vault with presigned transactions.
13:00 <@jeremyrubin> and it would be a non-interactive genesis of the vault
13:00 < iamzensored> It's also less practical to store transactions than a couple backup mnemonics
13:00 < iamzensored> *pre-signed txs
13:00 <@jeremyrubin> well I think until we're really secure on WASM determinism and stuff you'd probably want to save all the sapio output
13:00 <@jeremyrubin> but it's still "possible" you don't have to save as much presigned stuff
13:00 <@jeremyrubin> I guess also auditability is good? 
13:01 <@jeremyrubin> You can't tell if a presigned was corrupted/cheated or not, but CTV you can tell it's correct
13:02 <@jeremyrubin> What do people think about paying fees for vaults to unroll? I think as of now CTV vaults would basically assume some sort of package relay + CPFP anchor outputs
13:02 < bucko> I think this is the original vault paper that was referenced earlier: https://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
13:03 <@jeremyrubin> correct
13:03 <@jeremyrubin> rgrant: yes, you would need RNG
13:03 <@jeremyrubin> rgrant: but also some sort of 'secure device'
13:03 < prayank> package relay + CPFP.. this sounds less tested than CTV
13:04 <@jeremyrubin> prayank: you can also over-estimate fees, but CPFP / package relay is theoretically required for lightning
13:04 <@jeremyrubin> prayank: also consensus v.s. non consensus code
13:05 <@jeremyrubin> mod: 4 mins remaining
13:05 < prayank> jeremyrubin: Sarcasm
13:05 <@jeremyrubin> sidenote, i also work on transaction sponsors / fee accounts as a more general purpose solution for this, but that's not solidified
13:06 <@jeremyrubin> prayank: sarcasm? don't know her
13:06 < prayank> CPFP has lot of issues and some wallets don't work like core wallet
13:06 <@jeremyrubin> so one other point i hear come up is a desire for more flexible vaults
13:06 < bucko> I'm a little behind, so forgive me if this is now off topic, but on the toxic waste thing, I was also thinking recently that this is particularly undesirable for vaults which are almost inherently super long term. It's very hard to know what the situation will be in say 20-30 years time when you might be in an inheritance scenario for example 
13:06 < rgrant> package relay will help.  it's a vault, so a couple extra txs would probably be worth it.  but it would be nice to keep ideas for improvements in fee paying moving forward
13:07 <@jeremyrubin> e.g., withdrawing known amounts is bad, but if you could withdraw *up to X* per period that would be better
13:07 < bucko> When you have this element of trust on a 3rd party, even if it can be partially mitigated, there are so many unknowns in the future that you really want to reduce that as much as possible (which ctv makes much more controllable afaict) 
13:07 <@jeremyrubin> my view is because you can always send excess to cold that you don't want (or to another vault...) this might be overkill?
13:07 <@jeremyrubin> bucko: right, the proof can be years later
13:08 <@jeremyrubin> ctv does permit a proof, not just a trust assumption
13:08 < S3rj3> prayank: wallets that don't know how to handle CPFP can't be called wallets.... It just represents how much the devs of the wallet knew about the coin 
13:08 <@jeremyrubin> mod: 1 min
13:08 < prayank> Even Core has a bug : https://twitter.com/realtbast/status/1486012770244075523
13:08 < prayank> Shared in this thread
13:09 <@jeremyrubin> mod: actually we'll go to 1:10 on this
13:09 <@jeremyrubin> we can talk cpfp in the next topic
13:09 <@jeremyrubin> any closing thoughts on vaults for the meeting?
13:10 <@jeremyrubin> #topic Congestion Control (20 Mins)
13:10 < S3rj3> I really love the idea of vaults, but I'm more in favor of private key and things like that rather than mnemonics 
13:10 <@jeremyrubin> So congestion control is the idea of 'merkelizing and segregating' outputs from the parent txn
13:10 <@jeremyrubin> these merkelized outputs can be claimed lazily after the fact
13:10 <@jeremyrubin> but permit confirmation of receivability earlier
13:11 <@jeremyrubin> it is somewhat controversial because wallets right now would not do the best job with it and it requires things like CPFP to be handled better
13:11 <@jeremyrubin> i wrote a post about exisiting behavior and congestion control here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019756.html
13:11 <@jeremyrubin> does anyone have any questions about this use case?
13:11 < bucko> Maybe one place to start here since it ties into a previous topic is I feel like there have been some criticisms of congestion control as a good use case or argument for CTV. I can't remember the specifics though, maybe you could share some of them? 
13:12 <@jeremyrubin> I think the main arguments against are: 1) wallet complexity 2) uses more space overall 3) this is dumb blocks are empty
13:12 <@jeremyrubin> for 1) the post i shared above answers how this is already complexity that wallets should handle
13:13 < bucko> Wasn't there also one that (related to 1) was that we'd need exchange opt in. 
13:13 <@jeremyrubin> for 2) it actually doesn't use more space than existing incentive compatible behavior on how you might split up txns already, and even if it did, it's a small constant factor more 
13:13 <@jeremyrubin> for 3) ¯\_(ツ)_/¯ 
13:15 <@jeremyrubin> bucko: correct, exchanges may need to opt in. individual users could batch their payout requests non-interactively and benefit, but in order for exhanges to do it they would have to implement something new. however, it could save them very large amounts of fee to do so because it makes on-line batch updating not cost O(N^2) fees...
13:15 < rgrant> i think a fourth criticism would be: first recipient pays more, until merchants using this work out reasonable SLAs for when they'll boost a branch of transactions.
13:15 <@jeremyrubin> since you only have to replace O(1) outputs with RBF to add inputs, not O(N) outputs with rbf (and feerate increase means N updates --> O(N^2) fee cost)
13:17 <@jeremyrubin> rgrant: i discussed on SLP the SLAs and stuff and how that might slowly evolve to standard practices here https://stephanlivera.com/episode/339/
13:17 <@jeremyrubin> rgrant: c-f for SLA
13:17 < bucko> also discussed problem 3 which was interesting in the context of maybe we can make blocks more full by making transactions more useful with something like CTV which also gives us the tools we need to deal with the resulting congestion :) 
13:18 <@jeremyrubin> yeah
13:18 <@jeremyrubin> i guess it is sort of a do we remove the branch blocking the road before we hit the branch
13:18 <@jeremyrubin> so some of these things get Jevons' paradox-y
13:18 <@jeremyrubin> https://en.wikipedia.org/wiki/Jevons_paradox
13:20 <@jeremyrubin> also note that congestion control + non-interactive lightning (not on todays agenda; will cover next time) are really good for things like Muun Wallet
13:20 <@jeremyrubin> or lightning in general
13:21 < rgrant> hey, the batched txns could have a "everbody shares the fee" trigger as well, so users could get out using a cooperative (classical online) scheme.
13:21 <@jeremyrubin> Another relevant concept to bring up is the 21i measure (layer2-to-one index, how long would it take for a service to exit customers to layer 1 coins)
13:21 < prayank> jeremyrubin: sorry but I agree with jamesob what he said in last meeting. this is not the best usecase and worst for marketing of ctv
13:21 <@jeremyrubin> e.g., coinbase might take months to pay everyone their coin with on chain txs, so might a sidechain like liquid.
13:21 < prayank> there is no congestion. nobody wants to use bitcoin 99% of the time
13:22 <@jeremyrubin> CTV would make it possible to payout from these services within 1 block which improves them quite a lot and limits 'thundering herd' bankrun effects
13:22 <@jeremyrubin> prayank: i agree
13:22 < prayank> https://bitcoin.stackexchange.com/questions/111101/fee-rate-and-market-cycle
13:22 <@jeremyrubin> see jevons' paradox
13:23 < prayank> we need CTV so people use bitcoin
13:23 <@jeremyrubin> the corollary is that people/the market inherently would not want to rely on Bitcoin until they know such problems are solved
13:23 <@jeremyrubin> so having solutions to it means that more use can show up
13:23 <@jeremyrubin> mod: ~7 mins
13:24 <@jeremyrubin> prayank: I also +1 that we want more people to use bitcoin...
13:25 <@jeremyrubin> contrary to popular belief, i am not a marketing guru.. i think congestion control is theoretically important for bitcoin robustness/reliability and i think it's "easy" to solve with CTV near optimally
13:25 < rgrant> what's the read on excitement from exchanges for congestion control?
13:25 < rgrant> (since they're the main offenders)
13:26 <@jeremyrubin> rgrant: i haven't heard any objections to the direction, mostly positive, although unlikely to spend eng time on something they can't deploy in 1-2 quarters
13:26 <@jeremyrubin> i think there is more excitement from sidechain/wrapped bitcoin + wallets like Muun or Lightning Labs
13:27 < rgrant> i think without their support or definite interest, the vast majority of people will not have the social cues to pay attention to this use case.
13:27 <@jeremyrubin> Oh also Mining Pools seem to really like lazy payouts
13:28 < rgrant> aha.
13:28 <@jeremyrubin> rgrant: define definite interest?
13:29 <@jeremyrubin> also note we have 2 mins left and theres not so many techncial questions
13:29 < rgrant> in social cue land, someone is interested when i hear them talking about ti.
13:29 <@jeremyrubin> does everyone basically agree that it works?
13:29 <@jeremyrubin> it's just a do people want this question?
13:29 < bucko> I think that sounds right. I guess one kind of technical question is if this is the optimal way to solve the problem if we agree it is
13:30 < rgrant> everyone will want it, but no developers want to think about changing their wallet software for it.
13:30 <@jeremyrubin> mod: 1 min
13:30 < rgrant> * will want it when the next fee crunch hits
13:30 <@jeremyrubin> rgrant: i guess that's the point of https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019756.html
13:30 < rgrant> same thing happened to LN, BTW.
13:31 <@jeremyrubin> if you haven't already implemented congestion ready wallets, users will hate you
13:31 <@jeremyrubin> and that's independent of CTV or no
13:31 <@jeremyrubin> #topic - Payment Pools (20 Mins)
13:32 <@jeremyrubin> Ok so payment pools are the idea of a congestion control tree + MuSig Keys for owners of sub-leaves in the tree
13:32 <@jeremyrubin> you can think of them as a 'lazy rolling coinjoin'
13:32 < prayank> This is interesting
13:33 <@jeremyrubin> you could imagine payment pools operating in different modes, e.g., payment pools with embedded Channels, payment pools that operate trusted for 1 day and close book daily, payment pools that operated trusted and close every time the L2 norm of trusted transfers exceed T, etc
13:33 <@jeremyrubin> payment pools generally have some interesting questions to ask
13:33 <@jeremyrubin> what does it cost to kick 1 person out?
13:34 <@jeremyrubin> what does it cost to kick N people out?
13:34 <@jeremyrubin> what does it cost for 1 person to choose to leave it?
13:34 <@jeremyrubin> what happens to those who remain in such a scenario?
13:35 <@jeremyrubin> what kind of privacy do users have from each other / how much data must be known?
13:35 <@jeremyrubin> There have been different designs proposed, such as CoinPool or TLUV based pools.
13:35 <@jeremyrubin> CTV's solution to this is to have a tree of multisigs (e..g, 1 n-of-n or split to 2 n/2 of n/2)
13:36 <@jeremyrubin> This costs log_R(n) O(R) transactions to evict 1 person.
13:36 <@jeremyrubin> Kicking N people out costs approximately O(N) because it amortizes
13:36 <@jeremyrubin> it costs 1 person worst case O(R) to leave unilaterally, and E[O(1)] aggregately (amortizes)
13:37 <@jeremyrubin> In the event of a single failure, with radix R, the pool splits into R-1 groups and then recursively so on (e.g., if R = 4, you get 3 groups of size N/4, 3 groups of size N/16, etc)
13:38 <@jeremyrubin> other solutions (non-ctv) prefer pools which do not split, but each party has only O(1) transactions that are eith O(log(N)) in size or O(1) where there is a huge constant (crypto accumulators)
13:39 < prayank> payment pools with embedded Channels? how does this work? any tldr
13:39 <@jeremyrubin> CTV also has sub-structural privacy, whereas you only care about specifics of balances along your own leaves in the pool, TLUV or accumulator based pools require full information for all parties.
13:40 <@jeremyrubin> Lastly, a question exists of total number of supported users, TLUV maxes out (for nuanced reasons) around 30, CTV allows any number
13:40 <@jeremyrubin> prayank: instead of the pool having leaf nodes as being single owner utxos, they could be channels.
13:40 <@jeremyrubin> then you could trustlessly change balances via LN using the embedded channel.
13:41 <@jeremyrubin> the pool could even be oblivious to if users are using channels inside or not, since musig would make it look like just normal keys
13:41 < prayank> jeremyrubin: this max user thing is interesting, why is it 30 and CTV makes it unlimited?
13:41 <@jeremyrubin> prayank: TLUV tweaks the taproot key. E.g. A+B+C -> A+B when C exits
13:42 <@jeremyrubin> because points must be even to be valid Tr keys, you have to do a n*2**N (I think?) algorithm to generate a valid taproot key for TLUV
13:42 <@jeremyrubin> you can maybe do 30 keys, but definitely not 60
13:42 <@jeremyrubin> mod: 10 mins 
13:42 < prayank> Thanks
13:43 <@jeremyrubin> prayank: there might be tweaks to this that would permit more keys, but not without some sort of change to taproot / a new taproot version for odd keys?
13:43 <@jeremyrubin> payment pools do have some sort of natural "dunbar's number" though. 
13:44 <@jeremyrubin> you can think of CTV bisecting as a on-chain search for 'stable pools' who are mutually online enough for each other
13:44 <@jeremyrubin> so it's not clear that unless you have a good expectation of positive behavior that pools would scale beyond 30 anyways
13:45 < rgrant> when i get ejected i get a full payout to a predesignated address?
13:45 <@jeremyrubin> correct.
13:45 -!- iamzensored [~iamzensor@user/iamzensored] has quit [Quit: Leaving]
13:45 <@jeremyrubin> that address could be a channel address, of course
13:45 <@jeremyrubin> so then you'd just get a channel
13:46 < rgrant> and when i'm in the pool we're passing around data that some coordinator module/website will occasionally ask us to sign for?
13:46 <@jeremyrubin> (btw, I think that TLUV requires that if 1 person is offline you need to do N-1 exits -- it's not clear that it works for *kicking someone* v.s. everyone else leaving -- aj might know if i'm wrong on that)
13:47 <@jeremyrubin> rgrant: well it could be full decentralized
13:47 <@jeremyrubin> but practically, sure, it might look like that
13:47 <@jeremyrubin> and you can verify that it pays you the amount you expect to still have
13:47 <@jeremyrubin> and you don't care what else has happened
13:47 <@jeremyrubin> so you don't need to "see" most of that data to be happy
13:48 < rgrant> but from the outside there's just one UTXO.  it's cool that the internal data is ephemeral.
13:48 < bucko> What's the process look like for updating those payout amounts? Anytime there is some payment made from the payment pool, presumably these payouts need to also be updated
13:48 <@jeremyrubin> correct
13:48 <@jeremyrubin> I showcase a possible state transition system in
13:48 <@jeremyrubin> https://rubin.io/bitcoin/2021/12/10/advent-13/
13:49 <@jeremyrubin> basically, I assume you'd have a payment pool instance number i = 0...u64
13:49 <@jeremyrubin> and then you'd collect signed balance transfer requests
13:49 <@jeremyrubin> then, say, once a day you'd do a cutoff
13:49 <@jeremyrubin> collect all payments requested, subtract/add/ cut-through
13:49 <@jeremyrubin> and then get all N to sign off on a new pool
13:50 <@jeremyrubin> and transition
13:50 <@jeremyrubin> if you were more clever, you'd only have to share balance updates with your sub-tree parties
13:50 < bucko> subtree being the "exit paths"? 
13:50 <@jeremyrubin> but that's a software engineering concern less than a 'is this possible'
13:50 <@jeremyrubin> mod: 1 min!
13:51 <@jeremyrubin> bucko: imagine i have a tree with ALice, bob, dave, carol
13:51 <@jeremyrubin> radix 2
13:51 <@jeremyrubin> if alice makes a payment, dave and carol don't need to learn if it was alice or bob
13:51 <@jeremyrubin> just that it was "the left side of the tree"
13:51 < rgrant> i think this is a very strong use case, but there's obviously lots of work to do to show people the thing in operation, so devs will have to use their imaginations - like we all did for SegWit.
13:52 <@jeremyrubin> #topic - General Q&A (15 Mins)
13:52 < prayank> Any comments on email by Lloyd Fournier, waxwing and Jonas Nick
13:52 <@jeremyrubin> now we're just open ended, feel free to revisit anything we didn't get to fully
13:52 < bucko> Very cool. I like that "subtree" version especially. I imagine you'd really want to have specialty payment pool wallets to make this really practical
13:52 <@jeremyrubin> prayank: i plan to have those in the next meeting as topics
13:53 <@jeremyrubin> bucko: i assume so, yes
13:53 < prayank> Okay
13:53 <@jeremyrubin> i also assume all coinjoins would want this for many reasons
13:53 <@jeremyrubin> since you have the opportunity to keep information much more hidden for longer periods
13:53 <@jeremyrubin> and it solves some issues around variable amounts 
13:53 <@jeremyrubin> but that needs real Privacy Experts to fully flesh out what info leaks are OK v.s. bad
13:53 < rgrant> ahh, Jonas says APO will be just as good for this.
13:54 < bucko> I guess that's kind of a similar argument for like ecash for privacy too
13:54 < prayank> rgrant: he also says A downside compared to CTV is the additional overhead of 64 witness bytes (<sig>)
13:54 <@jeremyrubin> bucko: yeah. you could make a CTV Pool that pays 1x a day have a backing ecash system btw
13:55 < rgrant> will/would.  are we doing two opcodes yet?
13:55 < bucko> oh no. Another use case. 
13:55 <@jeremyrubin> bucko: we also didn't talk about coin pools with non-unanimous sign-off
13:55 < bucko> How will this ever get community buy in if there are any other use cases :-\ 
13:55 <@jeremyrubin> it should actually be 66 bytes, since you need 1 byte for tag + 1 byte of pushdata
13:56 <@jeremyrubin> but you might also be able to use the 0x01 key and save 32 bytes, but then it becomes something that requires pre-signing with a important key
13:56 <@jeremyrubin> OP_GENERATOR that puts G on the stack would help though
13:57 <@jeremyrubin> so I think if you did APO + OP_GENERATOR + OP_CAT it would be similar overhead to CTV
13:57 < prayank> I hope APO doesnt have any ATO. JK
13:57 <@jeremyrubin> <half sig> OP_G OP_CAT 0x01 OP_G OP_CAT CHECKSIG
13:58 <@jeremyrubin> mod: 10 mins
13:58 <@jeremyrubin> mod: sorry we're running just a tad over :)
13:59 <@jeremyrubin> i was hoping that gleb and antoine would be here since they have some CoinPool work...
13:59 <@jeremyrubin> anything else anyone wants to bring up?
13:59 <@jeremyrubin> should we just end?
13:59 < rgrant> going AFK.  bye everyone, see you next time.
14:00 < prayank> Thanks everyone
14:00 -!- prayank [~Prayank@45.64.9.48] has left ##ctv-bip-review []
14:00 < bucko> All good! Thanks for the good session. I guess is there going to be another spaces to pair with this like last time? 
14:00 <@jeremyrubin> mod: 1 min unless anyone wants to discuss something...
14:00 <@jeremyrubin> bucko: no plans for a space at this moment
14:01 <@jeremyrubin> thanks everyone for you attendance!
14:01 <@jeremyrubin> #endmeeting
14:01  * jeremyrubin phew
14:01 -!- NotASithLord [~NotASithL@170.250.22.245] has quit [Quit: Client closed]
14:01 < S3rj3> It's my first time here.... So no silly question on the first meeting... Have a lot to read to catch up 
14:01 -!- bucko [~bucko@136.49.111.169] has quit [Quit: Leaving...]
14:02 <@jeremyrubin> S3rj3: no silly questions, just silly people
14:02 <@jeremyrubin> questions are more than fine, feel free to ask here and will respond
14:05 < S3rj3> I know where the answers are, you gave us the link to SAL
14:06 < S3rj3> SLA and SLP.... 
14:06 < S3rj3> But have  no ideea what they stand for.... So I will definitely need to read a little back maybe 
14:07 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
14:07 -!- CubicEarth [~CubicEart@2603-6080-6b00-03b1-b4b0-a833-7fe8-0110.res6.spectrum.com] has quit [Quit: Client closed]
14:08 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:08 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Remote host closed the connection]
14:09 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:09 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Remote host closed the connection]
14:09 -!- josedrobles [~jdrobpar@24.red-83-34-107.dynamicip.rima-tde.net] has quit [Quit: Konversation terminated!]
14:09 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:09 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
14:10 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:12 < S3rj3> Nice to meet you jeremyrubin ! Cya around 
14:12 <@jeremyrubin> SLP --> Stephen Livera Podcast
14:12 <@jeremyrubin> SLA Service Level Agreement
14:12 < S3rj3> That's the podcast with the voice over right? 
14:12 <@jeremyrubin> basically, when you request a withdrawal from Exchange A, how quickly to the promise to have it
14:12 <@jeremyrubin> voice over?
14:13 <@jeremyrubin> https://stephanlivera.com/episode/339/
14:13 <@jeremyrubin> it has a transcript
14:14 < S3rj3> You had tweet and you said people could watch it without the need to hear yourvoice.... I was thinking they did a voice over
14:14 < S3rj3> 😂😂😂
14:16 < S3rj3> I will play it tomorrow at maximum volume... This way my neighbours will be more educated 
14:20 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
14:21 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:22 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Read error: Connection reset by peer]
14:25 -!- S3rj3 [~S3rj3@78.97.204.248] has joined ##ctv-bip-review
14:25 -!- S3rj3 [~S3rj3@78.97.204.248] has quit [Client Quit]
15:37 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...]
16:07 -!- CubicEarth [~CubicEart@2603-6080-6b00-03b1-b4b0-a833-7fe8-0110.res6.spectrum.com] has joined ##ctv-bip-review
16:17 -!- CubicEarth [~CubicEart@2603-6080-6b00-03b1-b4b0-a833-7fe8-0110.res6.spectrum.com] has quit [Quit: Client closed]
--- Log closed Wed Jan 26 00:00:41 2022