--- Log opened Sat Jan 11 00:00:45 2025
05:39 -!- duderonomy [~duderonom@h69-21-110-28.mdsnwi.tisp.static.tds.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:59 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-rust
05:59 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
06:12 -!- pyth [~pyth@14.161.212.139] has quit [Ping timeout: 248 seconds]
06:13 -!- pyth [~pyth@94.131.10.128] has joined #bitcoin-rust
06:18 -!- Ademan [~Ademan@user/Ademan] has quit [Ping timeout: 252 seconds]
06:34 -!- pyth [~pyth@94.131.10.128] has quit [Ping timeout: 265 seconds]
06:35 -!- pyth [~pyth@14.161.212.139] has joined #bitcoin-rust
06:59 -!- pyth [~pyth@14.161.212.139] has quit [Remote host closed the connection]
07:00 -!- pyth [~pyth@14.161.212.139] has joined #bitcoin-rust
08:20 -!- greypw149508 [~greypw@user/greypw] has joined #bitcoin-rust
08:23 -!- greypw14950 [~greypw@user/greypw] has quit [Ping timeout: 264 seconds]
08:23 -!- greypw149508 is now known as greypw14950
13:31 -!- Ademan [~Ademan@user/Ademan] has joined #bitcoin-rust
13:39 < Ademan> is there a const way I can create an opcode? Previously I've been just renaming OP_NOP4 and OP_RETURN_205 in the use statement, but it'd be pretty nice for its debug formatter to use the correct name
13:40 -!- duderonomy [~duderonom@h69-21-110-28.mdsnwi.tisp.static.tds.net] has joined #bitcoin-rust
13:43 < Ademan> oh shoot wait the way Display is implemented doesn't allow that anyway
13:45 < Ademan> I guess I could define a newtype around script that has a different Display (delegates to <Opcode as Display> except for the opcodes I want to override)
15:20 < andytoshi> yeah, you pretty-much gotta do that
15:21 < andytoshi> i'm leaning toward "users have to define their own wrapper types to do anything user-facing with Script"
15:21 < andytoshi> except hex encoding/decoding
15:21 < andytoshi> e.g. there have been a few proposals for ascii parsers in rust-bitcoin but i don't think we can accept any of them. either they fail to cover some usecases or they're way too complicated
16:16 < shesek> Ademan, that's what I ended up doing: https://github.com/shesek/minsc/blob/dev/src/stdlib/btc.rs#L906
16:23 < shesek> well, a separate display trait rather than a newtype, but the opcode detection/delegation logic is similar to what you'd need
16:26 < shesek> I'm also using it to display PUSHNUM opcodes more compactly as just <N>
16:33 -!- shesek [~shesek@user/shesek] has quit [Quit: The Lounge - https://thelounge.chat]
16:35 -!- shesek [~shesek@user/shesek] has joined #bitcoin-rust
16:41 < Ademan_> shesek: thanks! I also meant to reply about the electrs issue but I've honestly forgotten what the issue I ran into was... haha
16:45 < Ademan_> that's quite an optimistic set of opcodes!
16:48 < shesek> most of them is what's available on Elements, its just OP_CTV that's a soft fork candidate in that list
16:51 < shesek> I actually want to add OP_CSFS, OP_PAIRCOMMIT and OP_INTERNALKEY too, but they all conflict with opcode bytes used by Elements
16:52 < shesek> for now I just define them explicitly in scripts that use them, with a comment explaining why they're getting serialized back weirdly >.< https://min.sc/v0.3/#gist=82d92568c2fcba62203157f8df11354e
17:11 < Ademan_> yeah those are the opcodes I care about ;-)
17:12 < Ademan_> also minsc looks pretty neat! (and I want to spend a minute to understand this example vault design too)
17:13 < shesek> that lnhance delegated vault example isn't really well documented, might be easier to follow along the pure CTV-only vault at https://min.sc/v0.3/#github=examples/ctv-vault.minsc
17:16 < shesek> especially since minsc itself is like 95% undocumented (500+ commits since I last updated the documentation website >.<), I'm the only one that knows it really haha
17:17 < Ademan_> I've got my own CTV vault implementation actually (haven't released it yet though) so I'm curious what you're doing in the LNHANCE version
17:18 < Ademan_> particularly curious*
17:18 < Ademan_> once I release my vault I'm going to read all of the prior art I didn't know existed when I started lol
17:19 < Ademan_> (just in case I accidentally do something different and interesting from everybody else)
17:21 < shesek> you basically have a master key that signs over pairs of delegated authorization pubkeys and CTV hashes. when spending you show that: (1) the master key signed ctv_hash+delegated_pk (2) the delegated_pk signed the tx and (3) that the CTV hash matches the transaction. this lets you add additional policies to vaults without changing its taptree or
17:21 < shesek> generating new addresses
17:23 < shesek> I actually wrote a little summary of the pros/cons this has just earlier today. a bit too long to paste here I think, you can see it here: https://gist.github.com/shesek/77c982773df360ee4a12513b9832d7c0
17:27 < shesek> I also have a work in progress OP_VAULT vault. wanted to get a taste of the different approaches and their limitations. then hopefully planning to make a little GUI for one of them
17:28 < shesek> curious to hear more about your design :)
17:32 < shesek> I probably also need a CAT vault to really complete the series, but CAT introspection is such a huge PITA and you don't really get that much without txout amount arithmetics that I don't know if its worth it ^^
19:35 < Ademan> maybe this is exactly what you intended, but jamesob has highlighted the use case where a vault might have an "oops I lost my keys, send to custodian (but I can claw back in a certain very generous time frame)" path. Your delegated keys might be an interesting way to add these backup custodians off chain
19:42 < shesek> the example has a delegated key for recovery after a 1 year delay that's basically exactly that, just demonstrated using social recovery (a "friend_ pk") instead of a custodian
19:48 < shesek> the requirement to reuse the internal key and delegated key for all your outputs is kind of a turn off, though
19:49 < shesek> OP_VAULT necessities key reuse too if you want to enable batching
21:53 -!- duderonomy [~duderonom@h69-21-110-28.mdsnwi.tisp.static.tds.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:30 -!- pyth [~pyth@14.161.212.139] has quit [Ping timeout: 272 seconds]
23:10 -!- pyth [~pyth@113.184.143.105] has joined #bitcoin-rust
23:30 -!- duderonomy [~duderonom@h69-21-110-28.mdsnwi.tisp.static.tds.net] has joined #bitcoin-rust
--- Log closed Sun Jan 12 00:00:46 2025