[Bitcoin-ml] Proposed address format for bitcoin cash

Tom Zander tomz at freedommail.ch
Wed Nov 8 15:41:15 UTC 2017


On Wednesday, 8 November 2017 15:58:26 CET freetrader wrote:
> > I asked specifically what problem this is trying to solve. I have not
> > seen this answered.
> I'll try to answer your question from my perspective. I'm sure it's not
> complete.

So,lets be clear, my question is about which problem you are trying to 
solve. So this is your list of the problems people have been complaining 
about or have lost money over, yes?

> - insensitivity to case --> easier to transmit between people

I don’t see how anyone could have been complaining that we really need to 
solve this.
You don’t expect people to read a code over the phone, do you?
None of the current ways we transmit addresses have this problem. 
(QR/NFC/clipboard/email/click-on-webbrowser-link).

> - allows more flexible payload (longer hashes etc) --> can accommodate
> future new address needs 

Like what?
This isn’t a problem. This is a solution in search of a problem.

> - ability to error-correct 

You may be confused, the current address type has that too. And its more 
than sufficient. There is no material problem to solve here.

> - readable prefix --> can identify address type better

Ditto, the current format has this already.
Additionally, the URI spec adds “bitcoincash:” for payments, this also 
already exists and fulfills the role you want.

> There's four advantages, but at this point I'm rehashing stuff.

Ah, advantages. None of them actually solve problems that people have.
Its like I’m hearing the PR guys explain that the new version of MSWord has 
“advantages” over the previous one.

I have to conclude that it doesn't actually solve any problems real people 
have. Not solving problems while suggesting something that is very expensive 
for the entire ecosystem is at best irresponsible.

The costs;
* with ABC not supporting the existing solution and being months behind with 
a possible solution, they cause more and more people to lose money.
* a rip-and-replace is needed to do this upgrade, whereas the simple “just 
change the version-byte” change we currently have allows a clean upgrade 
path.
* Its magnitudes more complex than the currently shipped solution, that cost 
is development cost the entire ecosystem would have to repeat.

> Note that I'm not arguing against also doing the simpler thing.
> This is not trying to distract you, it's trying to get to the bottom of
> reasoning against a better solution on grounds which I find unconvincing.

A solution already being deployed is by default the better solution. Running 
code wins every single time.
You have to argue why yours is better for the actual users you claim to 
serve.

And stop trying to reverse roles, 
the simple truth is that ABC refuses to support a solution we already have 
that avoids people losing money. Something that is already on the market, 
being supported and gaining traction.
That is behavior you need to defend.

Because the bottom line is that if you put the weight of ABC behind the 
Bitpay solution, we would have had it solved already.

THAT would be the way to make people stop losing money by accidentally 
sending BTC to a BCH address or vice versa.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


More information about the bitcoin-ml mailing list