Quote from: Coding Enthusiast on December 19, 2016, 05:25:36 AM

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.