diff options
author | Walter Stanish <walter@stani.sh> | 2012-11-27 10:16:01 +0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2012-11-27 02:16:09 +0000 |
commit | bdbbf66bd8e18ca99679209df384b8c0ab5120ef (patch) | |
tree | 80b09079616d32228888766f549f60867137e0f7 | |
parent | 427a90a64448cbbb76364b495b5dac1bc5f52f69 (diff) | |
download | pi-bitcoindev-bdbbf66bd8e18ca99679209df384b8c0ab5120ef.tar.gz pi-bitcoindev-bdbbf66bd8e18ca99679209df384b8c0ab5120ef.zip |
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
-rw-r--r-- | 5d/fc31fa434249249db7e6ce26174573e5c0e344 | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/5d/fc31fa434249249db7e6ce26174573e5c0e344 b/5d/fc31fa434249249db7e6ce26174573e5c0e344 new file mode 100644 index 000000000..91c5844a8 --- /dev/null +++ b/5d/fc31fa434249249db7e6ce26174573e5c0e344 @@ -0,0 +1,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 + + |