Just to chime in on these points:
My discussions with ghost43 and ThomasV led me to the same conclusion, at least in general, for the whole watch-only issue:
It's necessary that the key tweak (`c` as per draft BIP) be known by Proposer (because has to add it to transaction before signing) and Receiver (to check ownership), but must not be known by anyone else (else Coinjoin function fails), hence it can't be publically derivable in any way but must require information secret to the two parties. This can be a pure random sent along with the encrypted proposal (the original concept), or based on such, or implicit via ECDH (arubi's suggestion, now in the draft, requiring each party to access their own secret key). So I reached the same conclusion: the classic watch-only use case of monitoring a wallet in real time with no privkey access is incompatible with this.
It's worth mentioning a nuance, however: distinguish two requirements: (1) to recover from zero information and (2) to monitor in real time as new SNICKER transactions arrive.
For (2) it's interesting to observe that the tweak `c` is not a money-controlling secret; it's only a privacy-controlling secret. If you imagined two wallets, one hot and one cold, with the second tracking the first but having a lower security requirement because cold, then the `c` values could be sent along from the hot to the cold, as they are created, without changing the cold's security model as they are not money-controlling private keys. They should still be encrypted of course, but that's largely a technical detail, if they were exposed it would only break the effect of the coinjoin outputs being indistinguishable.
For (1) the above does not apply; for there, we don't have anyone telling us what `c` values to look for, we have to somehow rederive, and to do that we need key access, so it reverts to the discussion above about whether it might be possible to interact with the cold wallet 'manually' so to speak.
To be clear, I don't think either of the above paragraphs describe things that are particularly likely to be implemented, but the hot/cold monitoring is at least feasible, if there were enough desire for it.
At the higher level, how important is this? I guess it just depends; there are similar problems (not identical, and perhaps more addressable?) in Lightning; importing keys is generally non-trivial; one can always sweep non-standard keys back into the HD tree, but clearly that is not really a solution in general; one can mark out wallets/seeds of this type as distinct; not all wallets need to have watch-only (phone wallets? small wallets? lower security?) one can prioritise spends of these coins. Etc.
Some more general comments:
I didn't discuss the security of the construction for a Receiver from a Proposer who should after all be assumed to be an attacker (except, I emphasised that PSBT parsing could be sensitive on this point); I hope it's clear to everyone that the construction Q = P + cG is only controllable by the owner of the discrete log of P (trivial reduction: if an attacker who knows c, can find the private key q of Q, he can derive the private key p of P as q - c, thus he is an ECDLP cracker).
Thanks for all the comments so far, it's been very useful.
AdamISZ/waxwing/Adam Gibson
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > The SNICKER recovery process is, of course, only required for wallet
>
> recovery and not normal wallet use, so I don't think a small amount of
> round-trip communication between the hot wallet and the cold wallet is
> too much to ask---especially since anyone using SNICKER with a
> watching-only wallet must be regularly interacting with their cold
> wallet anyway to sign the coinjoins.
>
> What you described only considers the "initial setup" of a watch-only wallet. There are many usecases for watch-only wallets. There doesn't even necessarily need to be any offline-signing involved. For example, consider a user who has a hot wallet on their laptop with xprv; and wants to watch their addresses using an xpub from their mobile. Or consider giving an xpub to an accountant. Or giving an xpub to your Electrum Personal Server (which is how it works).
>
> Note that all these usecases require "on-going" discovery of addresses, and so they would break.
>
> ghost43
>
> (ps: Apologies Dave for the double-email; forgot to cc list originally)
>
> bitcoin-dev mailing list
_______________________________________________
bitcoin-dev mailing list