--- Log opened Wed Feb 10 00:00:25 2021
00:38 -!- jonatack [~jon@37.167.157.108] has joined ##miniscript
01:05 -!- jonatack_ [~jon@37.166.50.22] has joined ##miniscript
01:08 -!- jonatack_ [~jon@37.166.50.22] has quit [Client Quit]
01:08 -!- jonatack_ [~jon@37.166.50.22] has joined ##miniscript
01:08 -!- jonatack_ [~jon@37.166.50.22] has quit [Client Quit]
01:09 -!- jonatack [~jon@37.167.157.108] has quit [Ping timeout: 240 seconds]
01:09 -!- jonatack [~jon@37.166.50.22] has joined ##miniscript
03:07 -!- afilini [~user@gateway/tor-sasl/afilini] has quit [Remote host closed the connection]
03:07 -!- afilini [~user@gateway/tor-sasl/afilini] has joined ##miniscript
03:34 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript
03:34 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
03:34 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript
04:00 -!- jonatack [~jon@37.166.50.22] has quit [Quit: jonatack]
04:06 -!- jonatack [~jon@37.166.50.22] has joined ##miniscript
04:08 -!- jonatack [~jon@37.166.50.22] has quit [Read error: Connection reset by peer]
04:08 -!- jonatack [~jon@37.166.50.22] has joined ##miniscript
04:45 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 272 seconds]
04:46 -!- jonatack [~jon@37.166.50.22] has joined ##miniscript
05:11 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 272 seconds]
06:14 -!- jonatack [~jon@37.166.50.22] has joined ##miniscript
08:46 < andytoshi> i really do not like "taproot descriptors should use compressed public keys and just ignore the first byte". this creates ambiguity and extra (useless) parsing to check that the first byte is either 2 or 3
08:47 < sipa> andytoshi: so you're going to replace bip32? :)
08:47 < sipa> the whole point was not needing to do that
08:47 < andytoshi> oh! i may be misunderstanding you
08:48 < andytoshi> i do think we should use the same old xpubkeys/xprivkeys
08:48 < andytoshi> and "derive taproot keys" by just deriving compressed keys and dropping the first byte
08:48 < sipa> yes, exactly
08:48 < andytoshi> but if the user puts an explicity EC key into a taproot descriptor
08:48 < andytoshi> i'd like this to be a xonly key, and disallow explicit old-school keys
08:48 < sipa> hmm
08:48 < sipa> that seems reasonable
08:49 < andytoshi> ok cool :)
08:52 < sipa> that also means psbt will need a new field to indicate derivation paths for xonly keys
08:53 < sipa> e.g. a tr([origininfo]xonlypubkey) descriptor will need to have some way of storing that origin info
08:53 < sipa> in psbt
08:54 < sipa> it obviously needs new fields anyway, of course
08:54 < andytoshi> yep. i think i prefer that to using the old key->path fields
08:55 < andytoshi> reusing*
08:56 < sipa> there is a tiny advantage to not doing that, actually
08:56 < sipa> if you have the full pubkey, you know whether to negate at signing time
08:56 < andytoshi> ahh hmm
08:56 < sipa> so a fullpubkey -> path is actually exactly what you need
08:57 < andytoshi> yeah, and fullpubkey is also what you want in the descriptor
08:57 < sipa> though in xonly -> (path, y parity) form would be more natural
08:57 < andytoshi> yeah, i like that from a purity standpoint
08:57 < andytoshi> and i guess, the user already needs to keep the parity around separate from the key
08:58 < andytoshi> for use in revealing script paths
08:58 < sipa> also, the key origin fields now act as sort of a "request sig" field, for dumb signers that don't understand scripts
08:58 < sipa> those aren't enough for taproot
08:58 < sipa> as the leaf hash goes into the signature
09:00 < sipa> so from that perspective we may want somethig else anyway
09:10 < andytoshi> yeah, agreed
11:03 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
11:09 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript
11:29 < sipa> andytoshi: hmm, so
11:30 < sipa> a descriptor tr(xpub.../.../0) would allow computing the negation flag to apply to the private key from just the derivation (because it computes the Y parity along with the X coordinate)
11:31 < sipa> but a descriptor tr([origin]xonlypubkey) wouldn't - unless of course that negation flag is added to become part of the origin info
11:31 < sipa> but that raises the question... why not use the full pubkey in the descriptor?
11:31 < sipa> that'd convey exactly the same
11:32 < sipa> i'm torn
11:34 < sipa> this feels a bit similar to pubkey hashes... the x-only key is what ends up on chain, so it's similar to a pubkeyhash; but in both cases the wallet still actually tracks full pubkeys, as those are what gets derived
11:37 < andytoshi> yeah, that makes sense to me
11:37 < andytoshi> it's a bit weird thoughbecause "x-only pubkeys" are supposed to be first-class objects, unlike pubkeyhashes which are sorta "a weird way of encoding a p2pkh address"
11:38 < sipa> yeah, they are - from a pure signature signing/verification perspective
11:39 < sipa> but we don't generate keys directly in wallet infrastructure, but through BIP32 (or other tweaking...), and those deal with full keys
11:39 < andytoshi> given tr([origin]xonlypubkey) .. do you actually need the negation flag?
11:40 < sipa> you do if you don't want to need to try to find the private key twice (assuming the derivation code is full-pubkey based)
11:40 < sipa> i'm sure there are ways to make things work fine without it
11:41 < sipa> it's just something i observed while implementing, that the full pubkey actually has information that may be relevant to a signer
11:42 < andytoshi> i'm not following. you can derive the private key from the origin, which presumably is full-pubkey based
11:42 < andytoshi> then you need to compute the pubkey from that, so you can check that the given xonlypubkey is correct
11:42 < andytoshi> and in doing so, you'll get the negation flag for free
11:42 < sipa> well if you have a dictionary of private keys indexed by pubkey or pubkeyhash, instead of deriving directly, you need to try both
11:44 < andytoshi> i'd expect then that you'd have a dictionary of (privkey, negation flag) ... or even just directly negate the privkey before storing it
11:44 < sipa> yes, that would be a "a way to make things work fine without it" :)
11:44 < sipa> i'm assuming key derivation infrastructure that doesn't have that
11:45 < sipa> (which was one of the reasons for making our pubkeys even-tiebroken instead of square)
11:46 < sipa> i'm perfectly fine with just making things try both in bitcoin core; a hash + map lookup is negligible compared to the rest of signing
11:46 < sipa> but maybe it impacts other stuff
11:51 < sipa> i'll see how far i get without it
11:55 < andytoshi> ok, cool ... i think it's conceptually cleaner to not have the negation flag as part of the pubkey
11:55 < andytoshi> since it isn't useful for validators, there's extra logic if it's "wrong"
11:56 < andytoshi> and it puts more work on people doing xonly stuff
11:56 < andytoshi> and i haven't heard of people using this "map from origin to privkey" model ... though i guess, i haven't done any work on software wallets before
11:57 < sipa> not from origin to privkey
11:57 < sipa> but bitcoin core has a map of privkeys, indexed by hash160
11:57 < sipa> when signing from a descriptor, that map is expanded into, and the signing logic uses that map to find the right keys to sign
11:58 < andytoshi> right i see
11:58 < andytoshi> i guess, my view is that this negation flag is sorta the wallet's responsibility to store alongside the privkey (if it wants to store privkey+flag, rather than just negating the privkey directly)
11:59 < sipa> that's fair
11:59 < andytoshi> and putting it into the descriptor feels like it's imposing extra accounting (and type confusion between xonly and old-school pubkeys)
11:59 < andytoshi> but i could be convinced either way
11:59 < sipa> well the type confusion exists anyway
11:59 < andytoshi> in some sense all the descriptor key data is "stuff the wallet shuold be tracking" :P
11:59 < sipa> because xpub expressions are defining compressed keys, not xonly keys
11:59 < andytoshi> yeah i think you're right
12:00 < andytoshi> there's no way to pretend that isn't the case in an API
12:00 < sipa> maybe it even makes sense to permit both... in the same way that origin info is optional or not
12:00 < sipa> and some things may work without it
12:00 < andytoshi> oh hmm, that i could definitely get behind
12:00 < andytoshi> well s/definitely// :) lemme think about it
12:00 < sipa> it's hard to know exactly what information a signer needs to sign
12:00 < andytoshi> yeah
12:01 < sipa> so in tr, you can write an xonlypubkey expression, or an ordinary one (in which case it gets coerced to an xonly one)
12:01 < sipa> i'm not sure either
12:05 < andytoshi> after trying to say this out loud to sanket1729 i feel like putting the bit into the origin data is the most sensible thing
12:05 < andytoshi> though whether it should be require or not .. i'm not sure
12:06 < andytoshi> but yeah, i don't feel super strongly about this. i'm apprehensive about rust-miniscript having to haul this aux bit around beside every one of our keys, when in 100% of my usage i don't care about it (because i don't derive secret keys)
12:09 < sipa> i think that's more complexith than it"s worth
12:10 < andytoshi> it may be
12:10 < andytoshi> my reasoning here is that the bit represents part of "how you derive the key"
12:10 < sipa> maybe we should think about what psbt should store
12:11 < sipa> and in function of that determine what should be in the descriptors
12:11 < andytoshi> so, current PSBT stores a key->origin map rigth?
12:11 < sipa> right
12:11 < sipa> but that's not sufficient
12:12 < sipa> i think we need a (xonlykey,optional leafhash)->origin map (and maaaaybe that origin info also contains a negation bit)
12:13 < andytoshi> can you elaborate on the leafhash
12:13 < sipa> to know what leaf it's in
12:13 < sipa> as the leaf hash goes into the signature
12:13 < andytoshi> oh! yeah ofc
12:13 < sipa> a miniscript/descriotor like signer doesn't need this
12:14 < sipa> it'd just detect the keys in the scripts
12:14 < andytoshi> yeah
12:14 < andytoshi> but ideally signers can be really dumb
12:14 < sipa> but a dumb signer that doesn't care about scripts may
12:14 < sipa> also needs a (leafhash)->(leaf version, script) map
12:16 < sipa> or ecen
12:16 < sipa> a (leafhash)->(leaf version, script, control block) map
12:16  * andytoshi needs to double check bip341
12:16 < andytoshi> but thta sounds right
12:16 < sipa> well, leaf version is in the control block
12:17 < andytoshi> so .. that map can be created by anybody who knows the full descriptor. doesn't have to be a wallet who knows extra data about the keys
12:17 < sipa> yeah
12:18 < sipa> control block is (leaf version, negation flag for tweak, inner pubkey, merkle branch)
12:18 < andytoshi> i'm tempted to say that there should be yet another map which is xonly->negation ... or maybe xonly->full pubkey
12:18 < sipa> but!
12:18 < sipa> both the leaf hash as the output pubkey are committed to by the sighash
12:19 < sipa> so i think a signer doesn't actually need to care that the provided control blocks are correct
12:19 < sipa> only that the leaf hash matches the script (if they care about the script at all)
12:19 < andytoshi> hmm ... if the signer blindly trusts the control block to have the right negation flag, it may sign with the wrong key
12:19 < andytoshi> is that more dangerous than signing the wrong data?
12:20 < andytoshi> i don't think so... but it makes me a little nervous
12:20 < sipa> if the negation flag is wrong, the witness will be invalid
12:20 < andytoshi> yeah. you're right.
12:20 < sipa> it's entirely redundant
12:20 < sipa> for fee estimation it may matter though
12:21 < sipa> you could be tricked into thinking the script you can sign for needs kilobytes of merkle branch data
12:21 < sipa> while it's near the top
12:23 < sipa> also a (leafhash)->(script, control block) map is fairly redundant; storing the whole tree with branches merged may be significantly less data
12:23 < andytoshi> hard to say
12:23 < sipa> but i feel just a leafhash-indexed map is a lot simpler to reason about
12:23 < andytoshi> probably you'd want both the map and the whole tree (optional) in PSBT
12:24 < sipa> if you have the whole map, you can infer the tree
12:24 < sipa> if you really want to
12:24 < andytoshi> right ... so i guess, bot hfields would be optional
12:24 < andytoshi> i think you're right that the map is easier to think about 
12:25 < andytoshi> but it could be really big sometimes, if you had a ton of branches and they were all potentially used
12:25 < sipa> well
12:25 < sipa> asymptotically it goes from O(n) to O(n log n)
12:25 < sipa> for a reasonably balanced tree
12:26 < sipa> which i think is the worst case situation for this, actually
12:26 < andytoshi> yeah i think you're right
12:26 < sipa> imbalanced trees will have a smaller difference between map and tree representation
12:27 < andytoshi> right
12:28 < sipa> it's how my test python signing code has worked, actually: process tree representation into a map indexed by leaf, that contains control block information for each... signing is then just looking up in the map, and copying the script and cblock
13:05 -!- jonatack_ [~jon@37.173.248.254] has joined ##miniscript
13:06 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit]
13:06 -!- jonatack_ [~jon@37.173.248.254] has joined ##miniscript
13:06 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit]
13:08 -!- jonatack_ [~jon@37.173.248.254] has joined ##miniscript
13:08 -!- jonatack_ [~jon@37.173.248.254] has quit [Client Quit]
13:09 -!- jonatack [~jon@37.166.50.22] has quit [Ping timeout: 256 seconds]
13:10 -!- jonatack [~jon@37.173.248.254] has joined ##miniscript
13:28 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 264 seconds]
13:40 -!- jonatack [~jon@37.173.248.254] has joined ##miniscript
14:03 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]
14:04 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined ##miniscript
14:13 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Read error: Connection reset by peer]
14:17 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined ##miniscript
14:19 -!- gwollon [~gwillen@unaffiliated/gwillen] has joined ##miniscript
14:19 -!- gwollon is now known as gwillen
14:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
14:25 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript
14:49 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 272 seconds]
14:54 -!- jonatack [~jon@37.173.248.254] has joined ##miniscript
15:50 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 264 seconds]
15:58 -!- jonatack [~jon@37.173.248.254] has joined ##miniscript
22:23 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
--- Log closed Thu Feb 11 00:00:26 2021