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; 
MIME-Version: 1.0
Sender: walter.stanish@gmail.com
In-Reply-To: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
Date: Tue, 27 Nov 2012 10:16:01 +0800
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

> 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