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

Blockfreight™ | Julian Smith julian.smith at blockfreight.com
Wed Nov 15 00:39:36 UTC 2017


And as a counterproposal and in the spirit of tongue-in-cheek conciliation,
but so as to illustrate my main point:

- maybe you could propose a unique address format SegWit transactions ?

That was it's easier to identify those from proper Bitcoin transactions by
their form (say when printed on a business card).


On Wed, Nov 15, 2017 at 11:32 AM, Blockfreight™ | Julian Smith <
julian.smith at blockfreight.com> wrote:

> Fuck no let's not.
>
> Bitcoin addresses work.
>
> This isn't useful.
>
> On Wed, Nov 15, 2017 at 11:25 AM, Amaury Séchet via bitcoin-ml <
> bitcoin-ml at lists.linuxfoundation.org> wrote:
>
>> 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/c3e86f23/attachment.html>


More information about the bitcoin-ml mailing list