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 6507240B for ; Sun, 20 Oct 2019 00:29:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0ABD5F8 for ; Sun, 20 Oct 2019 00:29:34 +0000 (UTC) Date: Sun, 20 Oct 2019 00:29:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1571531372; bh=CrWp2hBaALQIYMt6JrK16kqm0k57zMwsKsiPBLXwYwA=; h=Date:To:From:Cc:Reply-To:Subject:Feedback-ID:From; b=cITqzvem174VKxC0qmlSEir9B4Q70FRcz7iHnzYtJEG1QSqxoN4OaCkJo6Kj0IRqY +RhaHTL17GKmvn0fEE0oh4HJxteU79EeEv6DdNTGLYBMgocFtz6j/syfO36HE6l9mu 16jzfD+BPJQoojUsv02hNMVGB502cARYybuC/6a0= To: "bitcoin-dev@lists.linuxfoundation.org" From: SomberNight Reply-To: SomberNight Message-ID: Feedback-ID: daQbrs0DpmRrllQYkksiX-ZnvUtz6D5CoTQt69spWvfuKGSaRC1oU4kOBEGTrhNvt_RBDz2CWSzCwYz6Ytdxzw==: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: Sun, 20 Oct 2019 04:30:58 +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: Sun, 20 Oct 2019 00:29:36 -0000 Hi all, waxwing, ThomasV, and I recently had a discussion about implementing SNICKE= R in Electrum; specifically the "Receiver" role. To me, SNICKER is an inter= esting proposal, due to the non-interactivity and because it seems it would= be easy to implement the "Receiver" role in a light wallet. If enough user= s are using wallets that implement the "Receiver" role, even if full nodes = and specialised scripts are needed to run SNICKER as a "Proposer", then coi= njoins via SNICKER could become fairly frequent on-chain, benefitting the w= hole ecosystem indirectly by breaking common chain-analysis assumptions eve= n further. The BIP (draft) describes how the Receiver can deterministically find all h= is outputs and reconstruct all corresponding private keys, just from the se= ed words and the blockchain. However what is not explicitly pointed out, and what I would like to point = out in this mail, is that SNICKER breaks watch-only functionality. See "Receiver actions" > "Storage of Keys" section ("Re-derive from blockch= ain history"). [0] Specifically, the output address in the SNICKER transaction that pays to th= e "Receiver", is constructed from the pubkey `P_A + cG`, where `P_A` is a p= ubkey of "Receiver" (typically a leaf pubkey along some BIP32 path), and `c= ` is a tweak. This tweak was constructed such that `c =3D ECDH(Q, P_A)`, wh= ere `Q` is a pubkey of the "Proposer" that appears in the witness of the SN= ICKER tx. As the referenced section [0] explains, the "Receiver" can restore from see= d, and assuming he knows he needs to do extra scanning steps (e.g. via a se= ed version that signals SNICKER support), he can find and regain access to = his SNICKER outputs. However, to calculate `c` he needs access to his priva= te keys, as it is the ECDH of one of the Receiver's pubkeys and one of the = Proposer's pubkeys. This means the proposed scheme is fundamentally incompatible with watch-onl= y wallets. Nowadays many users expect being able to watch their addresses from an unse= cure machine, or to be able to offline sign transactions. In the case of El= ectrum specifically, Electrum Personal Server (EPS) is also using xpubs to = function. We've been exposing users to xpubs since the initial BIP32 implem= entation (and even predating BIP32, in the legacy Electrum HD scheme, there= were already "master public keys"). It would seem that if we implemented SNICKER, users would have to make a ch= oice, most likely during wallet creation time, whether they want to be able= to use xpubs or to potentially participate in SNICKER coinjoins as a "Rece= iver" (and then encode the choice in the seed version). This choice seems r= ather difficult to communicate to users. Further, if SNICKER is not support= ed by the default choice then it is less likely to take off and hence less = useful for the user; OTOH if xpubs are not supported by the default choice = then existing user expectations are broken. (Note that I am using a loosened definition of xpub here. The pubkeys in SN= ICKER tx output scripts are not along any BIP32 derivation. The point here = is whether they could somehow be identified deterministically without acces= s to secret material.) Unfortunately it is not clear how the SNICKER scheme could be adjusted to "= fix" this. Note that `c` needs to be known exactly by the two coinjoin-part= icipants and no-one else; otherwise the anonymity set (of 2) is broken as: - which SNICKER output corresponds to the tweaked public key and hence to t= he Receiver, can then be identified (as soon as the output is spent and the= pubkey appears on-chain), and - using subset-sum analysis the inputs and the outputs can be linked SNICKER assumes almost no communication between the two parties, so it seem= s difficult to find a sufficient construction for `c` such that it can be r= ecreated by the Receiver if he only has an xpub (and access to the blockcha= in) as all pubkeys from the xpub that the Proposer would have access to are= already public information visible on-chain. ghost43 [0] https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storag= e_of_Keys > Hello list, > Here is a link for a draft of a BIP for a different type of CoinJoin I've= named 'SNICKER' =3D Simple Non-Interactive Coinjoin with Keys for Encrypti= on Reused. > > https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79 > > Purpose of writing this as a BIP: > There was some discussion on the Wasabi repo about this recently (https:/= /github.com/zkSNACKs/Meta/issues/67) and it prompted me to do something I s= hould have done way back when I came up with the idea in late '17: write a = technical specification, because one of the main attractive points about th= is is that it isn't a hugely difficult task for a wallet developer to imple= ment (especially: Receiver side), and it would only really have value if wa= llet developers did indeed implement it. To be specific, it requires ECDH (= which is already available in libsecp256k1 anyway) and ECIES which is prett= y easy to do (just ecdh and hmac, kinda). > > Plenty of uncertainty on the specs, in particular the specification for t= ransactions, e.g. see 'Partially signed transactions' subsection, point 3).= Also perhaps the encryption specs. I went with the exact algo already used= by Electrum here, but it could be considered dubious (CBC). > > Thanks for any feedback. > > Adam Gibson / waxwing