From the perspective of the user interface, the bitcoin address format is IMHO one of the big problems bitcoin faces to be widely accepted as a global payment system.
A typical bitcoin address looks like 19xuKwgfphk3mMaN7TEYYYULLou671KxfC. This must be spooky for a regular person.
Other payment systems have a WAY more user friendly address. Paypal, for instance uses your email address as the payment address.
So
jdoe.452@hotmail.com is a valid payment address for Paypal users.
Bank accounts in many countries follow the IBAN format. A sample account id for Switzerland would be CH93 0076 2011 6238 5295 7 (
http://www.xe.com/ibancalculator/sample/?ibancountry=switzerland).
A bit more complicated, but also more robust against mistakes than the Paypal format.
After a little bit of googling on the subject, I've been unable to find any good alternatives for expressing a bitcoin address in a more user friendly manner. (I'd welcome any information about similar or better proposals).
So (at the risk of infuriating #youknowwho# for not having done an extensive research of the prior state of the art) I'd like to share an idea for, what I believe, could be a robust and user friendly address format:
Let's present it with an example (taken from this block
https://blockexplorer.com/block/0000000000000000004e389113ddc1334eaf18ce5ea944ecc6042e17a6ebb80b):
The address:
19xuKwgfphk3mMaN7TEYYYULLou671KxfCcould be represented as :
BTC.443860.3.56318(
Precondition: Your address exists as a single output in a transaction that has ben cemented in the bitcoin blockchain)
The format would be something like this:
<BTC>.
<block_number>.
<transaction_number>.<CRC-16(Base58Check_bitcoin-address)>
Where:
<BTC> Currency code, fixed in the case of Bitcoin.
<block_number> Block number of a transaction committed in the blockchain that has the desired address as its single output. In our example,
443860.
<transaction_number> Ordinal number (within the block) of the transaction whose only output is the address we want to represent. In our example,
3 (zero_based)
<CRC-16> Checksum in CRC-16 format of the bitcoin address we want to represent. In our example, CRC-16(19xuKwgfphk3mMaN7TEYYYULLou671KxfC)=56318
I see these benefits to this format:
a) Compact, with < 25 characters (18 in the example). Many years from now, the block number will be nearly same length. As for the transaction_number, it is around 4 digits currently, probably below 6 digits for a long time.
b)
User friendly, as it is not only compact, but mostly composed of decimal numbers, easy to transmit even by voice and
much less intimidating than the current format.
c) Robust, the CRC-16 (just an example, other checksum algorithm could be used instead) provides safety against transcription mistakes.
e) Independent of the address format. If new address formats are introduced, the system is still valid since it is only a pointer to the address itself.
The biggest drawback I can see is the address reuse it may introduce. Using a second level of indirection would help here, by pointing to a transaction with multiple outputs E.g: BTC.443860.3.
25.56318. And you can always point to a new address as soon as you have another transaction committed to the chain.
Another problem is that you can not use this address format to receive payments until you have committed an anchor transaction.
Do you see any other major problems, improvement suggestions or any other alternatives? If there are other, better ideas to improve the address format, what is hampering them?
No, in my opinion that address can create collision address some day and can be manipulated easily
Show Posts
why not, BitBeans are incoming 
it's christmas time
What happen with this?
