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
|
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 <mh.in.england@gmail.com>) id 1TJBD2-0000EV-Bx
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 22:45:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.181 as permitted sender)
client-ip=209.85.212.181; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f181.google.com;
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TJBD1-0004JQ-Ft
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 22:45:00 +0000
Received: by wibhq12 with SMTP id hq12so1151558wib.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Oct 2012 15:44:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.106.9 with SMTP id gq9mr500874wib.12.1349217893234; Tue,
02 Oct 2012 15:44:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.159.131 with HTTP; Tue, 2 Oct 2012 15:44:53 -0700 (PDT)
In-Reply-To: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
References: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
<CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
Date: Wed, 3 Oct 2012 00:44:53 +0200
X-Google-Sender-Auth: zDWm90FHGWwPyqYJIzOTOz-tol0
Message-ID: <CANEZrP3iot94HW17HpdH9ALMehMQKtRYY0LEe88FgRqU3BAchw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1TJBD1-0004JQ-Ft
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol thoughts
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: Tue, 02 Oct 2012 22:45:00 -0000
I think it's worth pondering the different things we may want in
future, even if that future is quite far out, just to ensure we have a
robust design that won't box us in later. Brainstorming feature ideas
now doesn't commit anyone to implementing them, but it may help
improve the final v1 design.
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks.
A simple way to solve this problem is just use the SSL identity of the
server that is taking part in the protocol, but it's not much harder
to embed a signature + cert chain into the invoice itself. And once
you're doing that, allowing several different sigs/cert chains is
pretty easy. It means you keep the design open to cases where SSL may
not be appropriate. Eg, you could create invoices signed by your
web-of-trust identity, or some non-SSL Bitcoin specific verification
system.
None of those things have to actually be implemented, but by
considering them now we can make the protocol more future prooof.
> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.
A signed invoice + the blockchain transactions does this, BUT with a
major caveat: if you have not set up dispute mediation, there is
nobody to prove faultlessness to.
So I'm not sure this would be very useful. Supporting real dispute
mediation seems more practical, but also more work.
> + Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).
This would be nice, I think invoices could be wrapped by another
protocol that handles it. I'm not sure it needs to be a part of the
core payment protocol. There are lots of different ways to implement
this and I'm not sure there's agreement on what it should look like -
somebody needs to build a "proprietary" implementation first.
|
