--- Day changed Fri Oct 18 2019 00:26 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined ##hwi 00:43 -!- jonatack_ [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Quit: jonatack_] 00:43 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined ##hwi 02:48 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 04:23 -!- jonatack [~jon@185.28.187.26] has joined ##hwi 07:22 < achow101> ghost43: have you read through the descriptors docs in the core repo? 07:23 < achow101> the only things that really need to be shared are an xpub followed by the derivation path each cosigner wants to use 07:27 < achow101> the key origin information does not necessarily have to be given, and you probably don't actually want to for privacy reasons 07:43 -!- jonatack [~jon@185.28.187.26] has quit [Ping timeout: 245 seconds] 08:48 < ghost43> achow101: see e.g. https://github.com/spesmilo/electrum/issues/5672#issuecomment-541042680 08:48 < ghost43> what do you mean by key origin here specifically? 08:49 < ghost43> (yes, I've read output script descriptors doc) 08:49 < achow101> Fingerprint and derivation path for the xpub. It's the stuff in [...] before the xpub 08:49 < ghost43> what would you put in the PSBT in that case? 08:50 < ghost43> I assume you are suggesting leaving out the PSBT_GLOBAL_XPUB key then 08:50 < ghost43> what about PSBT_IN_BIP32_DERIVATION fields? 08:50 < achow101> what I mean is that not every software wallet needs to necessarily know everyone else's fingerprint and derivation path 08:51 < achow101> that info can be added by the cosigners during the psbt updating step 08:51 < achow101> obviously it's easier to have everyone know them so they don't need to have multiple rounds of communication 08:54 < achow101> ghost43: why not just make a descriptor and pass those around to everyone to then be combined into the multi descriptor? 08:55 < ghost43> well what is the descriptor in this case? the partial one? there does not seem to be a format specified for that 08:55 < achow101> e.g. each person provides sh(wpkh([...]xpub.../*) which then means the multisig is sh-wsh and the keys are there 08:56 < achow101> also gets the benefit of the checksum 08:56 < ghost43> ahh yes that could work but it's kind of weird... converting from wpkh to wsh 08:58 < ghost43> and it will break later, with e.g. witness v1. now you can guess that the wpkh guy wants wsh for multisig but when there are multiple favours of multisig itself... well. 08:58 < achow101> istm it's kind of like sharing x/y/zpub as electrum does now. both describe the keys and scriptPubKeys in the wallet 08:58 < ghost43> yes exactly, my headache is how replace the sharing of x/y/zpub that we are doing now 08:59 < ghost43> I've now documented this btw at https://github.com/spesmilo/electrum/issues/5715 08:59 < achow101> with witness v1, there will be other descriptors things added 08:59 < ghost43> sure but my point is that there might not be a clean map from single sig to multi sig anymore then 08:59 < ghost43> you cannot really make that assumption that there will 08:59 < achow101> so if someone wanted a taproot multisig, they would send tap(...xpub..) 09:00 < achow101> right.. 09:03 < ghost43> to be perfectly honest, part of my headache is also that I am almost done implementing PSBT in electrum; and I did not foresee having to also implement output script descriptors as a dependency... I am not sure I have the time for it now; but I would like to get the PSBT changes merged soonish because it's a change both very deep and with large depth, it affects most of the code, which means it is a nightmare in terms of conflicts. so I am selfishly 09:03 < ghost43> also trying to consider solutions that *for the moment* don't need output script descriptors also implemented (because to do that properly, that would also be a huge amount of work) 09:03 < ghost43> large depth and breadth* 09:04 < ghost43> although we could parse/serialize descriptors and only support the ones that correspond to what the wallet logic already has 09:05 < ghost43> another issue is that a descriptor actually is not enough because it cannot represent a m/0/i (receive), m/1/j (change) hierarchy 09:05 < ghost43> you need to use two descriptors for that, and other metadata to distinguish them... 09:05 < ghost43> sooooooo it's a mess 09:06 < ghost43> at least sortedmulti now exists because that too is needed :) 09:08 < achow101> maybe we should add new syntax that indicates different derivation paths 09:08 < achow101> re key sharing, maybe instead send a 1-of-1 multi descriptor instead of pkh? 09:09 < ghost43> yes maybe. how is this handled in HWI btw? 09:09 < achow101> it isn't 09:10 < ghost43> so it's only for users that are advanced enough to manually construct the descriptor? 09:10 < achow101> pretty much 09:11 < ghost43> what would be really nice is syntax for the m/0/i (receive), m/1/j (change) hierarchy 09:11 < ghost43> I think basically all light wallets use this atm; so maybe it could be special cased 09:11 < ghost43> it must be the overwhelming majority of usecases of anything involving an xpub 09:12 < achow101> perhaps xpub..{0/*,1/*} 09:12 < achow101> curly braces are already part of the acceptable characters 09:14 < ghost43> if this syntax existed, electrum could transition temporarily to use "KEY" expressions instead of xpubs. and then at a later time we could implement descriptors :) 09:16 < achow101> i'll talk to sipa about it 09:16 < ghost43> thank you 09:24 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 09:34 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 10:33 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has joined ##hwi 10:59 < achow101> ghost43: fyi https://github.com/bitcoin/bitcoin/issues/17190 13:51 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Quit: jonatack] 13:53 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 14:03 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 14:32 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 15:19 < ghost43> ty, I commented there 15:20 < ghost43> "achow101> what I mean is that not every software wallet needs to necessarily know everyone else's fingerprint and derivation path" << back to this point for a bit; I would like to understand this better. What is exactly included in the PSBT and when; so e.g. 15:20 < ghost43> re PSBT_IN_BIP32_DERIVATION, the bip says "The master key fingerprint as defined by BIP 32 concatenated with the derivation path of the public key" 15:20 < ghost43> so to me that suggests you need to put the full derivation path there 15:22 < ghost43> say there is a 2of3 multisig input between A, B, C. A constructs a psbt, he only knows his own full deriv info; only has intermediate xpub and derivation suffixes for B and C. what does A put into the fields for this input PSBT_IN_BIP32_DERIVATION key? 15:24 < ghost43> what is even "master fingerprint" in this case 15:25 < ghost43> or are you suggesting that when setting up the wallet B and C modified their intermediate xpubs, changed the depth field to 0, the parent fp to 0, the child index to 0, and pretended that their intermediate xpubs are actually roots 15:26 < ghost43> and then they have logic at signing time to resolve this and identify themselves 15:27 < ghost43> because ISTM that A needs to put some PSBT_IN_BIP32_DERIVATION key-value for B and for C as well into the input map as otherwise they cannot figure out how to derive that key 15:28 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 15:32 < achow101> ghost43: what I mean is that each signer know all of their own keys and their derivation paths. when a psbt is passed to them, they can then add in the key derivation info themselves so it can be passed to the actual signer with private keys 15:32 < ghost43> how could a signer figure out the derivation path to a pubkey? 15:33 < ghost43> you mean they have a prebuilt index with some gap limit? 15:33 < achow101> signer is not the right term here 15:33 < achow101> more like updater 15:33 < achow101> The thing that watches the blockchain for inputs and outputs and has all of the info that is needed to give to another signer 15:33 < achow101> s/another signer/the thing that has the private keys 15:34 < ghost43> ok so what would the updater put there? they would put the whole path now? 15:35 < achow101> yes, the updater would add the full paths and xpubs 15:35 < ghost43> ok so in case of inputs I assume it's reasonable that a cosigner might sign if his own path is there but there is no derivation info for the other keys involved. it's reasonable 15:35 < ghost43> but then let's talk about outputs and change detection 15:36 < ghost43> any reasonable validation before signing would want derivation info there for *all* keys to derive the keys themselves 15:36 < achow101> not necessarily 15:36 < ghost43> this is what the coldcard does for example 15:37 < ghost43> well if you cannot derive the pubkeys involved in the change yourself then you cannot be sure you are not being robbed 15:37 < ghost43> (which I guess is a vulnerability at the moment with e.g. trezor if you use say 2of3 multisig) 15:37 < achow101> first, we need to assume that everyone is following this same policy: if the threshold is greater than n/2, so long as a key that I control is in an output, I consider that output to be change and sign 15:38 < achow101> Now if someone was malicious and replaced another person's keys with their own, then they will not be able to replace enough keys to reach the threshold, someone will always fail to sign because they do not see their key there 15:38 < ghost43> why is it related to n/2? in 2of3, just because 1 key is yours, both others might be malicious 15:39 < achow101> in a 2 of 3, if one person is malicious and replaces the other signer with their own, the other signer will not sign and the transaction fails 15:39 < achow101> n/2 is because the attacker will be able to replace to the threshold if <= n/2 15:40 < ghost43> I guess I don't understand how the replacing works 15:41 < achow101> suppose a 2 of 3 with pk1, pk2, pk3 15:41 < achow101> now if pk3 is malicious and replaces pk2 with pk3', the multisig becomes pk1, pk3, pk3' 15:42 < achow101> oh wait, i think i forgot a step 15:45 < ghost43> oh wait one thing I was missing is that you define change to be something that uses the same policy as the inputs; so actually trezor is not vulnerable 15:45 < ghost43> as you can compare xpubs there 15:46 < achow101> oh ok, i remember now 15:47 < achow101> if an attacker replaces the "change" to pk1, pk3, and pk3', the signer for pk2 will see that the "change" does not include him and see that more money is leaving than he is expecting, so he fails to sign. thus the transaction fails 15:48 < achow101> in this model, the definition of change is "the policy of the output includes me" 15:50 < ghost43> ok so that's fine I guess. but so you are changing the security model to this n/2 thing? Critically it's not just that cosigners should be able to spend the input they should also be able to *find* it; deterministically restore from the script descriptor (e.g.) 15:50 < ghost43> if ANY key is replaced deterministic restore does not work 15:50 < ghost43> or at least they will not recognise the address as theirs 15:51 < ghost43> sure you can argue that they can spend *IF* they still have the PSBT (lol..) 15:52 < achow101> yeah, this is more of a signing policy thing for dumb signers, not the wallet side of things 15:52 < ghost43> basically any serious signer would only sign if they can derive all the keys from xpubs 15:52 < ghost43> so my question is still; what do you expect updaters to put into the PSBT_OUT_BIP32_DERIVATION field 15:53 < ghost43> because ISTM you need the full path 15:54 < ghost43> and also the corresponding inputs values actually, as the signers should validate that inputs and change output have the same policy 15:55 < achow101> updatesr need to put the path from whatever xpub they put in PSBT_GLOBAL_XPUB 15:55 < achow101> err, that's not quite right 15:56 < achow101> to make it simple, just put the full path 15:56 < ghost43> "the key origin information does not necessarily have to be given, and you probably don't actually want to for privacy reasons" 15:56 < ghost43> so what about that point? :P 15:56 < achow101> you can do the intermediate xpub thing 15:57 < ghost43> you mean faking an intermediate xpub to be a root? 15:57 < achow101> yes 15:57 < ghost43> "The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key." << so you would need to change all the fields in the xpub; but ok 15:57 < achow101> yes 15:58 < ghost43> but then the issue is that when this PSBT is given to a hw wallet signer device, it won't be able to derive the keys 15:58 < ghost43> because the PSBT now does not contain the derivation prefix 15:58 < ghost43> that the hw device neeeds 15:59 < achow101> so then the software wallet needs to know that it put an intermediate and modify the psbt prior to passing to the signer 16:01 < ghost43> not only that but *after* signing change it back 16:01 < ghost43> it's a mess 16:02 < achow101> it's only really a concern if you consider derivation paths to be private-ish information 16:03 < ghost43> well the reason I started thinking about this is because currently in electrum if you restore from a "master public key" which is an intermediate xpub, you will not be able to create "valid" PSBTs basically 16:04 < ghost43> hence all the "parallel" discussion of output script descriptors 16:04 < achow101> ah, so you'd want to restore from an xpub with key origin info 16:05 < ghost43> yes, it's basically why I want to use KEY expression or something along those lines to describe a cosigner 16:05 < ghost43> it's almost the same issues 16:05 < ghost43> -s 16:06 < achow101> w.r.t KEY checksum, you can just make a valid descriptor checksum at the end of it 16:06 < achow101> "valid". it's basically bech32 with a different charset and polynomial 16:10 < ghost43> yes ok, not a bad idea; will think about it 16:12 < ghost43> another horrible thing is that this data (root fp, deriv prefix) is simply not available for existing wallet files; so there is basically no upgrade path 16:13 < ghost43> (well deriv prefix is available for hw keystores specifically but only those) 16:14 < achow101> you don't store the seed or master key? 16:14 < ghost43> well for an xpub-only wallet for example? 16:15 < ghost43> I detail this in point 2 of https://github.com/spesmilo/electrum/issues/5715 16:16 < achow101> i wouldn't expect that the signer for a watch-only electrum wallet to not also be electrum 16:17 < achow101> so maybe it wouldn't be unreasonable for electrum to also consider the standard xpub it exports as a root 16:17 < achow101> and just do the whole intermediate key thing, but it's less painful because you don't need to mutate the psbt back and forth 16:19 < ghost43> you mean re upgrades or in general? because in general the signer could be a coldcard for example 16:20 < achow101> upgrades 16:20 < achow101> if it were coldcard, that would have been initialized with the correct info, no? 16:20 < ghost43> well if it has a hardware keystore 16:21 < ghost43> but it could conceivably, because of psbt support, have a bip32 xpub only keystore 16:21 < ghost43> specifically; if the user constructs a watch only wallet from the xpub only 16:21 < ghost43> the user would expect to be able to create PSBTs that a coldcard would sign 16:21 < ghost43> but this is not the case 16:21 < achow101> but it wouldn't, and it doesn't now, does it? 16:22 < achow101> if you made a watch only using a coldcard xpub, would you be able to make a psbt now that you could give the coldcard to sign? 16:23 < ghost43> no, not now, because coldcard hacked some small subset of PSBT into their electrum plugin that is only available at all in specific cases 16:23 < ghost43> so this is only going forward; as with "native psbt support" this can happen 16:24 < achow101> right, so nothing changes, and I don't think it is reasonable for people who do that to expect that an upgrade would 16:28 < achow101> or you could just do what we did in core which was basically that you had to make a new watch only wallet if you wanted psbt to have all the derivation path stuff 16:29 < achow101> since derivation info was never something that could be imported before 16:31 < ghost43> well in Core the way you implemented PSBT support is as an addon to all existing stuff, right? so specifically the old raw transaction stuff is still there and is compatible? 16:32 < ghost43> in this case this might be reasonable to do; but I actually want to rip out our custom format that we currently use because I don't want to have all that code and it would make the GUI really complicated if there were competing formats 16:32 < ghost43> so that means you need to able to create PSBTs to keep doing what you already worked in the past 16:33 < ghost43> so that means if you cannot create PSBTs your wallet is basically broken :) 16:35 < ghost43> in any case, I will figure out something re upgrades, don't worry about that. the main issue what to replace xpubs with in the wizard/etc 16:39 < achow101> yeah, we just left all the old raw tx stuff there 16:39 < achow101> with xpub stuff, in the proposed syntax for the multiple derivation paths, how would you handle if someone gave non-standard derivation paths? 16:42 < ghost43> well right now I would just reject them. but I assume you mean longer term, which one I would use as change? 16:43 < achow101> yeah 16:44 < ghost43> I don't know.. there's no good answer there 16:45 < achow101> since sipa and ryanofsky were saying that this seems like something which doesn't belong in descriptors themselves but rather a layer above it 16:46 < achow101> maybe we should make "wallet descriptors" which includes output descriptors and other metadata 16:48 < ghost43> well my issue specifically is about constructing these kind of things; descriptors (either for output script, or even whole wallet) 16:48 < ghost43> what cosigners should share with each other 16:49 < ghost43> you could use a wallet descriptor (or the changed syntax output script descriptor) for a watch only single-signer wallet though 16:49 < achow101> right 16:50 < ghost43> I am considering using [abcd0123/48h/0h/0h/2h]xpub661My... 16:50 < ghost43> without der suffix 16:50 < ghost43> where m/0/i and m/1/j is implied I mean 16:51 < ghost43> one issue is that this then overloads an existing interpretation you have 16:51 < ghost43> which is of a single key derived at the xpub as a leaf 16:52 < achow101> right. and that would not be good if someone were to want to use core as one of the cosigners 16:52 < achow101> well, core as a cosigner right now just doesn't work at all since we don't use xpubs 16:55 < achow101> do you so any downsides of ryanofsky's suggestion of just a big json string with both? 17:09 < ghost43> well it does not look unreasonable; for technical users I guess it would be fine, for average users though I think it might be a bit weird that they are copy-pasting these json strings around. I mean if the users are not exposed to this because of say using QR codes (which they can also do ofc) I wouldn't really care, but because of the copy-paste usecase I think it at least *looks* a bit ugly :) I don't really have a better response atm 17:10 < achow101> just base64 encode it so it looks like special magic sauce :) 17:10 < ghost43> hmmm :) 17:49 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 265 seconds] 17:55 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##hwi 21:06 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 22:01 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 22:35 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 22:40 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 265 seconds] 22:49 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined ##hwi 23:06 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]