public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Leandro Coutinho <lescoutinhovr@gmail•com>
To: Peter Todd <pete@petertodd•org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Steve Davis <steven.charles.davis@gmail•com>
Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers
Date: Sat, 25 Feb 2017 20:09:18 -0300	[thread overview]
Message-ID: <CAN6UTaz5Y9hRjCgHAETF2HMxZ7TPdAe06NmjQ1cQgHvBsf0RSQ@mail.gmail.com> (raw)
In-Reply-To: <20170225214018.GA16524@savin.petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

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 that give a sense of how large scale this
computation was: *

   - *Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in
   total*
   - *6,500 years of CPU computation to complete the attack first phase*
   - *110 years of GPU computation to complete the second phase*


https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
Richest address: 124,178 BTC ($142,853,079 USD)



On Sat, Feb 25, 2017 at 6:40 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> 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 you at all there: we're still at the point where the
> computational costs of such attacks limit their real-world impact, which is
> exactly when you want the *maximum* exposure to what they are and what the
> risks are, so that people develop mitigations.
>
> Keeping details secret tends to keep the attacks out of public view, which
> might be a good trade-off in a situation where the attacks are immediately
> practical and the need to deploy a fix is well understood. But we're in the
> exact opposite situation.
>
> > I was rather hoping that we could have a fuller discussion of what the
> best practical response would be to such an issue?
>
> Deploying segwit's 256-bit digests is a response that's already fully
> coded and
> ready to deploy, with the one exception of a new address format. That
> address
> format is being actively worked on, and could be deployed relatively
> quickly if
> needed.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3431 bytes --]

  parent reply	other threads:[~2017-02-25 23:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.22137.1487974823.31141.bitcoin-dev@lists.linuxfoundation.org>
2017-02-24 23:49 ` Steve Davis
2017-02-25  1:01   ` Peter Todd
2017-02-25 12:04     ` Steve Davis
2017-02-25 14:50       ` Leandro Coutinho
2017-02-25 16:10         ` Ethan Heilman
2017-02-25 17:45           ` Shin'ichiro Matsuo
2017-02-27  9:15             ` Henning Kopp
2017-02-25 18:19           ` Alice Wonder
2017-02-25 18:36             ` Ethan Heilman
2017-02-25 19:12           ` Peter Todd
2017-02-25 20:42             ` Watson Ladd
2017-02-25 20:57               ` Peter Todd
2017-02-25 20:53             ` Russell O'Connor
2017-02-25 21:04               ` Peter Todd
2017-02-25 21:21                 ` Dave Scotese
2017-02-25 21:34                   ` Steve Davis
2017-02-25 21:40                     ` Peter Todd
2017-02-25 21:54                       ` Steve Davis
2017-02-25 22:14                         ` Pieter Wuille
2017-02-25 22:34                           ` Ethan Heilman
2017-02-26  6:26                           ` Steve Davis
2017-02-26  6:36                             ` Pieter Wuille
2017-02-26  7:16                               ` Steve Davis
     [not found]                                 ` <CAPg+sBirowtHqUT5GUJf9hmDEACKVX19HAon-rrz7GmO8OBsNg@mail.gmail.com>
2017-02-26 16:53                                   ` Steve Davis
2017-02-25 23:09                       ` Leandro Coutinho [this message]
2017-02-23 18:14 Peter Todd
2017-02-23 21:28 ` Peter Todd
2017-02-23 23:57   ` Aymeric Vitte
2017-02-24 10:04     ` Tim Ruffing
2017-02-24 15:18       ` Aymeric Vitte
2017-02-24 16:30         ` Tim Ruffing
2017-02-24 17:29           ` Aymeric Vitte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN6UTaz5Y9hRjCgHAETF2HMxZ7TPdAe06NmjQ1cQgHvBsf0RSQ@mail.gmail.com \
    --to=lescoutinhovr@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(echo .)org \
    --cc=steven.charles.davis@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox