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 9AF2EF37 for ; Tue, 22 Oct 2019 13:21:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5384C896 for ; Tue, 22 Oct 2019 13:21:07 +0000 (UTC) Date: Tue, 22 Oct 2019 13:21:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1571750465; bh=GDmhqn5K32xmGIJe2M3WBlcVVxI30DKCUGdlMZVGXG4=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=uDtZbn6LpDxBrASISc51mAj3AF6X0KzSIkWe2z4weDZNymuEczL6OOkr5ER8Ap9nR hX8m4RmyYWyJFBvJvhzMHrzaFuQ7jPm+d2dr4zwz74H8xtOgw1A3sTvf2kELwwJHAk WylF4i/gtuIystQhNMzbM4ClPQYQ8QvqwiqlVrrI= To: SomberNight , Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: References: <20191021000608.ajvzjxh6phtuhydp@ganymede> Feedback-ID: bXDrzvuRufYtwlP51LbX1U1HVhop5RoBgHwub9Drp1-jSqeBk7WF1gtL3tVf_bUUZyA1LgUYiqtef7oP8A2trw==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 22 Oct 2019 13:28:32 +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: Tue, 22 Oct 2019 13:21:09 -0000 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 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