đ
Original date posted:2015-09-11
đ Original message: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 at lists.linuxfoundation.org> wrote:
> Are you aware of the payment protocol?
> On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev" <
> bitcoin-dev at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/6ce236b5/attachment.html>;
Kristov Atlas [ARCHIVE] /
npub1arâŚ5ksrm
2023-06-07 17:39:58
in reply to nevent1qâŚgyjt
Author Public Key
npub1arzmapjcjg2yf3hpe6e5h407mn3ry662vhmjhdpe5tft2nelhd9sk5ksrmPublished at
2023-06-07 17:39:58Event JSON
{
"id": "1882101f833036480cd746217c6cdda2de2d5a9d9351d314a06bdb7e396196d8",
"pubkey": "e8c5be8658921444c6e1ceb34bd5fedce2326b4a65f72bb439a2d2b54f3fbb4b",
"created_at": 1686159598,
"kind": 1,
"tags": [
[
"e",
"3a79f8bfa01f62843757ccd69db1de9234940fe2a7a004268205308b812ee156",
"",
"root"
],
[
"e",
"32752c3b771fc8b2c245f74213a229687491d3cdfcc94f38bd6ae331bbe3cbe2",
"",
"reply"
],
[
"p",
"ba04f4d1170f593a978aba85df5755615cf525b48d666a395a387ee1bf42efe3"
]
],
"content": "đ
Original date posted:2015-09-11\nđ Original message:I applaud your brainstorming efforts! :) But I dislike just about\neverything about this proposal.\n\nBitcoin addresses should never be reused, for privacy and security reasons\ndocumented extensively online.\n\nI definitely do not want my computer to maintain a registry of every\naddress in the world any more than I want to maintain a list of all email\naddresses, web addresses, etc. This cannot be scaled and is wasteful since\nmost participants in the network don't need to transact.\n\nIf we need naming conventions, I'd rather see a name registry system\noff-chain attached to bip47 reusable payment codes.\n\n-Kr\nOn Sep 10, 2015 5:32 PM, \"Mark Friedenbach via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Are you aware of the payment protocol?\n\u003e On Sep 10, 2015 2:12 PM, \"essofluffy . via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi Everyone,\n\u003e\u003e\n\u003e\u003e An issue I'm sure everyone here is familiar with is the problem\n\u003e\u003e concerning the fact that Bitcoin addresses are too complex to memorize and\n\u003e\u003e share. Current Bitcoin addresses can be very intimidating to new users. As\n\u003e\u003e Bitcoin grows it's necessary to provide a much more user friendly\n\u003e\u003e experience to the end user. I think that having the capability to assign a\n\u003e\u003e unique name to a Bitcoin address is in the best interest of Bitcoin and\n\u003e\u003e it's users.\n\u003e\u003e I've recently come up with a method for assigning a unique name to a\n\u003e\u003e specific Bitcoin address. I'm looking to get some feedback/criticism on\n\u003e\u003e this method that I have detailed below.\n\u003e\u003e\n\u003e\u003e Letâs run through Bob and Alice transacting with a Named Bitcoin Address.\n\u003e\u003e Bob wants to collect a payment from Alice for a service/good he is\n\u003e\u003e selling, but Alice wants to pay from her home computer where she securely\n\u003e\u003e keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin address\n\u003e\u003e and because Bob is using a Named Bitcoin Address and a supported wallet he\n\u003e\u003e can give her an easy to memorize and hard to mess up address. Bobâs address\n\u003e\u003e is simply âSendBitcoinsToBobâ which can easily be written down or\n\u003e\u003e memorized. Now Alice can go home send the Bitcoin from her own supported\n\u003e\u003e wallet and be positive that she sent it to Bob.\n\u003e\u003e\n\u003e\u003e Letâs look at how Bobâs supported wallet made that address.\n\u003e\u003e\n\u003e\u003e First Bob letâs his wallet know that he wants to create a new address. In\n\u003e\u003e response, his wallet simply asks him what he wants that address to be\n\u003e\u003e named. Bob then enters âSendBitcoinsToBobâ as his preferred address name.\n\u003e\u003e The wallet then letâs Bob know if his preferred address name is available.\n\u003e\u003e If itâs available the name is broadcasted to the network and ready to use.\n\u003e\u003e\n\u003e\u003e Now letâs get a little more technical.\n\u003e\u003e\n\u003e\u003e When Bob inputs his preferred address name the client has to make sure\n\u003e\u003e this name hasnât been taken or else who knows where Alice will be sending\n\u003e\u003e her Bitcoins. The client does this by referencing a downloaded âdirectoryâ\n\u003e\u003e of names chosen by people using this system. This directory of names are\n\u003e\u003e transactions sent to an address without a private key (but still viewable\n\u003e\u003e on the blockchain) with the name appended to the transactions as an\n\u003e\u003e OP_RETURN output. These transactions are downloaded or indexed, depending\n\u003e\u003e on whether or not the wallet contains the full Blockchain or is an SPV\n\u003e\u003e wallet. Because of such a large amount of possible address names a binary\n\u003e\u003e search method is used to search through all this data efficiently. The\n\u003e\u003e names could be sorted in two ways, the first being the first character and\n\u003e\u003e the second being the total length of the name (I will being exploring\n\u003e\u003e additional methods to make this process more efficient). So now that Bobâs\n\u003e\u003e client has verified that the name has not been taken and is valid (valid\n\u003e\u003e meaning it's under 35 bytes long and only using chars 0-9 and a-z) it sends\n\u003e\u003e a transaction of 1 satoshi and a small fee to the address without a private\n\u003e\u003e key as talked about earlier. The transaction's OP_RETURN output consists of\n\u003e\u003e two parts. The implementation version of this method (up to 8 characters)\n\u003e\u003e and the name itself (up to 32 characters). Once the transaction is\n\u003e\u003e broadcasted to the network and confirmed the name is ready to be used.\n\u003e\u003e\n\u003e\u003e Letâs look at how Aliceâs supported wallet sends her Bitcoin to Bobâs\n\u003e\u003e Named Bitcoin Address.\n\u003e\u003e\n\u003e\u003e When Alice enters in Bobâs address, âSendBitcoinsToBobâ Aliceâs client\n\u003e\u003e references the same âdirectoryâ as Bob only on her device and searches for\n\u003e\u003e the OP_RETURN output of âSendBitcoinsToBobâ using a very similar binary\n\u003e\u003e search method as used for the verification of the availability of an\n\u003e\u003e address name. If a name isnât found the client would simply return an\n\u003e\u003e error. If the name is found then the client will pull the information of\n\u003e\u003e that transaction and use the address it was sent from as the address to\n\u003e\u003e send the Bitcoin to.\n\u003e\u003e\n\u003e\u003e Essentially what this idea describes is a method to assign a name to a\n\u003e\u003e Bitcoin address in a way that is completely verifiable and independent of a\n\u003e\u003e third party.\n\u003e\u003e\n\u003e\u003e Please ask your questions and provide feedback.\n\u003e\u003e\n\u003e\u003e - Devin\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150911/6ce236b5/attachment.html\u003e",
"sig": "5ec060e4e5f5b7a3f92176423c5f531e5119d31a0ef8a153cfc221b5fa193fcd64df917c85551a15fcbcd644dbb8cbf6a58961bfe072caa80099465e63ab0e86"
}