Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-05-24 📝 Original message:On Sat, May 24, 2014 at ...
📅 Original date posted:2014-05-24
📝 Original message: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.
> If miners are concerned about that 1-3 second gap, they
> should perhaps focus on making sure the tx they are mining are
> well-propagated already, so that most of the network has most of the
> transactions already in their memory pool by the time their block is mined.
With an alternative transport protocol, assuming the content has
already been relayed a block could be sent in a couple back to back
UDP packets. (e.g. a few bytes per transaction to disambiguate the
transaction order out of the already sent transactions). So I think
very similar latency could be achieved without doing any thing which
might increase the motivations for miners to misbehave.
Published at
2023-06-07 15:22:05Event JSON
{
"id": "5870b9e7a8f8bce101af208b0c2c4d73842b51258f572bea967931786dcc10b9",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151325,
"kind": 1,
"tags": [
[
"e",
"db0c94828eb521bd60e5a762540ad2fb3c4dc34552a9817c80dbbcb4c4cf34fe",
"",
"root"
],
[
"e",
"6fce683bd053e427ba08e075a49fb5378098ac951cd744e58fd7220fe78d10e3",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2014-05-24\n📝 Original message:On Sat, May 24, 2014 at 5:04 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e I think the most important change is modifying the way Bitcoin Core\n\u003e prioritizes blocks. Right now it uses the first full block verified.\n\u003e Instead, it should consider the first valid header received as highest\n\u003e priority, but only mine on it once it has done full verification of the\n\nThis directly opens an attack where as soon as you find a block you\nannounce the header to the world and then you delay announcing the\nblock content. You can continue to mine on the block but no one else\ncan (or alternatively they break their rule and risk extending an\ninvalid block— bad news for SPV wallets)— then when you find a\nsuccessor block or someone else finds a competing block you\nimmediately announce the content.\n\nIt basically means that you can always delay announcing a block and be\nsure that doing so doesn't deprive you of your winning position.\n\n\u003e If miners are concerned about that 1-3 second gap, they\n\u003e should perhaps focus on making sure the tx they are mining are\n\u003e well-propagated already, so that most of the network has most of the\n\u003e transactions already in their memory pool by the time their block is mined.\n\nWith an alternative transport protocol, assuming the content has\nalready been relayed a block could be sent in a couple back to back\nUDP packets. (e.g. a few bytes per transaction to disambiguate the\ntransaction order out of the already sent transactions). So I think\nvery similar latency could be achieved without doing any thing which\nmight increase the motivations for miners to misbehave.",
"sig": "ae16504522de573b0789df384a91d78aa09abd9c62dc95141d35d461f63ac999e97c1aa225d527abdfd761a04bddd3dd0a85a73646696f7149fd731a78423813"
}