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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
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 <walter.stanish@gmail.com>) id 1TdAiX-0007bO-QG
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 02:16:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=walter.stanish@gmail.com;
helo=mail-bk0-f47.google.com;
Received: from mail-bk0-f47.google.com ([209.85.214.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TdAiW-0006yi-Fa
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 02:16:09 +0000
Received: by mail-bk0-f47.google.com with SMTP id j4so3460178bkw.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 26 Nov 2012 18:16:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.145.217 with SMTP id e25mr4155520bkv.123.1353982562011;
Mon, 26 Nov 2012 18:16:02 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.204.49.133 with HTTP; Mon, 26 Nov 2012 18:16:01 -0800 (PST)
In-Reply-To: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
Date: Tue, 27 Nov 2012 10:16:01 +0800
X-Google-Sender-Auth: 3-nJsW4Wu7BBn65Q1XZJxRo98Zc
Message-ID: <CACwuEiP7CGeZZGW=mXwrFAAqbbwbrPXTPb8vOEDuO9_96hqBGg@mail.gmail.com>
From: Walter Stanish <walter@stani.sh>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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
(walter.stanish[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: 1TdAiW-0006yi-Fa
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 02:16:10 -0000
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
I agree this is a very pertinent subject, and with a bit of looking
around it is clear that there is a requirement here for emerging
financial ecosystems of many types, certainly not just for the Bitcoin
community, which until now seems to have been getting along just about
OK despite the current levels of complexity.
That said, I have a number of serious concerns with the proposal.
1. Undue Broadening of Scope: From an architectural perspective, if
one accepts the unix mantra of "do one thing and do it well" as
reasonable and time-proven doctrine, given that Bitcoin is already
trying to be both a commodity and a distributed consensus-based
settlement system, does it really make sense to attempt to tack-on
business-level functions?
2. X.509: I have read (somewhere or other, recently) that it is
generally considered bad form to mandate specific cryptographic
systems in new protocols where open support is possible. Given the
recent issues with X.509, the security nightmare that already exists
with the volume of (sometimes cracked, sometimes
government-compromised?) issuers, and the complexity of the scheme, it
seems a little strange to singularly mandate X.509, despite its
widespread use at present. There are also a swathe of potential
issues around DNS interdependence, information leakage within
certificates themselves and/or their DNS-interpretation by clients,
etc. I would consider suggesting open support with initial support for
GPG, as it is apparently preferred as a simple and further
decentralized solution by the majority of the open source and
cryptographic software development community.
3. Failure to Review Existing Work: I would urge anyone to be wary of
adopting any proposal that does not inform itself through reference to
existing protocols in the same area. In this area there are a few
protocols in current use (chiefly in Europe) such as those listed at
http://en.wikipedia.org/wiki/Invoice#Electronic_invoices as well as
various hosted platforms such as http://xero.co.nz/ (chiefly
Australia/New Zealand). Often, existing work shows its age with
after-the-fact alterations that sit poorly with initial assumptions:
exactly the kind of situation one can walk in to developing against a
proposal before adequately researching the area.
4. Complexity of Metadata: Physical and digital invoicing for
businesses operating at scale often requires delivery terms, product
classification codes, locale-specific taxation (often at multiple
levels), various fees and discounts (sometimes fulfillment-speed
linked with multiple tiers/thresholds), and other features that I am
skeptical are ever going to be made fully available within a business
protocol tacked on to a hybrid digital currency/settlement system
(like Bitcoin) as a secondary concern.
5. Non-BTC Currencies/Currency-like Commodities: No approach to
non-BTC currencies appears to have been made, which makes the
"invoice" of limited utility for almost all businesses, save those
willing to accept all of the 'capital risk' (exchange rate fluctuation
risk) inherent in a BTC-based fulfilment process with a potential term
long enough to justify an invoicing process. (Does this narrow scope
actually cover any existing business?)
6. DNS: As already mentioned with regards to X.509: a huge red flag as
an area of potential vulnerability, or at least information leakage.
I must now admit that in raising the above I am definitely biased. My
employer (Payward, Inc.) and other organizations (OpenCoin, Inc.,
etc.) have been working with the Internet Engineering Task Force
(IETF) on tabling some open proposals within this area under the
auspices of the Internet Financial Exchange Project
(http://ifex-project.org/). Our hope is to facilitate the requisite
standardisation within internet-connected systems to deal with what is
perhaps fairly characterised as a relatively heterogeneous outlook on
the rise of cryptographic (and other alternate) currencies and
commodities, and emerging settlement infrastructures.
Whilst the current Bitcoin proposal is admirable for correctly raising
the area as one of immediate concern, I hope that the above points out
some of the perhaps as-yet unconsidered complexities and draws in to
question whether Bitcoin is in fact the appropriate place to implement
a solution, given the hassles that will entail. After all, wouldn't
Bitcoin developer time would be better spent improving the core of
bitcoin (ie. distributed settlement system and commodity) rather than
adding new features?
I would invite parties within the Bitcoin community with an interest
in non directly settlement-linked financial transaction negotiation
and reporting features to consider contributing to the existing,
re-usable efforts at the IFEX Project, rather than supporting the
extension of one currency/commodity and settlement infrastructure (ie.
Bitcoin) which IMHO is likely to detract from developer time, increase
complexity, and perhaps result in a less polished and re-applicable
solution overall.
Our proposals:
- X-ISO4217-A3 (X-ISO4217-A3). A published proposal that provides a
mechanism for the open identification of currencies or currency-like
commodities on the internet. (Bitcoin is registered as XBTC).
http://www.ifex-project.org/our-proposals/x-iso4217-a3
- Internet IBAN (IIBAN). A published proposal that provides a
mechanism for the open identification of financial endpoints on the
internet. (IBAN compatible, checksum-included, name-squatting problem
avoiding. The registry of entities is IANA-managed, encourages GPG
use, and avoids the X.509 requirement.)
http://www.ifex-project.org/our-proposals/iiban
- Internet MIC (IMIC). A published proposal that provides a mechanism
for the open identification of financial markets on the internet.
(Such as most Bitcoin exchanges)
http://www.ifex-project.org/our-proposals/imic
- Internet Financial EXchange (IFEX). A proposal under development
that facilitates the negotiation of financial transactions between
internet-based financial endpoints. (The area we would love your
input) http://www.ifex-project.org/our-proposals/ifex
Sincerely and with the utmost respect for the Bitcoin project's excellent work,
Walter Stanish
|
