📅 Original date posted:2019-11-06
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191106/8c5a95bc/attachment.html>;
Riccardo Casatta [ARCHIVE] /
npub13t…yxl7q
2023-06-07 18:21:29
in reply to nevent1q…9vjj
Author Public Key
npub13t8gempry5dh8dkjw2m9wc0j4wu5kxlk9jxtwf24350fx2gtlqksmyxl7qPublished at
2023-06-07 18:21:29Event JSON
{
"id": "c6b942ac78bf62f7c482dbdff3904feb2890709aab6125ea4a486041d51e6f82",
"pubkey": "8ace8cec23251b73b6d272b65761f2abb94b1bf62c8cb725558d1e93290bf82d",
"created_at": 1686162089,
"kind": 1,
"tags": [
[
"e",
"0b6cab19e3ebe66be93fe581d0ea0bbc0bdabc78f062662d38f259a2c73bc26b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2019-11-06\n📝 Original message:Hello Adam,\n\nare you sure you can't tackle the watch-only issue?\n\nWhat if the proposer create the coinjoin-tx, plus another tx (encrypted\nwith the shared secret) which is a 1 input-1 output (1to1) tx which spend\nhis output to another of his key.\nAt this point when the receiver accept the proposal tx he could create\nother tx 1to1 which are spending his tweaked output to pure bip32 derived\nkey, he than broadcast together the coinjoin tx and for every output of the\ncoinjoin tx one other tx which is a 1to1 tx.\n\nNotes:\n* We are obviously spending more fee because there are more txs involved\nbut the receiver ends up having only bip32 derived outputs.\n* The receiver must create the 1to1 tx or the receiver lose privacy by\nbeing the only one to create 1to1 tx\n* a good strategy could be to let the coinjoin tx have a very low fee,\nwhile the 1to1 tx an higher one so there is less risk that only the\ncoinjoin gets mined\n* Whit this spending strategy, the wallet initial scan does not need to be\nmodified\n\n\nIl giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e ha scritto:\n\n\u003e Just to chime in on these points:\n\u003e\n\u003e My discussions with ghost43 and ThomasV led me to the same conclusion, at\n\u003e least in general, for the whole watch-only issue:\n\u003e\n\u003e It's necessary that the key tweak (`c` as per draft BIP) be known by\n\u003e Proposer (because has to add it to transaction before signing) and Receiver\n\u003e (to check ownership), but must not be known by anyone else (else Coinjoin\n\u003e function fails), hence it can't be publically derivable in any way but must\n\u003e require information secret to the two parties. This can be a pure random\n\u003e sent along with the encrypted proposal (the original concept), or based on\n\u003e such, or implicit via ECDH (arubi's suggestion, now in the draft, requiring\n\u003e each party to access their own secret key). So I reached the same\n\u003e conclusion: the classic watch-only use case of monitoring a wallet in real\n\u003e time with no privkey access is incompatible with this.\n\u003e\n\u003e It's worth mentioning a nuance, however: distinguish two requirements: (1)\n\u003e to recover from zero information and (2) to monitor in real time as new\n\u003e SNICKER transactions arrive.\n\u003e\n\u003e For (2) it's interesting to observe that the tweak `c` is not a\n\u003e money-controlling secret; it's only a privacy-controlling secret. If you\n\u003e imagined two wallets, one hot and one cold, with the second tracking the\n\u003e first but having a lower security requirement because cold, then the `c`\n\u003e values could be sent along from the hot to the cold, as they are created,\n\u003e without changing the cold's security model as they are not\n\u003e money-controlling private keys. They should still be encrypted of course,\n\u003e but that's largely a technical detail, if they were exposed it would only\n\u003e break the effect of the coinjoin outputs being indistinguishable.\n\u003e\n\u003e For (1) the above does not apply; for there, we don't have anyone telling\n\u003e us what `c` values to look for, we have to somehow rederive, and to do that\n\u003e we need key access, so it reverts to the discussion above about whether it\n\u003e might be possible to interact with the cold wallet 'manually' so to speak.\n\u003e\n\u003e To be clear, I don't think either of the above paragraphs describe things\n\u003e that are particularly likely to be implemented, but the hot/cold monitoring\n\u003e is at least feasible, if there were enough desire for it.\n\u003e\n\u003e At the higher level, how important is this? I guess it just depends; there\n\u003e are similar problems (not identical, and perhaps more addressable?) in\n\u003e Lightning; importing keys is generally non-trivial; one can always sweep\n\u003e non-standard keys back into the HD tree, but clearly that is not really a\n\u003e solution in general; one can mark out wallets/seeds of this type as\n\u003e distinct; not all wallets need to have watch-only (phone wallets? small\n\u003e wallets? lower security?) one can prioritise spends of these coins. Etc.\n\u003e\n\u003e Some more general comments:\n\u003e\n\u003e Note Elichai's comment on the draft (repeated here for local convenience:\n\u003e https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#gistcomment-3014924)\n\u003e about AES-GCM vs AES-CBC, any thoughts?\n\u003e\n\u003e I didn't discuss the security of the construction for a Receiver from a\n\u003e Proposer who should after all be assumed to be an attacker (except, I\n\u003e emphasised that PSBT parsing could be sensitive on this point); I hope it's\n\u003e clear to everyone that the construction Q = P + cG is only controllable by\n\u003e the owner of the discrete log of P (trivial reduction: if an attacker who\n\u003e knows c, can find the private key q of Q, he can derive the private key p\n\u003e of P as q - c, thus he is an ECDLP cracker).\n\u003e\n\u003e Thanks for all the comments so far, it's been very useful.\n\u003e\n\u003e AdamISZ/waxwing/Adam Gibson\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Monday, October 21, 2019 4:04 PM, SomberNight via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e \u003e The SNICKER recovery process is, of course, only required for wallet\n\u003e \u003e\n\u003e \u003e recovery and not normal wallet use, so I don't think a small amount of\n\u003e \u003e round-trip communication between the hot wallet and the cold wallet is\n\u003e \u003e too much to ask---especially since anyone using SNICKER with a\n\u003e \u003e watching-only wallet must be regularly interacting with their cold\n\u003e \u003e wallet anyway to sign the coinjoins.\n\u003e \u003e\n\u003e \u003e What you described only considers the \"initial setup\" of a watch-only\n\u003e wallet. There are many usecases for watch-only wallets. There doesn't even\n\u003e necessarily need to be any offline-signing involved. For example, consider\n\u003e a user who has a hot wallet on their laptop with xprv; and wants to watch\n\u003e their addresses using an xpub from their mobile. Or consider giving an xpub\n\u003e to an accountant. Or giving an xpub to your Electrum Personal Server (which\n\u003e is how it works).\n\u003e \u003e\n\u003e \u003e Note that all these usecases require \"on-going\" discovery of addresses,\n\u003e and so they would break.\n\u003e \u003e\n\u003e \u003e ghost43\n\u003e \u003e\n\u003e \u003e (ps: Apologies Dave for the double-email; forgot to cc list originally)\n\u003e \u003e\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\n\n-- \nRiccardo Casatta - @RCasatta \u003chttps://twitter.com/RCasatta\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191106/8c5a95bc/attachment.html\u003e",
"sig": "fed7a6918508ae1f42e646f345ceea99a65d772ff77fc11cb9f859035216c2c1a52226444f317909e5eccc53ae0929955288315354d932efb927f6aad091168b"
}