Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AAC9E120B for ; Thu, 10 Sep 2015 21:32:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6EA95137 for ; Thu, 10 Sep 2015 21:32:38 +0000 (UTC) Received: by ioii196 with SMTP id i196so77014751ioi.3 for ; Thu, 10 Sep 2015 14:32:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J+caJ4jwUC/wWwQXsoXRlTuWXnOg88YPCbED2cUkzJY=; b=kjTL4gBjiujIhB4+N/QmrbArJz2bOJi7mIPMc90ipPaYgXGsJqXm/qmWe90/11XhlI QTqUg2bWA1yCzuUF8Si85pre717l77C3RoBnGicEJQBFWfazEgztdmvjIOGTJxZ7ZjZC KlgJ5lOGuga98VVaYg0GQs6MtocXpz+zyk1QwmdzpqtEX/82Fb4HpwW9aB3YkTkMZOHP o55GBxhaqbsK4zSk5Kz5gIlvy57x8xqhaz4HA4pvZ+vAv4H2lFgKI4v/3YPfaW4/DGgp aBJgd/J505AYp+xbtExr6vWCKXttvpbGU8KMcQ21FeAPF74IYTcZRgEFZFR3nIDX+nEr sCKw== X-Gm-Message-State: ALoCoQlRAp1j9EhlfH8mLYzH5foZ2U/RLDH+xMiuEoDBaSMrsJI6bLOf89ejep0uZmOMNKC+qwOU MIME-Version: 1.0 X-Received: by 10.107.15.159 with SMTP id 31mr57287190iop.159.1441920757689; Thu, 10 Sep 2015 14:32:37 -0700 (PDT) Received: by 10.107.135.104 with HTTP; Thu, 10 Sep 2015 14:32:37 -0700 (PDT) X-Originating-IP: [172.56.16.178] Received: by 10.107.135.104 with HTTP; Thu, 10 Sep 2015 14:32:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Sep 2015 14:32:37 -0700 Message-ID: From: Mark Friedenbach To: "essofluffy ." Content-Type: multipart/alternative; boundary=001a113ee8688e8c7e051f6b567c X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Named Bitcoin Addresses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 21:32:39 -0000 --001a113ee8688e8c7e051f6b567c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Are you aware of the payment protocol? On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Everyone, > > An issue I'm sure everyone here is familiar with is the problem concernin= g > the fact that Bitcoin addresses are too complex to memorize and share. > Current Bitcoin addresses can be very intimidating to new users. As Bitco= in > grows it's necessary to provide a much more user friendly experience to t= he > end user. I think that having the capability to assign a unique name to a > Bitcoin address is in the best interest of Bitcoin and it's users. > I've recently come up with a method for assigning a unique name to a > specific Bitcoin address. I'm looking to get some feedback/criticism on > this method that I have detailed below. > > Let=E2=80=99s run through Bob and Alice transacting with a Named Bitcoin = Address. > Bob wants to collect a payment from Alice for a service/good he is > selling, but Alice wants to pay from her home computer where she securely > keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin address > and because Bob is using a Named Bitcoin Address and a supported wallet h= e > can give her an easy to memorize and hard to mess up address. Bob=E2=80= =99s address > is simply =E2=80=98SendBitcoinsToBob=E2=80=99 which can easily be written= down or > memorized. Now Alice can go home send the Bitcoin from her own supported > wallet and be positive that she sent it to Bob. > > Let=E2=80=99s look at how Bob=E2=80=99s supported wallet made that addres= s. > > First Bob let=E2=80=99s his wallet know that he wants to create a new add= ress. In > response, his wallet simply asks him what he wants that address to be > named. Bob then enters =E2=80=98SendBitcoinsToBob=E2=80=99 as his preferr= ed address name. > The wallet then let=E2=80=99s Bob know if his preferred address name is a= vailable. > If it=E2=80=99s available the name is broadcasted to the network and read= y to use. > > Now let=E2=80=99s get a little more technical. > > When Bob inputs his preferred address name the client has to make sure > this name hasn=E2=80=99t been taken or else who knows where Alice will be= sending > her Bitcoins. The client does this by referencing a downloaded =E2=80=9Cd= irectory=E2=80=9D > of names chosen by people using this system. This directory of names are > transactions sent to an address without a private key (but still viewable > on the blockchain) with the name appended to the transactions as an > OP_RETURN output. These transactions are downloaded or indexed, depending > on whether or not the wallet contains the full Blockchain or is an SPV > wallet. Because of such a large amount of possible address names a binary > search method is used to search through all this data efficiently. The > names could be sorted in two ways, the first being the first character an= d > the second being the total length of the name (I will being exploring > additional methods to make this process more efficient). So now that Bob= =E2=80=99s > client has verified that the name has not been taken and is valid (valid > meaning it's under 35 bytes long and only using chars 0-9 and a-z) it sen= ds > a transaction of 1 satoshi and a small fee to the address without a priva= te > key as talked about earlier. The transaction's OP_RETURN output consists = of > two parts. The implementation version of this method (up to 8 characters) > and the name itself (up to 32 characters). Once the transaction is > broadcasted to the network and confirmed the name is ready to be used. > > Let=E2=80=99s look at how Alice=E2=80=99s supported wallet sends her Bitc= oin to Bob=E2=80=99s > Named Bitcoin Address. > > When Alice enters in Bob=E2=80=99s address, =E2=80=98SendBitcoinsToBob=E2= =80=99 Alice=E2=80=99s client > references the same =E2=80=9Cdirectory=E2=80=9D as Bob only on her device= and searches for > the OP_RETURN output of =E2=80=98SendBitcoinsToBob=E2=80=99 using a very = similar binary > search method as used for the verification of the availability of an > address name. If a name isn=E2=80=99t found the client would simply retur= n an > error. If the name is found then the client will pull the information of > that transaction and use the address it was sent from as the address to > send the Bitcoin to. > > Essentially what this idea describes is a method to assign a name to a > Bitcoin address in a way that is completely verifiable and independent of= a > third party. > > Please ask your questions and provide feedback. > > - Devin > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113ee8688e8c7e051f6b567c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Are you aware of the payment protocol?

