📅 Original date posted:2011-11-23
🗒️ Summary of this message: A block with a difficulty of 36 billion was found, 24,000 times harder than the target, which could have caused a disaster if held onto and broadcasted later.
📝 Original message:I can substantiate Gavin's point quite powerfully: a couple months ago I
did a search for the "hardest" block in the network and found a *very
**impressive* one:
https://bitcointalk.org/index.php?topic=29675.0
That block has a difficulty of **36 billion** when the network had a
difficulty of **1.5 million**, which is 24,000 times harder than the
target. If we were going by the /actual /hardest chain instead
target-based-hardest chain, /then this block produced in July would
might still represent the longest chain!/
Yes, that means that whichever miner produced this block, could've held
onto it for 2-4 months without doing anything else, and then broadcast
it to fork the blockchain from a block produced months ago. That's not
theoretical, that's real data in the blockchain and it would be a disaster.
-Alan
On 11/23/2011 10:09 AM, Gavin Andresen wrote:
> On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker
> <decker.christian at gmail.com> wrote:
>> At some point you might find an incredibly hard block that makes your forked
>> chain the hardest one in the network
> Seems to me that's the real problem with any "hardest block found in X
> minutes" scheme.
>
> If I get lucky and find a really extremely hard block then I have an
> incentive to keep it secret and build a couple more blocks on top of
> it, then announce them all at the same time.
>
> If the rest of the network rejects my longer chain because I didn't
> announce the extremely hard block in a timely fashion... then how
> could the network ever recover from a real network split? A network
> split/rejoin will look exactly the same.
>
> Bitcoin as-is doesn't have the "I got lucky and found an extremely
> hard block" problem because the difficulty TARGET is used to compute
> chain difficulty, not the actual hashes found.
>
>
> ---
>
> PS: I proposed a different method for dealing with large hash power
> drops for the testnet on the Forums yesterday, and am testing it
> today.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/c80449ce/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 02:41:24
in reply to nevent1q…cfjx
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 02:41:24Event JSON
{
"id": "d5bd92bbbea80642b0d07aae1a84de01ad7c7dff7c8d206d987b2026376f1c44",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686105684,
"kind": 1,
"tags": [
[
"e",
"2046d4dc725b4ce8920d2c47249dd7dad0c6e38daddd7a5e99f03e9b24dd8e66",
"",
"root"
],
[
"e",
"b6e36c2b5a69b668f37e9c85c5f0ddbe8c8d5355aae19bea5de094a4b62690b7",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-11-23\n🗒️ Summary of this message: A block with a difficulty of 36 billion was found, 24,000 times harder than the target, which could have caused a disaster if held onto and broadcasted later.\n📝 Original message:I can substantiate Gavin's point quite powerfully: a couple months ago I \ndid a search for the \"hardest\" block in the network and found a *very \n**impressive* one:\n\nhttps://bitcointalk.org/index.php?topic=29675.0\n\nThat block has a difficulty of **36 billion** when the network had a \ndifficulty of **1.5 million**, which is 24,000 times harder than the \ntarget. If we were going by the /actual /hardest chain instead \ntarget-based-hardest chain, /then this block produced in July would \nmight still represent the longest chain!/\n\nYes, that means that whichever miner produced this block, could've held \nonto it for 2-4 months without doing anything else, and then broadcast \nit to fork the blockchain from a block produced months ago. That's not \ntheoretical, that's real data in the blockchain and it would be a disaster.\n\n-Alan\n\n\n\nOn 11/23/2011 10:09 AM, Gavin Andresen wrote:\n\u003e On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker\n\u003e \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e\u003e At some point you might find an incredibly hard block that makes your forked\n\u003e\u003e chain the hardest one in the network\n\u003e Seems to me that's the real problem with any \"hardest block found in X\n\u003e minutes\" scheme.\n\u003e\n\u003e If I get lucky and find a really extremely hard block then I have an\n\u003e incentive to keep it secret and build a couple more blocks on top of\n\u003e it, then announce them all at the same time.\n\u003e\n\u003e If the rest of the network rejects my longer chain because I didn't\n\u003e announce the extremely hard block in a timely fashion... then how\n\u003e could the network ever recover from a real network split? A network\n\u003e split/rejoin will look exactly the same.\n\u003e\n\u003e Bitcoin as-is doesn't have the \"I got lucky and found an extremely\n\u003e hard block\" problem because the difficulty TARGET is used to compute\n\u003e chain difficulty, not the actual hashes found.\n\u003e\n\u003e\n\u003e ---\n\u003e\n\u003e PS: I proposed a different method for dealing with large hash power\n\u003e drops for the testnet on the Forums yesterday, and am testing it\n\u003e today.\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111123/c80449ce/attachment.html\u003e",
"sig": "44b021e6a0586fd8096dbd7602b555e09f0309f1326ca3a1d2d92e08dd459b4185ccc346c8c2b825c0daa60d8abefbbe9657f3bb242aa5b0994d13334634845b"
}