--- Log opened Tue Feb 08 00:00:53 2022
01:04 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
03:51 -!- otoburb_ is now known as otoburb
05:34 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Ping timeout: 276 seconds]
05:36 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined ##ctv-bip-review
05:43 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
06:17 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Quit: No Ping reply in 180 seconds.]
06:19 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review
07:02 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection]
07:02 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##ctv-bip-review
09:43 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
09:46 -!- tbw [~tbw@2a01:799:18e0:5d00:e5d6:4b2c:f1fe:f16] has joined ##ctv-bip-review
09:57 -!- ircisnotagreatth [~ircisnota@2804:296c:2100:343b:1ac0:4dff:fef3:df53] has joined ##ctv-bip-review
10:20 -!- joostjgr [~joostjgr@2a02-a450-1546-1-d4cd-a5a2-7582-2bae.fixed6.kpn.net] has joined ##ctv-bip-review
11:13 -!- ircisnotagreatth [~ircisnota@2804:296c:2100:343b:1ac0:4dff:fef3:df53] has quit [Quit: Client closed]
11:15 -!- ircisnotagreatth [~ircisnota@2804:296c:2100:343b:1ac0:4dff:fef3:df53] has joined ##ctv-bip-review
11:58 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has joined ##ctv-bip-review
11:59 -!- Earnestly [~earnest@user/earnestly] has joined ##ctv-bip-review
12:00 < jeremyrubin> #startmeeting agenda here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019856.html
12:00 < jeremyrubin> GM friends!
12:00 < jeremyrubin> A great agenda today with DLCs, Lightning, Pathcoin, TXHash and more!
12:01 < jeremyrubin> #topic Bug Bounty (10 mins)
12:01 < realtbast[m]> Good evening!
12:01 -!- roconnor [~roconnor@coq/roconnor] has joined ##ctv-bip-review
12:02 < jeremyrubin> not sure if Ariel is here, but bug bounty program (formal) continues to be WIP, but if anyone discovers something we'll do awards. We're considering some of the cool stuff people have posted / benchmarking for eligibility as well in the mid term. 
12:02 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review
12:02 < rgrant> hi
12:02 < roconnor> hi
12:02 < jeremyrubin> There has been *some* pushback from the donors that they really only want the funds to be used for *bugs* not for sponsoring research
12:02 < jamesob> hi
12:03 < llfourn> hi
12:03 -!- prayank [~andr0irc@45.64.9.48] has joined ##ctv-bip-review
12:03 < jeremyrubin> but I think we can accomodate letting people specify different approaches, with a little more legwork (they can just drip funding into the account we end up using as bugs are assessed, and as long as most are OK with general funding + bugs it's Good)
12:04 < jeremyrubin> Does anyone have any particular questions about bug bounty system?
12:04 < jeremyrubin> as a reminder the draft program is here https://docs.google.com/document/d/1pN6YzQ6HlR8t_-ZZoEdTegt88w6gJzCkcA_a4IXpKAo/edit
12:05 < jeremyrubin> if nothing, we can move on in a sec!
12:05  * rgrant participates in silent assent
12:06 < jeremyrubin> cool. Let's move things along then!
12:06 -!- ircisnotagreatth is now known as fiatjaf
12:06 < jeremyrubin> #topic: - Non-Interactive Lightning Channels (20 minutes)
12:07 < jeremyrubin> Ok so to start maybe let's run down how a channel works today
12:07 < jeremyrubin> step 1, Alice and Bob propose opening a channel
12:07 < jeremyrubin> step 2, Alice and Bob pick some particular inputs to spend into the channel (dual funded or no)
12:08 < jeremyrubin> step 3, Alice and Bob agree on a multisig addr that they make an unsigned txn with step 2 from
12:08 < jeremyrubin> step 4, alice and bob pre-sign the first revokable step in the tx chain spending from that multisig addr
12:08 < jeremyrubin> step 5, alice and bob sign the root txn and broadcast
12:09 < jeremyrubin> now they have a channel
12:09 < jeremyrubin> they can then sign an update 1 (or 0+1, N+1), and then revoke state 0
12:09 < jeremyrubin> does that make sense for all?
12:10 < realtbast[m]> looking good ;)
12:10 < jeremyrubin> cool!
12:10 < jeremyrubin> So for a non-interactive channel, what does that mean?
12:10 < jeremyrubin> Well if you recall, last week we talked about non-interactivity really be "asynchronous non-blocking" or something else more nuanced
12:10 < jeremyrubin> In this model (let's think about single funded for now)
12:11 < jeremyrubin> step 1: Alice decides to open a channel with Bob, Alice knows a "key generator (e.g. HD key or just a well known PK) for Bob (or looks up via Web of trust?)
12:11 < jeremyrubin> step 2: Alice picks some inputs.
12:12 < jeremyrubin> step 3: Alice creates a channel which can be automatically refunded after a 2 week claim period (using CTV!) 
12:12 < jeremyrubin> this channel is created in an on-chain txn of Alice's
12:13 < jeremyrubin> step 4: Alice posts the channel construction proof to a bulletin board/email that Bob can observe
12:13 < jeremyrubin> Alice can update states to Bob while Bob's key remains offline
12:13 < jeremyrubin> if Bob wants to send to alice, Bob's key must then go online
12:13 -!- RubenSomsen [sid301948@user/rubensomsen] has joined ##ctv-bip-review
12:13 < jeremyrubin> That's a LOT! Does anyone have any high level questions?
12:14 < jeremyrubin> Is the "less interactivity" of this construction clear?
12:14 < realtbast[m]> So the use-case is mostly for wallet users right?
12:14 < realtbast[m]> To let them receive offline?
12:14 < jeremyrubin> There's 2 paths we can take the discussion... how the non-interactivty works, applications that can use the non-interactivity.
12:15 < jeremyrubin> realtbast[m]: well one use case is that Bob requests Alice open a channel to them, and then goes offline for 24 hours. When Bob wakes up, Bob sees the channel proof from Alice.
12:15 < realtbast[m]> It would help me to first understand the usecases
12:15 < jeremyrubin> Cool!
12:15 < realtbast[m]> if others are ok with that
12:15 -!- psztorc [~asus@12.107.181.2] has joined ##ctv-bip-review
12:15 < jeremyrubin> So imagine i am a Liquidity Provider for Lightning
12:15 < jeremyrubin> and I want to open 10,000 channels for users
12:16 < jeremyrubin> I am going to do it in a batched txn
12:16 < rgrant> seems like a meshnet might be a good use case.
12:16 -!- Guest66 [~Guest66@cpe-172-250-19-6.socal.res.rr.com] has joined ##ctv-bip-review
12:16 < jeremyrubin> if I had traditional lightning, one user DoS'ing the protocol (or just being offline) would make me have to restart.
12:17 < jeremyrubin> so maybe you could batch 10 people, but if you get up to 100 with a 1% failure rate per client you fail every time
12:17 < jeremyrubin> With CTV, you can aggregate requests to open channels
12:17 < jeremyrubin> and then the LSP can unilaterally open up 10k channels in a single TX without needing an interactive "blocking" protocol
12:17 < jeremyrubin> does that make sense realtbast[m]
12:18 < realtbast[m]> yeah that use-case makes sense
12:18 < realtbast[m]> we could do for example a daily batch for all the channel open requests we received
12:18 < jeremyrubin> further, since these channels are in-bound cap only, they can immediately "receive" funds by the LSP half-signing updates even when their key remains offline
12:19 < realtbast[m]> about that half-signing, how does that work timing out a payment?
12:19 < realtbast[m]> the LSP adds HTLCs to an offline recipient, what happens if the recipient doesn't come online?
12:19 < jeremyrubin> it works like normal LN updates
12:20 < realtbast[m]> Since previous states aren't revoked, we can simply broadcast an old one or just invalidate it?
12:20 < realtbast[m]> I don't see how that helps though, while the recipient is offline they can't produce the preimage so the money is blocked
12:20 < jeremyrubin> well don't think about HTLC yet
12:20 < jeremyrubin> just think about the use case where Alice opened channel
12:21 < jeremyrubin> Bob is Online, but Bob's key is offline
12:21 < realtbast[m]> If the funds are stuck, I don't care that I was able to pre-add that to the commit tx
12:21 < realtbast[m]> ok
12:21 < jeremyrubin> Alice can send Bob updated states i, i+1, i+2
12:21 < jeremyrubin> and they are half-signed
12:21 < jeremyrubin> pays_to_bob(i+m) > pays_to_bob(i) forall i, m > 0
12:22 < jeremyrubin> so Bob, when Bob brings the signing key online, just has to finalize the largest state 
12:22 < jeremyrubin> does that make sense?
12:22 < jeremyrubin> it's not a suuuuper important point, but it can be useful (it's something normal lightning can do to as long as flows are unipolar)
12:22 < realtbast[m]> yep, that makes sense, however does alice handle a payment timing out though?
12:22 < realtbast[m]> If Bob is online, Alice can only use the latest state right?
12:23 < jeremyrubin> yes
12:23 < realtbast[m]> But if Bob hasn't signed it, Alice is screwed
12:23 < jeremyrubin> Ah, Alice can use the last state she has
12:23 < jeremyrubin> which at this time is the one in the CTV commitment
12:23 < jeremyrubin> which just returns funds to her
12:23 < jeremyrubin> there's no revokation Alice has issued
12:24 < jeremyrubin> so she can't be punished at this point
12:24 < jeremyrubin> and since pays_to_bob(i+m) > pays_to_bob(i) forall i, m > 0, alice prefers to close at state 0
12:24 < jeremyrubin> (not sure this is the most useful part of the non-interactive stuff so maybe we can move on?)
12:24 < realtbast[m]> ok, that was the bit I was missing, there's no revocation because it's not actually using htlcs, just directly replacing the amounts in each participant's outputs?
12:25 < realtbast[m]> ok, let's move on if you think that's not the most relevant point
12:25 -!- Earnestly [~earnest@user/earnestly] has left ##ctv-bip-review [WeeChat 3.4]
12:25 < jeremyrubin> yeah. I am not a LN expert but I think HTLCs require both parties fully online?
12:25 < jeremyrubin> something for a LN expert to think about
12:25 < jeremyrubin> and it's a general point for all lightning protocols of when you have to sign reciporcally or not, unspecific to CTV
12:25 < realtbast[m]> yes that's the part I'm struggling with, I don't see how to make that work with HTLCs, but I'll think about it
12:26 < jeremyrubin> But "useful" insofar as e..g in El Salvador you could give everyone cold storage inbound capacity
12:26 < jeremyrubin> but anyhow, the next logical leap is to then use congestion control
12:26 < jeremyrubin> so that if you open up 10k channels it's in a tree rather than a 10k big txn
12:27 < jeremyrubin> this means you can now open up as many channels as quickly as you want for as many customers
12:27 < jeremyrubin> E.g., bringing 1bn people on LN full self custody "could" be done in one block, as long as they don't all then have to close at the same time of course.
12:28 < realtbast[m]> gotcha, even though to actually use these channels you'll probably need to wait for the txs to confirm, otherwise you can't handle the payment timeout cases, right?
12:28 < jeremyrubin> nope!
12:28 < jeremyrubin> you can use them right away as long as the timeouts are relative not absolte
12:29 < jeremyrubin> so it depends on your HTLC protocol i suppose?
12:29 < realtbast[m]> ok, but are there proposals for multi-hop payments that work without absolute timeouts though?
12:29 < jeremyrubin> im not a LN Expert
12:29 < realtbast[m]> on top of my head I believe we do need absolute timeouts there
12:29 < jeremyrubin> mod: 1 min
12:30 < jeremyrubin> realtbast[m]: interesting. why?
12:30 < jeremyrubin> IIRC something like Interledger doens't use HTLCs at all for multi-hop
12:30 < realtbast[m]> because for multi-hop payments you need to be able to increase that timeout at each hop, don't you?
12:30 < jeremyrubin> #topic - CTV's "Dramatic" Improvement of DLCs (20 Minutes)
12:30 < jeremyrubin> realtbast[m]: we can circle back on this at the end
12:31 < jeremyrubin> llfourn do you want to take the mic?
12:31 < realtbast[m]> sure, thanks for these explanations
12:31 < jeremyrubin> I can start off, llfourn may be split brained in a DLC meeting now :)
12:32 < jeremyrubin> So there have been derivative proposals using CTV for a while
12:32 < jeremyrubin> but im not that smort and dont know how dlc oracle math works
12:32 < jeremyrubin> llfourn is smart, and figured out that you can extract the execution points into just bare keys
12:32 < jeremyrubin> and then use CTV to bind the outcomes
12:33 < jeremyrubin> without needing the weird binary search in txn space that i'd previously proposed
12:34 < jeremyrubin> combining the non-interactiveness of CTV, + the beauty of DLC math, gives a wonderful composition of properties where DLCs are wayyy faster to construct than before, and have a similar non-interactivity as we discussed previously
12:34 < jeremyrubin> This enables not only things like HFT DLCs in Channels, but also things like paying someone into a DLC when they are offline
12:35 < jeremyrubin> llfourn's research shows a 10x speedup in the simple case, and up to 300x (addtl 30x) when >1 oracle is used
12:35 < jeremyrubin> any questions on it?
12:35 < prayank> Thibaut shared some benchmark for performance on mailing list: https://mailmanlists.org/pipermail/dlc-dev/2022-February/000115.html (10-25x)
12:35 < jeremyrubin> I think his results corroborate llfourn's since it was the single oracle case, right?
12:35 < llfourn> I think the number in theory was 30x but it depends on implementation.
12:36 < llfourn> It's sounds pretty close to what I was expecting so yeah.
12:36 < jeremyrubin> gotcha -- was not clear weather you meant additional 30x (10x * 30x) or 300x?
12:37 < jeremyrubin> ooohg
12:37 < jeremyrubin> the additional part was a 10x
12:37 < llfourn> yep
12:37 < jeremyrubin> so somewhere from 100x - 300x improvement for a multi oracle dlc, and also ~0 network data
12:38 < jeremyrubin> for context, 5 seconds * 300 = 25 minutes, so it's definitely in the realm of "would work on mobile phones" : "would not - -"
12:38 < jeremyrubin> (i pulled 5 seconds from nowhere, but i think it helps contextualize)
12:39 < jeremyrubin> mod: ~10 mins
12:39 < jeremyrubin> does anyone have any further qs
12:40 < llfourn> Yes. I am really excited about what these improvements might mean to application developers. The DLC approach so far is to build something like the lightning network i.e. users run nodes which send messages back and forth. Now with the added non-interactivity you could explore other designs e.g. client and server (where server's key is pre-fetched by the clients) where clients can post orders in single HTTP requests.
12:41 < jeremyrubin> what has the reception been like on these things in the broader DLC community?
12:41 < llfourn> improvement of performance and message size is also crucial.
12:41 < llfourn> we'll see I'm sure we'll talk about it in the meeting later today!
12:41 < jeremyrubin> :D
12:42 < jeremyrubin> one thing that also strikes me is that you can have 3 phases for a DLC
12:42 -!- utxhoe [~utxhoe@ip-185-104-136-48.ptr.icomera.net] has joined ##ctv-bip-review
12:42 < jeremyrubin> phase 1: non-interactive setup
12:42 < jeremyrubin> phase 2: lazy backfill with "true DLC" protocol
12:42 < jeremyrubin> phase 3: cooperative or uncooperative close
12:43 < jeremyrubin> that might bridge the gap between getting witness size/privacy down while getting the speedups on commitment 
12:43 -!- utxhoe [~utxhoe@ip-185-104-136-48.ptr.icomera.net] has quit [Client Quit]
12:43 < llfourn> yes.
12:43 < jeremyrubin> but if state management storage is an issue i could see that non being popular
12:44 < llfourn> the problem I have when designing is the non-interactive setup will always lead to some kind of on-chain fingerprint either with ANYONECANPAY or CTV. Is that the way you see it too?
12:44 < jeremyrubin> i think you have two options
12:44 < jeremyrubin> either your protocol is *actually* an escrow to the oracles
12:45 < jeremyrubin> or it's not an escrow to the oracles, and you need the footprint
12:46 < jeremyrubin> also i think you construction w/ checksigadd is non optimal
12:46 < jeremyrubin> since you could in theory for a 3 of 5 setup
12:46 < jeremyrubin> do 10x more branches with all subsets of keys
12:47 < jeremyrubin> and that would be a difference of (log(n) + 5)*32 vs log(n*10)*32 = log(n) + log(10) = (log(n) + 3)*32
12:47 < jeremyrubin> so in theory pre-compiling the combos could maybe save you some witness space
12:48 < jeremyrubin> (n.b. huffman encoding + combos can save a *lot* more too, at the cost of worst case >> avg case)
12:48 < jeremyrubin> does that make sense?
12:48 < jeremyrubin> (and if you are all N-N path combos, you can musig the points together)
12:49 < jeremyrubin> mod: 1 min
12:50 < jeremyrubin> #topic - PathCoin (15 Minutes)
12:50 < jeremyrubin> is waxwing here?
12:50 < jeremyrubin> i am not sure i can give a solid explanation of it yet...
12:51 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined ##ctv-bip-review
12:51 < jeremyrubin> ok
12:51 < jeremyrubin> well
12:51 < jeremyrubin> i can do my best
12:51 < jeremyrubin> so
12:52 < jeremyrubin> pathcoin is a protocol whereby you 'precommit' to chains of transfers
12:52 < jeremyrubin> and then you have some sort of revocation for a previous path to transfer it to the next person
12:53 < jeremyrubin> there's a bit of a computational blowup, but in theory you could precompile all sequences of transfers for like 5-10 people without toooo much work
12:53 < jeremyrubin> (e.g. 10! is 3M)
12:53 < jeremyrubin> so then if everyone "knows" that a coin A exists
12:53 < jeremyrubin> and is initially held by Alice
12:54 < jeremyrubin> Alice can give the coin to Bob and a transcript revoking past transfers
12:54 < jeremyrubin> and then Bob has the coin
12:54 < jeremyrubin> Bob can then do the same to Carol
12:54 < jeremyrubin> etc etc
12:54 < jeremyrubin> but this is around where my understanding taps out
12:55 < jeremyrubin> other than that it's a multi-owner coin that can be xferred without a central authority 
12:55 < jeremyrubin> kinda like a virtual opendime
12:55 < jeremyrubin> i am afraid i probably can't answer many questions on it
12:55 < jeremyrubin> but i think i can contrast it with lightning
12:56 < jeremyrubin> where we really don't know how to make non-eltoo like channels "work" well for >2 parties, and even with eltoo >2 parties can get messy and require N parties to sign all updates
12:57 < jeremyrubin> in contrast, pathcoin would enable N parties to transfer between themselves with only 1 party (well 2, if you included receiver) needed to be online 
12:57 < jeremyrubin> This therefore might be a really scalable way to transfer money, especially if you had N parties with  a few coins of different value then you could combine them in different ways to make different payments amounts
12:58 < jeremyrubin> so overall i think it's really cool
12:58 < jeremyrubin> any questions?
12:58 < llfourn> I think pathcoin is an interesting theoretical result. I read it and  tried to see if we couldn't just do the same thing with a more lightning like approach but I failed.
12:58 < rgrant> this could work well in a net-settlement scheme where the parties communicate frequently.
12:58 < jeremyrubin> i think the core innovation is "1 of N sending"
12:58 < jeremyrubin> which does not work with any lightning result i am aware of
12:59 -!- John [~John@pool-162-84-182-26.nycmny.fios.verizon.net] has joined ##ctv-bip-review
12:59 < jeremyrubin> llfourn: +1 -- kinda like establishing a really high bound on a theorem, I think now that a 'shape' is out there for this, someone will think through a crapload of ux improvements
13:00 < jeremyrubin> maybe let's move on though unless someone has something good to throw in the mix?
13:01 < jeremyrubin> #topic - OP_TXHASH (30 Minutes)
13:01 < jeremyrubin> txhash is a proposal from roconnor to more generically encapsulate sighashing and signing into one spec
13:02 < jeremyrubin> it's goal is to make possible all of what CTV, APO, etc are trying to do in 1 spec
13:02 < jeremyrubin> and not need 'lots of little soft forks' if we want new behaviors down the line
13:03 < jeremyrubin> at a high level, the way it works is by having a ~20-30 bit "sighash flag" that computes and pushes to the stack a hash
13:04 < jeremyrubin> the bits select/deselect various fields to be included in the hash (which is not strictly defined, but could be a merkle tree, a flat hash, etc... just any generic commitment)
13:05 < jeremyrubin> this combines with CheckSigFromStackVerify to replace CheckSig in some contexts, whereby the txn hashing is separate from the checking of a signature against a msg
13:05 < jeremyrubin> notably, APO would be not done as a new keytype, just something you wouild do with CSFS and TXHASH
13:05 < jeremyrubin> CTV would be just a TXHASH and an <H> EQUALVERIFY
13:06 < jeremyrubin> does anyone have any questions? roconnor did i explain it sufficiently?
13:06 < roconnor> yes.
13:06 < rgrant> it seems the main question with this one is whether we're ready for recursive covenants.  that could take a while to sort out.
13:07 < jamesob> jeremyrubin: though the "TXHASH" part includes giving a flag that specifies the hash, right?
13:07 < jeremyrubin> jamesob: correct, for CTV it would be <flags for ctv-like> TXHASH <H> EQUALVERIFY
13:07 < jamesob> rgrant: I think the other issue is that txhash would have a larger on-chain footprint than CTV, since the same operation takes more bytes to specify in the scriptPubkey
13:08 < jeremyrubin> so maybe 3-4 bytes fo the flag, and 1 byte for equalverify 
13:08 < jeremyrubin> (3 bytes = 24 bits, +1 byte of push)
13:08 < llfourn> maybe CTV could be renamed to TXHASH_ALL_OUTPUTS_EQUALVERIFY :)
13:08 < roconnor> while I support recursive covenants, if the TXHASH-V0 design required the hash to cover the txhash flags themselves, recursive covenants would probably not possible without CAT.
13:10 < jeremyrubin> notably also rusty's proposal to do just pushtx / txdata like semantics would also be recursive. pushing the hash with the flags means the hashes are "NFTs" (input hashes not comparable to output hashes)
13:10 < rgrant> do we know how to reason through the "probably" part?
13:11 < jeremyrubin> to be fair, CTV is also a "probably" as is the current script system
13:11 < jamesob> I like the idea that users can specify the sighash that encumbers their coins, which is essentially what txhash gives you
13:12 < roconnor> jeremyrubin is right.  Schnorr sigs themselves seems to have again come very close to enabling recursive covenants.
13:12 < jamesob> though I am concerned with the amount of extra space on chain this would consume relative to e.g. bare CTV, which seems like it may well be very popular
13:12 < roconnor> maybe they did and we haven't figured it out yet.
13:12 < rgrant> use cases that i can forsee wanting can afford the 5 bytes.
13:12 < jeremyrubin> jamesob: I think a fair counter with the sentiment you're expressing is that txhash prevents small soft forks for new behaviors, but makes it likely we'd do them for efficiency 
13:12 < roconnor> TXHASH cannot be used for bare CTV in legacy script, if that's what you mean by bare CTV.
13:13 < jamesob> rgrant what if 40% of on-chain volume ends up CTV-style spends? that's a lot of bytes
13:13 < jeremyrubin> jamesob: yeah, over bare CTV you're talking a lot more overhead like 32-100 bytes depending on the use case
13:13 < jeremyrubin> since in bare CTV, the script is not a part of the txn data at all
13:14 < jamesob> jeremyrubin: that's a good point - future softforks that pack common operations into a single opcode certainly aren't out of the question
13:14 < roconnor> maybe I don't know what bare CTV is.
13:14 < jeremyrubin> CTV in a scriptPubKey directly 
13:14 < jeremyrubin> rather than in segwit
13:14 < rgrant> jamesob: true.  jeremyrubin: which use cases need 100 bytes?  well, maybe back to roconnor to ask if the other soft forks aren't contentious, what does the elegance buy us?
13:15 -!- tbw [~tbw@2a01:799:18e0:5d00:e5d6:4b2c:f1fe:f16] has quit [Quit: Client closed]
13:15 < jeremyrubin> congestion control is very sensitive to exact txn sizes since it changes what radixes are optimal
13:16 < jeremyrubin> so things like batch opened channels for example
13:16 < roconnor> every soft-fork is a huge endeviour no matter how contentious it is or isn't.
13:16 < jeremyrubin> vaults i think are less sensitive since if you need one you're "rich" and maybe don't mind paying?
13:16 < jeremyrubin> roconnor: that sort of feels a bit like a self-fulfilling prophecy
13:16 < rgrant> OIC, yes for congestion control just offering a UTXO, that would be a big difference.
13:17 < roconnor> Even when everyone is on board, soft-forks aren't easy to coordinate and pose significant risks.
13:17 < jeremyrubin> like a small soft fork is possible, but if we say all soft forks must be big, then the marginal add of more complexity in a sf makes them bigger changes from the getgo
13:17 < jeremyrubin> it seems like there can be >1 nash eq on soft fork complexity...
13:17 < roconnor> It's not a matter of the size; it is the nature of the process itself.
13:18 < roconnor> the technical nature.
13:18 < jamesob> why not do both txhash and CTV? we already know there is demand for CTV use-cases, and txhash would let people experiment 
13:19 < jeremyrubin> sure, 1 line of code could be very bad. I mean size e.g. how many hours you need to spend thinking about it to be confident
13:19 < jeremyrubin> clearly taproot > ctv in that regard, since you need to prove our schnorr algo correct
13:19 < rgrant> i would be in favor of a single TXHASH soft fork that included a developers-agreement to add a CTV soft fork at the next one instigated for some other reason.  also visa versa.
13:20 < rgrant> this way both on-chain bytes and elegance could be offered.
13:20 < roconnor> it's not the code changes I'm refering to here.  It is the process of going through a soft fork.  Defining a time where the change over happens.  Ensuring that nodes are upgraded on time.  Trying to ensure miners are not going to mine newly invalid blocks ... 
13:20 < jeremyrubin> there's definitely been some sentiments i've seen -- e.g. shinobi -- that if CTV is a stepping stone to "more" it's a NACK for him
13:21 < roconnor> this lays the floor on the difficulty of soft-forks.
13:21 < jamesob> both txhash and CTV seem pretty low-risk (I'm nearly convinced in CTV's case), though I am curious about how you'd approach avoiding quad-hashing with txhash... seems like with enough degrees of freedom in the hash flag, you'd be able to cook up a transaction that takes a while to validate
13:21 < jeremyrubin> sure. I guess it's a matter of -- sort of like an Amdahls law thing -- if you assess that to be particularly large or small compared to the review of the actual thing itself
13:21 < rgrant> roconnor: in prior meetings we agreed that to manage all that it's best to have things ready for a speedy trial by late summer.
13:21 < jeremyrubin> rgrant: roconnor wasn't in past meetings and that has no bearing on what we should do 
13:22 < jeremyrubin> but yes we did discuss the matters of practicality of such timelines
13:22 < roconnor> So even if the code changes are trivially correct and everyone is on board, soft forks are still a pretty big risk.
13:22 < rgrant> jeremyrubin: good point.  i meant it as an offer that we've thought about coordination issues and there is a route forward
13:23 < jeremyrubin> roconnor: i think this seems like the contention? I don't think that to be so, especially not via a signalled soft fork process
13:23 < jeremyrubin> hence the self fulfilling prophecy part, it's sort of a thing where if you beleive it to be true it becomes true?
13:23 < rgrant> roconnor: what's the risk though?  that someone blocks consensus?  it's worse not to try.
13:24 < jeremyrubin> jamesob: I think you can prove that the max amount of data a txhash can hash is bounded
13:24 < jamesob> roconnor: recall 2017 when we have CLTV/CSV activate without much ado... I think maybe we can go back to a state where uncontroversial, safe changes are deployed without so much craziness
13:24 < jeremyrubin> so it can be shown to not be worse than e.g. OP_HASH256
13:24 < roconnor> The risk is that  is that some users and miners fail to upgrade on time and miners mine on top of blocks without validation (as they are somewhat incentivised to).
13:24 -!- Guest66 [~Guest66@cpe-172-250-19-6.socal.res.rr.com] has quit [Quit: Client closed]
13:24 < jeremyrubin> but the bigger concern i have is that we then have to grow our precomputeddata caches to be e.g. 20x32 bytes big
13:25 < roconnor> I don't think it would end up like that.
13:25 < jeremyrubin> roconnor: what do you assess those odds to be in general, and also the impact of such an event (some users/ miners)
13:25 < rgrant> roconnor: that seems like a minimal risk.  not all miners have to validate for the system to function.  that's a node's job.  the rest of the network keeps them in line.  
13:26 < roconnor> the risks are low, but amoung the greatest that the bitcoin system faces.
13:26 < jeremyrubin> roconnor: orthogonal question, what about doing TXHASH but discouraging combinations that aren't 
13:26 < jeremyrubin> known what they're good for?
13:26 < jeremyrubin> maybe not a huge point to it...
13:27 < roconnor> those combinations aren't known until redemption time, and I don't think it makes sense to not relay based on redemptions.
13:27 < jeremyrubin> fair
13:27 < rgrant> roconnor: on biggest risk, i disagree.  brain drain to EVM programming, and bagholding in shitcoins, means that inaction incurs some permanent loss.
13:27 < jeremyrubin> I guess the question becomes somewhat w.r.t. sf safety is what is actually the magnitude of those risks and the probability of them happening
13:28 < jeremyrubin> like if they are particularly big and likely then i agree much much more conservatism is meritted 
13:28 < roconnor> It is a matter of opinion.  And I'm certainly not saying don't have soft forks.
13:28 < jeremyrubin> Have you seen any e.g. hypothetical actuarial tables on these risks?
13:28 < roconnor> Just make the soft-forks that we do have as useful as possible.
13:29 < prayank> roconnor: right every soft fork has risk and reward
13:29 < jeremyrubin> so one question i have in that regard is, say, from here it takes 2 years for TXHASH to be "ready" in that regard... where's the state of e.g. simplicity at?
13:29 < jamesob> controversial change should be given extreme scrutiny during the SF process... but changes like these seem relatively constrained and so easy to show safety. But anyway, I think this boils down to "flexibility vs. space efficiency" for me, and that's sort of tough to reason about
13:29 < jeremyrubin> Is this a constant endeavor to be 'more useful', can the dog ever catch the tail?
13:30 < roconnor> For example, while I'm pro-recursive-covenants, I think it makes sense to avoid including them here, just so it doesn't end up as a point of contention at this point in time, even though I'm not sure who would be contending against it.
13:30 < rgrant> roconnor: would you agree to support CTV in a later soft fork if it would save 2% of block space, and if TXHASH already was live?
13:30 < roconnor> for 2%. ... probably not.
13:30 < jamesob> roconnor: I don't think anyone is against recursive covenants per se - it's just that the proposals that tend to enable them end up being much harder to reason about, e.g. CAT
13:30 < rgrant> what's your N?
13:30 < jeremyrubin> rgrant: that's interesting because if soft forks are super risky then it'd be a bad tradeoff
13:30 < jeremyrubin> rgrant: cool thought experiment
13:31 < roconnor> idk.  50% probably yes.
13:31 < rgrant> jeremyrubin: nah, it would be an add-on to a soft fork that was already necessary.
13:31 < jeremyrubin> mod: i'm going to reorg the meeting -- we're now in "general discussion" and can keep chatting on this, we'll cap the meeting at 1:50 and talk about CTV/elements
13:31 < jeremyrubin> #topic General Discuss
13:32 < jeremyrubin> we can carry on discussing but this is a bit more meta :)
13:32 < rgrant> roconnor: i'd push very hard for the separate opcode if it would make a 7% difference.  
13:34 < rgrant> however, this may be a bad bargain, because the congestion control options would develop differently under TXHASH, and the empirical savings might not be there.
13:34 < jeremyrubin> i'd have to do the math out but I suspect that bare CTV makes a bigger impact than that since you lose about ~80 bytes let's say compared to TXHASH in Taproot, on a 200 byte txn.
13:34 < rgrant> roconnor: remember, no proposing an additional soft fork just for CTV.
13:35 < rgrant> *not (in this thought experiment) proposing
13:35 < jeremyrubin> rgrant: if i understand you correctly, you're saying what if we did TXHASH and CTV
13:35 < jeremyrubin> at the same time
13:35 < roconnor> I'm not myself strongly opposed to doing both TXHASH and CTV all at once.  Myself, I think it is boarderline and not worth it, but meh.
13:36 < rgrant> jeremyrubin: not at the same time.  do TXHASH first, so that we can observe how many bytes would be saved if CTV represented some of those contracts more succinctly.
13:36 < jeremyrubin> ah. there's some feedback loop stuff for sure.
13:36 < jeremyrubin> personally i just kind of think that the lowest risk path (if this is about mitigating technical risk) is to do subsets of functionality 
13:37 < jeremyrubin> e.g. CTV is a subset of TXHASH
13:37 < jeremyrubin> so CTV, then TXHASH shows us that the core of TXHASH is "safe"
13:37 < jeremyrubin> and that TXHASH is a bigger technical risk to bitcoin than the risk of a soft fork itself
13:37 < rgrant> roconnor: i think we're well into CISC land already, so i generally favor opcodes when they are: usefully advancing the state of the art; safe; and present acceptable long-term maintenance costs.
13:38 < jeremyrubin> that's why i'm interested to figure out some sort of risk categorization for these things.
13:39 < roconnor> Well I certainly judge the soft fork risk to be bigger than TXHASH.
13:39 < jeremyrubin> interesting!
13:39 < roconnor> right.  We seem to have very different judgements of the risks of soft forks.
13:39 < jeremyrubin> my anecdotal counter is that we spent wayyyy more time reviewing Taproot than we spent reviewing Speedy Triak
13:40 < jamesob> Downside of soft-fork risk seems limited: there's some operational screwup and a subsequent chainsplit. Open-ended changes to validation semantics seem much higher risk because the ability to respond is very limited
13:40 < jeremyrubin> jamesob: good point, also the response happens in a period of weeks, whereas validation semantics are a cost forever
13:40 < jamesob> (I mean I'm not downplaying how much a chainsplit would suck, but having a validation rule that allows a semi-permanent DoS is way worse)
13:40 < rgrant> jamesob: +1
13:41 < jeremyrubin> i've seen it proposed somewhere that we do more 'pointless soft forks' just so that we can actually improve / de risk our soft forking process
13:41 < roconnor> I again I judge the risk of the process of the soft fork, getting everyone upgraded on time, to be risker than taproot or the speedy trial code itself.
13:41 < jeremyrubin> but some people think that that we don
13:41 < jeremyrubin> *dont get experience with it as a feature not a bug
13:41 < roconnor> but that process is part of the soft-fork process and cannot be mitigated.
13:41 < roconnor> other than by having fewer soft-forks.
13:42 < jamesob> roconnor: what is the concrete failure you're worried about? someone who uses a new opcode losing a bunch of money?
13:42 < roconnor> chain splits.
13:42 < rgrant> roconnor: i think it's legitimate that if there were tons of soft forks that there would be miner burn-out on upgrading.
13:42 < jeremyrubin> hmmm i guess to steelman your perspective, you can prove that taproot is correct, but you can't prove a soft fork process correct since it uses user behavior 
13:43 < jeremyrubin> so processes where a user can fuck something up are riskier than 'pure' systems
13:44 < prayank> Which topic are we discussing right now?
13:44 < jeremyrubin> prayank general discussion
13:44 < jamesob> how would a chainsplit happen during activation? if you're a user running your own consensus rules, you're not at risk of a few miners being late to upgrade
13:44 < roconnor> the risk is to users who haven't upgraded.
13:44 < prayank> jeremyrubin: Thanks
13:45 < jamesob> (I ask "how" not because I can't see how one would happen, but I want to hear your specifics about who is impacted)
13:45 < rgrant> one game-theoretic way to counter miner burnout would be to ask miners to do one or two seasonal upgrades per year, to lower the risk of them being surprised.  if these always happened, they would have processes in place to upgrade.
13:45 < jeremyrubin> jamesob: one risk is that your mempool has a bad txn in it after the new rules and you add that txn to your block, even if you're upgraded. but we do handle that kind of stuff in the code currently.
13:45 < jamesob> so in your nightmare scenario, an unupgraded miner mines a block that fails the new softfork rule and a network split happens
13:46 < roconnor> and the next miner does an optimistic mining on top of it.
13:46 < roconnor> i.e. mining without validation.
13:47 < jamesob> but if the majority of miners _have_ actually upgraded, the unupgraded chain will be reorged out after some (probably short) period of time
13:47 < jeremyrubin> mod: ~3 mins on this left :o
13:47 < roconnor> if.
13:47 < rgrant> roconnor: non-upgraded users don't care if the block validated according to old or new rules, because they're only depending on old rules.
13:48  * jeremyrubin this is spartaaaaa
13:48 < jamesob> so if the majority of miners have lied about signaling for update, who loses here? the miners who upgraded genuinely?
13:48 < jamesob> and for what period of time?
13:48 < jamesob> I'm just trying to account for the risks precisely here
13:49 < jeremyrubin> it also strikes me that miners could comissively do a secret soft fork to screw over honest miners in the same way
13:49 < jeremyrubin> so im not sure if it's really more than 'bad behavior => bad outcome'
13:49 < jeremyrubin> at least during a SF there are "more eyes on it"
13:50 < jamesob> like, in any case, users who are using their own validation rules won't have funds loss AFAICT => manageable risk
13:50 < roconnor> I'm pretty sure everyone loses if there is a lot of waffling about whether miners ought to mine on the old rules or the new rules.
13:50 < jeremyrubin> this has been a super stimulating convo
13:50 < jeremyrubin> but sadly
13:50 < jeremyrubin> #topic: emulating CTV on Liquid
13:50 < jamesob> wompwomp
13:50 < jeremyrubin> this is thanks to AJ, you can emulate CTV on Liquid (maybe?) 
13:51 < jeremyrubin> Neither of us actually know how CT works in Elements
13:51 -!- John [~John@pool-162-84-182-26.nycmny.fios.verizon.net] has quit [Quit: Client closed]
13:51 < roconnor> I guess I ought to stay for this part.
13:51 < rgrant> jeremyrubin: i saw that, but it seemed to use a lot of bytes.  so use cases would be rather forced.
13:51 < jeremyrubin> but it seems with whatever the newest upgrade is, it is possible
13:51 < jeremyrubin> link here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019851.html
13:51 < jeremyrubin> it's not an exact match but 'close nuff' to build most use cases
13:52 < jeremyrubin> if the CT parts actually works though
13:52 < jeremyrubin> roconnor: does the CT part make some hash cycle? or is it all witness-y uncomitted data?
13:52 < roconnor> Not sure that CT plays much of a role here.  They are just blinded values.
13:53 < jeremyrubin> well i guess i could just see it creating some kind of hash cycle or mutable data that messes something uop
13:54 < roconnor> in practice you will want to probably add the RANGEPROOF and maybe SURJECTIONPROOF reflection codes as well for complicated reasons.
13:54 < jeremyrubin> i have code for CTV in Miniscript
13:54 < jeremyrubin> the fragment generation could be adapted to AJ's code for elements-miniscript
13:54 < roconnor> There certainly isn't any consensus rules that would cause a hash cycle.
13:54 < jeremyrubin> roconnor: cool
13:54 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has left ##ctv-bip-review []
13:54 < roconnor> My weak understanding is that there wouldn't be any protocol rules either, though I'm not certain.
13:55 < jeremyrubin> ah i guess part of it is the blinding requires fresh entropy
13:55 < jeremyrubin> so it's not clear who you need to send what to for that / compilation is not-deterministic unless your entropy source is a seed passed in?
13:55 < jeremyrubin> I guess the other question is if people actually care (sorry roconnor) to build apps like vaults on Liquid
13:56 < roconnor> There is some hack to use the rangeproof to as a comms channel to transmit their half of the DH key exchange to the receipiant that I don't quite understand.
13:56 < roconnor> but I'm doubtful it would pose a problem.
13:56 < jeremyrubin> given that there's not all that much capital on liquid, it's not really where people look for strong custody tools
13:56 < jeremyrubin> and wrt scalability / congestion control it's already a L2
13:56 < jeremyrubin> and for Lightning there's (correct me if im wrong) no Liquid Lightning network
13:56 < jeremyrubin> are DLCs happening on liquid?
13:57 < jamesob> rational or not, I know there are at least a few high-value bitcoin users who don't have the bandwidth/interest in experimenting on liquid but would definitely make use of more practical vaulting strategies
13:57 < roconnor> I don't have answers to these questions.  But since Liquid is multi-asset, at least some of these CTV uses sound compelling.
13:58 < rgrant> jamesob: +1
13:58 < jeremyrubin> i guess my feeling would be that CTV being doable on liquid as a precursor to CTV being a thing for Bitcoin presupposes generating much stronger demand for Liquid... which is a weird burden for a BIP to bear to me?
13:59 < jeremyrubin> i think liquid is itself a strong example, liquid fed could use CTV well, but there aren't layer 3's built on liquid already that could use CTV for their federation wallets
13:59 < roconnor> Dmitry's entire Asset-based lending on liquid reads like a giant CTV based covenant.
13:59 < jeremyrubin> mod: 1 min remaining
14:00 < roconnor> and that was designed even before the new opcodes were available.
14:00 < prayank> Liquid doesn't even need CTV with all the opcodes that were added recently afaik. Signet (bitcoin) would be better for CTV experiments IMO.
14:00 < rgrant> jeremyrubin: i'd separate proof-of-demand from proof-of-implementation.  if there were Liquid devs available, and CTV was implemented there, i think that could be meaningful to some people.  sounds like a weird monopoly tax, though.
14:00 < roconnor> basically it uses CTV like operations to commit to a payback scheme with intrest for the lending of assets given collateral of another asset.
14:01 < jeremyrubin> last words?
14:02 < jeremyrubin> thanks everyone for attending, a lot of great food for thought. see you in 2 weeks (or sooner).
14:02 < jeremyrubin> #endmeeting
14:02 -!- roconnor [~roconnor@coq/roconnor] has left ##ctv-bip-review [Konversation terminated!]
14:03 -!- prayank [~andr0irc@45.64.9.48] has quit [Quit: irc thread exit]
14:05 < rgrant> thanks for organizing, jeremyrubin.  bye!
14:05 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...]
14:06 -!- fiatjaf [~ircisnota@2804:296c:2100:343b:1ac0:4dff:fef3:df53] has quit [Quit: Client closed]
14:43 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
15:14 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
15:21 -!- phasnox [~phasnox@191.99.79.16] has joined ##ctv-bip-review
16:25 -!- psztorc [~asus@12.107.181.2] has quit [Quit: Leaving]
18:18 -!- Guest36 [~Guest36@190.63.235.74] has joined ##ctv-bip-review
18:28 -!- Guest36 [~Guest36@190.63.235.74] has quit [Quit: Client closed]
19:49 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 250 seconds]
21:37 -!- phasnox [~phasnox@191.99.79.16] has quit [Ping timeout: 256 seconds]
21:46 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
22:19 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 240 seconds]
22:57 -!- _aj_ [aj@user/aj/x-5857768] has joined ##ctv-bip-review
--- Log closed Wed Feb 09 00:00:54 2022