Re: [bitcoin-dev] Draft BIP for SNICKER

[popo <PoliceTerror@dyne.org>]

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 <https://protonmail.com> Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, November 6, 2019 4:52 PM, Riccardo Casatta via bitcoin-dev
> <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 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
>> <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 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
>>     <bitcoin-dev@lists.linuxfoundation.org
>>     <mailto: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 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
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto: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
>