Re: [bitcoin-dev] Payswap

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning list,

A few more things to consider:

Probably the correct order for this would be for the payer to instantiate the Scriptless Script payment to the payee first, then the payee instantiating the change back to the payer.

By use of some kind of Scriptless Script, it is possible to as well implement a proof-of-payment system similar to Lightning, which might be useful to prove to an auditor that a payment has been made (without being forced to reveal this to anyone other than the auditor).
Both the payer and payee can generate a scalar.
The payee provides a signed invoice (can reuse the Lightning BOLT11 invoice format) attesting the payment point that needs to be paid, the payment point being the generator point times te payee scalar.
The payer then instantiates the Scriptless Script PTLC, requiring knowledge of the payee scalar + the payer scalar from the payee.
Then the payee instantiates the change Scriptless Script PTLC, requiring knowledge of the payer scalar from the payer.
Then the payee claims the change, which allows the payer to claim the full transfer while revealing the payee scalar as a proof-of-payment.


Regards,
ZmnSCPxj

> Good morning list,
>
> On a recent post on lightning-dev, 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, 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
>
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev