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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3C41BC0174
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jan 2020 10:12:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 391168855C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jan 2020 10:12:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id oSUq2Pys7KnJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jan 2020 10:12:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by hemlock.osuosl.org (Postfix) with ESMTPS id 3060788552
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jan 2020 10:12:00 +0000 (UTC)
Date: Fri, 24 Jan 2020 10:11:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1579860718;
bh=BQftjUmz4geZOLXi9gUakcbrJ3KfdlnTBcOne2pdKdc=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=sTHXMihpS1vdtOk9CoV5WQOem5noIUh/4Ps0FM5J6FY44B8/qFi0LXdHETof7S5ai
HgArb9hBxHr4596uVQpFCMoISH4D58BPFx/8VW5Qg9Q82HDxyUsX5vb9KKqKVpFbFQ
xNgUYKRu5EGlhCSSqDaIwjr7IcwxPH9C/orpOsuE=
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
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: Fri, 24 Jan 2020 10:12:03 -0000
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
|
