Named Bitcoin Addresses

Named Bitcoin Addresses
2015-09-10 21:32 ` Mark Friedenbach
  
From: essofluffy . @ 2015-09-10 21:12 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 4156 bytes --]

Hi Everyone,

An issue I'm sure everyone here is familiar with is the problem concerning
the fact that Bitcoin addresses are too complex to memorize and share.
Current Bitcoin addresses can be very intimidating to new users. As Bitcoin
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’s 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 he can give her
an easy to memorize and hard to mess up address. Bob’s address is simply
‘SendBitcoinsToBob’ 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’s look at how Bob’s supported wallet made that address.

First Bob let’s 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 ‘SendBitcoinsToBob’ as his preferred address name.
The wallet then let’s Bob know if his preferred address name is available.
If it’s available the name is broadcasted to the network and ready to use.

Now let’s get a little more technical.

When Bob inputs his preferred address name the client has to make sure this
name hasn’t been taken or else who knows where Alice will be sending her
Bitcoins. The client does this by referencing a downloaded “directory” 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 and
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’s
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 sends
a transaction of 1 satoshi and 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 32 characters). Once the transaction is
broadcasted to the network and confirmed the name is ready to be used.

Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s Named
Bitcoin Address.

When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
references the same “directory” as Bob only on her device and searches for
the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
search method as used for the verification of the availability of an
address name. If a name isn’t found the client would simply return 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

[-- Attachment #2: Type: text/html, Size: 6515 bytes --]

 permalink raw reply	[|nested]
2015-09-10 21:12 [bitcoin-dev] Named Bitcoin Addresses essofluffy .

  2015-09-11  9:43   ` Andy Chase
  2015-09-11 15:13   ` Kristov Atlas
  
From: Mark Friedenbach @ 2015-09-10 21:32 UTC (permalink / raw)
  To: essofluffy .;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4635 bytes --]

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 concerning
> the fact that Bitcoin addresses are too complex to memorize and share.
> Current Bitcoin addresses can be very intimidating to new users. As Bitcoin
> 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’s 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 he
> can give her an easy to memorize and hard to mess up address. Bob’s address
> is simply ‘SendBitcoinsToBob’ 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’s look at how Bob’s supported wallet made that address.
>
> First Bob let’s 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 ‘SendBitcoinsToBob’ as his preferred address name.
> The wallet then let’s Bob know if his preferred address name is available.
> If it’s available the name is broadcasted to the network and ready to use.
>
> Now let’s get a little more technical.
>
> When Bob inputs his preferred address name the client has to make sure
> this name hasn’t been taken or else who knows where Alice will be sending
> her Bitcoins. The client does this by referencing a downloaded “directory”
> 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 and
> 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’s
> 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 sends
> a transaction of 1 satoshi and 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 32 characters). Once the transaction is
> broadcasted to the network and confirmed the name is ready to be used.
>
> Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s
> Named Bitcoin Address.
>
> When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
> references the same “directory” as Bob only on her device and searches for
> the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
> search method as used for the verification of the availability of an
> address name. If a name isn’t found the client would simply return 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
>
>

[-- Attachment #2: Type: text/html, Size: 7291 bytes --]

 permalink raw reply	[|nested]
2015-09-10 21:32 ` Mark Friedenbach

  2015-09-11 15:13   ` Kristov Atlas
  
From: Andy Chase @ 2015-09-11  9:43 UTC (permalink / raw)
  To: Mark Friedenbach;  Bitcoin Dev

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 concerning
>> the fact that Bitcoin addresses are too complex to memorize and share.
>> Current Bitcoin addresses can be very intimidating to new users. As Bitcoin
>> 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’s 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 he
>> can give her an easy to memorize and hard to mess up address. Bob’s address
>> is simply ‘SendBitcoinsToBob’ 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’s look at how Bob’s supported wallet made that address.
>>
>> First Bob let’s 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 ‘SendBitcoinsToBob’ as his preferred address name. The
>> wallet then let’s Bob know if his preferred address name is available. If
>> it’s available the name is broadcasted to the network and ready to use.
>>
>> Now let’s get a little more technical.
>>
>> When Bob inputs his preferred address name the client has to make sure
>> this name hasn’t been taken or else who knows where Alice will be sending
>> her Bitcoins. The client does this by referencing a downloaded “directory”
>> 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 and 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’s 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 sends a transaction of 1 satoshi and 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 32
>> characters). Once the transaction is broadcasted to the network and
>> confirmed the name is ready to be used.
>>
>> Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s
>> Named Bitcoin Address.
>>
>> When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
>> references the same “directory” as Bob only on her device and searches for
>> the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
>> search method as used for the verification of the availability of an address
>> name. If a name isn’t found the client would simply return 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


 permalink raw reply	[|nested]
2015-09-10 21:32 ` Mark Friedenbach
  2015-09-11  9:43   ` Andy Chase

  
From: Kristov Atlas @ 2015-09-11 15:13 UTC (permalink / raw)
  To: Mark Friedenbach;  bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 5653 bytes --]

I applaud your brainstorming efforts! :) But I dislike just about
everything about this proposal.

Bitcoin addresses should never be reused, for privacy and security reasons
documented extensively online.

I definitely do not want my computer to maintain a registry of every
address in the world any more than I want to maintain a list of all email
addresses, web addresses, etc. This cannot be scaled and is wasteful since
most participants in the network don't need to transact.

If we need naming conventions, I'd rather see a name registry system
off-chain attached to bip47 reusable payment codes.

-Kr
On Sep 10, 2015 5: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
>> concerning the fact that Bitcoin addresses are too complex to memorize and
>> share. Current Bitcoin addresses can be very intimidating to new users. As
>> Bitcoin 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’s 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 he
>> can give her an easy to memorize and hard to mess up address. Bob’s address
>> is simply ‘SendBitcoinsToBob’ 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’s look at how Bob’s supported wallet made that address.
>>
>> First Bob let’s 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 ‘SendBitcoinsToBob’ as his preferred address name.
>> The wallet then let’s Bob know if his preferred address name is available.
>> If it’s available the name is broadcasted to the network and ready to use.
>>
>> Now let’s get a little more technical.
>>
>> When Bob inputs his preferred address name the client has to make sure
>> this name hasn’t been taken or else who knows where Alice will be sending
>> her Bitcoins. The client does this by referencing a downloaded “directory”
>> 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 and
>> 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’s
>> 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 sends
>> a transaction of 1 satoshi and 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 32 characters). Once the transaction is
>> broadcasted to the network and confirmed the name is ready to be used.
>>
>> Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s
>> Named Bitcoin Address.
>>
>> When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
>> references the same “directory” as Bob only on her device and searches for
>> the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
>> search method as used for the verification of the availability of an
>> address name. If a name isn’t found the client would simply return 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
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 8806 bytes --]

 permalink raw reply	[|nested]