From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 52D25E72 for ; Fri, 11 Sep 2015 09:44:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A44A712C for ; Fri, 11 Sep 2015 09:44:14 +0000 (UTC) Received: by iofh134 with SMTP id h134so91912097iof.0 for ; Fri, 11 Sep 2015 02:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=KvvO3K2UpWjkVA8Y98tBjIa+ApeBW+M22+4b7JIEdkY=; b=TIfla1ftJOQ+W52GLbMTfiV1NkfJcFBRNMo1GeJaOg7aSxVn1JLe7zpYv96DXoLrkh 9RA18tTfyVQJt2kM19dGq76F5nmkS2LIlc7cbeRy8/cCgpBCB9x0rt4sARvuLrOxAaCA OX/DVi+6jqE0fzhYO+f5i1uJgr7hHwocsHpBIZ6pVAHlqgRwFMRnAHb3MQGoZX/w0pVs /qAwjJs68UeSH1+TO4tm0EUJZX4VpS9hr9zpingt0qwkrbJadO2moc/tP1NodK9BekTh 40L0VQkm0mwhceNQgQudMlXaKqnq5OV+7Cr/RHaqVo54iCnXnzRACY8iPQF/6S8N2riV 6D+A== X-Received: by 10.107.166.139 with SMTP id p133mr2048127ioe.113.1441964654026; Fri, 11 Sep 2015 02:44:14 -0700 (PDT) MIME-Version: 1.0 Sender: asperous2@gmail.com Received: by 10.50.3.33 with HTTP; Fri, 11 Sep 2015 02:43:54 -0700 (PDT) In-Reply-To: References: From: Andy Chase Date: Fri, 11 Sep 2015 02:43:54 -0700 X-Google-Sender-Auth: Q46MF_UQfG3rHUvC1odKjWXAXkU Message-ID: To: Mark Friedenbach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, 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: Fri, 11 Sep 2015 09:44:15 -0000 What's some more information about the "memorizing and sharing" use case? In most cases if you wanted someone to send you money you'd send them a payment request via email (or just send them your address). There's a bunch of solutions to your problem listed here: https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki But sending a payment request via BIP-70 is the "best practice": https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki On Thu, Sep 10, 2015 at 2:32 PM, Mark Friedenbach via bitcoin-dev wrote: > Are you aware of the payment protocol? > > On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev" > wrote: >> >> Hi Everyone, >> >> An issue I'm sure everyone here is familiar with is the problem concerni= ng >> the fact that Bitcoin addresses are too complex to memorize and share. >> Current Bitcoin addresses can be very intimidating to new users. As Bitc= oin >> grows it's necessary to provide a much more user friendly experience to = the >> 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 securel= y >> keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin addres= s >> and because Bob is using a Named Bitcoin Address and a supported wallet = he >> 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 writte= n 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 addre= ss. >> >> First Bob let=E2=80=99s his wallet know that he wants to create a new ad= dress. In >> response, his wallet simply asks him what he wants that address to be na= med. >> Bob then enters =E2=80=98SendBitcoinsToBob=E2=80=99 as his preferred add= ress name. The >> wallet then let=E2=80=99s Bob know if his preferred address name is avai= lable. 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 knows where Alice will b= e sending >> her Bitcoins. The client does this by referencing a downloaded =E2=80=9C= directory=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 viewabl= e on >> the blockchain) with the name appended to the transactions as an OP_RETU= RN >> output. These transactions are downloaded or indexed, depending on wheth= er >> or not the wallet contains the full Blockchain or is an SPV wallet. Beca= use >> 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 sor= ted >> in two ways, the first being the first character and the second being th= e >> total length of the name (I will being exploring additional methods to m= ake >> this process more efficient). So now that Bob=E2=80=99s client has verif= ied 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 sends a transaction of 1 satoshi an= d a >> small fee to the address without a private 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 3= 2 >> 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 Bit= coin 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 devic= e 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 add= ress >> name. If a name isn=E2=80=99t found the client would simply return an er= ror. If the >> name is found then the client will pull the information of that transact= ion >> 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 o= f 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 >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >