📅 Original date posted:2019-10-21
📝 Original message: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 at 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 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/20191021/51924e75/attachment.html>;
Riccardo Casatta [ARCHIVE] /
npub13t…yxl7q
2023-06-07 18:21:21
in reply to nevent1q…2qzh
Author Public Key
npub13t8gempry5dh8dkjw2m9wc0j4wu5kxlk9jxtwf24350fx2gtlqksmyxl7qPublished at
2023-06-07 18:21:21Event JSON
{
"id": "587c1dc29d835d8cc77fc9c97cb7e222179ecfb23fbb6f9613ec224261ee7443",
"pubkey": "8ace8cec23251b73b6d272b65761f2abb94b1bf62c8cb725558d1e93290bf82d",
"created_at": 1686162081,
"kind": 1,
"tags": [
[
"e",
"4eebbc8bc3daff40ccfd7cd861b40fbefe0a195e36a48c2dc4b9476bb3ec5980",
"",
"root"
],
[
"e",
"6e696723874273fd581ef89f3f8cf6840908f73c2f76590382a0618823209c13",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2019-10-21\n📝 Original message:The \"Receiver\" could immediately create a tx that spend the coinjoin\noutputs to bip32 keys,\nThe hard part is that he had to delay the broadcast otherwise he loose\nprivacy\n\nIl giorno lun 21 ott 2019 alle ore 02:08 David A. Harding via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e ha scritto:\n\n\u003e On Sun, Oct 20, 2019 at 12:29:25AM +0000, SomberNight via bitcoin-dev\n\u003e wrote:\n\u003e \u003e waxwing, ThomasV, and I recently had a discussion about implementing\n\u003e \u003e SNICKER in Electrum; specifically the \"Receiver\" role.\n\u003e\n\u003e That'd be awesome!\n\u003e\n\u003e \u003e As the referenced section [0] explains, the \"Receiver\" can restore\n\u003e \u003e from seed, and assuming he knows he needs to do extra scanning steps\n\u003e \u003e (e.g. via a seed version that signals SNICKER support), he can find\n\u003e \u003e and regain access to his SNICKER outputs. However, to calculate `c` he\n\u003e \u003e needs access to his private keys, as it is the ECDH of one of the\n\u003e \u003e Receiver's pubkeys and one of the Proposer's pubkeys.\n\u003e \u003e\n\u003e \u003e This means the proposed scheme is fundamentally incompatible with\n\u003e \u003e watch-only wallets.\n\u003e \u003e\n\u003e \u003e [0]\n\u003e https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys\n\u003e\n\u003e Your logic seems correct for the watching half of the wallet, but I\n\u003e think it's ok to consider requiring interaction with the cold wallet.\n\u003e Let's look at the recovery procedure from the SNICKER documentation\n\u003e that you kindly cited:\n\u003e\n\u003e 1. Derive all regular addresses normally (doable watch-only for\n\u003e wallets using public BIP32 derivation)\n\u003e\n\u003e 2. Find all transactions spending an output for each of those\n\u003e addresses. Determine whether the spend looks like a SNICKER\n\u003e coinjoin (e.g. \"two equal-[value] outputs\"). (doable watch-only)\n\u003e\n\u003e 3. \"For each of those transactions, check, for each of the two equal\n\u003e sized outputs, whether one destination address can be regenerated\n\u003e from by taking c found in the method described above\" (not doable\n\u003e watch only; requires private keys)\n\u003e\n\u003e I'd expect the set of candidate transactions produced in step #2 to be\n\u003e pretty small and probably with no false positives for users not\n\u003e participating in SNICKER coinjoins or doing lots of payment batching.\n\u003e That means, if any SNICKER candidates were found by a watch-only wallet,\n\u003e they could be compactly bundled up and the user could be encouraged to\n\u003e copy them to the corresponding cold wallet using the same means used for\n\u003e PSBTs (e.g. USB drive, QR codes, etc). You wouldn't even need the whole\n\u003e transactions, just the BIP32 index of the user's key, the pubkey of the\n\u003e suspected proposer, and a checksum of the resultant address.\n\u003e\n\u003e The cold wallet could then perform step #3 using its private keys and\n\u003e return a file/QRcode/whatever to the hot wallet telling it any shared\n\u003e secrets it found.\n\u003e\n\u003e This process may need to be repeated several times if an output created\n\u003e by one SNICKER round is spent in a subsequent SNICKER round. This can be\n\u003e addressed by simply refusing to participate in chains of SNICKER\n\u003e transactions or by refusing to participant in chains of SNICKERs more\n\u003e than n long (requring a maximum n rounds of recovery). It could also be\n\u003e addressed by the watching-only wallet looking ahead at the block chain a\n\u003e bit in order to grab SNICKER-like child and grandchild transactions of\n\u003e our SNICKER candidates and sending them also to the cold wallet for\n\u003e attempted shared secret recovery.\n\u003e\n\u003e The SNICKER recovery process is, of course, only required for wallet\n\u003e recovery and not normal wallet use, so I don't think a small amount of\n\u003e round-trip communication between the hot wallet and the cold wallet is\n\u003e too much to ask---especially since anyone using SNICKER with a\n\u003e watching-only wallet must be regularly interacting with their cold\n\u003e wallet anyway to sign the coinjoins.\n\u003e\n\u003e -Dave\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/20191021/51924e75/attachment.html\u003e",
"sig": "496543f246bee7a71610533772571e5bc690ba5d0dc8967068035eadc87f993edb20633bb44aa2ec3ffc47941417e0f8c81585c9907d9e60ba80161986419933"
}