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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1TdOw6-0006VF-Qe
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 17:27:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TdOw5-0008BC-VO
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 17:27:06 +0000
Received: by mail-we0-f175.google.com with SMTP id z53so3491533wey.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 27 Nov 2012 09:26:59 -0800 (PST)
Received: by 10.180.7.199 with SMTP id l7mr24786101wia.15.1354037219892;
Tue, 27 Nov 2012 09:26:59 -0800 (PST)
Received: from momentum.localnet ([91.84.15.31])
by mx.google.com with ESMTPS id gz3sm3389414wib.2.2012.11.27.09.26.57
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 27 Nov 2012 09:26:58 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: Mike Hearn <mike@plan99.net>
Date: Tue, 27 Nov 2012 17:26:56 +0000
User-Agent: KMail/1.13.7 (Linux/3.2.0-3-686-pae; KDE/4.8.4; i686; ; )
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<201211271703.39282.andyparkins@gmail.com>
<CANEZrP0NZykzrvC1=YZv4czbu+EPaR3qpjQ2WZDsA8DhroR2_g@mail.gmail.com>
In-Reply-To: <CANEZrP0NZykzrvC1=YZv4czbu+EPaR3qpjQ2WZDsA8DhroR2_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201211271726.56370.andyparkins@gmail.com>
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
(andyparkins[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: 1TdOw5-0008BC-VO
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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, 27 Nov 2012 17:27:07 -0000
On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:
> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce an invoice with the right security
> bits.
That's good; I've not done anything with protocol buffers, so wasn't aware it
was that simple.
> > In particular two additional identification types:
> > - GnuPG (obviously)
>
> It's not obvious to me, incidentally. The web of trust has been
> dead-on-arrival since it was first proposed, and for good reasons.
> SSL/X.509, for better or worse, has significant usage.
Sorry, I meant "obviously" in the sense that "obviously that's the other one
that everyone will want". The web-of-trust as a universal identity mechanism
is, I agree, not useful. However, as a localised, smaller-scale identity
verification system it's used by every GnuPG user. You become your own
certificate authority. For example, I've set up my whole family with GnuPG;
I've set them up to trust me to authenticate (and I doubt any of them has ever
added anyone else). Then I take on the responsibility of signing all my
family/friends keys and they don't need to worry about it.
There's no reason that a small group of companies wouldn't do exactly the same
sort of thing.
> Your case of a small business is a perfect example of people who won't
> be using GPG. If they don't want to buy an SSL cert, they can just as
Bear in mind, I was using that example as an example of a hash protected in a
GPG envelope, not a GPG-signed invoice. People who've already got their GPG
system in place will appreciate being able to leverage it.
> well put a reference number in the memo field or a "Hey Bob, here is
> the bill we discussed". The payer does not get the multi-factor auth
How can they put a hash of an invoice inside the invoice? In my "hash mode"
invoices, it would be a random number (or possibly specifying the hash
algorithm) then the SignedInvoice would simply be the original invoice + hash.
That hash would then be reported via some secure channel outside of bitcoin's
domain.
> protection so if their computer has a virus, they may be hosed. But
> that's good incentive for sellers to get verified. Some CA authorities
> do it for free these days.
I don't understand what the relevance of multi-factor is to invoices? The
payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or
not? This invoice system has one primary job: to ensure that the target of
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
