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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1W8y2M-0004eg-Cc
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 20:16:34 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W8y2K-0007J8-9F for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 20:16:34 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ;
Thu, 30 Jan 2014 12:32:08 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Gavin Andresen" <gavinandresen@gmail.com>, "Pieter Wuille"
<pieter.wuille@gmail.com>
References: <lc409d$4mf$1@ger.gmane.org>
<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
<CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com>
<CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com>
<CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com>
<CAJHLa0MVbDnC0i+uT9Sahxk8ht9R5ztSJ-kOU5ERapeVibH9eg@mail.gmail.com>
<CABsx9T1jAobC_p9oa_PX8M7Bo6Db3=oBhPuhp5CXVHqTRb=Hng@mail.gmail.com>
<CAPg+sBiz1oXqsRTpQpVghTFupj6jsp5M-zDGKe7bjeUBHNMxUA@mail.gmail.com>
Date: Thu, 30 Jan 2014 12:16:28 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xainxqs2yldrnw@laptop-air>
In-Reply-To: <CAPg+sBiz1oXqsRTpQpVghTFupj6jsp5M-zDGKe7bjeUBHNMxUA@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -2.0 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 HK_SCAM_S4 BODY: HK_SCAM_S4
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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: 1W8y2K-0007J8-9F
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, Andreas
Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
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: Thu, 30 Jan 2014 20:16:34 -0000
Please note, responding to Pieter and Chuck concurrently.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
<pieter.wuille@gmail.com> wrote:
> Currently, with the specification and implementation in Bitcoin Core,
> if a merchant wants to use the refund or memo feature, they need to
> provide an alternative route for delivering that information to them
> *before* the transaction is made, as sending the transaction may
> result in the transfer of funds without knowing what to do with it (if
> their receive server is down at the right time) and potnetially no way
> to contact the sender. This makes these fields utterly useless.
>
> This is not a matter of letting wallets experiment with the best
> behaviour. This is removing the ability to rely on the payment
> protocol being bidirectional.
I think we want to separate the two issues;
1) Reliably getting refund/memo fields to the merchant/payee
2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and
if/when they should be [double]-spent to clear them
We should be able to solve '1' without having to fully spec out behavior
for 2.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
<pieter.wuille@gmail.com> wrote:
> I don't care whether wallets broadcast the transactions or not (they
> can experiment with that as they like). But we should take measures to
> prevent a transaction for being broadcast without the payment being
> delivered. One way is never broadcasting the transaction yourself.
> Another is retrying to send the payment if delivery fails.
>
> Here is what I would suggest to add to the specification:
> * If a payment_uri is specified, the client must attempt to send the
> payment there.
> * If a transaction is broadcast (which is permitted even if sending
> the payment fails), a client should make a reasonable attempt of
> delivering the payment (remembering, retrying, ...).
> * If a paymentACK has been received, the client is no longer
> responsible for broadcasting the transaction (but still may).
To reliably deliver refund/memo fields, we could;
a) Send them as part of the initial request for the
PaymentRequest/PaymentDetails
b) Send them as a response to the PaymentRequest/PaymentDetails before
the transaction is even formed and any unspent outputs are selected
c) Send them as a response to the PaymentRequest/PaymentDetails with the
UNsigned transaction, and then follow up with the signed transaction in a
separate message.
'a' is problematic because while wallet software could easily append some
data to the queryString, it doesn't work if the user is downloading then
opening the PaymentRequest as a file. So 'a' is a no-go I think.
'b' is fine, if not overly chatty. The only thing committed is a refund
address, which is a lot less problematic than committed unspent outputs.
'c' is nice because it lets the server preview the transaction (and
ACK/NACK it with a memo of their own -- e.g. 'fee too low'?) without being
able to broadcast it, so we know unspent outputs are not yet committed.
But all of these require too many changes to the protocol for my liking.
On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>
wrote:
> 3. Customer builds a set of transactions and sends a new
> PaymentApprovalRequest message which includes a refund address and the
> unsigned transactions and their associated fully-signed transactionhash,
> the whole message signed with the private key of the refund address.
"Unsigned transactions and their associated fully-signed transaction hash"
-- isn't that a fully signed transaction? In this case, it doesn't solve
the core problem of the server being able to broadcast that transaction
without ACKing.
On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle.com>
wrote:
> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.
For merchant confidence that the address is correct, we can leave the
transport security to the transport layer.
For payer proving refund address was X after merchant sends a refund to Y,
that's a different story. I don't think we want to *require* access to the
refund address private key. For example, BIP32 public derivation may have
just the pubkey available. Offline transaction signing is one thing, but
offline PP message signing is too much. I think there are better ways to
secure the refund address which can reuse existing code, and certainly the
option should remain to send a plain refund address just relying on
transport security and trusting the merchant.
|
