1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7AB1DC0174
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jan 2020 04:38:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 5C7CE8639E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jan 2020 04:38:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 7iMvoPKu4gQF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jan 2020 04:38:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by whitealder.osuosl.org (Postfix) with ESMTPS id 42F5085E12
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jan 2020 04:38:18 +0000 (UTC)
Date: Tue, 21 Jan 2020 04:38:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1579581495;
bh=6EvGdGht5sIHI/qFP4+QvF5ckDovBdFJwJQavEGtiIY=;
h=Date:To:From:Reply-To:Subject:Feedback-ID:From;
b=iSdCjz9rIo900AcH90a2+l1LPOLQfojwNF0q6Sg93i5qRv4q3nrEiTraDSUv9aD5R
gyLZ45xCS1+NClgWQ0RVLCkYIOhbrsq5G/op1CnIOwaq/NRblXmi4umDAnEBeoGd/5
aGfN8IZEvDaKTE3PUAKuBJf2ZGDOS3VrhNQapwjE=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2020 04:38:20 -0000
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
|
