Is this address format (e.g.: BTC.443860.3.56318) a good idea?

[JFC]

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:

   19xuKwgfphk3mMaN7TEYYYULLou671KxfC

could 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?

[1715512369]

1715512369

[1715512369]

1715512369

[trout]

The idea is kinda similar to firstbits (if you haven't seen, look it up - it's pretty neat), but the CRC part is a clear advantage.  Firstbits pretty much died off and I think it happened because of errors in calculating firstbit addresses by a popular service (blockchain.info) which resulted in some loss of funds.

However, I suppose the fact that you have to get a transaction in the blockchain before you can use an address, as well as the implied mandatory address reuse, could be a killer

[JFC]

However, I suppose the fact that you have to get a transaction in the blockchain before you can use an address, as well as the implied mandatory address reuse, could be a killer

Won't address reuse be much less of a problem when using LN?

[cryptoGsus]

The idea is kinda similar to firstbits (if you haven't seen, look it up - it's pretty neat), but the CRC part is a clear advantage.  Firstbits pretty much died off and I think it happened because of errors in calculating firstbit addresses by a popular service (blockchain.info) which resulted in some loss of funds.

However, I suppose the fact that you have to get a transaction in the blockchain before you can use an address, as well as the implied mandatory address reuse, could be a killer

Firstbits looks like an interesting idea. This format fixes most of the problems, but even with a checksum I think the two problems you mentioned here are a killer.

[Coding Enthusiast]

The biggest problem IMO is that you can't use this format with an empty address. And also SPV clients can not do this on their own.
Also for this:

(Precondition: Your address exists as a single output in a transaction that has ben cemented in the bitcoin blockchain)

The transaction can have multiple outputs too, you can just add a new number after that "3" representing the index (ref

Also why not use QR code?
They are simple, easily generated, and have error correction built in.

[JFC]

(Precondition: Your address exists as a single output in a transaction that has ben cemented in the bitcoin blockchain)

The transaction can have multiple outputs too, you can just add a new number after that "3" representing the index (ref

Hi,

You are right. I talked about the possibility of adding another indirection level when mentioning the drawbacks (please mind the 25 after the 3). I didn't want however to present it as the general case as it introduces more complexity.

"Using a second level of indirection would help here, by pointing to a transaction with multiple outputs E.g: BTC.443860.3.25.56318"

I will address your other points in a separate post.

[JFC]

The biggest problem IMO is that you can't use this format with an empty address. And also SPV clients can not do this on their own.
Also for this:

(Precondition: Your address exists as a single output in a transaction that has ben cemented in the bitcoin blockchain)

Also why not use QR code?
They are simple, easily generated, and have error correction built in.

Warning:

I may extend myself a little bit over here. Also, this comment will be less of a technical nature and more about easy of use and safety. If you aren't interested in these matters, please skip this post.

The biggest problem IMO is that you can't use this format with an empty address

I am in no way proposing this alternate way of generating and expressing bitcoin addresses as a replacement for the generic case. It would make absolutely no sense for many reasons we probably don't even need to explain here.

However, I think there are a few use cases where this kind of address communication can be a significant improvement over the normal Base58Check format.

But first, let's talk a little bit about some of the problems of the current way of generating payment addresses for some scenarios:

• The Base58Check format is, IMHO, barely an improvement (if any) over the HEX representation of an address from the point of the user interface. It is intimidating, weird looking and very error prone if you had to type it.
• QR Codes are non human readable. You really have no idea where you are transferring your money to when you are relying on a QR
• Generating a new address each time you want to receive a new payment is safe -since you don't expose your public key- and adds privacy. But it is also very opaque. Those paying you don't really know who they are paying to, and that can be a big problem, sometimes.

The fact that many, many investors in bitcoin are holding their funds at a exchange is proof enough of the complexity of handling bitcoin.

Let me present a scenario where I don't think standard bitcoin payments are the best answers.

Imagine you are going to pay for your shining new house. Let's say the price is 3 million USD. The year is 2020, so you have to pay around 3 BTC

You are presented with a QR code and asked to transfer those 3.14 BTC.

Will you really feel confident doing such a transaction? The destination address is, from the point of view of the payer, totally indistinguishable from any other. She has absolutely no way of verifying that the recipient of the money is the realty company. Maybe the clerk is showing her a QR of an address she generated for herself. Or somehow a hacker managed to generate a QR pointing to a similar, but different address. In this scenario, the pseudonymous nature of bitcoin payments is something more negative than positive.

What would be an alternative way of making this payment?

a) The company sends a small amount of BTC (e.g.: 73 satoshis, which won't be dust by then)  to an address and prints a letter with the instructions to pay in the easy format. Something like "Please, pay BTC 3.14 to this address BTC.443860.3.56318 (c.c.c.: 73)".

b) The customer opens her wallet, types the address in the easy format and verifies that the destination address has the 73 satoshis in that output. (Previously, her wallet verified the checksum provided by the last part of the address, 56318).

c) Confident that she is paying to the proper destination (the letter came sealed and so on...), she hits send and transfer that ginormous amount of BTC.

This procedure may be overkill if you are paying for a coffee but it is not (IMHO) when you have to transfer any meaningful amount of money.

In fact, I believe the proper way of making this payment would be to pay in two transactions, both destined to the same address. Once you complete the first one (Let's say for 146 satoshis), the recipient confirms you that the payment was OK and you can proceed sending the rest of the money.

The way I see it, using the same address repeatedly, makes this transaction much safer, not less.

Since none of the outputs having this address are spent -for now-, the public key isn't exposed during the process.  By generating a new payto: address for each house sale, privacy is also not a concern for the buyer.

So, I believe for this use case, this method of payment is clearly superior to the normal QR payment.

Also, although I don't fully understand the LN draft yet (who does?  ), from my current understanding I believe that you are forced to open a funding transaction to create a channel. Then you make an indefinite amount of payments (and, hopefully, money transfers in your direction) over the course of a potentially long time.
So, this could be an ideal case for this easy address format, since: a) You have to create the funding transaction anyway and b) You have to reuse the address anyway.

Comments?

Note: Paypal already does something similar (at least in my country) when you open a bank-backed account. Upon completing the application process, they send you a small amount of money (let's say 0.13 €) to your bank account. To finish the process, you have to tell them the exact amount you received, thus proving that you are in control of that bank account.

[GreenLighter]

There would be duplicates

[JFC]

There would be duplicates

Could you please elaborate?

[zinobiq]

i think that it needs to tested very long and guarantee that no colission there are.

[Evil-Knievel]

Not gonna work, after blockchain reorganization (in the course of short chain forks) the money will suddenly end up with someone else lol.

[JFC]

Not gonna work, after blockchain reorganization (in the course of short chain forks) the money will suddenly end up with someone else lol.

Hi,

In my original post, I said:

(Precondition: Your address exists as a single output in a transaction that has ben cemented in the bitcoin blockchain)

Maybe cemented is not the most precise word here. A block with more than 6 confirmations is generally considered safe enough so your money isn't going anywhere you don't intend. As long as the implementation doesn't let you refer to a block with fewer than 6 confirmations, you should be safe (https://en.bitcoin.it/wiki/Confirmation).

But you can easily wait -let's say 12- confirmations or more to get additional safety. Waiting for 24 hours will give you around 144 blocks on top of yours. One has to be really paranoid to go any further; but it is your money. Wait as long as you want to feel safe.

In addition to that, the CRC-16 part of the easy address format (the last number) means that you have a probability of a collision of 1/2^16 (0.0000152587890625). And this is just a rough idea. Instead of using CRC-16 you could take the last n-bits of a Hash, thus getting a higher protection (20 bits gives you a chance of about 1 in a million of a collision, and can be expressed with <=5 decimal digits most of the time). So even if you mistype the address or there is a fork, there is very little chance of losing any money. Using the amount transferred to the 'anchor' transaction (see my example of the house sale in a previous answer) will grant you an even higher degree of confidence that you are sending your money to the right destination.

On the other hand, upon a second reading of your comment I think maybe we have a bit of a missunderstanding here.

When you say:

 

the money will suddenly end up with someone else lol "

maybe you are in the belief that I am proposing recording addresses on the blockchain in this format, which I am absolutely not.

I am just proposing an additional way to express a payment destination, that is easier and safer for certain payments.

In the end, your wallet will retrieve and use the underlying bitcoin address (that is the Hash-160 of your public key). There is NO change at all in the bitcoin blockchain.

[GreenLighter]

There would be duplicates

Could you please elaborate?

In two ways. First, there are bound to be more than one Bitcoin address bound to certain keys. Easy to fix this one by increasing the amount of number slots. Second, by using a smaller pool of characters, you are more likely to generate the same address multiple times. This is why Bitcoin uses base58. If characters that look similar to you are not a problem, you could expand it to base64, increasing the address possibilities significantly. Taking it a step further, which would add 0, O, I, l you could add other characters like !@#$%)^()& to add even more

[JFC]

There would be duplicates

Could you please elaborate?

In two ways. First, there are bound to be more than one Bitcoin address bound to certain keys. Easy to fix this one by increasing the amount of number slots. Second, by using a smaller pool of characters, you are more likely to generate the same address multiple times. This is why Bitcoin uses base58. If characters that look similar to you are not a problem, you could expand it to base64, increasing the address possibilities significantly. Taking it a step further, which would add 0, O, I, l you could add other characters like !@#$%)^()& to add even more

Hi, thanks for your extended comments.

I think you are missing a key element of this system to express an address.

As a precondition, the intended address must exist already in the blockchain. You can't use this scheme to represent a new address that you have generated but no one has seen yet.

So, you are counting the addressing capacity of this scheme the wrong way.
This address scheme is not a way of shortening any arbitrary bitcoin address by expressing it with only decimal digits.
Any such schemes are obviously destined to fail since you can't express the 2¹⁶⁰ addresses with a few decimal characters. (You'd need up to 49 decimal digits, to be more precise; that is 0 .. 1461501637330902918203684832716283019655932542975 ).

But, given the precondition stated above, we don't need to be able to represent every possible address. We only have to be able to express an address that is already recorded in the bitcoin blockchain.

So, this address scheme is simply a secure and human friendly way to represent a pointer to an existing address.
As a result, we only need enough digits to express the pointer, like this (I am showing here the more complex case, where you can have different outputs in a transaction):

Pointer to the block . Pointer to the transaction . Pointer to the output . Checksum

How many decimal digits do we need to express any bitcoin address already recorded in the blockchain as a transaction output then?


Let's count them :

Pointer to the block -> 6 digits.

We are around block 444.000 nowadays, after 9 years of constantly producing blocks. At this speed (1 block every 10 minutes) we won't need more than 6 digits for ten more years.

Pointer to the transaction -> 4 digits (máx) Depends on the block size. Nowaways 4 digits. I don't think we'll need more than 5 digits for a long time.

Pointer to the output (within the transaction) -> 4 digit (máx) .

According to Gavin Andresen transactions larger than 100K won't be relayed. That means fewer than 2000 outputs per transaction.

Checksum -> 7 digits (max)  (I am counting on using the last 5 hex digits of a SHA256 hash to have a risk of an undetected error smaller than one in a million).

So, you need 6 + 4 + 4 + 7 = 21 decimal digits in a worst case scenario nowadays (not counting decimal separators and the BTC prefix). Most of the time, you'll need around 6 + 3 + 2 + 5 = 16 or 17 decimal digits.

[Joel_Jantsen]

Not a good idea.I could go into technical stuff but let's save it for another day.The idea has been discussed before,not exactly this but much smaller range of integers like maximum 5 digits.That was a turn down too.In your case,it's equally difficult to remember.Until and unless we associate bitcoin addresses with something that is far easier to remember,example,human brains forget the text but pictorial memories live for longer time in brain.Maybe if we can associate a bitcoin address to a picture and human has to just remember the picture.

[JFC]

Not a good idea.I could go into technical stuff but let's save it for another day.The idea has been discussed before,not exactly this but much smaller range of integers like maximum 5 digits.That was a turn down too.In your case,it's equally difficult to remember.Until and unless we associate bitcoin addresses with something that is far easier to remember,example,human brains forget the text but pictorial memories live for longer time in brain.Maybe if we can associate a bitcoin address to a picture and human has to just remember the picture.

Joel,

sorry but I can't see your point. I have never intended this format to be "remembered".
It is however a format that can be typed relatively easily and doesn't (IMHO) scare an user the way a traditional bitcoin address does.

I am not sure this forum is the best place to appreciate this. We are technical people and are comfortable with hashes, Base64 encoding, hex representations...

For a normal person, an address like 19xuKwgfphk3mMaN7TEYYYULLou671KxfC is scary.

Just compare it with BTC.443860.3.0.8803362

The way I see it, using this way to transfer (a decent amount of) money has the following benefits:

a) Way less scary
b) Compact (15 decimal digits in the example vs 34 case sensitive alphanumeric positions)
c) Possible to be dictated and typed easily (only needs the numerical keypad)
d) Secure (mostly but not only, because of the checksum)
e) Familiar; very similar to what regular people use to transfer money
f) Doesn't need any external database or service, it just makes use of the blockchain
g) The implementation in a wallet is ridiculously easy
h) Doesn't require major testing, since it doesn't change the bitcoin protocol in any way
i) It is completely optional. You can use if you need it and when you need it.
g) You can even use it without a software implementation (Just use the blockchain.info website)
h) Could be a good match for LN payments (not absolutely sure of this, however, see my previous post)

It has also the following challenges:

a) Not implemented anywhere. Just an idea (yet)
b) Not valid for every transaction (it doesn't intend to, anyway)
c) It could have some security risks I am not capable of seeing (that's the top reason I posted this, btw)
d) Needs a standard (Anyone would like to help me writing a BIP for it?)

