From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C098C087F for ; Sat, 23 Nov 2019 12:43:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 3AE1985B94 for ; Sat, 23 Nov 2019 12:43:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V_BQAn_FWYP for ; Sat, 23 Nov 2019 12:43:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by fraxinus.osuosl.org (Postfix) with ESMTPS id AEADD85A74 for ; Sat, 23 Nov 2019 12:43:35 +0000 (UTC) Date: Sat, 23 Nov 2019 12:43:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1574513013; bh=tHFTB3lhnabyqxOc84UzfrRxRZwanPq/WdTxcqYl0n4=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=qkUI2359thPRp6GEAQ/xECCKXdl9nfaaQ1eC3NvNxFDQExF4RJq0Q/WJuhPnde900 kEhdThvujIc1HZoCWhKRoi9j8m4yBTSwmABiI22S3BzcC/R5qiErDNZd3EF70I6nY7 oIlmatxeb2+4skr7k3ihHlqWyEuu6sHmZHJcXzQg= To: popo , Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: <_KQ9Rhe6FCZjxJX7inBrWnwtHG0K-aiK7LBf7xhlyrbUr_zNC_A3Act3MiOJ1wl9S7mFwIlVl29H6tmP6SLWk-S5zUzsFOVexKiVGUC_1i4=@protonmail.com> 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-Mailman-Approved-At: Sat, 23 Nov 2019 13:17:19 +0000 Subject: Re: [bitcoin-dev] Draft BIP for SNICKER X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2019 12:43:38 -0000 Two party mixes can be useful in the context of a very large number of them= . There is no pretence that doing one such, or even doing several such, gives= any privacy *guarantees*. However, if it can be arranged that such 'mixes' occur frequently across a = broad spectrum of wallets - and the claim is that that is possible precisel= y because at least one of the two participants needs to do *absolutely noth= ing at all* for the join to happen - then the degradation of blockchain ana= lysis could be pretty severe. What's described here therefore is essentially an attempt to go to the othe= r far extreme from 'rigidly controlled and coordinated large mix sets' to '= ultra loosely coupled almost zero coordination mixing', trading off size in= one step for convenience/low effort/even zero effort mixing. Part of that = may (or may not) involve Proposers being specialised entities, and it's onl= y the Receiver side that's zero effort. It should be noted that the two extremes are not incompatible; if one is va= luable, it doesn't mean the other isn't. But what I think you can deduce: a proposal to do SNICKER that just involve= d a very small set of users would not be much use (still not zero, though);= the tradeoffs have been made having in mind the idea of more usage, especi= ally more *broad* usage. Answering about 2 party joins in more general terms: Any such coinjoin, no matter its pattern, will break the common input owner= ship heuristic. If there are equal sized outputs of the same scriptpubkey t= ype (as is proposed) then that delinking effect is of considerable value al= so. 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 Friday, November 22, 2019 2:57 PM, popo via bitcoin-dev wrote: > Hi, AFAIK snicker is limited to 2 party mixes for the foreseeable future. > What makes this a useful anonymity system for cryptocurrency/Bitcoin? > > Thanks > > On 11/22/19 3:02 PM, AdamISZ via bitcoin-dev wrote: > > > Hi Riccardo, > > Apologies for not answering before, this slipped my mind. > > Clearly what you propose is possible, and adding the proposer's own > > signed transaction is a nice touch to make it more privacy-viable. > > For now my inclination is not to add this complexity, especially becaus= e > > of the cost implication. > > I'd note though that your idea about adding in second-stage transaction= s > > aligns with the CoinJoinXT idea (or perhaps, just the segwit idea!). > > Proposers could send sequences of transactions with various patterns, > > including backouts and promises, but it would clearly be way more > > complicated than what we're considering right now. > > Regards, > > Adam/waxwing > > Sent with ProtonMail https://protonmail.com Secure Email. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= =90 > > On Wednesday, November 6, 2019 4:52 PM, Riccardo Casatta via bitcoin-de= v > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > 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 creat= e > > > 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 outpu= ts. > > > > > > - 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 f= ee, > > > 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 bitcoin-dev > > > > > mailto: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 Receiver (to check ownership), but must not be known by anyon= e > > > 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, requirin= g > > > each party to access their own secret key). So I reached the same > > > conclusion: the classic watch-only use case of monitoring a walle= t > > > 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 secon= d > > > tracking the first but having a lower security requirement becaus= e > > > 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 th= e > > > 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 describ= e > > > 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; on= e > > > 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#= 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 emphasised that PSBT parsing could be sensitive on thi= s > > > 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 > > > > > > 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 c= old > > > > 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@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 > > > > > > > > > -- > > > Riccardo Casatta - @RCasatta https://twitter.com/RCasatta > > > > 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