diff options
| author | Walter Stanish <walter@stani.sh> | 2011-12-14 10:30:04 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-12-14 02:30:13 +0000 |
| commit | b4e17928de70edb4c3f07ff9826ddd54c524522b (patch) | |
| tree | 1c7593cca30d455abaeff515a3f565e5310808b3 | |
| parent | bf33d35353c8551e2956d066d171537ce7162d98 (diff) | |
| download | pi-bitcoindev-b4e17928de70edb4c3f07ff9826ddd54c524522b.tar.gz pi-bitcoindev-b4e17928de70edb4c3f07ff9826ddd54c524522b.zip | |
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
| -rw-r--r-- | 50/63a6e620efb257957b14d807a36bc65bf44c41 | 226 |
1 files changed, 226 insertions, 0 deletions
diff --git a/50/63a6e620efb257957b14d807a36bc65bf44c41 b/50/63a6e620efb257957b14d807a36bc65bf44c41 new file mode 100644 index 000000000..2cd028705 --- /dev/null +++ b/50/63a6e620efb257957b14d807a36bc65bf44c41 @@ -0,0 +1,226 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <walter.stanish@gmail.com>) id 1Raebl-00041x-DA + for bitcoin-development@lists.sourceforge.net; + Wed, 14 Dec 2011 02:30:13 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.210.175 as permitted sender) + client-ip=209.85.210.175; envelope-from=walter.stanish@gmail.com; + helo=mail-iy0-f175.google.com; +Received: from mail-iy0-f175.google.com ([209.85.210.175]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Raebh-0006lC-W9 + for bitcoin-development@lists.sourceforge.net; + Wed, 14 Dec 2011 02:30:13 +0000 +Received: by iadj38 with SMTP id j38so648399iad.34 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 13 Dec 2011 18:30:04 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.50.217.199 with SMTP id pa7mr16402220igc.48.1323829804642; + Tue, 13 Dec 2011 18:30:04 -0800 (PST) +Sender: walter.stanish@gmail.com +Received: by 10.42.151.69 with HTTP; Tue, 13 Dec 2011 18:30:04 -0800 (PST) +In-Reply-To: <CABsx9T3g=27QwQaoBKKJ2ckZhOUVMokRYNDq9yRXfGzVQOuFJg@mail.gmail.com> +References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com> + <CAGQP0AGvq603oshSGiP79A+gqDqW_hHG+qZjaZccCmo+gd3W2A@mail.gmail.com> + <201112121841.39864.luke@dashjr.org> + <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com> + <CAGQP0AGY32QP=rXyGftb5NbHA7fhcCne7W=pt5+onXp1Jbm98Q@mail.gmail.com> + <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com> + <CANEZrP1oPaqAT+LCfrAXO9WBz+oC2uvbP=5vx2+DX2P0qFusgA@mail.gmail.com> + <CALxbBHUgCOVMRxtnsmC2W-MaYfeDSzaftWMCCgcWsMBdZfzPQg@mail.gmail.com> + <CACwuEiNO=pSfgD415-5=HnaXdXbZ++Ps0n4cyjckLRRP-tJemA@mail.gmail.com> + <CABsx9T3g=27QwQaoBKKJ2ckZhOUVMokRYNDq9yRXfGzVQOuFJg@mail.gmail.com> +Date: Wed, 14 Dec 2011 10:30:04 +0800 +X-Google-Sender-Auth: CsHOo2N1W_00f-QSAeWEIDZLlM0 +Message-ID: <CACwuEiMTexatUaccpgfiqq48gr2swCfWDZCc772XCmN=G-VD-Q@mail.gmail.com> +From: Walter Stanish <walter@stani.sh> +To: Gavin Andresen <gavinandresen@gmail.com> +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -0.7 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 1.5 TVD_PH_BODY_ACCOUNTS_PRE BODY: TVD_PH_BODY_ACCOUNTS_PRE + -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 + -0.8 AWL AWL: From: address is in the auto white-list +X-Headers-End: 1Raebh-0006lC-W9 +Cc: "bitcoin-development@lists.sourceforge.net" + <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases +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, 14 Dec 2011 02:30:13 -0000 + +> Nifty! =A0Thanks for the pointers, I think we should avoid reinventing +> wheels whenever possible. + +Hear hear! + +> When composing my last response in this thread I wrote, and then erased: +> +> "There doesn't have to be one solution: I'd like to see some +> experimentation, with clients supporting different schemes for bitcoin +> address aliases, and maybe supporting plugins to extend the schemes +> supported (a plugin would take a string, do some +> behind-the-scenes-magic, and return a bitcoin address or public key)." + +Sure. Alias systems are a usability focused requirement and as such +should probably not be mandated by the network itself, anyway. + +> Defining Bitcoin as an IIBAN "institution", with 36^6 "accounts", +> seems like a forward-thinking idea, although I'm not clear on exactly +> how those 2.2billion "accounts" would get allocated and mapped into +> bitcoin addresses. + +It seems a clarification is in order, apologies for not being clearer. + +Under the IIBAN scheme, whilst Bitcoin *could* define some default +mechanism for automatically creating IIBANs that map to Bitcoin +addresses (for example, Bitcoin client authors could provide hosted +lookup), this was not the style of integration in mind while writing +the IIBAN draft. + +Rather than simply defining Bitcoin as a single 'institution' +(namespace segment) within the IIBAN standard, Payward Inc. envisages +large numbers of parties (including individuals or small groups of +individuals) operating individual Bitcoin-related (or LETS, or other +alternate currency) services to register as institutions (really just +'namespace holders') within the IIBAN registry. Each such party may +then define its own mapping system between Bitcoin, LETS, or other +alternate currency financial endpoints that it 'manages' (proxies for) +and IIBAN, within its namespace. As detailed within the IIBAN +proposal, this process could be peer to peer or centralized, +supporting one time or short-term use addresses as well as permanent +addresses. A permanent address within IIBAN could map via the +institution managing that portion of the IIBAN address space to a +single use address on the Bitcoin network. + +Institutions are important for the following reasons (from +http://tools.ietf.org/html/draft-iiban-00#section-4.3.2): + + With the advent of decentralized virtual currencies such as [BITCOIN] + the conventional idea of a financial institution (such as a bank) may + be seen by some as somewhat superfluous. However, the notion remains + useful: + + * Conventional currencies will not disappear in the conceivable + future, so the notion of financial institutions is expected + to endure at least as providers of currency exchange and holding + services. + + * Systems such as [BITCOIN] have quirks that require slightly + delayed settlement due to the nature of their decentralized, + consensus-based approach to fiscal transfer. Users requiring + instant settlement MAY thus see benefit in the use of a + centralized proxy system or organization as an instantaneous + financial settlement provider (the 'institution'). + + * IANA MAY delegate management of portions of the IIBAN name space + through such institutions. + +Furthermore from http://tools.ietf.org/html/draft-iiban-00#section-4.3.1: + + [Under IIBAN's combined issue paradigm] proxied issue is + facilitated through IANA managed institution registration, provision + for two types of privately issued addresses is reserved within this + document, and registered institutions COULD provide DHT or similar + mechanisms for the management of their delegated name space. The + combined issue paradigm offers adequate provision for both + manageability and decentralization, whilst maintaining heterogeneity. + +So the idea is that many institutions each provide mappings between +IIBAN and Bitcoin, in a range of ways, and we do not see the emergence +of a single mandated standard. There is no suggestion that Bitcoin +developers should implement a hard-coded mechanism. + +> I imagine some central organization that maps IIBAN account numbers to +> domain names... and then clients (or plugins in the clients) query +> that trusted central organization and then the account holder's domain +> to get a (possibly unique) public key or bitcoin address. + +This style of solution - in which a central organization becomes aware +of every single IIBAN-based transaction in the network - is not +necessary or desirable. Instead, under the IIBAN recommendation IANA +would publish the registry of IIBAN institutions for everyone to use +without the need to query any party. + +In the case of a financial transfer, a client or peer instutition +seeking to send funds to an IIBAN-denominated address would use some +hitherto-underfined mechanism* for translating the appropriate entry +within that registry (corresponding to the transfer's destination +address) to some kind of internet node representing the institution's +systems. + +* This mechanism may necessitate the storage of public keys within the +IIBAN institution registry and will be addressed within the next +version of the IIBAN draft. Community input is encouraged. + +In a second yet-to-be-define protocol**, various settlement-system +neutral (ie: not specific to Bitcoin, LETS, or any other system) +transaction-related metadata would then be exchanged, prior to any +actual transaction. Such metadata could include aspects of the +transaction such as description, financial system endpoint ('account') +holder name, account exists verification, settlement path negotiation +(based upon feasibility, transaction overheads, latency, etc.), which +party is to pay overheads, information mandated by local jurisdiction +such as business tax numbers (required in some countries of Europe, I +believe, for domestic B2B settlements), etc. + +** This mechanism does need to be defined, and Payward Inc. has +completed a not insubstantial amount of research in to existing +protocols and concerns within this area, which touches upon high +frequency automated banking, financial market support, and interbank +settlement policy. An additional Internet Draft proposing one such +potential mechanism will probably be published 'soon'. + +At the conclusion of this metadata exchange, the two nodes would have +either aborted the transaction, suspended it to seek human input (such +as settlement path selection based upon fee and latency metadata +garnered), or agreed upon financial settlement system specific +information to use in executing the transaction itself, likely out of +band. In the case of Bitcoin, this *might* include information such as +the blockcount after which the transaction will be considered settled +by the receiving institution, an effective 'gentleman's agreement' on +the terms of any opt-in notion of reversibility, a one time Bitcoin +address provided by the recipient institution for the sender to make a +Bitcoin transaction to, etc. + +From the perspective of a settlement system such as Bitcoin, IIBAN's +provision of settlement system neutral financial endpoint +identification provides the benefits outlined in the previous email, +as well as the possibility to publish a permanent, fixed address +without disclosing one's corresponding Bitcoin-derived income. From +the broader perspective of effective financial system innovation, it +hopes to provide a common basis upon which many such systems can +conceivably interoperate, regardless of their underlying systemic +differences. + +> As long as IIBANs are not the ONLY way of aliasing bitcoin addresses +> to more-human-friendly strings I think that would be a fine way to do +> it. + +Thank you for your vote of confidence. + +Regards, +Walter Stanish +Payward Inc. + + |