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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <chuck+bitcoindev@borboggle.com>) id 1W95XE-000635-DD
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Jan 2014 04:16:56 +0000
X-ACL-Warn:
Received: from borboggle.com ([69.164.197.78] helo=mail.borboggle.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1W95XD-0006s5-Au for bitcoin-development@lists.sourceforge.net;
Fri, 31 Jan 2014 04:16:56 +0000
Received: from [192.168.1.72] (unknown [180.183.149.52])
by mail.borboggle.com (Postfix) with ESMTPSA id 6B81DFA97;
Thu, 30 Jan 2014 23:27:57 -0500 (EST)
Message-ID: <52EB23A4.9@borboggle.com>
Date: Fri, 31 Jan 2014 11:16:36 +0700
From: Chuck <chuck+bitcoindev@borboggle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net,
Jeremy Spilman <jeremy@taplink.co>, 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>
<op.xainxqs2yldrnw@laptop-air>
In-Reply-To: <op.xainxqs2yldrnw@laptop-air>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1W95XD-0006s5-Au
Cc: 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: Fri, 31 Jan 2014 04:16:56 -0000
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
|
