diff options
| author | Andy Chase <theandychase@gmail.com> | 2015-09-11 02:43:54 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-11 09:44:15 +0000 |
| commit | 06f78e184acebabe0b0e58b5ecfa0e95632b71b2 (patch) | |
| tree | b33ff915461a1bc00ed181279cf89c09348d3e14 | |
| parent | 122b2fab9e29e79f1c140b307e1e4c3b1b71e9a7 (diff) | |
| download | pi-bitcoindev-06f78e184acebabe0b0e58b5ecfa0e95632b71b2.tar.gz pi-bitcoindev-06f78e184acebabe0b0e58b5ecfa0e95632b71b2.zip | |
Re: [bitcoin-dev] Named Bitcoin Addresses
| -rw-r--r-- | b0/6479f77cb17791d32291de06d0807e0c6d04e3 | 203 |
1 files changed, 203 insertions, 0 deletions
diff --git a/b0/6479f77cb17791d32291de06d0807e0c6d04e3 b/b0/6479f77cb17791d32291de06d0807e0c6d04e3 new file mode 100644 index 000000000..bfe4cddb7 --- /dev/null +++ b/b0/6479f77cb17791d32291de06d0807e0c6d04e3 @@ -0,0 +1,203 @@ +Return-Path: <asperous2@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 52D25E72 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 11 Sep 2015 09:44:14 +0000 (UTC) +Received: by iofh134 with SMTP id h134so91912097iof.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAOG=w-vsp6Oxx3WsjVoQ9xO41SqgUMw97h0Ba1jSd9s=KZL6wQ@mail.gmail.com> +References: <CAK8x=ZUhYQXGsrxZGDMQtXu80zqrejVnb01w=8s38-HF0VLXqA@mail.gmail.com> + <CAOG=w-vsp6Oxx3WsjVoQ9xO41SqgUMw97h0Ba1jSd9s=KZL6wQ@mail.gmail.com> +From: Andy Chase <theandychase@gmail.com> +Date: Fri, 11 Sep 2015 02:43:54 -0700 +X-Google-Sender-Auth: Q46MF_UQfG3rHUvC1odKjWXAXkU +Message-ID: <CAAxp-m9upffFeuf_SQM2OzSh=Jf-8QX3Rie6w73s0yLPMirGTA@mail.gmail.com> +To: Mark Friedenbach <mark@friedenbach.org> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> 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 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 +> + |