[Bitcoin-ml] Proposal to deploy cashaddr January, 14

Amaury Séchet deadalnix at gmail.com
Wed Nov 15 00:25:50 UTC 2017


Dear Bitcoin Cash community,

Bitcoin Cash has been in need for a new address format for quite some time.
There is an immediate problem as people mistakenly send BCH to BTC address
and vice versa, which is made worse by the fact that segwit on the BTC
chain had the brilliant idea to leverage outputs that anyone can spend,
which make the recovery of the funds delicate on the Bitcoin Cash chain.

Because this need is pressing, companies like Bitpay started using
incompatible addresses format and this is causing fragmentation in the
Bitcoin Cash ecosystem. I do not wish to blame Bitpay, they took action to
solve the problem their business faces, this is good business from their
part.

However, while the problem of funds sent on the wrong chain is pressing,
there are other reasons we need to update the address format. It is
imperative that the chosen standard for Bitcoin Cash address the various
issues present with the current address format as we cannot change
addresses every other tuesday. The most important one being that current
outputs are using 160 bits hashes for multiparty contracts such as
multisig, which is really playing with the limit of what can be considered
secure. It is also desirable that the format chosen can accommodate new
features we wish to deploy, or, in other terms, be extensible.

As a result, I propose to upgrade to the cashaddr format. This format (
https://github.com/Bitcoin-UAHF/spec/blob/master/cashaddr.md ) is based on
work from Rusty Russel ( https://rusty.ozlabs.org/?p=578 ) and uses BCH
codes in order to ensure error detection as suggested by Pieter Wuille for
bech32.

Using a new format will prevent users from mistakenly sending money on the
wrong chain. It also accept payloads up to 512 bits which ensures we can
deploy more secure way of doing multiparty smart contract in the future.
Finally, it uses a version field ensuring we can encode new features in
these addresses in the future without having to use a new format.

In addition of these must have features, cashaddr improve on several
aspects of current address format in a way that may not justify in itself
to use a new format, but are nevertheless really nice to have.
 - It uses a very strong checksum which ensure detection of up to 6 errors
in an address and 8 in ‘burst’. Larger number of errors have one chance
over a thousand billion to lead to a valid address.
 - It encode more compactly in QR codes as it allows the use of the
alphanumeric mode.
 - It is much faster to encode and decode than the previous format, which
is important for system having to handle a large number of addresses.

In order to reduce confusion for users with the use of different addresses,
I think it is important to deploy this shortly and stop the fragmentation
of the ecosystem. Deploying such a change on the network will take some
time for all wallet, exchanges and merchant to upgrade. Christmas and new
year is coming soon and nobody want to do such an upgrade during this time.
As a result, I propose we aim for a deployment around Jan, 14 . This leaves
2 month for everybody to get ready which I think is reasonable. Delaying
further would push us into the Chinese new year territory, which is also
undesirable.

The next version of Bitcoin ABC will include support for cashaddr, hidden
behind a configuration at first, so people can experiment with it. I would
like to invite via this message various participants in the ecosystem to do
the same.

Let's do it ?

Amaury Séchet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171115/4afb9119/attachment.html>


More information about the bitcoin-ml mailing list