Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id F2092C18DA for ; Fri, 22 Nov 2019 15:07:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id AD68520469 for ; Fri, 22 Nov 2019 15:07:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab3MF3qghuCi for ; Fri, 22 Nov 2019 15:07:39 +0000 (UTC) X-Greylist: delayed 00:09:20 by SQLgrey-1.7.6 Received: from vm6.ganeti.dyne.org (vm6.ganeti.dyne.org [195.169.149.119]) by silver.osuosl.org (Postfix) with ESMTPS id 8ADD020448 for ; Fri, 22 Nov 2019 15:07:39 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: policeterror@dyne.org) with ESMTPSA id A6F0AF60B85 To: bitcoin-dev@lists.linuxfoundation.org References: <20191021000608.ajvzjxh6phtuhydp@ganymede> From: popo Message-ID: Date: Fri, 22 Nov 2019 15:57:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 22 Nov 2019 15:13:32 +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: Fri, 22 Nov 2019 15:07:43 -0000 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 because > of the cost implication. > I'd note though that your idea about adding in second-stage transactions > 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 Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, November 6, 2019 4:52 PM, Riccardo Casatta via bitcoin-dev > 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 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 >> > > 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 anyone >> 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, requiring >> 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 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 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 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 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; 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#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 this >> point); I hope it's clear to everyone that the construction Q = 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. >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> 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 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >