[bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers
steven.charles.davis at gmail.com
Sat Feb 25 21:54:16 UTC 2017
> On Feb 25, 2017, at 3:40 PM, Peter Todd <pete at petertodd.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.
I agree with the latter part of your statement but am actually much less confident about the first part… I need to run some numbers on that.
> 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
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.
Surely there's a number of alternative approaches which could be explored, even if only to make a fair assessment of a best response?
More information about the bitcoin-dev