Leandro Coutinho [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-25 📝 Original message:If people split their ...
📅 Original date posted:2017-02-25
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/3c3e4b53/attachment.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/3c3e4b53/attachment.html>;