Bitcoin will have to become much more user friendly to achieve the kind of reach we all expect it to.

Bitcoin is clearly a ginormous technical achievement. However, money is not just a technology but also a social construct. Most of the people I know, couldn't care less about the trustless consensus nature of bitcoin, its mathematical properties, ...

When they hear about 'Miners' and 'Exchanges' instead of banks, 'Wallets' and 'Addresses' instead of bank accounts, 'Digital signatures', 'Elliptical curves',... they really get confused and scared. (And there are really many reasons to be scared. I would be terrified if I were the person responsible to make this 194,993 BTC transaction).  I believe we would be fooling ourselves if we think the bitcoin user interface (addresses, units of measure, confusion in the name of the network, the protocol, etc.) doesn't need a radical overhaul.

If we neglect the social aspects of bitcoin, by not improving also its non-technical deficits, it won't succeed as a payment platform. Maybe what we have is enough for it to succeed as a settlement network for an investor to be happy, but I think we can do much better.

_{Note: For the less technical people reading this -> let me repeat again that I am not proposing any change at all in the bitcoin protocol. This would only be an additional feature for a wallet that would not prevent you from using QRs or whatever method you are more comfortable with. Also, it doesn't need any kind of soft fork, hard fork, or fish fork} 

[Mandy420]

Opening new levels of discussion to improve bitcoin is a great thing but I kind of like the address format and I'm not that  a tech-savvy type of girl, I just got used to it

[DannyHamilton]

The way I see it, using this way to transfer (a decent amount of) money has the following benefits:

a) Way less scary I disagree.  I don't find bitcoin addresses scary at all.
b) Compact (15 decimal digits in the example vs 34 case sensitive alphanumeric positions)
c) Possible to be dictated and typed easily (only needs the numerical keypad) Bitcoin addresses can also be dictated and typed easily.
d) Secure (mostly but not only, because of the checksum) Bitcoin addresses also have a checksum.
e) Familiar; very similar to what regular people use to transfer money
f) Doesn't need any external database or service, it just makes use of the blockchain For most, the blockchain IS an external database.  Bitcoin addresses on the otherhand do NOT need an external database.
g) The implementation in a wallet is ridiculously easy Lite (SPV) wallets don't store the entire blockchain.  Bitcoin addresses are MUCH easier to implement in a wallet.
h) Doesn't require major testing, since it doesn't change the bitcoin protocol in any way Anything handling people's wealth should be tested.  Bitcoin addresses are already tested for more than 8 years.
i) It is completely optional. You can use if you need it and when you need it. Bitcoin addresses are already optional.  Your solution isn't optional if the other party hasn't implemented your solution, or if the other party refuses to accept traditional addresses.
g) You can even use it without a software implementation (Just use the blockchain.info website) I find blockchain.info's website to be VERY unreliable.

It has also the following challenges:

a) Not implemented anywhere. Just an idea (yet)
b) Not valid for every transaction (it doesn't intend to, anyway)
c) It could have some security risks I am not capable of seeing (that's the top reason I posted this, btw)
d) Needs a standard (Anyone would like to help me writing a BIP for it?)
e) Best practice is to NEVER re-use a bitcoin address.  This "solution" is useless for everyone except those that are already choosing to ignore this advice.

Bitcoin will have to become much more user friendly to achieve the kind of reach we all expect it to.

Just like TCP/IP and UDP and HTTPS and FTP and routers and switches and gateways and firewalls need to be much more user friendly for the internet to achieve the kind of reach we all expect it to?

The solution is to add layers on top of the technology, not to change the underlying technology or expect the average user to understand the underlying technology.  I realize that your suggestion IS a layer on top of the existing technology, it's just a bad layer that discourages best practices.

If we neglect the social aspects of bitcoin, by not improving also its non-technical deficits, it won't succeed as a payment platform.

Then I guess we don't need to change anything, because it is already succeeding as a payment platform.  Given your statement, I guess that must be proof that we've already "improved its non-technical deficits".

Maybe what we have is enough for it to succeed as a settlement network for an investor to be happy, but I think we can do much better.

And we will.  But not with this proposal.

[Kray]

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:

   19xuKwgfphk3mMaN7TEYYYULLou671KxfC

could 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

[JFC]

No, in my opinion that address can create collision address some day and can be manipulated easily

Kray, thanks for your comments.

I am very interested in the two points you raise here.

Could you please:

a) Give an example of a possible collision that would be undetected by the Checksum?
b) (Since you say that it "can be manipulated easily") Give me an example of an easy manipulation?

Thanks again for your time.