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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timo.hanke@web.de>) id 1UWVwK-000593-A9
for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 18:03:08 +0000
Received: from mout.web.de ([212.227.15.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UWVwJ-0000DL-7I for bitcoin-development@lists.sourceforge.net;
Sun, 28 Apr 2013 18:03:08 +0000
Received: from crunch ([217.50.173.229]) by smtp.web.de (mrweb101) with ESMTPA
(Nemesis) id 0LrJse-1Uc3L70TEK-013du6;
Sun, 28 Apr 2013 20:03:01 +0200
Date: Sun, 28 Apr 2013 20:03:04 +0200
From: Timo Hanke <timo.hanke@web.de>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20130428180304.GA30115@crunch>
References: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T3egz=7YNOrgx7WsfSthLfN2gfE60YfPEv8096vyErBqg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V02:K0:2cEgKHi5/QcGU9I5g8XVUcRWhQ8ZRUWie6zRMDUl69W
KyK/48hoaUntZYUrRHCwjHZwvNfYKhTt6S1GaZOG7zK2y3SLYk
1ZLGoBodY7nwqpgLYh3wb4s7UOGAv4vbVPMNh4xg461S7LvjQO
0UEJq7iDiqprYJKrOy5cFrwNDnzPSfrd2npxfNbyFbN9JO8siP
UWgELFUy6hqnLS6nmAsvQ==
X-Spam-Score: -2.4 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.15.3 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UWVwJ-0000DL-7I
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: timo.hanke@web.de
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: Sun, 28 Apr 2013 18:03:08 -0000
On Thu, Apr 25, 2013 at 09:07:07PM -0400, Gavin Andresen wrote:
> On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman <jeremy.spilman@gmail.com>wrote:
>
> > Right now I'm leaning towards writing a prototype using a single cert with
> > a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
> > and InvoiceID in the Payment Request. Gavin, would the best way to work on
> > this be to just fork your code on Github?
> >
>
> As usual, our bottleneck is code review / testing, so it would be nice if
> you spent some time reviewing code and helping test v0.9 so we can actually
> ship a v1 sometime in the next several months before you start working on a
> v2.
How does the current protocol protect the refund address? Protecting the
payee against a compromised webserver may be out of scope for now, due
to the lack of a suitable PKI, as Mike Hearn explained. But signing the
refund address is a more immediate issue. There is no obvious key that
the payer can use to sign the refund address. However, this can be
solved right now with marginal changes to the protocol, like this:
- Payee creates his PaymentDetails message with an explicit pubkey in
output.script, not an address.
- If payment_url is not specified then payer pays as before (he cannot
sign his refund address)
- If payment_url is specified then payer hashes his Payment message
(with transactions zeroed out) and pays to h*pubkey, where h is the
computed hash; then submits his Payment message.
- Upon receiving the Payment message, payee computes the same hash and
can pick his funds from h*pubkey.
As long as it is trivial to reconstruct the Payment message this is
completely safe. But probably this isn't the case in general. So the
drawback is that the payer has to backup the Payment message before
submitting it or before broadcasting the transaction, in order to keep a
proof. If the payer trusted the payee then it would suffice to wait for
an ACK before broadcasting. Because of the backup issue, refund address
signing should probably be an option that the payer can choose after
reading a backup warning.
|
