Date: Tue, 21 Jan 2020 04:38:07 +0000
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <nWAInXGl2LEOcttjF0HhV8rgmjNXZS9nfb8I-XApvOaz1KLZbzZcLDoPaa4ADDMpAKHF9-SfGX291bnYwNaW8afuMSL5KQjdV0E8LQksGSU=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Payswap
Precedence: list

Good morning list,

[On a recent post on lightning-dev](https://lists.linuxfoundation.org/piper=
mail/lightning-dev/2020-January/002431.html), I brought up the possibility =
of using a circular self-payment to hide the actual direction of payment fr=
om 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 t=
he destination and the destination returns the difference instead.

As the mechanisms on Lightning are also implementable directly on the block=
chain, I observe as well that we can use a similar mechanism based on CoinS=
wap 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 th=
an the payment amount.
* Create a single transaction that consumes those inputs and outputs the am=
ount to the destination and any remainder to a new address we control.

However, we can observe as well that transactions and transaction outputs c=
an 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 gr=
eater 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 payme=
nt 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 prot=
ocol.

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 li=
kely self-payment.
* A transaction with two outputs.
  * This is the CoinSwap funding transaction that was offered by the destin=
ation 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 destin=
ation to the sender, reversing the apparent direction of payment and obscur=
ing 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 se=
nder respectively.

The above is an active misleading of chain analysis.

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

Against the above flow I must caution:

* This involves more transactions than Payjoin, thus more expensive in bloc=
kspace.
* The protocol can be aborted by one participant, which will lead to spendi=
ng 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/li=
ghtning-dev/2019-October/002245.html), CoinSwap overhead approaches the ove=
rhead of setting up a temporary Lightning Network channel, thus it might ac=
tually be better to implement all CoinSwap protocols over Lightning instead=
.

Regards,
ZmnSCPxj