path: root/58/4e306a200c1bbb104083ef2a13b4f95674da76

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <walter.stanish@gmail.com>) id 1Tdi6y-0000uL-8l
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Nov 2012 13:55:36 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Tdi6r-0004f5-B7
	for bitcoin-development@lists.sourceforge.net;
	Wed, 28 Nov 2012 13:55:35 +0000
Received: by mail-bk0-f47.google.com with SMTP id j4so4251784bkw.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 28 Nov 2012 05:55:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.145.217 with SMTP id e25mr5876001bkv.123.1354110922649;
	Wed, 28 Nov 2012 05:55:22 -0800 (PST)
Sender: walter.stanish@gmail.com
Received: by 10.204.49.133 with HTTP; Wed, 28 Nov 2012 05:55:22 -0800 (PST)
In-Reply-To: <CABsx9T3BjnwufFKeYkHEoHxgJjoHc2+WCfimGBmmunS4ZwjzsA@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<CACwuEiP7CGeZZGW=mXwrFAAqbbwbrPXTPb8vOEDuO9_96hqBGg@mail.gmail.com>
	<CAAS2fgSY8hHiCJYEDv=y48hYRJJtB-R5EBX8JLz6NivBm+Z9PQ@mail.gmail.com>
	<CACwuEiMjf8WYOpfmzHUHMa-sy2VsJHaUNj1cj722Y=P_sosbvw@mail.gmail.com>
	<CAJ1JLtuJ8HQri7++2bodc2ACRrE7Y48oy0HkPR8d400MooHaqA@mail.gmail.com>
	<CACwuEiMgcv09U2P9dD58x-oMXMSg==fPYo0yRLsqzyuax96Eqw@mail.gmail.com>
	<CAJ1JLttTPi9XNwCGyvbvx8TXqbLyk0KxFRHxv_8UB+tEQrKvvA@mail.gmail.com>
	<CACwuEiNZobcpR4g=1AH=JReZFzHmH=6exNGTaPBBjm+q5eR9vg@mail.gmail.com>
	<895A1D97-68B4-4A2F-B4A1-34814B9BA8AC@ceptacle.com>
	<CANEZrP1u0-JNf1nd4NsZhrqC=M0Yx3J6cTYA=bzKm8CTucd85w@mail.gmail.com>
	<626D0E73-1111-4380-AABE-6C8C65F2FFCC@ceptacle.com>
	<CANEZrP03kSG5BYMykkW+UJiy65qPOBC7RuvKg85eLEmE3tnukQ@mail.gmail.com>
	<98E8A2D6-56D1-4E28-BB63-71E13382B5B8@ceptacle.com>
	<CABsx9T3BjnwufFKeYkHEoHxgJjoHc2+WCfimGBmmunS4ZwjzsA@mail.gmail.com>
Date: Wed, 28 Nov 2012 21:55:22 +0800
X-Google-Sender-Auth: xBRdYgb2EmQdISvMnZBJ7XgEBu8
Message-ID: <CACwuEiN6YwB6=hT5FJV5-3Fd8M3UiqYTsCQM4TQgG+vTpujDtg@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: 1Tdi6r-0004f5-B7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Michael Gronager <gronager@ceptacle.com>
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: Wed, 28 Nov 2012 13:55:36 -0000

> RE: the ifex-project and other electronic invoicing standards:  Thanks
> for the pointers, Walter! I'm all for adopting the best ideas that
> have come before, as long as we end up with something useful and small
> enough to convince ourselves it is as secure as we can make it.

Fair enough, although I would posit:
 0. You can't get more secure than not doing it at all.
 1. Small is sometimes beautiful, but sometimes just the 999th
crippled and half-featured attempt at a nontrivial problem space
(...linked heavily to implementation-time assumptions and/or specific
peer systems, and by its very nature destined for the dustbin of time?
Well, maybe. Eventually, we all are.)
 2. X.509 is not small (or beautiful, unless one is some weird new
kind of centralized cryptographic trust fetishist, of some sort you
might see with furrowed brows, boozing at midday sporting key & anchor
tattoos in old convention polo-shirts, mumbling to themselves about
the employee-motivation benefits of single sign-on...)

> looked at the ifex spec, and quickly got lost. It would help me if you
> could write up what our motivating use cases would look like if
> implemented on top of ifex.

Yes. Understandable. Thoughts around an IFEX protocol proposal, unlike
the other proposals, are still drafty (err...as a coastal verandah?)
and not the clearest. However, we have much research and progress has
been achieved in the odd year-or-so since beginning.  The fundamental
concerns of such a protocol (regarding the establishment of neutral,
open and technically-viable proposals for internet-wide
currency/commodity, market and financial endpoint identification) have
already been reasonably met.

