Date: Tue, 22 Oct 2019 13:21:00 +0000
To: SomberNight <somber.night@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <mq_HOhcWf2T7ik9Em3nb5VCePi5cV17Wf_c8qS5zWwXh0vnJVzBO_q6Nl8RQBJysBOhZC2rjAw3hbq2tHIoEyTKE8QQaJgF9LpgpcP0Nl8g=@protonmail.com>
In-Reply-To: <clOIQUf5e2vT3KqKplQwrS5MgB8ptPDSQWkpOMGoAE3rS90i7y-8mNRmcecfVJwiYePhNYAfFlBYsOKqvavm4yVI-zEfo8pnG6AY_fiyMXs=@protonmail.com>
References: <YwZ3vq20LFvpx-nKn1RJjcRHwYTAVCC0v0EyD0y6zVMlQtKXUFNAaEk_QE2dzYDU6z2eK0S0TDXRPfl1_y93RgDjdCGboOgjcERBTLUPHao=@protonmail.com>
	<20191021000608.ajvzjxh6phtuhydp@ganymede>
	<clOIQUf5e2vT3KqKplQwrS5MgB8ptPDSQWkpOMGoAE3rS90i7y-8mNRmcecfVJwiYePhNYAfFlBYsOKqvavm4yVI-zEfo8pnG6AY_fiyMXs=@protonmail.com>
Feedback-ID: bXDrzvuRufYtwlP51LbX1U1HVhop5RoBgHwub9Drp1-jSqeBk7WF1gtL3tVf_bUUZyA1LgUYiqtef7oP8A2trw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Draft BIP for SNICKER
Precedence: list

Just to chime in on these points:

My discussions with ghost43 and ThomasV led me to the same conclusion, at l=
east in general, for the whole watch-only issue:

It's necessary that the key tweak (`c` as per draft BIP) be known by Propos=
er (because has to add it to transaction before signing) and Receiver (to c=
heck ownership), but must not be known by anyone else (else Coinjoin functi=
on fails), hence it can't be publically derivable in any way but must requi=
re information secret to the two parties. This can be a pure random sent al=
ong with the encrypted proposal (the original concept), or based on such, o=
r implicit via ECDH (arubi's suggestion, now in the draft, requiring each p=
arty 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 pr=
ivkey 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 SNI=
CKER transactions arrive.

For (2) it's interesting to observe that the tweak `c` is not a money-contr=
olling 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 havin=
g a lower security requirement because cold, then the `c` values could be s=
ent along from the hot to the cold, as they are created, without changing t=
he cold's security model as they are not money-controlling private keys. Th=
ey should still be encrypted of course, but that's largely a technical deta=
il, if they were exposed it would only break the effect of the coinjoin out=
puts being indistinguishable.

For (1) the above does not apply; for there, we don't have anyone telling u=
s 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 t=
hat 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 Ligh=
tning; importing keys is generally non-trivial; one can always sweep non-st=
andard keys back into the HD tree, but clearly that is not really a solutio=
n 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 se=
curity?) one can prioritise spends of these coins. Etc.

Some more general comments:

Note Elichai's comment on the draft (repeated here for local convenience: h=
ttps://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#gistcomment=
-3014924) about AES-GCM vs AES-CBC, any thoughts?

I didn't discuss the security of the construction for a Receiver from a Pro=
poser who should after all be assumed to be an attacker (except, I emphasis=
ed that PSBT parsing could be sensitive on this point); I hope it's clear t=
o everyone that the construction Q =3D P + cG is only controllable by the o=
wner 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.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, October 21, 2019 4:04 PM, SomberNight via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

> > 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 wal=
let. There are many usecases for watch-only wallets. There doesn't even nec=
essarily need to be any offline-signing involved. For example, consider a u=
ser who has a hot wallet on their laptop with xprv; and wants to watch thei=
r 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, a=
nd so they would break.
>
> ghost43
>
> (ps: Apologies Dave for the double-email; forgot to cc list originally)
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev