📅 Original date posted:2014-05-24
📝 Original message:On 05/24/2014 08:14 PM, Gregory Maxwell wrote:
> On Sat, May 24, 2014 at 5:04 PM, Alan Reiner <etotheipi at gmail.com> wrote:
>> I think the most important change is modifying the way Bitcoin Core
>> prioritizes blocks. Right now it uses the first full block verified.
>> Instead, it should consider the first valid header received as highest
>> priority, but only mine on it once it has done full verification of the
> This directly opens an attack where as soon as you find a block you
> announce the header to the world and then you delay announcing the
> block content. You can continue to mine on the block but no one else
> can (or alternatively they break their rule and risk extending an
> invalid block— bad news for SPV wallets)— then when you find a
> successor block or someone else finds a competing block you
> immediately announce the content.
>
> It basically means that you can always delay announcing a block and be
> sure that doing so doesn't deprive you of your winning position.
>
>
Would this not be solved by putting a expiration on application of this
logic? For instance, if you haven't received the full new block within
5-10 seconds (perhaps adjusted based on local bandwidth), then the
header-received time is ignored. Or is this too hacky? I suppose this
is exactly what Ashley is trying to solve, she's just already made a few
more leaps forward in the design process than I have. I'll stop
derailing it.
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:22:05
in reply to nevent1q…r2qz
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:22:05Event JSON
{
"id": "daea070cd72d2bc4ef3c194bee5b2c47e8907e84e45d24fc46a2d4506ee80aa6",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686151325,
"kind": 1,
"tags": [
[
"e",
"db0c94828eb521bd60e5a762540ad2fb3c4dc34552a9817c80dbbcb4c4cf34fe",
"",
"root"
],
[
"e",
"5870b9e7a8f8bce101af208b0c2c4d73842b51258f572bea967931786dcc10b9",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-05-24\n📝 Original message:On 05/24/2014 08:14 PM, Gregory Maxwell wrote:\n\u003e On Sat, May 24, 2014 at 5:04 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\u003e I think the most important change is modifying the way Bitcoin Core\n\u003e\u003e prioritizes blocks. Right now it uses the first full block verified.\n\u003e\u003e Instead, it should consider the first valid header received as highest\n\u003e\u003e priority, but only mine on it once it has done full verification of the\n\u003e This directly opens an attack where as soon as you find a block you\n\u003e announce the header to the world and then you delay announcing the\n\u003e block content. You can continue to mine on the block but no one else\n\u003e can (or alternatively they break their rule and risk extending an\n\u003e invalid block— bad news for SPV wallets)— then when you find a\n\u003e successor block or someone else finds a competing block you\n\u003e immediately announce the content.\n\u003e\n\u003e It basically means that you can always delay announcing a block and be\n\u003e sure that doing so doesn't deprive you of your winning position.\n\u003e\n\u003e\n\nWould this not be solved by putting a expiration on application of this\nlogic? For instance, if you haven't received the full new block within\n5-10 seconds (perhaps adjusted based on local bandwidth), then the\nheader-received time is ignored. Or is this too hacky? I suppose this\nis exactly what Ashley is trying to solve, she's just already made a few\nmore leaps forward in the design process than I have. I'll stop\nderailing it.",
"sig": "832fa84feed4012c87c61f18c993381b5388af0b2351c3d5a486f9ec17e35215a92ab5da0473e4b4e8f65237a8b9b9de0cc83058d6d2bf54aee9a067ae05c7dc"
}