This has opened the door to the potential for faster progress on the
IFEX protocol itself ("a mechanism for the identification,
negotiation, description, execution and management of financial
transactions over their lifetime"), like, right about now. Which is
kind of the same zone of potential functionality (at least in a naive,
linguistic comparison sense) that people are talking about here.
Because of the hope to garner more interest from the Bitcoin community
with this post (do read on!), I spent a bunch of hours today cleaning
up and converting the IFEX Protocol's current breezy-draft form back
from the wiki formatting it had been lazing and grazing (and growing,
albeit slowly) in for the greater part of the year and moving to
Github (forks and issues very much encouraged) over here:
https://github.com/globalcitizen/ifex-protocol
  (Discussion list at http://group.ifex-project.org/ actually has
quite a few members at present, despite appearances to the contrary)

> implemented on top of ifex.

Re: "implemented on top of ifex", this is kind of opposite to how IFEX works.

IFEX's idea is to provide a flexible yet stable protocol that lets
individual (potential, ongoing, or completed) transactions on
arbitrary (legacy, conventional, emerging, or future) settlement
systems (in arbitrary currencies/commodities) to be described and
facilitated (executed, routed, monitored, etc.) in real time, by
describing accurately the objective properties of each of those
systems and components.

So, for example, an end user, requiring a transfer of <x> of <y>
currency/commodity from 'point a' to 'point b' would find routes to
achieve that, evaluate them in terms of monetary and temporal
overheads against their own trust and risk models plus any legal,
privacy or other requirements in order to select and effect the most
appropriate manner of settlement.

In short, IFEX sees Bitcoin as having such-and-such properties,
matches that to a need to transfer some funds, and effects the
transfer, monitoring and/or reporting on its state in a normalized
fashion throughout its lifetime.

I'll try again to describe the motivating use case:
==============
Recognising that Bitcoin is not the only emerging financial community
or settlement system facing real world business integration
challenges, and recognising the significant complexity of these in
common situations (multi-hop transactions, arbitrary currency
transactions, foreign exchange automation, liquidity guarantee
challenges, settlement latency negotiation, invoicing periods,
commercial payment or shipping terms, sovereign (exchange rate
fluctuation) and other forms of risk management, potentially
simultaneous multi-level fee, tax and discount requirements,
product/service coding, line items, complex tax calculations
(particularly in the US, and which may be based on both buyer and
seller geolocation), legal requirements to include various metadata,
etc.), instead of investing valuable developer time on internal
implementation (and subsequent maintenance) of a tightly-scoped
(==crippled?) business-level protocol extension to Bitcoin that can be
perhaps fairly characterised as unlikely to quickly evolve to meet
many of these real world requirements, and with as yet unclear real
world demand for such from the Bitcoin community, who must already
overcome significant complexity hurdles to use Bitcoin at all, Bitcoin
developers can instead simply declare this "out of scope" (win!) and
focus on Bitcoin's current roles as a digital commodity and settlement
system.

This approach to scope limitation has excellent historical support
from the unix community - "do one thing and do it well". Bitcoin
already does a few things, notably in its triple roles as
network-community, currency-like-commodity, and settlement system.

The alternative is that instead of creating load for the Bitcoin
developers, who may be ill-equipped and ill-resourced to properly
tackle these peripheral requirements, interested parties instead
contribute to projects like IFEX that view systems such as Bitcoin as
core use cases but are not limited by Bitcoin developer time or
project trajectory, and promise re-usability for other conventional,
emerging and future currencies/commodities/settlement systems, thus
retaining the capacity to attract interest and resources from those
communities (and broader, internet-centric interest groups and
infrastructure) toward a common goal, while creating a valuable shared
platform for interoperability between Bitcoin and those other systems
(including legacy financial systems) that allows Bitcoin to
objectively showcase its strengths.

Net result: Bitcoin developers can focus on Bitcoin. Meanwhile,
business level integration things completely tangential to the core
bitcoin codebase get done with a far broader scope and applicability,
providing a broader community and potential resource base for moving
things forward, and presenting a less "shifting-sands" approach to
potential implementers (who are safe in the knowledge that their now
standardized infrastructure can support a wide range of
currencies/commodities, settlement systems, financial network
topologies settlement paradigms, and will not critically rely upon any
given component system as a single point of failure). Bitcoin, through
the platform IFEX develops, gets to compete at the business level on a
fair and even basis with legacy and other emerging systems based upon
its highly desirable objective properties (speed, reach, low
overheads, rapid connection, lack of wacky X.509 certificate
purchasing requirements... yet, etc.), such that a business case *not*
to use it in various commercial settings becomes difficult to field.
Everyone wins.
==============

Note that the above basically echoes much of the (less verbose? more
digestible?) information available at http://ifex-project.org/ where -
along with http://tools.ietf.org/ - the full text of existing
proposals are also available, but attempts to do so in a more specific
fashion for Bitcoin developer community.

Considering the above, and that a single system is never going to meet
every person's needs all of the time (yes, even Bitcoin!), I really
hope that the Bitcoin developer community will see the benefits of
supporting an external rather than internal solution to business level
(or at least non directly settlement-facilitating) financial
transaction requirements, both for the Bitcoin project itself, its
users, and for that broader and longer-term goal (in very much the
same spirit) of effecting some sorely-needed, socially positive and
lasting change in global financial systems.  Nothing can be all things
to all people (especially X.509, which can be completely different
kinds of pain to all who come in to contact with it) - but at least
with an open, platform neutral financial transaction oriented protocol
outside of individual settlement system, currency and commodity
projects, each new system can stand on its own merit and support the
others, deriving shared fruits of increased user base, usability and
liquidity through heterogeneous interoperability.

Sincerely, hoping to work together with interested parties to move
forward in this area (come issue/fork the github repo!), and with the
utmost respect for all of the valuable work of the Bitcoin community
(though scratching my head a bit on the lack of an April 1 date or
punchline for this X.509 stuff!!), and, and, out of breath,
Walter Stanish