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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <christophe.biocca@gmail.com>) id 1W9Gr0-0006hV-Gd
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Jan 2014 16:22:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.53 as permitted sender)
client-ip=209.85.220.53;
envelope-from=christophe.biocca@gmail.com;
helo=mail-pa0-f53.google.com;
Received: from mail-pa0-f53.google.com ([209.85.220.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W9Gqz-000744-9n
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Jan 2014 16:22:06 +0000
Received: by mail-pa0-f53.google.com with SMTP id lj1so4585778pab.40
for <bitcoin-development@lists.sourceforge.net>;
Fri, 31 Jan 2014 08:21:59 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.68.44.71 with SMTP id c7mr11753927pbm.24.1391185319411; Fri,
31 Jan 2014 08:21:59 -0800 (PST)
Received: by 10.68.146.72 with HTTP; Fri, 31 Jan 2014 08:21:59 -0800 (PST)
In-Reply-To: <52EB23A4.9@borboggle.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>
<op.xainxqs2yldrnw@laptop-air> <52EB23A4.9@borboggle.com>
Date: Fri, 31 Jan 2014 11:21:59 -0500
Message-ID: <CANOOu=9RcZ5VLGBzONYmY6MtPAegqjiHk5bAWRN8q7T5Gz+Xeg@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Chuck <chuck+bitcoindev@borboggle.com>
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
(christophe.biocca[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: 1W9Gqz-000744-9n
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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: Fri, 31 Jan 2014 16:22:06 -0000
The merchant can always act maliciously by simply not delivering the
goods. The only recourse the payment protocol provides at that point
is that you have proof the merchant is acting maliciously (or at the
very least his payment system is broken).
Your scheme just adds an ACK of the specific unsigned transactions
before the payment is effectively irreversible.
I can't come up with a situation where the combination of signed
request and blockchain entry aren't enough evidence, yet where adding
an ACK by the merchant of the unsigned transaction tips the balance
the other way. If you know of such a possibility, I'd love to hear it,
because we'd know what we're trying to fix.
The only way I can see a malicious merchant exploiting wallet
behaviour around PaymentACK is by accepting the Payment message, not
broadcasting it, not returning an ACK, and hoping the wallet/user
retries paying with a new, non-conflicting transaction. Then he can
try milking multiple small payments out of the user before they
realize what happened, and broadcast them all at once, stealing more
funds than the user ever was willing to risk in the transaction. But
this is trivial to guard against at the wallet level (by making every
new payment conflict with all previous non-acked payments).
The non-reliability of getting memo/refund fields is a separate
problem, but it seems BitcoinJ's approach addresses that nicely.
On Thu, Jan 30, 2014 at 11:16 PM, Chuck <chuck+bitcoindev@borboggle.com> wrote:
> On 1/31/2014 3:16 AM, Jeremy Spilman wrote:
>> 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.
> My original message was focused on #1. Not only #1, but ensuring the
> merchant can't act maliciously too.
>
> As far as #2 is concerned, I don't think it makes any difference - it's
> in both the customer and the merchant's best interest to have the
> transactions confirmed.
>
>> 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.
> ...
>> 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.
> What I meant was (and maybe this was roundabout?): the customer includes
> the UNsigned transactions as well as the hashes (and only the hashes) of
> the fully signed transactions. The customer keeps the fully signed
> transactions private until the merchant ACKs the unsigned versions. If
> the merchant has the hash of the fully signed transaction, he can
> monitor the network for delivery of the signed transaction.
>
> It definitely complicates things, but it's nothing that can't be done.
>
> Cheers,
>
> Chuck
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
