--- Log opened Wed Mar 23 00:00:34 2022
03:52 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 252 seconds]
04:19 -!- midnight [~midnight@user/midnight] has joined ##miniscript
05:22 -!- shesek [~shesek@user/shesek] has joined ##miniscript
05:56 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:57 -!- shesek [~shesek@user/shesek] has joined ##miniscript
06:04 < andytoshi> i kinda like sanket's idea to use the bip32 derivation logic with an unspendable master key ... even if we wrap that in an unspend() syntax
06:04 < andytoshi> it's not as efficient as a more direct method, but i don't think efficiency really matters here that much
06:04 < andytoshi> and it gives you the ability to expose an alternate descriptor where you aren't revealing unspendability
06:04 < andytoshi> if you want
06:05 <@sipa> how so?
06:06 < andytoshi> by writing xpub(H/1/2/3/*) where H is secretly NUMS
06:06 <@sipa> that doesn't hide it?
06:07 < andytoshi> also -- wallet authors will have existing logic for doing these sorts of derivations which might help us get a schelling point
06:07 < andytoshi> doesn't it?
06:07 <@sipa> it's just syntactic sugar, if i understand your suggestion correctly?
06:08 < andytoshi> yes -- i am suggesting that unspend(r/*) be syntactic sugar for xpub(taggedhash_to_point("Unspend_key"+r+index)/*)
06:08 < andytoshi> but the latter, if just provide the output point, looks like it might be spendable
06:09 <@sipa> ah, then it's not syntactic sugar... due to the taggedhash
06:09 < andytoshi> ahh yeah you're right
06:09 <@sipa> but then what's the advantage, as there is still a tagged hash anyway?
06:10 < andytoshi> well we could use an untagged hash, but i guess hashing to a point, period, makes this incompatible with any existing construction
06:10 <@sipa> I think the advantage of the sanket1729's H-BIP32 approach is that it can be done without introducing any new syntax right, so it can be adopted as "standard" without needing to change the descriptor language at all.
06:11 <@sipa> I don't know if that's desirable - I think if we want to support provably unspendable keys, there should be language support to explicitly convey that. But it's possibly an implementation advantage to go that way.
06:11 < andytoshi> ok, understood. so i'm sorta suggesting that we could get the best of both worlds
06:11 < andytoshi> we add an explicit syntax, which can be converted to a "fallback" mode for wallets that don't understand it
06:11 <@sipa> But as soon as you're introducing a tagged hash or hash of any kind in addition to just xpub_based_on_H/..../*... then you can also just use that directly, without the derivation.
06:11 < andytoshi> by doing the NUMS derivation for them and then providing a normal-looking xpub
06:12 <@sipa> That's a fair point.
06:12 < andytoshi> but yes - if i understand you correctly, using an xpub at all (rather than a normal pub) has very little value
06:12 < andytoshi> i guess you get the ability to derive a sequence of unspendable keys this way
06:13 < andytoshi> but like, if you're trying to do shit like that, then you should probably only be using wallets that support it natively
06:13 <@sipa> i guess unspend(HEX) could be syntactic sugar for "the xpub whose pubkey is H, and whose chaincode is HEX"
06:14 <@sipa> then you can use tr(unspend(HEX), ...) or tr(unspend(HEX)/*, ...) etc
06:14 <@sipa> and we kind of get the derivation path "for free", because it leverages existing logic
06:15 <@sipa> (at the price of being far more computationally expensive than what is needed to achieve the same cryptographically)
06:15 < andytoshi> is H fixed here?
06:15 <@sipa> yes H is the second generator
06:15 < andytoshi> ok great, i understand
06:16 <@sipa> and that's purely syntactic sugar... you can translate both ways, so it doesn't hide anything
06:16 < andytoshi> so, i like this scheme -- yes, it is computationally wasteful, but keygen is already expensive and rare. the advantages are that it is very small in terms of added functionality/complexity for wallet authors, has little room for bikeshedding, and enables a "fallback" where you do the NUMS computation to provide descriptors for old wallets
06:17 < andytoshi> can you clarify "translate both ways"? it seems if i take unspend(HEX) and then actually do the derivation, then HEX is hidden
06:17 <@sipa> well, hopefully it's hidden after derivation! that's the whole point!
06:17 <@sipa> i meant that before derivation you can translate both ways
06:17 < andytoshi> ahh yes i gotcha
06:18 < andytoshi> conversion between unspend(HEX) and xpub(H+hex/*)
06:18 < andytoshi> H||HEX
06:18 < andytoshi> conversion between unspend(HEX) and xpub(H||HEX/*) .. both of which provide HEX explicitly
06:18 <@sipa> yeah, between unspend(HEX) and xpub(H||hex)
06:18 <@sipa> the /* would be outside
06:18 < andytoshi> there we go, thanks :)
06:19 < andytoshi> if i could edit IRC text i would've eventually iterated to the right thing :)
06:49 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
06:49 -!- shesek [~shesek@user/shesek] has joined ##miniscript
07:23 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:23 -!- shesek [~shesek@user/shesek] has joined ##miniscript
07:41 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:41 -!- shesek [~shesek@user/shesek] has joined ##miniscript
07:58 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:59 -!- shesek [~shesek@user/shesek] has joined ##miniscript
08:46 < jeremyrubin> i like this ^
08:47 < jeremyrubin> having a standard point we're deriving from makes a lot of sense to me 
08:48 < jeremyrubin> one poiint on the hex is that we should maybe do unspend(HEX) -> unspend(H(HEX)) so that it's always a fixed cost no matter what hex goes in 
08:48 < jeremyrubin> i have code for this https://github.com/sapio-lang/sapio/blob/6c6186205b0911885092210158c70dff7d496e87/ctv_emulators/src/lib.rs#L43
08:49 <@sipa> that removes the ability to translate back (not sure how desirable that is), and introduces more space for bikeshedding
08:49 <@sipa> not strictly opposed to it, though
08:50 < jeremyrubin> ah, maybe unspend_h and unspend_r where r is raw and _h gets hashed?
08:50 < jeremyrubin> you can still translate back, but only to prove that the key is unspendable 
08:51 < jeremyrubin> perhaps best to just do raw and let users pre-hash?
09:33 < sanket1729> xpub(H||HEX)/* is one sha512 extra than K = H + r*G? Don't know the exact numbers. But maybe not that bad considering we are point tweak addition in both cases. 
09:34 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
09:34 -!- shesek [~shesek@user/shesek] has joined ##miniscript
09:37 <@sipa> right, just more hashing, same amount of EC operations
09:37 <@sipa> in my mind i was comparing it with doing something like xpubH/i/j/k/l/m/n/.... (with i||j||k||l||m||n = 256 bits)
09:56 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
09:57 -!- shesek [~shesek@user/shesek] has joined ##miniscript
11:07 < andytoshi> lol, nack _r and _h, on the grounds of them encouraging bikeshedding
11:07 < andytoshi> i think we should just require the input to unspend() to be 32 bytes
11:07 < andytoshi> (but no strong feelings in any direction)
11:08 <@sipa> agreed
11:23 < sanket1729> So, we have unspend(<32-byte-hex>,NUM) => xpub(H||<32-byte-hex>)/NUM where NUM can be *. NUM must be present. To prove that a particular key in unspendable to a third party, users can also share the tweak value without sharing the entire xpub.
11:24 <@sipa> nono
11:24 <@sipa> unspend(<32-byte-hex>) which is equivalent to xpub(H||<32-byte-hex>)
11:24 <@sipa> for /NUM or /* we just use the existing key derivation language feature
11:25 <@sipa> you can write unspend(HEX)/16/18917/17/* too
11:25 < sanket1729> I see
11:26 <@sipa> and proving that a particular key is unspendable involves revealing HEX + derivation path
11:26 <@sipa> I think?
11:26 < sanket1729> That seems bad
11:26 < sanket1729> Because you reveal all keys derived from it
11:27 < sanket1729> You can only compute the final `r` value such that `K = H + r*G` and reveal that
11:27 <@sipa> Ah, you are right, indeed!
11:27 < sanket1729> so that you don't leak anything about other keys
11:28 <@sipa> sanket1729: Also, see last commit in https://github.com/sipa/miniscript/pull/105
11:28 <@sipa> it adds the code for determining the type-base expression rules
11:28 < sanket1729> The only concern I have with unspend(32-byte-hex) is that people might use it without the derivation path. In which case, it is just H
11:29 < sanket1729> nice, looking at it
11:29 <@sipa> maybe unspent(32-byte-hex) could be equivalent to xpub(H||32-byte-hex)/0 ?
11:29 <@sipa> to avoid that
11:31 < sanket1729> Yeah, I like that. It uses the 32-byte-hex to gain randomness
11:37 < andytoshi> a signature with key-H will also prove unspendability, in a zk way
11:37 < andytoshi> key minus H, to be clear
11:37 <@sipa> interesting, indeed
11:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
11:38 <@sipa> an advantage of using (composition of) additive tweaks
11:39 <@sipa> to prove a key is a multiple of H, you'd need to sign with a modified signing algorithm (e.g. BIP340 but in the spec all Gs replaced by H)
11:51 -!- shesek [~shesek@user/shesek] has joined ##miniscript
12:52 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:52 -!- shesek [~shesek@user/shesek] has joined ##miniscript
12:58 < sanket1729> I wonder if there is any practical use-case for proving in zero-knowledge that all some utxos are under the same BIP32 wallet. We can do it cleanly and efficiently, but can't think of any application
13:00 < sanket1729> simple pubkey controlled utxos. 
13:07 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
13:09 < jeremyrubin> xpubH/i/j/k/l/m/n/.... (with i||j||k||l||m||n = 256 bits) -- > iirc the reason i did it this way was to do 8 31 bit deriv paths and 1 1 byte deriv path, with makes the derivation entirely standard childnums
13:10 < jeremyrubin> so that, for my oracle service, it just tweaks the root key by the CTV hash of the txn sent to it, and signs that w/o question.
13:10 < jeremyrubin> but if you do some other tweaking it would require more/different features in descriptors
13:10 < jeremyrubin> that may be desirable in any case, but i wanted to go off the shelf
13:23 -!- shesek [~shesek@user/shesek] has joined ##miniscript
13:47 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
13:47 -!- shesek [~shesek@user/shesek] has joined ##miniscript
14:18 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
14:18 -!- shesek [~shesek@user/shesek] has joined ##miniscript
14:56 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
14:56 -!- shesek [~shesek@user/shesek] has joined ##miniscript
15:27 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:27 -!- shesek [~shesek@user/shesek] has joined ##miniscript
16:02 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:02 -!- shesek [~shesek@user/shesek] has joined ##miniscript
16:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:24 -!- shesek [~shesek@user/shesek] has joined ##miniscript
16:34 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:34 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:01 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:01 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:15 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:15 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:32 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:32 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:45 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:46 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:54 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:54 -!- shesek [~shesek@user/shesek] has joined ##miniscript
18:34 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
18:34 -!- shesek [~shesek@user/shesek] has joined ##miniscript
18:49 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
18:49 -!- shesek [~shesek@user/shesek] has joined ##miniscript
19:31 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
19:31 -!- shesek [~shesek@user/shesek] has joined ##miniscript
20:02 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
20:06 -!- shesek [~shesek@user/shesek] has quit [Ping timeout: 272 seconds]
21:11 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
21:11 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
21:36 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
21:36 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
21:47 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
21:47 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
22:02 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:02 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
22:04 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:04 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
22:14 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:14 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
22:25 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:26 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
22:50 < jeremyrubin> small bug i noticed
22:50 < jeremyrubin> concrete policy in rust: and(or(pk(A),pk(b)), older(100)) fails to compile
22:50 < jeremyrubin> and(or(pk(A),pk(b)),older(100)) compiles
22:50 < jeremyrubin> err: "unexpected « older»"
22:51 < jeremyrubin> i think our parser gets unhappy 
22:58 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
22:58 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
23:15 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
23:15 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
23:25 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
23:25 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
23:32 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
23:32 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
23:57 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
23:57 -!- shesek_ [~shesek@user/shesek] has joined ##miniscript
--- Log closed Thu Mar 24 00:00:35 2022