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

Ryan X. Charles ryan at yours.org
Thu Nov 16 20:17:47 UTC 2017


At Yours, our position on this issue is to follow BitPay’s lead. We have already implemented Copay’s new address format, which fully solves the most pressing issue of confusion between BTC and BCH. If BitPay moves to the new cashaddr format, we will follow.

If the new format is indeed better, I hope BitPay adopts it. We have pretty much one chance to update the address format to fix the BTC/BCH issue, because the community won’t be incentivized to switch again. Let’s go with the best format.

Ryan X. Charles
Cofounder & CEO of Yours
https://www.yours.org



> On Nov 16, 2017, at 5:49 AM, Matias Alejo Garcia via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org> wrote:
> 
> Thanks, Amaury and Jonald.
> 
> If someone is also curious about this, I found more information on the p2sh collision attach here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html>
> 
> It definitely seems we need to fix that. 
> 
> 
> 
> On Wed, Nov 15, 2017 at 9:57 PM, Jonald Fyookball <jonaldfyookball at outlook.com <mailto:jonaldfyookball at outlook.com>> wrote:
> Here's a relevant link
> 
> https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844 <https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844>
>  <https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844>	
> segregated witness - Birthday attack on P2SH - Bitcoin ... <https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844>
> bitcoin.stackexchange.com <http://bitcoin.stackexchange.com/>
> The Segwit Benefits document has this to say about P2SH security for base transactions: Multisig payments currently use P2SH which is secured by the 160-bit HASH160 ...
> 
> 
> From: bitcoin-ml-bounces at lists.linuxfoundation.org <mailto:bitcoin-ml-bounces at lists.linuxfoundation.org> <bitcoin-ml-bounces at lists.linuxfoundation.org <mailto:bitcoin-ml-bounces at lists.linuxfoundation.org>> on behalf of Amaury Séchet via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>>
> Sent: Wednesday, November 15, 2017 7:12:11 PM
> To: Matias Alejo Garcia; Bitcoin and related protocol coordination
> Subject: Re: [Bitcoin-ml] Proposal to deploy cashaddr January, 14
>  
> Sure.
> 
> If I want to steal your coins, I need to grind through addresses I control the private key for up to when I find an address that has the same hash as yours. This is called a pre-image attack. The hash is 160bits, which means you get 160 bits of security. This is considered very secure.
> 
> Now let's assume that instead of having just your key, you create a multisig address with some 3rd party. That 3rd party could grind thought the address they give you and other addresses on the side such as it can find 2 sets of addresses - one including your, the other which doesn't - such as both hash to the same value. In that case, you believe you control part of the key, but in fact the 3rd party knows another set of keys that control the coins completely. This is called a collision attack. Because of the birthday paradox, it turns out that collision attacks are significantly easier than pre-image attacks. For a hash of 160bits, the security when facing this kind of attack is of 80 bits. 80 bits is considered at the limit of what is secure, to quote djb, it is exciting crypto. We are very playing with the limit of what can be considered secure here.
> 
> In order to fix this, we need to use hash of 256 bits instead of 16O bits. This means we need an address format capable of encoding larger payload than a 160 bits hash.
> 
> I hope this makes things clearer.
> 
> Amaury Séchet
> 
> 2017-11-16 0:27 GMT+01:00 Matias Alejo Garcia via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>>:
> 
> Thanks Amaury for putting this proposal together!
> 
> 
> It seems using a different format from the other chain is the most important requirement (+ easily distinguishable by humans).  As Chris mentioned, migrating to just a different address version (C/H) would be the easiest to implement. IMHO, most of the new features the new format brings are not quite relevant, but this one:
> 
> > " 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."
> 
> Could you please explain that a little more or share a link with more information on the subject?
> 
> thanks!
> 
> matías
> 
> On Wed, Nov 15, 2017 at 5:31 PM, Chris Pacia via bitcoin-ml <bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>> wrote:
> So this is just my two cents. The cashaddr is nice, but substantially more difficult to implement than the alternatives. I've spent a few hours now working on it and still don't have it working. It would have been a two minute change to create the bitpay addr for example. 
> 
> Not saying it shouldn't be used, but the adoption speed is going to depend on how easy people find it to implement and the speed at which people get libraries out there. 
> 
> 
> On 11/14/2017 07:25 PM, Amaury Séchet via bitcoin-ml 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 <https://github.com/Bitcoin-UAHF/spec/blob/master/cashaddr.md> ) is based on work from Rusty Russel ( https://rusty.ozlabs.org/?p=578 <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 <mailto:bitcoin-ml at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
> 
> 
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
> 
> 
> 
> 
> -- 
> BitPay.com
> 
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
> 
> 
> 
> 
> 
> -- 
> BitPay.com <http://bitpay.com/>_______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org <mailto:bitcoin-ml at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171116/85598274/attachment-0001.html>


More information about the bitcoin-ml mailing list