--- Day changed Thu Oct 31 2019
01:45 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 246 seconds]     
01:55 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]     
02:07 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##hwi     
02:28 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
04:55 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 268 seconds]     
04:57 -!- jonatack [~jon@37.165.214.234] has joined ##hwi     
06:35 < instagibbs> if you don't have them in the keypool you also cant sign for them so :P
06:36 < instagibbs> for offline setups I would just make 10k+ keys or whatever
06:46 -!- jonatack [~jon@37.165.214.234] has quit [Read error: Connection reset by peer]     
08:51 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi     
09:09 < ghost43> achow101: still thinking about root fp and derivation prefix in PSBTs... :) You mentioned at one point that cosigners participating in a multisig might not want to reveal their full paths / root fp to each other for privacy reasons. I don't think we have fully fleshed this out. I am also trying to construct a solution that can avoid the extra RTT of everyone running their Updater before anyone can sign. Further note that the trezor (e.g.) requires all
09:10 < ghost43> intermediate xpubs to be available for multisig change detection (let's assume a hypothetical future when trezor has implemented native PSBT support for now). I would like the first cosigner to be able to construct a PSBT that her hardware signer will already sign. Using BIP174, currently I see no convenient way to overcome all this. I would need to fill in the PSBT_GLOBAL_UNSIGNED_TX for all cosigners, but that field requires a root fp and derivation
09:10 < ghost43> prefix, that I might not have for the others. I could of course fake them, e.g. by converting the xpub to a root (blank out the depth, child index, parent fp fields), but then that might result in issues later when other cosigners who do know the correct details get to see the psbt. Although of course the other signers might "fix" the faked fields if they run them through their updater as well. There are many inconveniences, e.g. the faking involved
09:10 < ghost43> changing the global xpub which means the first cosigner might also need to take care to remove the faked PSBT_GLOBAL_UNSIGNED_TX fields (as the xpub itself might not be recognised by anyone else). Note that the fact we can fake the root fp and the der prefix already means they are kind of useless (but the BIP mandates their presence). How about instead, there could be a new PSBT_GLOBAL_PRIVACY_XPUB (name TBA), only-key kv field. The user would put the
09:10 < ghost43> intermediate xpub of all cosigners there. Then, for the inputs and outputs, e.g. PSBT_IN_BIP32_DERIVATION, the fp there would be of the intermediate xpub's fp, and the path would be only the derivation suffix. Participants could figure out which GLOBAL_XPUB belongs to which input/output key by comparing the fingerprints. With this, the user that creates the original PSBT, assuming they know all the intermediate xpubs (but that is enough!) of all
09:10 < ghost43> cosigners, can create the inputs and outputs and fill in all the PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION and PSBT_GLOBAL_PRIVACY_XPUB fields in a consistent way with which everyone would be happy.
09:12 < ghost43> if you think it's reasonable I can write a mailing list post and also a PR for the BIP.
09:18 < achow101> i don't see how PSBT_GLOBAL_PRIVACY_XPUB would allow for anything different from PSBT_GLOBAL_XPUB
09:19 < ghost43> well first of all the first cosigner could add that kv field for all cosigners without having to know their key origin info
09:19 < achow101> right, but it's perfectly fine to just fake an intermediate as a root
09:20 < ThomasV> it's dirty to fake it
09:20 < ghost43> well at the very least, with the current phrasing in the BIP, I don't think implementers actually considered that PSBT_IN_BIP32_DERIVATION might contain a non-full path
09:20 < achow101> when it gets to the real updater for those keys, (in both cases) it would overwrite the PSBT_IN_BIP32_DERIVATION for its own keys, sees that there isn't a global xpub for them (because the intermediate won't match), and then add the correct xpub with deriv
09:21 < achow101> but either way PSBT_IN_BIP32_DERIVATION would have a non-full path anyways
09:22 < ghost43> well if we added a new PSBT_GLOBAL_PRIVACY_XPUB, that would make it clear that they might not contain the full path; at least it would have to be rephrased such that
09:22 < ThomasV> ..but then the updater needs to cleanup the psbt after it has been signed, before passing it to others, or it will leak the full derivation path
09:23 < ghost43> I think that clean-up is needed in either case actually
09:24 < ghost43> the hardware signer will want the full path for its own keys
09:24 < ghost43> (somewhere)
09:24 < achow101> The hardware wallet must have the full path. If you want deriv path privacy, you must cleanup after signing
09:39 < ghost43> achow101: okay. we will do the faking (convert xpubs to roots, inputs contain der suffix only)
09:40 < ghost43> thank you for your help re all the pestering :)
09:48 < ghost43> although one thing that I would still really like to be clarified in the BIP is whether signers want full paths in PSBT_IN_BIP32_DERIVATION. I think that is not made clear anywhere. Specifically it would be nice if signers also supported having just a der suffix there, and they would be able to build a full path from the der prefix in PSBT_GLOBAL_XPUB and the der suffix in PSBT_IN_BIP32_DERIVATION  (recognising what's going on by looking at the
09:48 < ghost43> fingerprint)
09:49 < ghost43> this would btw save space
09:50 < ghost43> it might already be supported btw; ThomasV interpreted the BIP as such; but to me at least it's not clear at all whether this is supposed to work or not
09:53 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
10:00 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds]     
10:22 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 268 seconds]     
10:22 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
10:26 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds]     
10:27 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
10:41 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds]     
10:46 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined ##hwi     
11:58 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds]     
13:23 < instagibbs> sorry what's "der prefix"
13:50 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi     
14:51 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]     
19:27 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi     
19:34 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds]     
19:48 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined ##hwi     
19:52 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]     
20:54 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds]     
21:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]     
21:25 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##hwi     
21:31 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined ##hwi     
22:20 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##hwi     
23:07 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds]     
23:29 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has joined ##hwi     
23:45 -!- ThomasV_ [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds]