From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BC6ECC4 for ; Wed, 6 Nov 2019 16:52:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38129189 for ; Wed, 6 Nov 2019 16:52:19 +0000 (UTC) Received: by mail-qt1-f170.google.com with SMTP id y10so27628879qto.3 for ; Wed, 06 Nov 2019 08:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Xn6UHzFUk7IJ43uj42aqC1HR8SAWIHNRhcJ6D58+GVk=; b=sSsfW3Jbp5XRGXyQzw1KkzU4mnCxx8jiY4PmCA/N3yMfy/wVUvHjcN80NTSdxhg91j laXetokxJuAMU3L1XdzRHS5FcDV1NZmfHgucL3LqGpMyAC2FQ2VU/EYf1ltUt0TxkKeu QQTPKsz8VO01GDF5A8L9BdeaIX8Nhas/Anx4Bc96HsmEmafwddfiDScBdJSLrAvdy2pM 9olm14rR8tX55S/JQZx4qJIOie5KSqp4GkRFR6bK1heTw25UsPXopFFDsUj4sCBu+KXt 7DHire8wYEt6agPI0GAhPDymt5NNJKtEO8Gk8GK8zD7P1rnA1cyyUPU7PFFviOSkb/05 WwOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Xn6UHzFUk7IJ43uj42aqC1HR8SAWIHNRhcJ6D58+GVk=; b=U+LghlY/bvMrk6kY2v+R03uthOyjzAEsKKQJXSJteaG7A1ycqGd3Mx+R7d/2qEfQY/ jAqncnesf/Muo1yMWpZ/Wbd8aXRTAAa9wND2yP+zbwJQZff0y9RXm2D80hw66uW5HQ4U RemcmlwsE1SvUYTMpqR7fyFn7FcSF+ocuahO8tuf1TGSPz/iA9JWNNQlzFTJg4MGUyeh tYKMY4e+q0ozzPyni09pNW7G+8qG2Px17y+f31xCuq3hROrXBb5oE6cAjIwQ/t6JlNgV hH6u5pzgexgk0azWaR3X77skSGmnUbigq2vTStMtTBYITG4amDvZ3nlY78sazLcUqyU8 QOGA== X-Gm-Message-State: APjAAAVoLxeajjVG2oSykKZ+SxUGSOZqKWQSmRGmFcZI88a1h05kEkuq puPJ/6S3dkoWGURCtZUYnq6ioHDkgtDWKx1jMeg= X-Google-Smtp-Source: APXvYqz1xhoEP5Yep5ezkCGKINYKt1tm/D4vQH2kahcKfDRyRJip588dYyMFVqTyQgzABhwyPpqzfhsFb6AG6vQdXpc= X-Received: by 2002:ac8:70c9:: with SMTP id g9mr3285832qtp.389.1573059138013; Wed, 06 Nov 2019 08:52:18 -0800 (PST) MIME-Version: 1.0 References: <20191021000608.ajvzjxh6phtuhydp@ganymede> In-Reply-To: From: Riccardo Casatta Date: Wed, 6 Nov 2019 17:52:06 +0100 Message-ID: To: AdamISZ , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000021ce350596b05fc4" X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 06 Nov 2019 17:16:07 +0000 Subject: Re: [bitcoin-dev] Draft BIP for SNICKER X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 16:52:20 -0000 --00000000000021ce350596b05fc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Adam, are you sure you can't tackle the watch-only issue? What if the proposer create the coinjoin-tx, plus another tx (encrypted with the shared secret) which is a 1 input-1 output (1to1) tx which spend his output to another of his key. At this point when the receiver accept the proposal tx he could create other tx 1to1 which are spending his tweaked output to pure bip32 derived key, he than broadcast together the coinjoin tx and for every output of the coinjoin tx one other tx which is a 1to1 tx. Notes: * We are obviously spending more fee because there are more txs involved but the receiver ends up having only bip32 derived outputs. * The receiver must create the 1to1 tx or the receiver lose privacy by being the only one to create 1to1 tx * a good strategy could be to let the coinjoin tx have a very low fee, while the 1to1 tx an higher one so there is less risk that only the coinjoin gets mined * Whit this spending strategy, the wallet initial scan does not need to be modified Il giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> ha scritto: > 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 Receiv= er > (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 mu= st > require information secret to the two parties. This can be a pure random > sent along with the encrypted proposal (the original concept), or based o= n > such, or implicit via ECDH (arubi's suggestion, now in the draft, requiri= ng > 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 rea= l > 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 th= at > we need key access, so it reverts to the discussion above about whether i= t > 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 monitori= ng > is at least feasible, if there were enough desire for it. > > At the higher level, how important is this? I guess it just depends; ther= e > 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: > > Note Elichai's comment on the draft (repeated here for local convenience: > https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#gistcomm= ent-3014924) > about AES-GCM vs AES-CBC, any thoughts? > > 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 =3D 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. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =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-dev@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 > wallet. There are many usecases for watch-only wallets. There doesn't eve= n > necessarily need to be any offline-signing involved. For example, conside= r > 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 xp= ub > to an accountant. Or giving an xpub to your Electrum Personal Server (whi= ch > 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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --=20 Riccardo Casatta - @RCasatta --00000000000021ce350596b05fc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hel= lo Adam,

are you sure you= can't tackle the watch-only issue?

What if the proposer create the coinjoin-tx, plus another tx= (encrypted with the shared secret) which is a 1 input-1 output (1to1) tx w= hich spend his output to another of his key.
At this point when the receiver accept the pr= oposal tx he could create other tx 1to1 which are spending his tweaked outp= ut to pure bip32 derived key, he than broadcast together the coinjoin tx an= d for every output of the coinjoin tx one other tx which is a 1to1 tx.

Notes:
* We are obviously spending more fee = because there are more txs involved but the receiver ends up having only bi= p32 derived outputs.
* The re= ceiver must create the 1to1 tx or the receiver lose privacy by being the on= ly one to create 1to1 tx
* a good strategy could be to let the coinjoin tx have a very= low fee, while the 1to1 tx an higher one so there is less risk that only t= he coinjoin gets mined
* Whit this spending strategy, the wallet initial scan does not nee= d to be modified


Il giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoi= n-dev <bitcoin-= dev@lists.linuxfoundation.org> ha scritto:
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 Pr= oposer (because has to add it to transaction before signing) and Receiver (= to check ownership), but must not be known by anyone else (else Coinjoin fu= nction fails), hence it can't be publically derivable in any way but mu= st 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, requ= iring each party to access their own secret key). So I reached the same con= clusion: the classic watch-only use case of monitoring a wallet in real tim= e 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-c= ontrolling secret; it's only a privacy-controlling secret. If you imagi= ned two wallets, one hot and one cold, with the second tracking the first b= ut having a lower security requirement because cold, then the `c` values co= uld be sent along from the hot to the cold, as they are created, without ch= anging the cold's security model as they are not money-controlling priv= ate 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 telli= ng us what `c` values to look for, we have to somehow rederive, and to do t= hat we need key access, so it reverts to the discussion above about whether= it might be possible to interact with the cold wallet 'manually' s= o to speak.

To be clear, I don't think either of the above paragraphs describe thin= gs that are particularly likely to be implemented, but the hot/cold monitor= ing 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 convenienc= e: https://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= Proposer who should after all be assumed to be an attacker (except, I emph= asised that PSBT parsing could be sensitive on this point); I hope it's= clear to everyone that the construction Q =3D P + cG is only controllable = by the owner of the discrete log of P (trivial reduction: if an attacker wh= o 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 <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

> > The SNICKER recovery process is, of course, only required for wal= let
>
> recovery and not normal wallet use, so I don't think a small amoun= t 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 w= atch-only wallet. There are many usecases for watch-only wallets. There doe= sn't even necessarily need to be any offline-signing involved. For exam= ple, consider a user who has a hot wallet on their laptop with xprv; and wa= nts to watch their addresses using an xpub from their mobile. Or consider g= iving 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
Riccardo Casatta - @RCasatta
--00000000000021ce350596b05fc4--