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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Wipgj-00046g-99
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 18:38:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.182 as permitted sender)
client-ip=209.85.213.182; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f182.google.com;
Received: from mail-ig0-f182.google.com ([209.85.213.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wipgi-0006pk-AV
for bitcoin-development@lists.sourceforge.net;
Fri, 09 May 2014 18:38:29 +0000
Received: by mail-ig0-f182.google.com with SMTP id uy17so1500152igb.15
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 May 2014 11:38:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.22.210 with SMTP id g18mr12109786igf.19.1399660702343;
Fri, 09 May 2014 11:38:22 -0700 (PDT)
Received: by 10.50.100.72 with HTTP; Fri, 9 May 2014 11:38:22 -0700 (PDT)
In-Reply-To: <20140509181353.GB27819@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>
Date: Fri, 9 May 2014 20:38:22 +0200
Message-ID: <CAPg+sBiSkeoD-Rxkoo+Dp8vTt0hE4FGLVxrdqTox6Njo8Mk5pw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wipgi-0006pk-AV
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: Fri, 09 May 2014 18:38:29 -0000
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.
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.
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.
It's also compatible with doing multiple payments in one Bitcoin
transaction - you can ask for ACKs from multiple parties before
signing the transaction.
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.
--
Pieter
|
