📅 Original date posted:2014-04-21
📝 Original message:On 04/21/2014 11:40 AM, Ashley Holman wrote:
> On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete at petertodd.org
> <mailto:pete at petertodd.org>> wrote:
>
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for the information to validate the block and
> update their UTXO sets. This results in the same problem as
> before, as the large pools who mine most blocks can validate
> either instantly - the self-mine case - or more quickly than the
> smaller miners.
>
>
> Under the headers first scenario, wouldn't the full block still reach
> everyone in the same time as it would under the current rules? So the
> small miner loses nothing in terms of updating their UTXO set, but
> gains an early "heads up" alert that a new block is coming. This
> allows them spend the propagation time working more productively on an
> empty block in the new chain rather than wasting time on an orphan.
> It's true that it doesn't solve the problem of larger pools vs
> smaller pools, but if it doesn't make it any worse then headers-first
> propagation would be a net benefit to the network since it removes the
> incentive to make small blocks.
>
I think the most important part is that nodes can reliably decide on
"first received", regardless of how they subsequently act on it. I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block, until
it has the necessary pieces to fully verify the first header received.
If that block data doesn't come, then it will be naturally ignored. But
if multiple blocks come at once, even if a competing block "verifies"
first, the node would still switch to considering the first header
received as the best block when it later receives proof it is valid
(which may only be a couple seconds).
In other words, the node will always consider the header-received time
as the primary ordering criteria, but will not mine on anything until it
has full proof of validity, even if /that/ is out of order. This means
that new blocks "effectively" propagate at the speed of 80 bytes, which
limits certain kinds of block-injection/racing attacks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/b0ca4320/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:19:12
in reply to nevent1q…dgcl
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:19:12Event JSON
{
"id": "f295e1ad92fb1430008392a95c8a1e3a0d1a4f5cdecce20f7f808e7dfb6f9767",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686151152,
"kind": 1,
"tags": [
[
"e",
"225542fbb0416409e03eda129471630d31d92ef89928ee3f68c485123513f923",
"",
"root"
],
[
"e",
"5e733157aceb3eba800b649baed9ef9c1ba2418c002690dc5314b65f499edf36",
"",
"reply"
],
[
"p",
"aa1955e2ae78ac220d3da7148643b207d31c232ce1a265debae5923983f8f9cc"
]
],
"content": "📅 Original date posted:2014-04-21\n📝 Original message:On 04/21/2014 11:40 AM, Ashley Holman wrote:\n\u003e On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd \u003cpete at petertodd.org\n\u003e \u003cmailto:pete at petertodd.org\u003e\u003e wrote:\n\u003e\n\u003e That is mistaken: you can't mine on top of just a block header,\n\u003e leaving small miners disadvantaged as they are earning no profit\n\u003e while they wait for the information to validate the block and\n\u003e update their UTXO sets. This results in the same problem as\n\u003e before, as the large pools who mine most blocks can validate\n\u003e either instantly - the self-mine case - or more quickly than the\n\u003e smaller miners.\n\u003e\n\u003e \n\u003e Under the headers first scenario, wouldn't the full block still reach\n\u003e everyone in the same time as it would under the current rules? So the\n\u003e small miner loses nothing in terms of updating their UTXO set, but\n\u003e gains an early \"heads up\" alert that a new block is coming. This\n\u003e allows them spend the propagation time working more productively on an\n\u003e empty block in the new chain rather than wasting time on an orphan.\n\u003e It's true that it doesn't solve the problem of larger pools vs\n\u003e smaller pools, but if it doesn't make it any worse then headers-first\n\u003e propagation would be a net benefit to the network since it removes the\n\u003e incentive to make small blocks.\n\u003e\n\nI think the most important part is that nodes can reliably decide on\n\"first received\", regardless of how they subsequently act on it. I\nbelieve it would be fine for a node to receive a header and continue\nmining the old block, or a subsequently-verified competing block, until\nit has the necessary pieces to fully verify the first header received. \nIf that block data doesn't come, then it will be naturally ignored. But\nif multiple blocks come at once, even if a competing block \"verifies\"\nfirst, the node would still switch to considering the first header\nreceived as the best block when it later receives proof it is valid\n(which may only be a couple seconds).\n\nIn other words, the node will always consider the header-received time\nas the primary ordering criteria, but will not mine on anything until it\nhas full proof of validity, even if /that/ is out of order. This means\nthat new blocks \"effectively\" propagate at the speed of 80 bytes, which\nlimits certain kinds of block-injection/racing attacks. \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/b0ca4320/attachment.html\u003e",
"sig": "793394aad2e6ddbeddf5f80bd7779a251adf518ebdd4da0ceb32c5751f15faebbb8253d616038f88aac263dbbced99f50b4cdcf90ece514f7d5cb58c0c59dc1a"
}