--- Log opened Tue Mar 08 00:00:19 2022
02:06 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
11:53 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds]
11:54 -!- luke-jr [~luke-jr@user/luke-jr] has joined ##ctv-bip-review
11:55 < jeremyrubin> Meeting start in 5!
11:55 -!- mjdietzx [sid527079@2a03:5180:f:3::8:ae7] has joined ##ctv-bip-review
12:00 < jeremyrubin> #startmeeting
12:00 < kanzure> hi
12:00 < jeremyrubin> gm frenz
12:00 < jamesob> hi
12:01 < jeremyrubin> topics for today: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020081.html
12:01 < michaelfolkson> hi
12:01 < jeremyrubin> #topic: 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
12:02 < jeremyrubin> sapio on master should be working with Taproot https://github.com/sapio-lang/sapio
12:02 < jeremyrubin> consider this to be super duper unstable since we're using alpha releases of custom patched versions of things
12:02 < jeremyrubin> so surely things will be broken!
12:02 < jamesob> jeremyrubin: easy place to see the whole taproot changeset?
12:03 < jeremyrubin> jamesob: not in particular :/
12:03 < jeremyrubin> most of the changes for taproot are just ingesting the newest versions of rust-miniscript and rust-bitcoin
12:03 < jeremyrubin> so the best effort on review would be to look at those
12:03 -!- Guest63 [~Guest63@217-197-184-106.pool.digikabel.hu] has joined ##ctv-bip-review
12:03 < jamesob> gotcha
12:03 < jeremyrubin> for sapio-specific changes, i would look in sapio/src/contract/compiler/mod.rs
12:04 < jeremyrubin> because I rewrote the logic to build a taproot tree out of sapio guard clauses which is kinda cool
12:04 < jeremyrubin> the rust-bitcoin/rust-miniscript stuff could use your help though
12:04 < jeremyrubin> sanket1729 may be awake & here?
12:05 -!- Guest91 [~Guest91@178-215-26.dynamic.cyta.gr] has joined ##ctv-bip-review
12:05 < jeremyrubin> but i've been reviewing the PRs in those repos and finding a fair amount of bugs by testing the sapio stuff
12:05 < jeremyrubin> so basically doing testing of flows, finding bugs, then passing feedback up the stack
12:05 < jeremyrubin> Sapio's use of these things is relatively straightforward
12:05 -!- Guest91 [~Guest91@178-215-26.dynamic.cyta.gr] has quit [Client Quit]
12:06 -!- Guest91 [~Guest91@178-215-26.dynamic.cyta.gr] has joined ##ctv-bip-review
12:08 < jeremyrubin> the next steps will be to wait for release on the deps, then rebase the sapio/ctv specific changes on top, then party
12:08 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review
12:08 < rgrant> hi
12:08 < jeremyrubin> hi
12:09 < jeremyrubin> i guess we don't have sanket1729 or anyone super involved in rust-bitcoin here... 
12:09 < jeremyrubin> https://github.com/rust-bitcoin/rust-miniscript/pull/301
12:09 < jeremyrubin> I think if you're looking for a small thing to work on, downloading this patch and building an example app / PSBT miniscript flow is pretty good for helping out
12:10 < jeremyrubin> the sapio stuff should be working too, so if people try out examples and have problems LMK. I still need to e..g re-try the tutorial from last week myself with the master 
12:10 < michaelfolkson> https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/mod.rs presumably?
12:11 < jeremyrubin> presumably for what?
12:11 < jeremyrubin> if you mean for examples, I meant https://rubin.io/bitcoin/2022/03/04/london-tutorial/ + the plugin_example directory 
12:11 < jeremyrubin> so you can try the wasm blobs 
12:11 < michaelfolkson> Looking for this -> sapio/src/contract/compiler/mod.rs
12:12 < michaelfolkson> [20:03:52]  <jeremyrubin> for sapio-specific changes, i would look in sapio/src/contract/compiler/mod.rs
12:12 < jeremyrubin> https://github.com/sapio-lang/sapio/blob/master/sapio/src/contract/compiler/mod.rs
12:12 -!- Guest91 [~Guest91@178-215-26.dynamic.cyta.gr] has quit [Quit: Client closed]
12:12 < michaelfolkson> Ah gotcha, two Sapio dirs, thanks
12:13 < jeremyrubin> sapio-contrib is a dir for just random examples 
12:13 < jeremyrubin> examples is a dir for application examples
12:13 < jeremyrubin> plugin_examples is a dir for WASM-able plugin examples
12:13 < jeremyrubin> confusing, eh
12:13 < jeremyrubin> for example, if jamesob made his vault program in Sapio, he could do a binary app in examples 
12:14 < jeremyrubin> some of the example code is pretty low quality though, so it's also a decent project to try polishing that stuff up
12:14 < jeremyrubin> https://github.com/sapio-lang/sapio/blob/072b8835dcf4ba6f8f00f3a5d9034ef8e021e0a7/sapio/src/contract/compiler/mod.rs#L338 is where the main taproot logic is
12:15 < jeremyrubin> as well as https://github.com/sapio-lang/sapio/blob/072b8835dcf4ba6f8f00f3a5d9034ef8e021e0a7/sapio/src/contract/abi/object.rs#L283 for PSBT stuff
12:15 < jeremyrubin> writing more stuff like https://github.com/sapio-lang/sapio/blob/master/integration_tests/tests/integration_test.rs is super welcome, since then we're actually checking these things work end-to-end
12:16 < jeremyrubin> Also: there is no MuSig support yet
12:17 < jeremyrubin> but i think that's a general problem, and not something we can solve with Sapio directly
12:17 < jeremyrubin> However, if someone wants to work on it
12:17 < jeremyrubin> https://github.com/sapio-lang/sapio/tree/master/ctv_emulators/src
12:17 < jeremyrubin> making it work *just* for the CTV Emulator Servers would be incredible
12:17 < jeremyrubin> because then you can get single-signature CTV emulation 
12:17 < jeremyrubin> with a N party protocol
12:18 < jeremyrubin> and the client can act as the hub for negotiating this
12:18 < jeremyrubin> but sadly theres like no psbt support for this stuff yet
12:18 < jeremyrubin> so you'd need to write a custom protocol for doing it
12:18 < jeremyrubin> if anyone is interested, LMK
12:19 < michaelfolkson> Taproot PSBT, MuSig is coming (for example in Core) but will take time
12:20 < jeremyrubin> yeah that's why for Sapio we can't support automated tooling for it yet
12:20 < michaelfolkson> Right
12:20 < jeremyrubin> #topic 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
12:20 < jeremyrubin> jamesob wrote a lovely post on this stuff recently
12:21 < jeremyrubin> at a recent event i also gave a presentation on it & it recieved a pretty warm reception by a number of developers, once they understood the problem space better. I'll start by describing what it is, and we can take questions after
12:22 < jeremyrubin> Basically, sponsor's goal is to make protocols agnostic to how their fees are paid for.
12:22 < jeremyrubin> Currently, you have to design a protocol with fees deeply in mind, since you can get attacked if it's not there
12:22 < jeremyrubin> E.g., a DLC for 2 parties must include some extra outputs / flexible signature in case you can't get the transaction mined since the feerate you picked was too small at close
12:23 -!- Guest89 [~Guest89@dsl-74-83-84-75.fuse.net] has joined ##ctv-bip-review
12:23 < jeremyrubin> sponsors philisophically says that transaction "intents" should be able to be feeless/fully fixed, and a fully third party agent should be able to increase it's priority by "bribing" miners externally to that txn itself
12:24 < rgrant> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
12:24 < jeremyrubin> sponsors says that all protocols should be designed to be progress friendly, that is, that *any* transaction happening should be good, if it is one that can happen
12:24 < jeremyrubin> e.g. Eltoo has a ratchet in it
12:25 < jeremyrubin> so you are happy in Eltoo to increase the ratchet, but the ratchet getting "stuck" at state N when it could go to N+1 is Bad™
12:25 < jeremyrubin> Does anyone have any questions so far?
12:26 < jeremyrubin> Sponsors is a concrete BIP of sorts. Meaning we know, loosely, how to implement something for this and theres code you could play with. It's not perfect though, because we want for sponsors to one day be in addition to better RBF rules and Package Relay. But conceptually, for it to work, there must be a consensus change.
12:27 -!- Guest138 [~Guest138@2603-8001-2601-c40a-4d66-1a2c-d7a2-de2e.res6.spectrum.com] has joined ##ctv-bip-review
12:27 -!- Guest138 [~Guest138@2603-8001-2601-c40a-4d66-1a2c-d7a2-de2e.res6.spectrum.com] has quit [Client Quit]
12:28 < jeremyrubin> The consensus rules are very simple: for each transaction T in a block: insert(targets, sponsoring(T)). for transaction in a block: delete(targets, T). check that targets is empty
12:28 < jeremyrubin> a transaction can have multiple targets it is sponsoring
12:28 < jeremyrubin> the check that the set is empty confirms all dependecies are satisifed
12:29 < jeremyrubin> sponsoring pulls the targets out of a specially formatted OP_RETURN type thing
12:29 < jeremyrubin> because it's in the TXID space, this prevents loops
12:29 -!- Guest51 [~Guest51@d118-75-81-3.try.wideopenwest.com] has joined ##ctv-bip-review
12:30 < jeremyrubin> For policy, we apply stricter rules: 1) only allow 1 target per thing 2) don't allow sponsoring sponsoring transactions 3) no children of sponsoring transactions 4) no unconfirmed parents (iirc) 5) must be small transactions, replacable 6) only 1 sponsor per transaction
12:30 < jeremyrubin> there might be some other restrictions too, but those are things we can hone in on to meet the goal
12:31 < jeremyrubin> the goal is: you can always replace a sponsoring txn with a better sponsoring txn to drive progress forward on a protocol 
12:31 < jeremyrubin> these limitations help ensure that goal
12:31 < jeremyrubin> because it's a brand new mechanism, we are free to make these things not usable for other purposes
12:31 < jeremyrubin> eventually though, with better mempool code, we can lift the restrictions.
12:31 < jeremyrubin> (maybe)
12:32 < jeremyrubin> but the goal of sponsors is to work well enough
12:32 < michaelfolkson> Would you use RBF if possible and only use sponsors when RBF isn't an option?
12:32 < jeremyrubin> OK, now Q&A time:
12:32 < jeremyrubin> michaelfolkson: I think protocol devs might wish to get rid of RBF
12:33 < jeremyrubin> RBF is super hard to work with, so "when RBF is possible" might be rare
12:33 < jeremyrubin> e.g. exchnages don't like RBF-ing because customers like being able to spend from unconfirmeds
12:33 < jeremyrubin> and they get support tickets
12:33 < michaelfolkson> "because we want for sponsors to one day be in addition to better RBF rules"
12:33 < jeremyrubin> cold storage doesn't like RBF-ing because re-signing could be very inconvenient 
12:34 < jeremyrubin> ah, the better RBF rules would be for things like Eltoo
12:34 < jamesob> michaelfolkson: the replacement semantics for sponsors might be much simpler than RBF because sponsors exist solely to subsidize feerate
12:34 < jeremyrubin> you have ratchet state N+1, and I've tried to pin you with state N-1
12:34 < jamesob> s/simpler/easier to work with
12:34 < jeremyrubin> you'd like to replace N-1 and bump it to the top
12:35 < jeremyrubin> but you might have to drive N-1 through with a sponsor, and then broadcast N+1 later
12:35 < jeremyrubin> so we want better RBF rules, but we want sponsors to allow us to always make progress
12:35 < jeremyrubin> jamesob+1
12:35 -!- Guest51 [~Guest51@d118-75-81-3.try.wideopenwest.com] has quit [Quit: Client closed]
12:35 < jeremyrubin> also if you get rid of flexible transaction hashes, RBF pinning is a lot harder
12:36 < jeremyrubin> Imagine Eltoo with a +1 CSV minimum on next spends, and SIGHASH_ALL
12:36 < jeremyrubin> now Eltoo is "pinning free" and RBF-free
12:36 < jeremyrubin> so now a RBF rule for sponsor + Eltoo Ratchet can always make progress and N+1 can replace N-1
12:37 < jeremyrubin> but with flexible Txs (e.g. add input for fee), you can hit pinning things and it's hard to clean up
12:38 < jeremyrubin> An example of why this is hard to do without sponsors:
12:38 < jeremyrubin> assume a new rule that is allow RBF of anything to increase feerate
12:38 < jeremyrubin> broadcast 3000 100kb txns feerate 100 sat/vb
12:38 < jeremyrubin> mempool now only has these txns
12:38 < jeremyrubin> RBF with 3000 200b txns feerate 101 sat/vb
12:38 < jeremyrubin> mempool absolute fee is now tiny
12:38 < jeremyrubin> so replace by feerate allows you to cheaply flush peoples mempool of all txns
12:39 < jeremyrubin> sponsors cheats on this by making sponsor txns have to be small and no child spends and stuff
12:40 < jeremyrubin> anyhow, we need to move on topic wise but
12:40 < jeremyrubin> the punchline is related to the next topic, which is that anchors/rbf and the like are all kinda hacky in the protocol for the thing you're building
12:40 < jeremyrubin> whereas sponsors is hacky in the bitcoin protocol (kinda?), but makes the protocols un-hacky
12:41 < jeremyrubin> so it's a good candidate for a unanimous improvement (except ptodd, who i dont think anyone cares about his gripe from the convos i had) for all protocol users
12:42 < jeremyrubin> it's also conceptually OK, insofar as there exists a similar transaction graph that could exist to what sponsors is doing, so we dont need to worry it introduces some sort of inherently novel behavior to bitcoin
12:42 < jeremyrubin> #topic 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
12:42 < jeremyrubin> jamesob want to take the floor?
12:42 < michaelfolkson> Sounds like sponsorship would benefit from being fleshed out in a BIP, I need to read more though before I have a view on it. Seems bold
12:42 < jeremyrubin> michaelfolkson: it's been a bip for like 2 years :p
12:42 < michaelfolkson> Oh really? Number? Haha
12:43 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
12:43 < jamesob> jeremyrubin: sadly have a conflicting meeting so only able to pay half attention at the moment
12:43 < jeremyrubin> i didn't get one assigned
12:43 < jeremyrubin> OK, i can do it and you can tell me if I'm wrong
12:43 < jamesob> +1
12:43 < jeremyrubin> so basically jamesob likes vaults a lot and works on custody stuff 
12:44 < jeremyrubin> however, he thinks that vault devs have been largely unpragmatic
12:44 < jeremyrubin> as such, jamesob doesn't care about super fancy recursive vaults or anything
12:44 < jamesob> it's true, i'm a simple man
12:44 < jeremyrubin> he just wanted to design something that minimally changes current cash flows from cold to hot wallets and improves status quo
12:45 < jeremyrubin> he also doesn't like wild EDSLs in rust, he likes python that you can read the whole thing in 5 mins
12:45 < jamesob> jeremyrubin my new spokesman
12:45 < jeremyrubin> so he came up with a very basic vault/unvault combo that maps onto the "undo send" contract in sapio
12:46 < jeremyrubin> an undo send is essentially a script that says: allow me to send money to a target T, but if I regret it, let me be able to claim it back for S seconds before T can spend it
12:46 < jeremyrubin> for CTV vaults, T must be pre-determined
12:47 < jeremyrubin> however, this isn't a huge deal because if T could be dynamically determined it's equivalent to a fixed-T just sending to T' in a new txn (and maybe more efficient, depending on your covenant)
12:47 < jeremyrubin> As such, jamesob proposes that you want to deposit coins into a thing whereby it can:
12:48 < jeremyrubin> 1) be sent to the vault
12:48 < jeremyrubin> 2) the vault can be "popped"
12:49 < jeremyrubin> 3) if the pop was not desired, have N seconds to do a predetermined transaction that moves it to a secure backup address
12:49 < jeremyrubin> 4) if the pop was desired, after N seconds, allow a hot key to spend it
12:49 < rgrant> sounds like most of the value of vaults is in that specification
12:49 < jeremyrubin> jamesob claims that this is like... 80% of the value
12:49 < jeremyrubin> rgrant: yeah
12:50 < jeremyrubin> because what it enables is your cold backup procedure to be really freaking annoying / shard coins to N backups with M-of-P multisigs, etc.
12:50 < jeremyrubin> something you never want to do
12:50 < jeremyrubin> and you hot wallet to be e.g. a simple single sig/multisig
12:50 < jeremyrubin> but you don't need to authorize from your annoying cold backup to send to hot
12:51 < jeremyrubin> and jamesob claims that for a lot of deployed custody things, this will be a huge improvement since they don't care as much about fancy recursion and stuff if they can monitor/respond, but monitor/respond is a big deal
12:51 < jeremyrubin> *not a big deal
12:52 < jeremyrubin> also in the flow jamesob gives, there are some optimizations you can do / safety things to make it so you can always go directly to cold backup, in case you're worried you might have a bug in CTV that stops you from spending
12:53 < jeremyrubin> Related to sponsors, this design requires you to use CPFP (or overpaying/estimating fees?). But it would be nicer if we could separate intent (vault) from how you pay for it (sponsors)
12:53 < jeremyrubin> how'd i do jamesob?
12:53 < jeremyrubin> what do people think of vaults like this?
12:54 < rgrant> sponsors is definitely nice for vaults.  seems like a useful vault.
12:54 < michaelfolkson> This is similar to Bryan's from a couple of years ago? Minus the sponsors?
12:54 < jeremyrubin> personally, I think jamesob did a great job opening my eyes to being even simpler. working on vaults devs often kinda say "i want moar complexity than CTV can do" and i've been showing how you can get all sorts of nice behaviors with just CTV! but what jamesob did a nice job of showing was "fuck nice behaviors, simple is really good"
12:55 < jeremyrubin> michaelfolkson: nope, kanzure and i both did recursive vaults
12:55 < jeremyrubin> jamesob's vault is simiular to a N=1 of kanzure or my vault proposal
12:55 < jeremyrubin> i.e. just the last step
12:56 < jeremyrubin> https://github.com/kanzure/python-vaults/
12:57 < jeremyrubin> i think it's nice that people can build more sophisticated vaults, but as rgrant said, "most of the value of vaults is in that specification"
12:57 < jeremyrubin> especially when it comes to deploying, this seems to be something that is a nice fit for what exchanges are already doing
12:58 < jeremyrubin> one thing that would be fun to do jamesob would be to make a faucet where you send people vaults to a hotkey they specify and you claw it back
12:58 < jeremyrubin> could start testing this out on signet 
12:59 < jeremyrubin>  mod: 1 min-ish remaining, can do some more if ppl have other qs since we started late
13:00 < jeremyrubin> #topic 4) What the heck is everyone talking about on the mailing list all of the
13:00 < jeremyrubin> sudden (30 minutes)
13:01 < jeremyrubin> so since the last month or so there seems to be a tangible... increase in activity on bitcoin-dev
13:01 < jeremyrubin> seems like people are really starting to think about inventive bitcoin primitives differently, which is great to see
13:02 < jeremyrubin> this is mostly intended to be Q&A/discussion format, so have at it...
13:02 < jeremyrubin> i do have a prepared remark to share from zmn, since his timezone is off
13:02 < jeremyrubin> Both `OP_EVICT` and `OP_FOLD` do not introduce anything more powerful than strict data totality (always provably terminating even across transactions).
13:02 < jeremyrubin> `OP_TLUV` in replace mode, in combination with `OP_CAT`, introduces data-codata totality which is just a shade below partiality and full Turing-completeness (each step terminates within a transaction, but may have infinite steps across multiple chained transactions).
13:03 < jeremyrubin> I think it is helpful to discuss generality vs specificity: a general language would have longer scripts (basic info theory, more general means more possible things to say means words have to be longer in order to say them) while a specific language would have shorter scripts but require a softfork each time we think of a new application.
13:03 < jeremyrubin> Specific language is shorter is cheaper and thus more palatable to end-users, General language requires fewer softforks (we hope) and thus more palatable to devs.
13:03 < jeremyrubin> `OP_CTV`, `OP_EVICT` are to the specificity side of the debate, while `OP_CSFS`, `OP_TX`/`OP_TXHASH` are to the generality side of the debate.
13:03 < jeremyrubin> An idea is to have a general language, then identify common patterns and make specific opcodes for those to shorten the SCRIPT.
13:03 < jeremyrubin> This can be interpreted as the "jet" concept in Simplicity, where Simplicity is a very general language (i.e. does not have `CHECKSIG` or `HASH160` built-in but you have the tools to build those) and then some standard series of code is identified by the compiler, which signals the interpreter to use a particular C implementation (the "jet") to
13:03 < jeremyrubin> speed up the execution of that code.
13:04 -!- zmnscpxj [~zmnscpxj@136.158.35.64] has joined ##ctv-bip-review
13:04 < jeremyrubin> A "jet" in the generality vs specificity debate would then be some general code that is later identified as common and then we implement a specific opcode for it.
13:04 < jamesob> here he is, zmn himself
13:04 < jeremyrubin> But if jets are consensus-critical we need a softfork anyway (obviating the advantage of generality) and if jets are not consensus-critical / relay-only then people will not really use jets as they do not get the cost advantage, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020076.html
13:04 < jeremyrubin> Could still argue for a middle-ground where we start with a general language, then "prove" the specific application as being useful enough that a softfork to add an opcode/conensus-critical-jet for the specific application.
13:04 < jeremyrubin> But we already have applications for `OP_CTV` and `OP_EVICT` soooooooooooooooooo......
13:04 < jeremyrubin> ty zmnscpxj for being here 🙏
13:04 < rgrant> a lot of it is avalanche from the initial objections to covenants that OP_CTV brought out as a question
13:04  * zmnscpxj waves
13:05 < jeremyrubin> ive just shared your comment above
13:05 < michaelfolkson> Just reading the above....
13:05 < zmnscpxj> thx thx
13:05 < michaelfolkson> So why the focus on strict data totality? What proposals introduce more power than that?
13:06 < jamesob> not sure if we're into amorphous response territory yet, so stop me if not, but I think if a lot of devs' response to CTV was "yeah but who's been experimenting with it," it's fair to reapply that - in general the onus is on people to show compelling uses before we throw super general stuff into consensus
13:06 < michaelfolkson> Power/danger
13:06 < jeremyrubin> zmnscpxj: im a big fan of your using hash chains as peano numbers
13:06 < jamesob> and being verbose on chain has not been looked on favorably in the past, for good reason
13:07 < zmnscpxj> michalefolkson: `OP_TX`, in combination with `OP_CAT`, would introduce data+codata totality, which is just a shade below partiality / Turing-completeness
13:07 < zmnscpxj> michaelfolkson: you can prove that each individual step terminates, but the overall computation could potentially not terminate (xref. drivechains-over-covenants)
13:08 < jeremyrubin> I think there's a decent perspective roconnor has shared to me, which is "don't send to turing complete scripts even if you can"
13:08 < zmnscpxj> jeremyrubin: that was a surprise to me as well, thought I would need `OP_ADD` and friends enabled
13:08 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...]
13:08 < jeremyrubin> so e.g. a Miniscript interpreted on a TC interpreter is still ok
13:09 -!- rgrant [~rgrant@user/rgrant] has joined ##ctv-bip-review
13:09 < michaelfolkson> Drivechains over covenants I can't comprehend (but I'll take your word for it that computation could potentially not terminate) :)
13:09 < jeremyrubin> lemma: if you can prove a program is halting, the program is not "turing complete" (turing complete describes machines not programs anyhow)
13:09 < jeremyrubin> i think the main issue is our ability to produce tooling for more complex things
13:09 < zmnscpxj> jeremyrubin: how sure are we that Miniscript compiler preserves the semantics of the Miniscript code when it translates down to the TC language? (other than being written by sipa and apoelstra)
13:09 < jeremyrubin> zmnscpxj: yep! would need a formally proven one
13:09 < jeremyrubin> and even then, is your prover correct, etc
13:10 < jeremyrubin> but also we don't have a proof that bitcoin script is not TC today :)
13:10 < zmnscpxj> ah crap, turtes all the way down
13:10 < jeremyrubin> In Sapio, we have continuation clauses
13:10 < jeremyrubin> https://learn.sapio-lang.org/ch03-02-finish.html
13:10 < jeremyrubin> these in theory you can model any covenant in
13:11 < zmnscpxj> jeremyrubin: proof by construction: SCRIPT cannot impose particular patterns on the transaction output script and has no unbound looping construct, so by construction, it cannot recurse
13:11 < michaelfolkson> The multiple chained transactions would need to all be in the same block to pose a termination concern right?
13:11 < jeremyrubin> but there's an issue of essentially: 1) generate a transition function you would like 2) compile it into a script covenant 3) request the transition you want 4) produce a satisifaction of the script covenant 5) prove the transition function *is* what you wanted/secure
13:11 < jeremyrubin> right now sapio continutations are just multisigs, so you can escape
13:12 < jeremyrubin> but for things where you're locked in it is harder
13:12 < jeremyrubin> and the 5 steps above are pretty hard to reason about
13:12 < zmnscpxj> michaelfolkson: not necessarily, it is just more power than we have ever handed out to Bitcoin UTXOs before, so it pays to be careful.  IMO
13:12 < jeremyrubin> there is a subset of covenants that are "easy to satisfy". CTV is like this because the satisfaction is just the transaction itself.
13:12 < jeremyrubin> but you could imagine CTV + some felxibility in which outputs you cover, it might be hard to figure out which subset should be covered
13:13 < zmnscpxj> jeremyrubin: multisig escape hatch is always better, so if you have a bug in your contract you get everyone to agree to get out
13:13 < jeremyrubin> so I think "how easy is this to produce witnesses that the transaction represents a valid state transition" is another good question for all these things
13:13 < jeremyrubin> some covenants can be quite hard to do that for
13:13 < jeremyrubin> (e.g. satisfy this garbled circuit)
13:14 < jeremyrubin> i think anyone who wants sophisticated covenants should prototype it as a multisig federation and make it work in Sapio as a continuation clause
13:15 < zmnscpxj> smart contracts unchained
13:15 < jeremyrubin> it seems like the most reasonable way to allow experimentation + getting decent tooling
13:15 < jeremyrubin> but you have to BYO satisifier logic for all things reachable, so you should be careful to make something that only returns valid transitions?
13:15 < michaelfolkson> I guess I'm just thinking a block is a separate standalone object in terms of verification. Once it is verified once that is the end of verification. Hence to pose a termination concern you'd need chained transactions in the same block
13:16 < jeremyrubin> a lot of these are things that are less an issue for verification, more an issue for behavior 
13:16 < jeremyrubin> for example, imagine a covenant that pays out if your immediate ancestors were all empty blocks?
13:16 < zmnscpxj> michaelfolkson: each transaction is a step, so if each step terminates (due to data + codata totality) then validation of a finite number of steps will also terminate
13:16 < jeremyrubin> it's easy to verify this, but it might be bad if people can write it
13:18 < jeremyrubin> (of course, this is a covenant you can write in CTV)
13:19 < zmnscpxj> jeremyrubin: hmmm "immediate ancestor blocks are empty" is expressible in CTV? how?
13:20 < jeremyrubin> CTV -> (loop, OP_RETURN , OP_RETURN... OP_RETURN)
13:21 < jeremyrubin> and you can make loop be something like:
13:21 < jeremyrubin> IF <program> CTV ELSE 1 CSV PK CHECKSIG ENDIF
13:21 < michaelfolkson> In terms of how powerful a covenant opcode a certain use case needs (e.g. vaults) I can't think of anything other than watch to see what vault designs people prototype and build out
13:21 < jeremyrubin> so you can prove that by reaching the end state (which pays the miner some rare NFT?) that you mined N blocks of dumb OP_RETURNs
13:21 < zmnscpxj> ah, semantically empty, not actually empty
13:22 < jeremyrubin> for actually empty, it can be done but not with CTV
13:22 < jeremyrubin> I think with OP_CAT yes though
13:23 < jeremyrubin> since with OP_CAT you can in theory trace back your UTXO parentage or trace *forwards* through the header chain in some weird ways
13:23 < jeremyrubin> the forwards one is a real mindfuck
13:23 < zmnscpxj> fuck, math is scary
13:24 < jeremyrubin> and because if you can trace to a coinbase output, you have a segwit wtxid commitment, you can query arbitrary other txs
13:24 < michaelfolkson> The covenant paper authors suggested ANYPREVOUT was as useful as CTV. I think the Revault guys like some of the newer covenant opcodes (TLUV etc)
13:24 < jeremyrubin> so, e.g., in theory CAT enables something sponsor-like +100 blocks
13:24 < jeremyrubin> because you can make something that miner can claim if their TXID contains the txn you're interested in
13:24 < jeremyrubin> very space inefficient though 
13:25 < jeremyrubin> APO is fine, but I think that it is premature in some sense given the LN dev community isn't pressing for it too hard
13:25 < jeremyrubin> I think theres some desire to be sure that if there is APO, all other things like SIGHASH_GROUP are settled too
13:25 < michaelfolkson> On timing we aren't going to agree :) But parking the timing question I'm genuinely curious
13:26 < michaelfolkson> Timing of soft forks etc
13:26 < zmnscpxj> jeremyrubin: well I want it for channel factories, though I am still thinking about how channel factories work out economically
13:26 < jeremyrubin> because it requires a big redesign of the LN system (of which they're still chewing on Taproot updates), so it makes sense to ensure all the batteries are included in that SF and everything composes well
13:27 < jeremyrubin> so if you add APO but not group and you need group + APO... you may as well wait?
13:27 < jeremyrubin> I think sponsors helps with this, because you can replace group with sponsors
13:27 < michaelfolkson> zmnscpxj said a while back some of the Taproot updates should wait for ANYPREVOUT. Don't know if you still think that zmnscpxj?
13:27 < michaelfolkson> Taproot Lightning updates
13:28 < jeremyrubin> mod: 3 mins, then general q&a, where we can continue on this or other topics
13:28 < zmnscpxj> michaelfolkson: people want PTLCs *now*, so they are not waiting for ANYPREVOUT anyway, so...
13:28 < jeremyrubin> timing wise: I would like to vault my coins today. i dont care if it's CTV, APO, TLUV, or something else. but i want the fastest path to having that available 
13:29 < jamesob> jeremyrubin: +1
13:29 < jamesob> as it stands, CTV is the most easily understood, concise approach IMO
13:29 < michaelfolkson> I get it. I don't want soft fork updates that will get replaced something better 1-2 years after. I guess that's the (friendly) tug of war here
13:30 < zmnscpxj> jamesob: agree
13:30 < jeremyrubin> one thing i have personal use for is e.g. vaulted coins you keep single sig hot wallet for at home that cannot be stolen while you're on vacation for  up to N days.
13:30 < jeremyrubin> jamesob model works well for that
13:30 < zmnscpxj> jeremyrubin: maybe "vaults" is to vague a term, since different users may want different policies....?
13:31 < jeremyrubin> #topic: general discussion (30m)
13:31 < jeremyrubin> zmnscpxj: naming things is hard
13:31 < zmnscpxj> point concedd
13:32 < jeremyrubin> maybe we call it elTew, as in "tew: a state of worried agitation or excitement"
13:32 < zmnscpxj> `head -c8 /dev/random`
13:32 < jeremyrubin> which is the state i'm in any time i am moving coins around
13:33 < jeremyrubin> i also have been trying to get ariard to rename coin pools to something like "HotTub"
13:33 < jeremyrubin> because coin pool just sounds so generic, people often conflict coin pool, payment pool, and join pool
13:34 < jeremyrubin> w.r.t jeremyrubin: maybe "vaults" is to vague a term, since different users may want different policies....?
13:34 < zmnscpxj> optech has been using joinpool consistently
13:34 < jeremyrubin> zmnscpxj: absolutely. i don't think we'll see one spec to rule them all
13:34 < jamesob> "HotTub" rofl
13:34 < jamesob> I'm dying
13:34 < jeremyrubin> Hot Tub Coin Machine is the name of my payment pool
13:35 < jeremyrubin> which is why e.g. sapio+ctv or one offs (jamesob) is a better bet than OP_VAULT
13:35 < jeremyrubin> but we're missing some key ingredients for them to be possible as of now
13:35 < jeremyrubin> *non-key, precomitted hash
13:36 < jeremyrubin> maybe luke-jr can assign names to projects, too
13:36 < jeremyrubin> ;)
13:36 < jamesob> lol
13:37 < michaelfolkson> Did you ask for a BIP number for sponsorship? Or just didn't bother because you didn't want to pursue it jeremyrubin?
13:38 < jeremyrubin> it wasn't correct within process to ask for one
13:38 < jeremyrubin> if you want to ammend the processes, I think that we should alot numbers for more things
13:39 < rgrant> michaelfolkson: "I don't want soft fork updates that will get replaced" /// Well, what if the soft fork was uncontroversial?  Why wouldn't you want it?
13:40 < jeremyrubin> FWIW I do not think CTV would be replaced *for a very long time*. People will write custody apps and depend on them, and the process to upgrade to something more complex would probably take decade. but CTV alone is a huge leap forward
13:40 < zmnscpxj> could always replace SCRIPT with Google NaCl.  Then force users to program in C++ their exact policies.
13:40 < jeremyrubin> zmnscpxj: OP_WASM
13:41 < zmnscpxj> ^^
13:41 < jeremyrubin> sapio compiles to wasm :)
13:41 < michaelfolkson> rgrant: If any soft fork has overwhelming community consensus then it doesn't matter what I think. While it doesn't we have to discuss what is needed to get there
13:42 < jeremyrubin> concretely: i discussed sponsors on the mailing list, I didn't think there was enough buy in to merit a BIP submission. whereas CTV did have that at the time, since I'd discussed it for 6+ months and gotten favourable feedback
13:42 < michaelfolkson> rgrant: Experimentation and building out of use cases so that comparisons between proposals can be made seems like a good direction to getting overwhelming community consensus
13:42 < jeremyrubin> I think recently sponsors is gaining some technical consensus as people are relaizing we're not smart enough to do CPFP/RBF
13:43 < jeremyrubin> michaelfolkson: can you measure what consensus is?
13:43 < zmnscpxj> humminh
13:43 < zmnscpxj> humming
13:43 < jeremyrubin> peter todd says it has to be unanimity (nearly)
13:43 < rgrant> michaelfolkson: that means waiting whenever someone claims that they have something to evaluate.  it invites a stalling attack.  
13:44 < zmnscpxj> maybe schedule a softfork every 4 years. that stops stalling attacks
13:44 < michaelfolkson> It is getting a touch too philosophical for me but Taproot was activated. So something similar to the consensus for that soft fork
13:44 < rgrant> michaelfolkson: instead, we should use a process that looks at the cost of making changes, and when the risk of error and cost of maintenance is low enough, we should move forward.  this will collect eventually-unused opcodes, as we learn.
13:45 < michaelfolkson> rgrant: I disagree but as I said if you get the rest of the community to agree with you it doesn't matter what I think
13:46 < rgrant> zmnscpxj: the rebuild-the-temple solution.  like how Ise Grand Shrine gets rebuilt every 20 years, in order to train the workers for the next generation.
13:46 < zmnscpxj> rgrant: was thinking more of "the bus is leaving, if you are not there you wait for the next bus" but that works too
13:47 < michaelfolkson> Anyway thanks for this jeremyrubin et al. And thanks for the guest appearances for those who showed up to discuss their work :)
13:47 < rgrant> michaelfolkson: we're not merely voting.  we're vetting good ideas.  so it does matter what you can put forward as a good reason.
13:47 < zmnscpxj> TheDAO?
13:47 < michaelfolkson> I need to re-read "codata totality"
13:48 < jeremyrubin> i have formed a new view on some of these things
13:48 < jeremyrubin> it's that soft forks are a memoryless process
13:48 < jeremyrubin> and they're always like +1 year away
13:48 < zmnscpxj> michaelfolkson: if you can tolerate it:  http://sblp2004.ic.uff.br/papers/turner.pdf
13:48 < jeremyrubin> (or maybe poisson?)
13:48 < jeremyrubin> so i think we never actually get any closer or further from having one
13:48 < rgrant> zmnscpxj: BTW, I'd schedule a bus every year.
13:48 < zmnscpxj> re: it's that soft forks are a memoryless process: so.... need to reignite the lockinontimeout debate?
13:49 < jeremyrubin> haha not that kind of memoryless, but i guess also yes
13:49 < jeremyrubin> we'll always rehash the same debates on that stuff
13:49 < jeremyrubin> i meant more timing wise
13:49 < zmnscpxj> LOT is resolved, long live LOT.
13:49 < jeremyrubin> like CTV is currently able to be set up for a soft fork activating in Novemeber 
13:49 < jeremyrubin> some people think we should wait 2 years though
13:50 < jeremyrubin> if we wait 1 year, it will be able to be set up in November, some people (same %?) will think it should be 2 years
13:50 < jeremyrubin> so you don't ever actually really get closer IMO
13:50 < jeremyrubin> so im sort of getting biased to just doing a ST with release params as a shot on goal, and if we don't want it we reject it
13:51 < jeremyrubin> but it's an unforced error if the choice is not even technically available
13:51 < zmnscpxj> "ST" ?=
13:51 < jeremyrubin> Speedy Trial
13:52 < rgrant> if a ST is rejected but work continues, then what's the cost of the "error"?
13:52 < jeremyrubin> not a UASF, a UASF could be e.g. a future iteration if it's clear users are upset if the 1st one fails.
13:52 < jeremyrubin> rgrant: ^^^ that the next try is probably LOT=true
13:53 < jeremyrubin> unless changes are made
13:53 < zmnscpxj> how is that different from UASF?
13:53 < jeremyrubin> well because there is a ST happening first which is not a UASF client
13:53 < rgrant> well, why not just get feedback and do another ST when the feedback is addressed?  why jump to LOT?
13:54 < jeremyrubin> ah, iff no feedback
13:54 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
13:54 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210422/f50fe48c/attachment-0001.png
13:54 < zmnscpxj> ah okay, so ST first then possibly UASF/LOT=true later
13:54 < jeremyrubin> see this big complex chart 
13:56 < zmnscpxj> that chart is the best argument for generality. let us not activate CTV, we should just pick One OPCODE To Rule Them All
13:56 < jeremyrubin> LOL
13:57 < jeremyrubin> zmnscpxj: i'll extend the chart in that case to include the process of designing OP_RING 
13:57 < jamesob> <javascript> OP_DOTHETHING
13:57 < jeremyrubin> because the design and OP chart is way worse than the activation logic
13:58 < jeremyrubin> anyways we're almost a wrap
13:58 < jeremyrubin> any last words?
13:58 < jeremyrubin> thanks all for coming
13:58 < rgrant> thanks for hosting!
13:58 < zmnscpxj> CTV and APO are awesome, we should activate them o(^^o)
13:58 < zmnscpxj> ^^
13:58 < rgrant> zmnscpxj: ^^
13:59 < jeremyrubin> zmnscpxj: step 1 for APO if you want is that you probably need +1 year from the date of the PR being opened ;)
13:59 -!- rgrant [~rgrant@user/rgrant] has quit [Quit: Leaving...]
14:00 -!- zmnscpxj [~zmnscpxj@136.158.35.64] has quit [Quit: Client closed]
14:00 < jeremyrubin> #endmeeting
14:00 < jamesob> thanks for hosting jeremyrubin
14:01 -!- Guest89 [~Guest89@dsl-74-83-84-75.fuse.net] has quit [Quit: Client closed]
14:03 < luke-jr> never ST
14:03 < sanket1729> I saw I was tagged here, did'nt want to interrupt the ongoing meeting
14:04 < luke-jr> ST is a reason enough to oppose CTV
14:04 < jeremyrubin> sanket1729: was more an invite to join :D
14:04 < jamesob> luke-jr: you're not fooling us, we know you go home and ST over and over again on regtest just to _feel something_
14:04 < jeremyrubin> was asking people how people can help w/ sapio, and I said revieiwng rust-miniscript/rust-bitcoin stuff for TR readiness
14:05 < jeremyrubin> if you have some specific asks would be helpful :)
14:05 < sanket1729> I missed like almost all the meeting. saw at 21:50 UTC
14:05 < sanket1729> One question without reading the logs
14:06 < sanket1729> CTV vaults must require pre-deciding what amounts to withdraw at commit time, right?
14:06 < jeremyrubin> correct 
14:06 < jeremyrubin> you can map dynamic withdrawal amounts onto withdrawing to a hot key and sending back to the vault / cold storage the rest of the funds though
14:07 < jeremyrubin> you can also pre-commit to a few different amounts
14:10 < sanket1729> I can see how committing to few different amounts(powers of two maybe) might be useful. Still that seems limiting in the sense given usage patterns and bitcoin price is dynamic. 
14:11 < sanket1729> But not as bad as I initially thought
14:12 < jeremyrubin> the main issue with dynamic amounts is that you are kind of (options)^steps blowup
14:12 < jeremyrubin> however, dynamic programming helps a fair amount with that since a lot of states are reusable
15:21 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
15:41 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Read error: Connection reset by peer]
15:41 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
15:41 -!- ls55 [sid489830@id-489830.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
15:41 -!- RubenSomsen [sid301948@user/rubensomsen] has joined ##ctv-bip-review
15:41 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined ##ctv-bip-review
15:42 -!- ls55 [sid489830@helmsley.irccloud.com] has joined ##ctv-bip-review
15:50 -!- Guest63 [~Guest63@217-197-184-106.pool.digikabel.hu] has quit [Quit: Client closed]
15:51 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
16:25 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 272 seconds]
18:22 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
18:53 -!- rocket_fuel__ is now known as rocket_fuel
18:56 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 256 seconds]
18:56 -!- rocket_fuel [sid2662@id-2662.ilkley.irccloud.com] has quit [Changing host]
18:56 -!- rocket_fuel [sid2662@user/rocket-fuel/x-5142944] has joined ##ctv-bip-review
19:40 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
19:50 -!- luke-jr [~luke-jr@user/luke-jr] has joined ##ctv-bip-review
20:53 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
21:25 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has quit [Ping timeout: 240 seconds]
21:25 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 240 seconds]
21:29 -!- geyaeb [~geyaeb@gateway/tor-sasl/geyaeb] has joined ##ctv-bip-review
22:09 -!- duelists [~arathor@36.75.201.69] has quit [Read error: Connection reset by peer]
23:23 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined ##ctv-bip-review
23:55 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 240 seconds]
--- Log closed Wed Mar 09 00:00:21 2022