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

[Amaury Séchet]

Ideally, we want to switch to the new format by default, but support the
old one for a transition period.

2017-11-15 1:58 GMT+01:00 Jason Cox <jasonbradleycox at gmail.com>:

> I agree this sounds like a solid idea (especially for multiparty
> contracts).  However, I'm not as familiar with how address format changes
> get deployed.  Will all old format addresses be forced to send to new
> format addresses only going forward, or will wallet providers be expected
> to provide for sending to both address formats?
>
> On Nov 14, 2017 4:39 PM, "checksum0 via bitcoin-ml" <bitcoin-ml at lists.
> linuxfoundation.org> wrote:
>
> Let's definitely do this. Changing the address prefix is easy however the
> larger payloads as well as stronger checksum capability is a must.
>
> Let's move quickly like only the Bitcoin Cash community can do.
>
> P.S.: Please let's not have the knee jerk reaction of judging bech32 over
> it's perceived association with segwit.
>
>
> -------- Original Message --------
> Subject: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
> Local Time: November 14, 2017 7:25 PM
> UTC Time: November 15, 2017 12:25 AM
> From: bitcoin-ml at lists.linuxfoundation.org
> To: Bitcoin and related network protocol discussion <
> bitcoin-ml at lists.linuxfoundation.org>
>
> 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
>
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171115/4cb25f39/attachment.html>