On Sep 10, 2015 2:12 PM, "essofluffy . via = bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Everyone,=C2=A0

=
An issue I'm sure everyone here is familiar with is the pr= oblem concerning the fact that=C2=A0Bitcoin addresses are too complex=C2=A0= to memorize and share. Current Bitcoin addresses can be very intimidating t= o new users. As Bitcoin grows it's necessary to provide a much more use= r friendly experience to the end user. I think that having the capability t= o assign a unique=C2=A0name to a Bitcoin address is in the best interest of= Bitcoin and it's users.
<= span style=3D"background-color:rgba(255,255,255,0)">I've recently come = up with a method for assigning a unique name to a specific Bitcoin address.= I'm looking to get some feedback/criticism on this method that I have = detailed below.

Let=E2=80=99s r= un through Bob and Alice transacting with a=C2=A0Named Bitcoin Address.
Bob wants to collect a payment from Alice for a service/goo= d he is selling, but Alice wants to pay from her home computer where she se= curely keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin ad= dress and because Bob is using a Named Bitcoin Address and a=C2=A0supported= wallet he can give her an easy to memorize and hard to mess up address. Bo= b=E2=80=99s address is simply =E2=80=98SendBitcoinsToBob=E2=80=99 which can= easily be written down or memorized. Now Alice can go home send the Bitcoi= n from her own supported wallet and be positive that she sent it to Bob.

Let=E2=80=99s look at how Bob=E2= =80=99s supported wallet made that address.

<= /font>
First Bob let=E2=80=99s his wallet know that he wants to create= a new address. In response, his wallet simply asks him what he wants that = address to be named. Bob then enters =E2=80=98SendBitcoinsToBob=E2=80=99 as= his preferred address name. The wallet then let=E2=80=99s Bob know if his = preferred address name is available. If it=E2=80=99s available the name is = broadcasted to the network and ready to use.

=
Now let=E2=80=99s get a little more technical.

When Bob inputs his preferred address name the = client has to make sure this name hasn=E2=80=99t been taken or else who kno= ws where Alice will be sending her Bitcoins. The client does this by refere= ncing a downloaded =E2=80=9Cdirectory=E2=80=9D of names chosen by people us= ing this system. This directory of names are transactions sent to an addres= s without a private key (but still viewable on the blockchain) with the nam= e appended to the transactions as an OP_RETURN output. These transactions= =C2=A0are=C2=A0downloaded or indexed, depending on whether or not the walle= t contains the full Blockchain or is an SPV wallet. Because of such a large= amount of possible address names a binary search method is used to search = through all this data efficiently. The names could be sorted in two ways, t= he first being the first character and the second being the total length of= the name (I will being exploring additional methods to make this process m= ore efficient). So now that Bob=E2=80=99s client has verified that the name= has not been taken and is valid (valid meaning it's under 35 bytes lon= g and only using chars 0-9 and a-z) it sends a transaction of 1 satoshi=C2= =A0and a small fee to the address without a private key as talked about ear= lier. The transaction's=C2=A0OP_RETURN output=C2=A0consists=C2=A0of two= parts. The implementation version of this method=C2=A0(up to 8=C2=A0charac= ters) and the name itself (up to 32=C2=A0characters). Once the transaction = is broadcasted to the network and confirmed the name is=C2=A0ready to be us= ed.

Let=E2=80=99s look at how Al= ice=E2=80=99s supported wallet sends her Bitcoin to Bob=E2=80=99s Named Bit= coin Address.=C2=A0

When Alice e= nters in Bob=E2=80=99s address, =E2=80=98SendBitcoinsToBob=E2=80=99 Alice= =E2=80=99s client references the same =E2=80=9Cdirectory=E2=80=9D as Bob on= ly on her device and searches for the OP_RETURN output of =E2=80=98SendBitc= oinsToBob=E2=80=99 using a very similar binary search method as used for th= e verification of the availability of an address name. If a name isn=E2=80= =99t found the client would simply return an error. If the name is found th= en the client will pull the information of that transaction and use the add= ress it was sent from as the address to send the Bitcoin to.<= /div>

Essentially what this idea=C2=A0describes=C2= =A0is a method to assign a name to a Bitcoin address in a way that is compl= etely verifiable and independent of a third party.
=
<= /span>
Please ask your questions and provide feedback.

- Devin
=C2=A0=

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113ee8688e8c7e051f6b567c--