--- Log opened Sat Mar 25 00:00:21 2023
01:17 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
07:23 -!- jonatack2 [~jonatack@user/jonatack] has joined ##miniscript
07:25 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
08:13 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 276 seconds]
16:02 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has joined ##miniscript
16:31 < andytoshi> sipa: so, i think it would be useful to be able to specify xpubs where the seed is inline
16:31 < andytoshi> for wallet imports, mainly
16:31 <@sipa> if it's just for import, that's easy
16:31 < andytoshi> yeah, i only care about import here
16:32 <@sipa> as you'd just implement it in the parser
16:32 < andytoshi> yeah
16:32 < andytoshi> so, i'm happy to do that .. but then i need to write a spec and so on
16:33 <@sipa> if you also want the ability to dump the private descriptor that lists the seed... that's a lot harfer
16:33 <@sipa> harder
16:33 < andytoshi> i wonder if i should extend the codex32 spec to describe bip32 paths. it feels out of scope for codex32
16:33 < andytoshi> hmm, yeah, true
16:33 < andytoshi> i probably do want the ability to export as well
16:34 < andytoshi> so, right now isn't there a way i can write bip32 paths starting from a fingerprint?
16:34 < andytoshi> maybe i just want to add the ability to import/export seed->fingerprint mappings
16:34 < andytoshi> independent of descriptors
16:35 <@sipa> the issue is that the data structure that stores private keys only works from pubkeyhash to privkey
16:35 <@sipa> and an xprv internally just doesn't exist, it's an xpub with additional master private key stored in the keystore
16:35 <@sipa> which on private dump can be recombined into an xprv
16:36 < andytoshi> ok, i think i can work wit that
16:36 < andytoshi> though i'm a bit confused -- is the master chaincode stored somewhere?
16:36 <@sipa> in the xpub
16:36 < andytoshi> ok, makes sense
16:37 < andytoshi> so, i'd be fine then with a way to just add additional master privkeys, on import (throwing away the seed)
16:37 <@sipa> yeah that's easy
16:37 < andytoshi> this is, i think, how we'd originally imagined using codex32. and i'd thought that the sethdseed RPC was how to do it
16:38 < andytoshi> so maybe i want to just add a new RPC, "addhdseed" or something, which sticks stuff in the keystore, and maybe outputs the master xpub
16:38 < andytoshi> and "listhdseeds" which lists the available master xpubs maybe .. and you'd still need to use "dumpwallet" to get any private data out
16:39 <@sipa> listdescriptors can dump private material too
16:39 <@sipa> but if you just implement it at parse time, then listdescriptor will just give the converter xprv, rather than the seed
16:40 < andytoshi> right. that is what i'm planning to do
16:40 < andytoshi> ok, so i'd have an "addhdseed" ... there'd be no "listhdseeds", i misspoke there, because we don't store the seed
16:40 < andytoshi> but there'd maybe be a "listmasterkeys"
16:41 <@sipa> sounds like you don't need anything at all then as new RPC? just implement the seed to xprv conversion in the descriptor parsing
16:41 < andytoshi> well if i do that then i need a spec for how the seed data fits into a string-encoded key :)
16:41 -!- salvatoshi [~salvatosh@lfbn-idf3-1-1331-187.w92-170.abo.wanadoo.fr] has quit [Ping timeout: 265 seconds]
16:41 < andytoshi> vs if i just add a separate RPC, i can just take codex32 strings
16:42 <@sipa> and then you can import "wpkh(codex32(....))" or so as descriptor, and it'd be converted to the equivalent "wpkh(xprv...)"
16:42 < andytoshi> and wpkh(codex32(...)/44h/0h/1/2/3) etc?
16:43 <@sipa> right
16:43 < andytoshi> ok, cool, i think i can go aheda and do that
16:43 < andytoshi> codex32 has a bip, the only ad-hoc thing i'm doing here is sticking codex32() around it
16:43 < andytoshi> wellll almost. i also want the ability to provide multiple shares, rather than a single seed
16:44 < andytoshi> so i might do codex32({share a, share c, share d})
16:44 < andytoshi> s/ //g
16:44 <@sipa> or just codex32(share_a,share_b,...)
16:44 < andytoshi> oh, yeah, that's much nicer
16:44 < andytoshi> and obviouser
16:45 < andytoshi> ok perfect, i'm happy now. i'll start working on implementing this, and mabye can have a PR before the weekend is over
16:45 < andytoshi> also i guess we shoulda stayed in #bitcoin-core-dev after all :P
17:00 < andytoshi> one mildly annoying thing is that importdescriptors wants a valid checksum, but if i'm importing a descriptor i wrote myself, and which core won't output, it's hard to get that
17:00 < andytoshi> though if i just tack #xxxxxxxx onto the end, the error message will tell me the correct checksum
17:01 < andytoshi> and like, it's a bch code that uses gf32 ... so i could do it by hand :P
17:06 <@sipa> getdescriptorinfo can also compute the checksum
18:01 < andytoshi> thanks!
20:01 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined ##miniscript
--- Log closed Sun Mar 26 00:00:21 2023