Re: [bitcoin-dev] Draft BIP for SNICKER

[AdamISZ via bitcoin-dev]

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 precisely 
because at least one of the two participants needs to do *absolutely nothing at 
all* for the join to happen - then the degradation of blockchain analysis could 
be pretty severe.

What's described here therefore is essentially an attempt to go to the other 
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 only the Receiver 
side that's zero effort.

It should be noted that the two extremes are not incompatible; if one is 
valuable, it doesn't mean the other isn't.

But what I think you can deduce: a proposal to do SNICKER that just involved 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, especially more 
*broad* usage.

Answering about 2 party joins in more general terms:

Any such coinjoin, no matter its pattern, will break the common input ownership 
heuristic. If there are equal sized outputs of the same scriptpubkey type (as 
is proposed) then that delinking effect is of considerable value also.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
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 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
> > >  > > 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,

Re: [bitcoin-dev] Draft BIP for SNICKER

[popo via bitcoin-dev]

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 

Re: [bitcoin-dev] Draft BIP for SNICKER

[AdamISZ via bitcoin-dev]

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 
 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/2c1

Re: [bitcoin-dev] Draft BIP for SNICKER

[Riccardo Casatta via bitcoin-dev]

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> 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> wrote:
>
> > > The SNICKER recovery process is, of course, only re

Re: [bitcoin-dev] Draft BIP for SNICKER

[AdamISZ via bitcoin-dev]

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.linuxfound

Re: [bitcoin-dev] Draft BIP for SNICKER

[SomberNight via bitcoin-dev]

> 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

Re: [bitcoin-dev] Draft BIP for SNICKER

[Riccardo Casatta via bitcoin-dev]

The "Receiver" could immediately create a tx that spend the coinjoin
outputs to bip32 keys,
The hard part is that he had to delay the broadcast otherwise he loose
privacy

Il giorno lun 21 ott 2019 alle ore 02:08 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> ha scritto:

> On Sun, Oct 20, 2019 at 12:29:25AM +, SomberNight via bitcoin-dev
> wrote:
> > waxwing, ThomasV, and I recently had a discussion about implementing
> > SNICKER in Electrum; specifically the "Receiver" role.
>
> That'd be awesome!
>
> > As the referenced section [0] explains, the "Receiver" can restore
> > from seed, and assuming he knows he needs to do extra scanning steps
> > (e.g. via a seed version that signals SNICKER support), he can find
> > and regain access to his SNICKER outputs. However, to calculate `c` he
> > needs access to his private 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-only wallets.
> >
> > [0]
> https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys
>
> Your logic seems correct for the watching half of the wallet, but I
> think it's ok to consider requiring interaction with the cold wallet.
> Let's look at the recovery procedure from the SNICKER documentation
> that you kindly cited:
>
> 1. Derive all regular addresses normally (doable watch-only for
> wallets using public BIP32 derivation)
>
> 2. Find all transactions spending an output for each of those
> addresses.  Determine whether the spend looks like a SNICKER
> coinjoin (e.g. "two equal-[value] outputs").  (doable watch-only)
>
> 3. "For each of those transactions, check, for each of the two equal
> sized outputs, whether one destination address can be regenerated
> from by taking c found in the method described above" (not doable
> watch only; requires private keys)
>
> I'd expect the set of candidate transactions produced in step #2 to be
> pretty small and probably with no false positives for users not
> participating in SNICKER coinjoins or doing lots of payment batching.
> That means, if any SNICKER candidates were found by a watch-only wallet,
> they could be compactly bundled up and the user could be encouraged to
> copy them to the corresponding cold wallet using the same means used for
> PSBTs (e.g. USB drive, QR codes, etc).  You wouldn't even need the whole
> transactions, just the BIP32 index of the user's key, the pubkey of the
> suspected proposer, and a checksum of the resultant address.
>
> The cold wallet could then perform step #3 using its private keys and
> return a file/QRcode/whatever to the hot wallet telling it any shared
> secrets it found.
>
> This process may need to be repeated several times if an output created
> by one SNICKER round is spent in a subsequent SNICKER round.  This can be
> addressed by simply refusing to participate in chains of SNICKER
> transactions or by refusing to participant in chains of SNICKERs more
> than n long (requring a maximum n rounds of recovery).  It could also be
> addressed by the watching-only wallet looking ahead at the block chain a
> bit in order to grab SNICKER-like child and grandchild transactions of
> our SNICKER candidates and sending them also to the cold wallet for
> attempted shared secret recovery.
>
> 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.
>
> -Dave
> ___
> 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

Re: [bitcoin-dev] Draft BIP for SNICKER

[David A. Harding via bitcoin-dev]

On Sun, Oct 20, 2019 at 12:29:25AM +, SomberNight via bitcoin-dev wrote:
> waxwing, ThomasV, and I recently had a discussion about implementing
> SNICKER in Electrum; specifically the "Receiver" role. 

That'd be awesome!

> As the referenced section [0] explains, the "Receiver" can restore
> from seed, and assuming he knows he needs to do extra scanning steps
> (e.g. via a seed version that signals SNICKER support), he can find
> and regain access to his SNICKER outputs. However, to calculate `c` he
> needs access to his private 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-only wallets.
> 
> [0] 
> https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys

