Date: Wed, 03 Jun 2020 04:53:52 +0000
To: Chris Belcher <belcher@riseup.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>
In-Reply-To: <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
 <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
 <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
	massively improving Bitcoin privacy and fungibility
Precedence: list

Good morning Chris,

> > Good morning Ruben and Chris,
>
> > I am not in fact convinced that PayJoin-with-CoinSwap adds that much pr=
ivacy.
> > 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 s=
imilar 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 u=
sed 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 a=
ll the obligations attached never get confirmed in the first place.

The chances may be small --- Bob can certainly monitor for Alice broadcasti=
ng 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 c=
ould arrange the replacement by other means, such as not using the RBF-enab=
led flag, broadcasting the self-paying replacement near miner nodes, and br=
oadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob full=
node will then reject attempts to replace it, but miners will also reject t=
he CoinSwap-expected funding tx and it will not confirm anyway.


With the pre-SAS 4-tx setup, this potentially allows Alice to steal the fun=
ds of Bob; after Alice gets its funding-tx-replacement confirmed together w=
ith the Bob honest-funding-tx, Alice can use the contract transaction and p=
ublish the preimage to take the Bob funds.
Since the Alice-side funding tx has been replaced, knowledge of the hash pr=
eimage will not help Bob any: the Alice funding tx has been replaced and Bo=
b 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 u=
p 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 fund=
ing tx with the longest timelock has to confirm first before the next is ev=
en 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 "prev=
ious" 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 betw=
een all makers and itself.
So, in an S6 sequence of Alice -> Bob1 -> Bob2 -> Alice, after Alice provid=
es the preimage, Bob2 encrypts the private key being handed over in an asym=
metric 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 b=
roadcast all those data to all participants, and only the correct participa=
nt 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 th=
at 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 mi=
tigation.)

Regards,
ZmnSCPxj