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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to