Your logic seems correct for the watching half of the wallet, but I
think it's ok to consider requiring interaction with the cold wallet.
Let's look at the recovery procedure from the SNICKER documentation
that you kindly cited:

1. Derive all regular addresses normally (doable watch-only for
wallets using public BIP32 derivation)

2. Find all transactions spending an output for each of those
addresses.  Determine whether the spend looks like a SNICKER
coinjoin (e.g. "two equal-[value] outputs").  (doable watch-only)

3. "For each of those transactions, check, for each of the two equal
sized outputs, whether one destination address can be regenerated
from by taking c found in the method described above" (not doable
watch only; requires private keys)

I'd expect the set of candidate transactions produced in step #2 to be
pretty small and probably with no false positives for users not
participating in SNICKER coinjoins or doing lots of payment batching.
That means, if any SNICKER candidates were found by a watch-only wallet,
they could be compactly bundled up and the user could be encouraged to
copy them to the corresponding cold wallet using the same means used for
PSBTs (e.g. USB drive, QR codes, etc).  You wouldn't even need the whole
transactions, just the BIP32 index of the user's key, the pubkey of the
suspected proposer, and a checksum of the resultant address.

The cold wallet could then perform step #3 using its private keys and
return a file/QRcode/whatever to the hot wallet telling it any shared
secrets it found.

This process may need to be repeated several times if an output created
by one SNICKER round is spent in a subsequent SNICKER round.  This can be
addressed by simply refusing to participate in chains of SNICKER
transactions or by refusing to participant in chains of SNICKERs more
than n long (requring a maximum n rounds of recovery).  It could also be
addressed by the watching-only wallet looking ahead at the block chain a
bit in order to grab SNICKER-like child and grandchild transactions of
our SNICKER candidates and sending them also to the cold wallet for
attempted shared secret recovery.

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.

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Draft BIP for SNICKER

[SomberNight via bitcoin-dev]

Hi all,

waxwing, ThomasV, and I recently had a discussion about implementing SNICKER in 
Electrum; specifically the "Receiver" role. To me, SNICKER is an interesting 
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 users are using 
wallets that implement the "Receiver" role, even if full nodes and specialised 
scripts are needed to run SNICKER as a "Proposer", then coinjoins via SNICKER 
could become fairly frequent on-chain, benefitting the whole ecosystem 
indirectly by breaking common chain-analysis assumptions even further.

The BIP (draft) describes how the Receiver can deterministically find all his 
outputs and reconstruct all corresponding private keys, just from the seed 
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 blockchain 
history"). [0]

Specifically, the output address in the SNICKER transaction that pays to the 
"Receiver", is constructed from the pubkey `P_A + cG`, where `P_A` is a pubkey 
of "Receiver" (typically a leaf pubkey along some BIP32 path), and `c` is a 
tweak. This tweak was constructed such that `c = ECDH(Q, P_A)`, where `Q` is a 
pubkey of the "Proposer" that appears in the witness of the SNICKER tx.

As the referenced section [0] explains, the "Receiver" can restore from seed, 
and assuming he knows he needs to do extra scanning steps (e.g. via a seed 
version that signals SNICKER support), he can find and regain access to his 
SNICKER outputs. However, to calculate `c` he needs access to his private 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-only 
wallets.
Nowadays many users expect being able to watch their addresses from an unsecure 
machine, or to be able to offline sign transactions. In the case of Electrum 
specifically, Electrum Personal Server (EPS) is also using xpubs to function. 
We've been exposing users to xpubs since the initial BIP32 implementation (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 
choice, most likely during wallet creation time, whether they want to be able 
to use xpubs or to potentially participate in SNICKER coinjoins as a "Receiver" 
(and then encode the choice in the seed version). This choice seems rather 
difficult to communicate to users. Further, if SNICKER is not supported 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 
SNICKER tx output scripts are not along any BIP32 derivation. The point here is 
whether they could somehow be identified deterministically without access 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-participants 
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 the 
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 seems 
difficult to find a sufficient construction for `c` such that it can be 
recreated by the Receiver if he only has an xpub (and access to the blockchain) 
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#Storage_of_Keys



> Hello list,
> Here is a link for a draft of a BIP for a different type of CoinJoin I've 
> named 'SNICKER' = Simple Non-Interactive Coinjoin with Keys for Encryption 
> 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 should 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 this is that it isn't a hugely difficult task for a wallet 
> developer to implement (especially: Receiver side), and it would only really 
> have value if wallet developers did indeed implement it. To be specific, it 
> requires ECDH (which is already available in libsecp256k1 anyway) and ECIES 
> wh

[bitcoin-dev] Draft BIP for SNICKER

[AdamISZ via bitcoin-dev]

Hello list,
Here is a link for a draft of a BIP for a different type of CoinJoin I've named 
'SNICKER' = Simple Non-Interactive Coinjoin with Keys for Encryption Reused.

https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79

Summary in document abstract and motivation, but also there is a more 
discursive blog post I wrote a while back, linked in the abstract, if you find 
that helpful.

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 should 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 this 
is that it isn't a hugely difficult task for a wallet developer to implement 
(especially: Receiver side), and it would only really have value if wallet 
developers did indeed implement it. To be specific, it requires ECDH (which is 
already available in libsecp256k1 anyway) and ECIES which is pretty easy to do 
(just ecdh and hmac, kinda).

Plenty of uncertainty on the specs, in particular the specification for 
transactions, 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

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev