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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WjpxZ-00059m-67
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 13:08:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.113 as permitted sender)
client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
helo=outmail148113.authsmtp.com;
Received: from outmail148113.authsmtp.com ([62.13.148.113])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WjpxY-0002ps-0c for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 13:08:01 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s4CD7q0B075961;
Mon, 12 May 2014 14:07:52 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s4CD7l7x051278
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 12 May 2014 14:07:49 +0100 (BST)
Date: Mon, 12 May 2014 09:07:44 -0400
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20140512130744.GC12679@savin>
References: <CANEZrP3VNXSc2cd3b9pz9iC2BR0-vG=tfYwMyUGBGaWPq+geXQ@mail.gmail.com>
<20140509150325.GA30436@savin>
<CANEZrP1m=-GWD5rLRe9vrx0JYKeKXghNw-a47ZbJTd1h3ngFww@mail.gmail.com>
<20140509152715.GA12421@savin>
<CANEZrP0Yom_JjN2PnPsfKV5S4wZSze4XTcJJU2ZWee4VGo20tw@mail.gmail.com>
<CAPg+sBh-OA7xSp3=SEGS1fP-d2CDMzMy_=S_jOs1hvdaWTw0mA@mail.gmail.com>
<20140509181353.GB27819@savin>
<CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HG+GLK89HZ1zG0kk"
Content-Disposition: inline
In-Reply-To: <CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 6b824f90-d9d6-11e3-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwAUFVQNAgsB AmIbWlBeUFp7XGM7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrBW91 AUIZGhl3dgdBcDBy ZUNgXj5dDkx4cRB0
QlMAHDkAeGZhPWMC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4mNRIc DxEEVSkvEAUdTjQ2
Iho6YkYGG1oWOUI2 WV/T
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WjpxY-0002ps-0c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] ECDH in the payment protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 13:08:01 -0000
--HG+GLK89HZ1zG0kk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, May 09, 2014 at 08:38:22PM +0200, Pieter Wuille wrote:
> On Fri, May 9, 2014 at 8:13 PM, Peter Todd <pete@petertodd.org> wrote:
> > I don't think we're going to find that's practical unfortunately due to
> > change. Every payment I make ties up txouts, so if we try to base the
> > atomicity of payments on whether or not the payee decides to broadcast
> > the transaction the payor is stuck with txouts that they can't use until
> > the payee makes up their mind. That leads to lots and lots of nasty edge
> > cases.
>=20
> I haven't talked much about it except for on IRC, but my idea was this:
> * PaymentACK messages become signed (with the same key as the payment
> request, or using some delegation mechanism, so that the same key
> doesn't need to remain online).
> * Instead of a full Bitcoin transaction, a Payment message contains a
> scriptSig-less Bitcoin transaction + a limit on its byte size (and
> perhaps a limit on its sigop count).
> * The sender sends such a Payment to the receiver before actually
> signing the transaction (or at least, before revealing the signed
> form).
> * The receiver only ACKs if the transaction satisfies the request, is
> within time limits, isn't unlikely to confirm.
> * If the sender likes the ACK (the refund and memo fields are intact,
> the transaction isn't changed, the signature key is valid, ...), he
> either sends the full transaction (with receiver taking responsibility
> for broadcasting) or broadcasts it himself.
>=20
> Together, this means that a paymentACK + a confirmed matching Bitcoin
> transaction can count as proof of payment. Both parties have a chance
> to disagree with the transaction, and are certain all communicated
> data (apart from transaction signatures) in both directions happened
> correctly before committing. It would completely remove the chance
> that the Bitcoin transaction gets broadcast without the receiver
> liking it (for legitimate or illegitimate reasons), or without the
> backchannel functioning correctly.
>=20
> It's also compatible with doing multiple payments in one Bitcoin
> transaction - you can ask for ACKs from multiple parties before
> signing the transaction.
>=20
> Of course, the sender can still withhold the signed transaction (in
> which case nothing happened, but we probably need a second timeout),
> or the receiver can always claim to have never received the
> transaction. The sender can broadcast the transaction himself in order
> to prevent that, after obtaining an ACK.
Yeah, with the receiver specifically signing off on the tx I think
that's fine. OTOH you still gotta ask if this process is really worth
it; do you really need this level of signing off for payments that are
only going to be considered fully valid after a confirmation? That's
always going to be the case for a large proportion of Bitcoin
transactions, and sticking to that model makes upgrades easier and
reduces the reasons why receivers would want to reimplement a bunch of
Bitcoin-related logic.
--=20
'peter'[:-1]@petertodd.org
00000000000000007cf5744be694eea2f20501e6db9d3362428aabd63dda4151
--HG+GLK89HZ1zG0kk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTcMebXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3Y2Y1NzQ0YmU2OTRlZWEyZjIwNTAxZTZkYjlkMzM2MjQy
OGFhYmQ2M2RkYTQxNTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsobgf/YjH8RXfrzm8DtqA78oAfIduF
y1l533YnAsBD2H/eXMBDxsTdmJRLp1ebfjC8fOJHXchvjfw0kKjq3NJlZUPxjqeI
+OmqLXJQbE3pg+gMKxc4Y8uJCAzcJ/GPgiAtQ4Rn7e7gfGgteCbT4lg+FsxhL46a
U375rZpFbYNG8Y09qe+QCpu77t7b2Zm0HqktiPfeBPYazRtxb/39nbxUM93aUHOL
5TybCuBVrgblACziFp47ONaKL4v+t1cobgyP1eEfj5eaZfjdLauTn8/8/2P3tLn6
b5rI0jFZOeypwhX1vAQl2fVigxBLjje789dhuRVwlwZs0cvzaFlXcfye5e3vnA==
=QNRc
-----END PGP SIGNATURE-----
--HG+GLK89HZ1zG0kk--
|
