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

Wed Dec 6 01:05:03 UTC 2017

1/ It is off topic
2/ Threshold multiparty signature suffer from exactly the same problem as
P2SH.

2017-12-05 16:16 GMT+01:00 digitsu via bitcoin-ml <
bitcoin-ml at lists.linuxfoundation.org>:

> Maybe worth mentioning that we don’t necessarily need to fix the p2sh
> collision problem by changing the address format.  Another solution is to
> stop using p2sh multisig’s altogether and use a partial threshold signature
> solution.  Essentially go back to the good old p2pkh.  Although that may
> segway the discussion a bit.
>
>
> On Nov 16, 2017, at 22:49, 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
>
> It definitely seems we need to fix that.
>
>
>
> On Wed, Nov 15, 2017 at 9:57 PM, Jonald Fyookball <jonaldfyookball@
> outlook.com> wrote:
>
>> Here's a relevant link
>>
>> https://bitcoin.stackexchange.com/questions/54841/birthday-a
>> ttack-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 <bit
>> coin-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 <http://bitpay.com/>
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171206/f284eec9/attachment-0001.html>