> On Feb 26, 2017, at 12:36 AM, Pieter Wuille wrote:
>
> The 80-bit collision attack only applies to jointly constructed addresses
> like multisig P2SH, not single-key ones.
That’s the part I’m less convinced about, and why I asked the original question
re SHA1 vs RIPEMD.
I’m checking my ow
Hi Pieter,
> On Feb 25, 2017, at 4:14 PM, Pieter Wuille wrote:
>
> Any alternative to move us away from RIPEMD160 would require:
>
“Any alternative”? What about reverting to:
[, OP_CHECKSIG]
or perhaps later
[<“compressed” public_key>, OP_CHECKSIG]
This appears to get away from the issue
On Feb 25, 2017 22:26, "Steve Davis" wrote:
Hi Pieter,
> On Feb 25, 2017, at 4:14 PM, Pieter Wuille
wrote:
>
> Any alternative to move us away from RIPEMD160 would require:
>
“Any alternative”? What about reverting to:
[, OP_CHECKSIG]
snip
Could that be the alternative?
Ok, fair enoug
Some thoughts about the activation mechanism for soft forks. In the past we
used IsSuperMajority and currently use BIP9 as soft fork activation methods,
where a supermajority of hashrate triggers nodes to begin enforcing new rules.
Hashrate based activation is convenient because it is the simple
If people split their bitcoins in multiple addresses, then maybe there
would be no need to worry(?), because the computational cost would be
higher than what the attacker would get.
>From Google:
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
*Here are some numbers
I strongly encourage Bitcoin to move from 80-bit collision resistance
(RIPEMD-160) to 128-bit collision resistance (SHA-256).
On Sat, Feb 25, 2017 at 5:14 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev"
On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Peter,
I really, really don’t want to get into it but segwit has many aspects that
are less appealing, not least of which being the amount of time it would
take to reach the critical mass.
Su
Hi Peter,
> On Feb 25, 2017, at 3:40 PM, Peter Todd wrote:
>
> On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote:
>> Yea, well. I don’t think it is ethical to post instructions without an
>> associated remediation (BIP) if you don’t see the potential attack.
>
> I can't agree with yo
Yea, well. I don’t think it is ethical to post instructions without an
associated remediation (BIP) if you don’t see the potential attack.
I was rather hoping that we could have a fuller discussion of what the best
practical response would be to such an issue?
> On Feb 25, 2017, at 3:21 PM, Da
On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote:
> Yea, well. I don’t think it is ethical to post instructions without an
> associated remediation (BIP) if you don’t see the potential attack.
I can't agree with you at all there: we're still at the point where the
computational costs o
I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a
PUBLIC key (msg) into a bitcoin address, so yeah, you could identify
ANOTHER (or the same, I guess - how would you know?) public key that has
the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see
how that
On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev
wrote:
> On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote:
>> >SHA1 is insecure because the SHA1 algorithm is insecure, not because
>> 160bits isn't enough.
>>
>> I would argue that 160-bits isn't enough for
On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote:
> On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev
> > wrote:
> > > >SHA1 is insecure because
On Sat, Feb 25, 2017 at 12:42:56PM -0800, Watson Ladd wrote:
> On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev
> wrote:
> > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev
> > wrote:
> >> >SHA1 is insecure because the SHA1 algorithm is insecure, not because
>
On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev
> wrote:
> > >SHA1 is insecure because the SHA1 algorithm is insecure, not because
> > 160bits isn't enough.
> >
> >
On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote:
> >SHA1 is insecure because the SHA1 algorithm is insecure, not because
> 160bits isn't enough.
>
> I would argue that 160-bits isn't enough for collision resistance. Assuming
> RIPEMD-160(SHA-256(msg)) has no flaws (i.
We should distinguish collision resistance from 2nd pre-image resistance, in
general.
As previously written, we should care both hash output length and algorithm
itself. The weakness of SHA-0 (preliminary version of SHA-1) was reported in
2004, then many research on the structure of SHA-1 were
>You have to not only produce a ripemd160 collision, you have to produce a
collision that is also a valid sha-256 hash - and that's much much much
more difficult.
I agree that merely finding a collision in RIPEMD-160 will be hard to use
in Bitcoin.
However finding a collision in RIPEMD-160(SHA-25
On 02/25/2017 08:10 AM, Ethan Heilman via bitcoin-dev wrote:
SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
I would argue that 160-bits isn't enough for collision resistance.
Assuming RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random
oracle), co
>SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
I would argue that 160-bits isn't enough for collision resistance. Assuming
RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions
can be generated in 2^80 queries (actually detecting t
Google recommeds "migrate to safer cryptographic hashes such as SHA-256 and
SHA-3"
It does not mention RIPEMD-160
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1
Em 25/02/2017 10:47, "Steve Davis via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> escreveu:
> On Feb 24, 2017, at 7:01 PM, Peter Todd wrote:
>
> On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev wrote:
>> If the 20 byte SHA1 is now considered insecure (with good reason), what
>> about RIPEMD-160 which is the foundation of Bitcoin addresses?
>
> SHA1 is insecure be
22 matches
Mail list logo
