--- Log opened Tue Mar 22 00:00:33 2022
00:06 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:07 -!- shesek [~shesek@user/shesek] has joined ##miniscript
00:19 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:19 -!- shesek [~shesek@user/shesek] has joined ##miniscript
00:23 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:23 -!- shesek [~shesek@user/shesek] has joined ##miniscript
01:02 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
01:02 -!- shesek [~shesek@user/shesek] has joined ##miniscript
03:11 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
03:11 -!- shesek [~shesek@user/shesek] has joined ##miniscript
03:50 -!- darosior [~darosior@194.36.189.246] has quit [Remote host closed the connection]
03:50 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript
04:58 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
04:58 -!- shesek [~shesek@user/shesek] has joined ##miniscript
05:20 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:20 -!- shesek [~shesek@user/shesek] has joined ##miniscript
05:33 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:34 -!- shesek [~shesek@user/shesek] has joined ##miniscript
05:53 <@sipa> nope, not unambiguous
06:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
06:16 -!- shesek [~shesek@user/shesek] has joined ##miniscript
07:11 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:12 -!- shesek [~shesek@user/shesek] has joined ##miniscript
07:41 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:42 -!- shesek [~shesek@user/shesek] has joined ##miniscript
08:57 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
08:58 -!- shesek [~shesek@user/shesek] has joined ##miniscript
10:29 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
10:30 -!- shesek [~shesek@user/shesek] has joined ##miniscript
11:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
11:16 -!- shesek [~shesek@user/shesek] has joined ##miniscript
12:09 < darosior> Why doesn't the 'a:' wrapper "forward" the 'z' property? Sure TOALTSTACK <X> FROMALTSTACK does technically consume the top stack element, but it puts it back and as long as X is 'z' it should appear to the following OPs as if it didn't consume anything.
12:11 < darosior> I was thinking about this in the context of https://github.com/sipa/miniscript/pull/105#issuecomment-1074459067, but unfortunately it would only enable '0' to be 'Wzdu' which is not very interesting. Still, i wonder if the 'a:' wrapper should for some reason never be 'z'?
12:11 <@sipa> There are other properties missing around W and z. Every Bz could be automatically treated as a W directly too.
12:11 <@sipa> But I think those aren't all that useful in practice.
12:15 < darosior> sipa: Have you thought about the duplicate keys issues i mentioned last week btw?
12:15 <@sipa> Ah, not really.
12:16 <@sipa> Now that you mention it, shouldn't we just have a Node::HasDuplicateKeys(), which is also counted in IsSane?
12:16 < darosior> I'll open an issue regarding 'z' and 'W' <-> 'Bz', if you don't mind. Probably not worth addressing now but there could be use case we missed
12:16 < darosior> I do think so
12:17 < darosior> As mentioned last time, just another cached function, computed at creation time
12:17 <@sipa> Counting Bz as W or Wz would be even better than passing through z through a.
12:17 < darosior> Oh, right
12:17 <@sipa> It might need a "wrapper" that involves no opcode, like and_v, to convert Bz to Wz
12:18 <@sipa> Alternatively, we could just permit and_b or_b and thresh to accept Bz args
12:18 <@sipa> In addition to W args.
12:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:25 -!- shesek [~shesek@user/shesek] has joined ##miniscript
13:19 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
13:20 -!- shesek [~shesek@user/shesek] has joined ##miniscript
13:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
13:39 -!- shesek [~shesek@user/shesek] has joined ##miniscript
13:52 < sanket1729> sipa: The list looks awesome
13:53 < sanket1729> I can try to manually review it
13:53 <@sipa> I'm fairly confident it is correct.
13:53 < sanket1729> Awesome
13:53 <@sipa> But after all the ways I found to prune it, it's probably far harder to manually review.
13:54 <@sipa> I'll post the code used to create it soon.
13:54 < sanket1729> Nice, looking forward to it. 
13:57 < sanket1729> I had another question about BIP341 related to sampling unspendable internal keys. The BIP states sample K such that `K = H + r*G` where H is unknown dlog point and is r is random. Can I use xpub where H is master public key and derive unspendable keys from it? I don't see anything wrong with it and it would be compatible with descriptor spec.
13:57 <@sipa> You mean G, not H?
13:58 <@sipa> H must be a point of unknown dlog.
13:58 < sanket1729> I think I would need H to be master xpub. I want to sample unspendable key
13:59 <@sipa> That's unspendable.
13:59 <@sipa> not unspendable
14:00 <@sipa> Oh, I think I misunderstand your suggestion.
14:00 <@sipa> You mean not using K=H+rG, but using K=xpub(H,some chaincode?)/.../... ?
14:01 < sanket1729> yes
14:01 <@sipa> Yeah, that works.
14:02 < sanket1729> Thanks, this seems more useful in practice. Because K = H+ rG would result in multiple descriptors one with each concrete key
14:02 < jeremyrubin> wait
14:02 < jeremyrubin> does this mean not all derivations are valid TR keys?
14:02 <@sipa> Presumably there are multiple.
14:02 <@sipa> But what xpub do you use?
14:03 <@sipa> jeremyrubin: Valid, just not spendable without breaking dlog.
14:03 <@sipa> (and, interestingly, if it does get spent, by revealing the way it was constructed, you get a transferable proof of dlog b0rkage)
14:05 <@sipa> sanket1729: I was imagining more something like K=H+rG, where r is some hash computed from the descriptor/derivation (but not involving any private keys).
14:06 <@sipa> That'd be significantly cheaper too.
14:07 < sanket1729> So, r is computed deterministically?
14:07 <@sipa> yeah
14:08 < sanket1729> So, it will be an update to descriptor spec?
14:08 < sanket1729> Maybe empty internal key?
14:08 <@sipa> possibly
14:08 <@sipa> but it's hard to do this in a way that works generically
14:09 <@sipa> e.g. you need to make sure that the r hash computation results in the same value for everyone
14:09 < jeremyrubin> yikes
14:09 < jeremyrubin> i definitely have code deployed that doesn't check for this case
14:10 <@sipa> jeremyrubin: You can't check for it.
14:10 <@sipa> That's the point.
14:10 <@sipa> It's just using a pubkey that nobody knows the private key to.
14:10 < jeremyrubin> right
14:10 < jeremyrubin> unhardened derivation is dead then?
14:10 <@sipa> ... wat?
14:11 <@sipa> How is that related to anything here?
14:11 < sanket1729> jeremyrubin: I think you are confusing this with something else. This is a way to sample unspendable keys, that's all
14:12 < jeremyrubin> sanket1729: gotcha
14:12 < jeremyrubin> i thought this applies to HD deriv
14:12 < jeremyrubin> since if someone applies a derivation path can they ensure it's always spendbale
14:12 <@sipa> Yes, if you do HD deriv on a key that nobody knows the dlog for, you end up with a key that nobody knows the dlog for.
14:13 < jeremyrubin> gotcha, but given that you know the dlog, and derivation path, the key is always spendable?
14:13 <@sipa> yes
14:13 < jeremyrubin> no weird evenness issue for IPK?
14:13 < sanket1729> Whats IPK?
14:13 <@sipa> this has nothing to do with evenness
14:13 < jeremyrubin> internal public key
14:14 < jeremyrubin> ok im definitely a bt out of my depth on the taproot crypto 
14:14 < jeremyrubin> but just saw the above and got 🤔
14:14 <@sipa> i think you may be conflating an earlier discussion here with the later one
14:14 <@sipa> we're literally just talking about doing derivation starting from an xpub that nobody knows the privkey for
14:15 <@sipa> which, i hope is obvious, will result in a keys that nobody knows the dlog for either
14:18 < sanket1729> > e.g. you need to make sure that the r hash computation results in the same value for everyone ... If I follow this correctly, you mean that not all parties will have the same descriptor, possibly some are missing origin info etc
14:18 <@sipa> right
14:18 <@sipa> they might have missing subtrees if we add that
14:18 <@sipa> or if you use unexpanded descriptors (with xpubs etc in, rather than concrete pubkeys), there may be multiple equivalent encodings
14:19 < sanket1729> right
14:20 < jeremyrubin> yeah sounds like my confusions was fromt hat
14:21 <@sipa> sanket1729: But what if there is only one leaf?
14:21 < sanket1729> Yep, it would need to take into some derivation info. Something that is not published on blockchain
14:21 < sanket1729> Which is not necessarily present
14:21 <@sipa> Then you can't assume that there is any information (besides the private key) that isn't available to the attacker.
14:21 < sanket1729> Yep
14:22 <@sipa> for key path spending there actually is
14:22 <@sipa> the internal pubkey!
14:22 <@sipa> oh, wait, we're exactly talking about cases where there is no internal pubkey
14:23 <@sipa> d'oh
14:41 < sanket1729> I don't see a clean way :( to do it. Maybe we need to go for the more expensive K=xpub(H,some chaincode?)/.../... . Will think a bit more about this
14:42 <@sipa> The problem is not the algorithm.
14:43 <@sipa> The issue is having a canonical, non-published, piece of information that all descriptor participants now.
14:44 <@sipa> The obvious solution is just adding it explicitly to the descriptor.
14:44 < sanket1729> yes, my suggestion was assuming the above
14:44 <@sipa> (using K=H+rG, with truly random r, and putting r in the descriptor itself)
14:47 <@sipa> e.g. by having a unspend(HEX) function in descriptor language, which is a valid pubkey function, equivalent to H+rG.
14:47 <@sipa> not very elegant, but compatible with whatever people want to do to construct the r value
14:48 < sanket1729> I was trying to avoid any changes to language. Maybe the explicitness of `unspend()` call is good
14:48 <@sipa> I mean... we need changes to the language anyway.
14:48 <@sipa> There currently is no way to signal a provably unspendable pubkey.
14:49 < sanket1729> Why? If we use  K=xpub(H,some chaincode?)/.../... ? participants can match the value of H?
14:50 <@sipa> Yes, and even the signalling of "use that formula for computing K" is a descriptor language change.
14:50 <@sipa> e.g. by omitting the internal key in tr((
14:51 <@sipa> So whatever we come up with, it's a language change.
14:51 < sanket1729> I think tr(xpub(H,some chaincode)/.../..., {...}) is not a change. Other participants can see the internal key and check that there are derived from H and conclude unspendable. 
14:52 <@sipa> oh, i see
14:52 < sanket1729> This is expressable in decsriptor language today
14:53 <@sipa> interesting, indeed
14:54 < sanket1729> This was my original question :P. Sorry for being unclear
15:02 <@sipa> I think if we want to support provably-unspendability as a feature in descriptors, there should be explicit language support for it.
15:03 <@sipa> Otherwise it's both obscure (you can't look at a descriptor and say that it's using unspendable inner keys), and not obviously a shelling point for accomplishing it (someone else could propose a different but incompatible way of constructing unspendable keys).
15:15 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:15 -!- shesek [~shesek@user/shesek] has joined ##miniscript
15:29 < sanket1729> Agreed. Just to suggest Something. How unspend(r/*) that expands to TaggedHash_"Unspend_key"(r+index)? Just forgo the idea for deriving `r` from the descriptor. Maybe, we can add the merkle root to the hash too. 
16:02 <@sipa> ah, good point, so not all derivations use the same internal key
16:55 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:55 -!- shesek [~shesek@user/shesek] has joined ##miniscript
17:22 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:39 <@sipa> could be unspend(HEX,NUM) to derive H+hash(HEX||NUM)G
17:39 <@sipa> and NUM can also be *
18:15 < sanket1729> Yep, I like this better
18:17 < sanket1729> I don't know if there is any benefit or drawback, but we can also include merkle root in there. Just to fix what tree we are blinding. 
18:18 <@sipa> yeah, the merkle root could function as a salt, perhaps reducing the needed length of the HEX value a bit
18:18 <@sipa> unsure
18:18 < sanket1729> Oops, sorry wrong word blinding. I meant creating an unspendable key from
18:18 <@sipa> alternatively, you could of course just also manually add the merkle root to HEX if you wanted to
18:19 < sanket1729> Yes, true. There might be no need to restrict it in spec itself. 
--- Log closed Wed Mar 23 00:00:34 2022