📅 Original date posted:2014-06-03
📝 Original message:There is a relevant post from Satoshi on this:
https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
Quote:
"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in
an orderly way. The software would be programmed to start using a new hash
after a certain block number. Everyone would have to upgrade by that time.
The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."
On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <eth3rs at gmail.com> wrote:
> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > Hi,
>> >
>> > I thought a lot about the worst case scenario of SHA256d being broken
>> in a
>> > way which could be abused to
>> > A) reduce the work of mining a block by some significant amount
>> > B) reduce the work of mining a block to zero, i.e. allow instant mining.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/287312fb/attachment.html>;
Ashley Holman [ARCHIVE] /
npub14g…u4vq6
2023-06-07 15:22:13
in reply to nevent1q…eu9v
Author Public Key
npub14gv4tc4w0zkzyrfa5u2gvsajqlf3cgevux3xth46ukfrnqlcl8xqru4vq6Seen on
wss://relay.nostr.bandPublished at
2023-06-07 15:22:13Event JSON
{
"id": "12f1819685c8749b8add59502c730f736e05e3b7bc4c9b1a1e6f08f78e3aeab5",
"pubkey": "aa1955e2ae78ac220d3da7148643b207d31c232ce1a265debae5923983f8f9cc",
"created_at": 1686151333,
"kind": 1,
"tags": [
[
"e",
"c3178a7c4915528f303d2155708d8624269c29cc1fae2cb68cf22f7c476bad58",
"",
"root"
],
[
"e",
"16d5dfdf35f6cb4c10f50b531d77e533502aa6106d78e24d24433186e6db9349",
"",
"reply"
],
[
"p",
"4760277fc06bd72dcdd8ef76810910d8852fb3f9d584f5b75a0bba7168ac81a0"
]
],
"content": "📅 Original date posted:2014-06-03\n📝 Original message:There is a relevant post from Satoshi on this:\n\nhttps://bitcointalk.org/index.php?topic=191.msg1585#msg1585\n\nQuote:\n\n\"If SHA-256 became completely broken, I think we could come to some\nagreement about what the honest block chain was before the trouble started,\nlock that in and continue from there with a new hash function.\n\nIf the hash breakdown came gradually, we could transition to a new hash in\nan orderly way. The software would be programmed to start using a new hash\nafter a certain block number. Everyone would have to upgrade by that time.\n The software could save the new hash of all the old blocks to make sure a\ndifferent block with the same old hash can't be used.\"\n\n\nOn Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman \u003ceth3rs at gmail.com\u003e wrote:\n\n\u003e An attack on the mining difficulty algorithm does not imply violation of\n\u003e the typical security properties of a cryptographic hash function*.\n\u003e\n\u003e Assume someone discovers a method which makes it far easier to discover\n\u003e new blocks, this method: may or may not be implementable by the current\n\u003e SHA256 ASIC hardware.\n\u003e\n\u003e 1. If it is usable by the mining hardware, then there will be brief period\n\u003e of overproduction and then difficulty will adjust. If the attack is so bad\n\u003e that difficulty can't scale and we run out of a leading zero's, then the\n\u003e SHA256 collision resistance is broken and we have bigger problems. Under\n\u003e this scenario, everyone would see the need to immediately switch to new\n\u003e hardware as people could create cycles and irreconcilable forks in the\n\u003e block chain\n\u003e\n\u003e 2. If the attack is not usable by the mining hardware, then the miners\n\u003e will need to switch to new ASICs anyways and the hash function can be\n\u003e changed without resistance.\n\u003e\n\u003e But lets ignore all that and say, for some unspecified reason, the bitcoin\n\u003e community wants to switch hash functions and has some lead time to do so.\n\u003e One could require that miners find two blocks, one computed using SHA256\n\u003e and one computed using the new hash function. We could then slowly shift\n\u003e the difficulty from SHA256 to the new hash function. This would allow\n\u003e miners a semi-predicable roadmap to switch their infrastructure away from\n\u003e SHA256.\n\u003e\n\u003e * It would be a distinguisher which would be bad, but collision resistance\n\u003e could be merely weakened.\n\u003e\n\u003e\n\u003e On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e\n\u003e\u003e On Tuesday, June 03, 2014 4:29:55 AM xor wrote:\n\u003e\u003e \u003e Hi,\n\u003e\u003e \u003e\n\u003e\u003e \u003e I thought a lot about the worst case scenario of SHA256d being broken\n\u003e\u003e in a\n\u003e\u003e \u003e way which could be abused to\n\u003e\u003e \u003e A) reduce the work of mining a block by some significant amount\n\u003e\u003e \u003e B) reduce the work of mining a block to zero, i.e. allow instant mining.\n\u003e\u003e\n\u003e\u003e C) fabricate past blocks entirely.\n\u003e\u003e\n\u003e\u003e If SHA256d is broken, Bitcoin as it is fails entirely.\n\u003e\u003e\n\u003e\u003e Luke\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e\u003e applications. Written by three acclaimed leaders in the field,\n\u003e\u003e this first edition is now available. Download your free book today!\n\u003e\u003e http://p.sf.net/sfu/NeoTech\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/NeoTech\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/287312fb/attachment.html\u003e",
"sig": "c4f4ce63260a779bfb7bfe8bffcb51f75ad1e5ad0e948d36656329912dd061b0ad64acaa465943313417b0264217dcab23fc6c1366012c08d8157c06fc76751a"
}