Pages:
Author

Topic: Is this address format (e.g.: BTC.443860.3.56318) a good idea? - page 2. (Read 2278 times)

JFC
newbie
Activity: 24
Merit: 17
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:

Quote
(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:

 
Quote
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.
legendary
Activity: 1260
Merit: 1168
Not gonna work, after blockchain reorganization (in the course of short chain forks) the money will suddenly end up with someone else lol.
newbie
Activity: 24
Merit: 0
i think that it needs to tested very long and guarantee that no colission there are.
JFC
newbie
Activity: 24
Merit: 17
There would be duplicates

Could you please elaborate?
jr. member
Activity: 36
Merit: 2
There would be duplicates
JFC
newbie
Activity: 24
Merit: 17
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:
Quote
(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.

Quote
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 Wink

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?  Wink), 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.
JFC
newbie
Activity: 24
Merit: 17

Quote
(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.

Quote
"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.
legendary
Activity: 1042
Merit: 2805
Bitcoin and C♯ 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:
Quote
(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.
newbie
Activity: 18
Merit: 0
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.
JFC
newbie
Activity: 24
Merit: 17
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?
sr. member
Activity: 333
Merit: 252
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
newbie
Activity: 24
Merit: 17
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 [email protected] 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:

...

Where:

Currency code, fixed in the case of Bitcoin.
  Block number of a transaction committed in the blockchain that has the desired address as its single output. In our example, 443860.
Ordinal number (within the block) of the transaction whose only output is the address we want to represent. In our example, 3 (zero_based)
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?
Pages:
Jump to: