Re: [bitcoin-dev] Payswap

2020-01-24 Thread ZmnSCPxj via bitcoin-dev
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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org

[bitcoin-dev] Payswap

2020-01-20 Thread ZmnSCPxj via bitcoin-dev
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

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