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 ) 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 ; 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: References: <1323731781.42953.YahooMailClassic@web120920.mail.ne1.yahoo.com> <201112121841.39864.luke@dashjr.org> <1323736946.58149.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Wed, 14 Dec 2011 10:30:04 +0800 X-Google-Sender-Auth: CsHOo2N1W_00f-QSAeWEIDZLlM0 Message-ID: From: Walter Stanish To: Gavin Andresen 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.