[bitcoin-dev] Payswap

From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Payswap
Date: Tue, 21 Jan 2020 04:38:07 +0000	[thread overview]
Message-ID: <nWAInXGl2LEOcttjF0HhV8rgmjNXZS9nfb8I-XApvOaz1KLZbzZcLDoPaa4ADDMpAKHF9-SfGX291bnYwNaW8afuMSL5KQjdV0E8LQksGSU=@protonmail.com> (raw)

Good morning list,

[On a recent post on lightning-dev](https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002431.html), I brought up the possibility of using a circular self-payment to hide the actual direction of payment from third-party snooping nodes.
Basically, instead of paying the amount to the destination, we can have an atomic mechanism by which the source pays a larger-than-amount payment to the destination and the destination returns the difference instead.

As the mechanisms on Lightning are also implementable directly on the blockchain, I observe as well that we can use a similar mechanism based on CoinSwap to mislead onchain analysis as well.

The normal payment flow for a Bitoin payer is typically:

* Locate some of its owned UTXO(s) that total an amount equal or greater than the payment amount.
* Create a single transaction that consumes those inputs and outputs the amount to the destination and any remainder to a new address we control.

However, we can observe as well that transactions and transaction outputs can be considered nodes and edges of a transaction graph, respectively.
We can then consider the categorical dual of such a graph.

Let me then present the Payswap payment flow:

* Sender locates some of its owned UTXO(s) that total an amount equal or greater than the payment amount.
  * Sender reveals the sum to destination.
* Destination locates some of its owned UTXO(s) that total an amount equal or greater than the difference (change) of the sender total minus the payment amount.
* Sender and destination set up an unequal CoinSwap:
  * Destination receives all the Sender coins.
  * Sender receives the difference between the Sender total and the payment amount (change).
* Sender and destination execute the CoinSwap and complete the payment protocol.

What appears onchain are:

* A transaction with a single output.
  * This is the CoinSwap funding transaction that was offered by the sender and claimed by the destination.
  * As a single-output transaction, this looks to chain analysis to be a likely self-payment.
* A transaction with two outputs.
  * This is the CoinSwap funding transaction that was offered by the destination and claimed by the sender.
  * The output that goes back to the destination looks like a change output according to chain analysis.
  * The output that goes to the sender looks like a payment from the destination to the sender, reversing the apparent direction of payment and obscuring the amount paid.
* Two more transaction that complete the protocol, each spending one of the above and moving the funds to unilateral control of the destination and sender respectively.

The above is an active misleading of chain analysis.

This is even possible today with 2p-ECDSA to make it use P2WPKH with Scriptless Script.

Against the above flow I must caution:

* This involves more transactions than Payjoin, thus more expensive in blockspace.
* The protocol can be aborted by one participant, which will lead to spending onchain fees to back out of the protocol, unlike Payjoin which is atomic with paying onchain fees.
* As I [point out elsewhere](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002245.html), CoinSwap overhead approaches the overhead of setting up a temporary Lightning Network channel, thus it might actually be better to implement all CoinSwap protocols over Lightning instead.

Regards,
ZmnSCPxj