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

Thu Nov 16 13:49:45 UTC 2017

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

It definitely seems we need to fix that.

On Wed, Nov 15, 2017 at 9:57 PM, Jonald Fyookball <
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>
> segregated witness - Birthday attack on P2SH - Bitcoin ...
> <https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh/54844>
> 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 <
> bitcoin-ml-bounces at lists.linuxfoundation.org> on behalf of Amaury Séchet
> via bitcoin-ml <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>:
>
>
> 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> 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 ) 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 listbitcoin-ml at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
>
>
> --
> BitPay.com
>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>
>
>

-- 
BitPay.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171116/e3a41535/attachment-0001.html>