From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Belcher <belcher@riseup•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Date: Wed, 03 Jun 2020 04:53:52 +0000 [thread overview]
Message-ID: <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com> (raw)
In-Reply-To: <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
Good morning Chris,
> > Good morning Ruben and Chris,
>
> > I am not in fact convinced that PayJoin-with-CoinSwap adds that much privacy.
> > These transactions:
> >
> > +---+ +---+
> > Alice ---| |--| |--- Bob
> > Alice ---| | | |
> > Bob ---| | +---+
> > +---+
> >
> >
> > Are not really much different in coin ownership analysis from these:
> >
> > +---+ +---+
> > Alice ---| |----| |--- Bob
> > Alice ---| | +--| |
> > +---+ | +---+
> > Bob ---------+
> >
>
> The main benefit of PayJoin-with-CoinSwap is it breaks the
> common-input-ownership heuristic, which is a major widely used
> heuristic. It would be a big win if that heuristic could be broken.
>
> PayJoin-with-CoinSwap would be useful if Alice is trying to recover some
> privacy which was previously degraded, for example if she is spending
> from a reused address or from an address linked to her identity. If she
> does a PayJoin with the reused address then some other economic entity
> would have his activity linked with Alice's.
>
> Just the fact that PayJoin-with-CoinSwap exists would improve privacy
> for people who don't use it, for example if someone buys bitcoin from an
> exchange that knows their identity and then co-spends it with other
> coins they obtained another way. The fact that PayJoin exists means an
> adversary cannot assume for sure that this user really owns that other
> address which was co-spent. This doesn't apply for regular CoinSwap,
> which only ever breaks the transaction graph heuristic, so in our
> example the destination the coins are sent to would be uncertain, but
> that the co-spent inputs are owned by the same person would be certain
> in a world where PayJoin didn't exist.
Alice can do PayJoin with a payee Carol that supports normal PayJoin, for similar overall results.
Though I suppose there is a mild advantage still with supporting it on the funding tx of the first transaction, as you noted.
> > But S6 has the mild advantage that all the funding transactions paying to 2-of-2s can appear on the same block, whereas chaining swaps will have a particular order of when the transactions appear onchain, which might be used to derive the order of swaps.
>
> On the other hand, funds claiming in S6 is also ordered in time, so
> someone paying attention to the mempool could guess as well the order of
> swaps.
>
> I think this is wrong, and that it's possible for the funding
> transactions of chained/routed swaps to all be in the same block as well.
>
> In CoinSwap it's possible to get DOS'd without the other side spending
> money if you broadcast your funding transaction first and the other side
> simply disappears. You'd get your money back but you have to waste time
> and spend miner fees. The other side didn't spend money to do this, not
> even miner fees.
>
> From the point of view of us as a maker in the route, we know we won't
> get DOS'd like this for free if we only broadcast our funding
> transaction once we've seen the other side's funding transaction being
> broadcast first. This should work as long as the two transactions have a
> similar fee rate. There might be an attack involving hash power: If the
> other side has a small amount of hash power and mines only their funding
> transaction in a manner similar to a finney attack, then our funding
> transaction should get mined very soon afterwards by another miner and
> the protocol will continue as normal. If the other side has knowledge of
> the preimage and uses it to do CPFP and take the money, then we can
> learn that preimage and do our own CPFP to get our money back too.
How about RBF?
A taker Alice can broadcast the funding tx spending its own funds.
The funding tx spends funds controlled unilaterally by Alice.
Alice can sign a replacement transaction for those funds, spending them to an address with unilateral control, and making the funding tx output with all the obligations attached never get confirmed in the first place.
The chances may be small --- Bob can certainly monitor for Alice broadcasting a replacement and counter-broadcast its own replacement --- but the risk still exists.
TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice could arrange the replacement by other means, such as not using the RBF-enabled flag, broadcasting the self-paying replacement near miner nodes, and broadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob fullnode will then reject attempts to replace it, but miners will also reject the CoinSwap-expected funding tx and it will not confirm anyway.
With the pre-SAS 4-tx setup, this potentially allows Alice to steal the funds of Bob; after Alice gets its funding-tx-replacement confirmed together with the Bob honest-funding-tx, Alice can use the contract transaction and publish the preimage to take the Bob funds.
Since the Alice-side funding tx has been replaced, knowledge of the hash preimage will not help Bob any: the Alice funding tx has been replaced and Bob cannot use the preimage to claim it (it does not exist).
With SAS Alice cannot outright steal the Bob funds, but the Bob funds will now be locked in a 2-of-2 and Alice can take it hostage (either Bob gives up on the funds, i.e. donates its value to all HODLers, or Bob gives most of the value to Alice).
For the avoidance of theft, it is probably better for Bob to wait for Alice-side funding tx to confirm, probably deeply because reorgs suck.
This at least makes it costly to perform this attack; you have to lock more of your funds longer in order to induce a competitor to lock its funds.
Come to think of it, the same issue probably holds for S6 as well, the funding tx with the longest timelock has to confirm first before the next is even broadcast, bleah.
> An interesting tangent could be to see if it's possible to make private
> key handover work with S6. A nice side-effect of private key handover is
> that the transfer of possession of the coins happens off-chain, so then
> paying attention to the mempool won't help an adversary much.
It certainly seems quite possible; each participant in S6 has a fixed "previous" and "next" participant.
Of course, this requires a secure tunnel, and my understanding of your plan for SwapMarket is that the taker Alice serves as the broadcast medium between all makers and itself.
So, in an S6 sequence of Alice -> Bob1 -> Bob2 -> Alice, after Alice provides the preimage, Bob2 encrypts the private key being handed over in an asymmetric encryption that only Alice can open (e.g. using some known pubkey of Alice, there are many to choose from), Bob1 similarly encrypts its privkey for Bob2, and Alice encrypts the private key to Bob1, and Alice can then broadcast all those data to all participants, and only the correct participant will be able to decrypt it.
---
On another privacy-related note, S6 mildly leaks to each maker its position in the route, via the timelocks.
Each Bob has to know the timelocks it is offered and which it will offer to the next participant, and the timelocks will be larger the further away that Bob is from the Alice taker.
This is a mild privacy leak, one that seems unremovable to me.
(It also exists in Lightning Network as well: we suggest the use of "shadow routes" to artificially increase the distance of forwarding nodes, as a mitigation.)
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-06-03 4:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 13:21 Chris Belcher
2020-05-30 16:00 ` Ruben Somsen
2020-05-31 2:30 ` ZmnSCPxj
2020-05-31 21:19 ` Ruben Somsen
2020-06-01 2:34 ` ZmnSCPxj
2020-06-01 10:19 ` Ruben Somsen
2020-06-02 22:24 ` Chris Belcher
2020-06-03 4:53 ` ZmnSCPxj [this message]
2020-06-03 14:50 ` ZmnSCPxj
2020-06-04 16:37 ` ZmnSCPxj
2020-06-05 22:39 ` Chris Belcher
2020-06-06 1:40 ` ZmnSCPxj
2020-06-06 3:59 ` ZmnSCPxj
2020-06-06 4:25 ` ZmnSCPxj
2020-06-10 10:15 ` Chris Belcher
2020-06-10 10:58 ` ZmnSCPxj
2020-06-10 11:19 ` Chris Belcher
2020-06-10 0:43 ` Mr. Lee Chiffre
2020-06-10 0:46 ` Mr. Lee Chiffre
2020-06-10 7:09 ` ZmnSCPxj
2020-06-10 11:15 ` Chris Belcher
2020-06-19 15:33 ` Jonas Nick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox