* Re: [bitcoin-dev] Draft BIP for SNICKER
@ 2019-10-20 0:29 SomberNight
2019-10-21 0:06 ` David A. Harding
0 siblings, 1 reply; 10+ messages in thread
From: SomberNight @ 2019-10-20 0:29 UTC (permalink / raw)
To: 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 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-10-20 0:29 [bitcoin-dev] Draft BIP for SNICKER SomberNight
@ 2019-10-21 0:06 ` David A. Harding
2019-10-21 11:00 ` Riccardo Casatta
2019-10-21 15:04 ` SomberNight
0 siblings, 2 replies; 10+ messages in thread
From: David A. Harding @ 2019-10-21 0:06 UTC (permalink / raw)
To: SomberNight, Bitcoin Protocol Discussion
On Sun, Oct 20, 2019 at 12:29:25AM +0000, 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-10-21 0:06 ` David A. Harding
@ 2019-10-21 11:00 ` Riccardo Casatta
2019-10-21 15:04 ` SomberNight
1 sibling, 0 replies; 10+ messages in thread
From: Riccardo Casatta @ 2019-10-21 11:00 UTC (permalink / raw)
To: David A. Harding via bitcoin-dev; +Cc: SomberNight
[-- Attachment #1: Type: text/plain, Size: 4063 bytes --]
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 +0000, 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 <https://twitter.com/RCasatta>
[-- Attachment #2: Type: text/html, Size: 5276 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-10-21 0:06 ` David A. Harding
2019-10-21 11:00 ` Riccardo Casatta
@ 2019-10-21 15:04 ` SomberNight
2019-10-22 13:21 ` AdamISZ
1 sibling, 1 reply; 10+ messages in thread
From: SomberNight @ 2019-10-21 15:04 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
> 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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-10-21 15:04 ` SomberNight
@ 2019-10-22 13:21 ` AdamISZ
2019-11-06 16:52 ` Riccardo Casatta
0 siblings, 1 reply; 10+ messages in thread
From: AdamISZ @ 2019-10-22 13:21 UTC (permalink / raw)
To: SomberNight, Bitcoin Protocol Discussion
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 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-10-22 13:21 ` AdamISZ
@ 2019-11-06 16:52 ` Riccardo Casatta
2019-11-22 14:02 ` AdamISZ
0 siblings, 1 reply; 10+ messages in thread
From: Riccardo Casatta @ 2019-11-06 16:52 UTC (permalink / raw)
To: AdamISZ, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6596 bytes --]
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 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 <https://twitter.com/RCasatta>
[-- Attachment #2: Type: text/html, Size: 8508 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-11-06 16:52 ` Riccardo Casatta
@ 2019-11-22 14:02 ` AdamISZ
2019-11-22 14:57 ` popo
0 siblings, 1 reply; 10+ messages in thread
From: AdamISZ @ 2019-11-22 14:02 UTC (permalink / raw)
To: Riccardo Casatta, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7326 bytes --]
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> 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 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](https://twitter.com/RCasatta)
[-- Attachment #2: Type: text/html, Size: 10041 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-11-22 14:02 ` AdamISZ
@ 2019-11-22 14:57 ` popo
2019-11-23 12:43 ` AdamISZ
0 siblings, 1 reply; 10+ messages in thread
From: popo @ 2019-11-22 14:57 UTC (permalink / raw)
To: 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 <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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Draft BIP for SNICKER
2019-11-22 14:57 ` popo
@ 2019-11-23 12:43 ` AdamISZ
0 siblings, 0 replies; 10+ messages in thread
From: AdamISZ @ 2019-11-23 12:43 UTC (permalink / raw)
To: popo, Bitcoin Protocol Discussion
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 <bitcoin-dev@lists•linuxfoundation.org> 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
> > > <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
>
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 10+ messages in thread
* [bitcoin-dev] Draft BIP for SNICKER
@ 2019-09-01 13:46 AdamISZ
0 siblings, 0 replies; 10+ messages in thread
From: AdamISZ @ 2019-09-01 13:46 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2043 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-11-23 12:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-20 0:29 [bitcoin-dev] Draft BIP for SNICKER SomberNight
2019-10-21 0:06 ` David A. Harding
2019-10-21 11:00 ` Riccardo Casatta
2019-10-21 15:04 ` SomberNight
2019-10-22 13:21 ` AdamISZ
2019-11-06 16:52 ` Riccardo Casatta
2019-11-22 14:02 ` AdamISZ
2019-11-22 14:57 ` popo
2019-11-23 12:43 ` AdamISZ
-- strict thread matches above, loose matches on Subject: below --
2019-09-01 13:46 AdamISZ
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox