Date: Fri, 24 Jan 2020 10:11:55 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <hWBM2yvN6QhN97j2qjFV_yWmCaRtCJ3cqO-LXRcKEZu89kzOaaQPmfRCuEq4uZe07WHKNNa5dZ7X1PqK4hd_9X5cxR8SuD0lWtUG-fVdIFA=@protonmail.com>
In-Reply-To: <nWAInXGl2LEOcttjF0HhV8rgmjNXZS9nfb8I-XApvOaz1KLZbzZcLDoPaa4ADDMpAKHF9-SfGX291bnYwNaW8afuMSL5KQjdV0E8LQksGSU=@protonmail.com>
References: <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: Re: [bitcoin-dev] Payswap
Precedence: list

Good morning list,

A few more things to consider:

Probably the correct order for this would be for the payer to instantiate t=
he Scriptless Script payment to the payee first, then the payee instantiati=
ng the change back to the payer.

By use of some kind of Scriptless Script, it is possible to as well impleme=
nt 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 poi=
nt 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 kn=
owledge 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 a=
n 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 blo=
ckchain, I observe as well that we can use a similar mechanism based on Coi=
nSwap 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 greate=
r than the payment amount.
> -   Create a single transaction that consumes those inputs and outputs th=
e amount to the destination and any remainder to a new address we control.
>
>     However, we can observe as well that transactions and transaction out=
puts 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 o=
r greater than the payment amount.
>     -   Sender reveals the sum to destination.
> -   Destination locates some of its owned UTXO(s) that total an amount eq=
ual or greater than the difference (change) of the sender total minus the p=
ayment 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 p=
ayment 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 b=
e 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 an=
d 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 sp=
ending onchain fees to back out of the protocol, unlike Payjoin which is at=
omic with paying onchain fees.
> -   As I point out elsewhere, CoinSwap overhead approaches the overhead o=
f 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