📅 Original date posted:2014-04-21
📝 Original message:Thank you for your thoughts.
> The earlier, larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk, and probably a negligible
> concern to most miners.
I really like Mark’s suggestion but one concern is that it might tip the needle too far. Currently, there is a private cost to include more transactions, which might be too high, but limit the amount of negative externalities that this creates on other miners. If I am able to create blocks that are very likely to be on the main chain with the maximum number of transactions then this makes imposing negative externalities on other miners less costly. Other nodes that are closely connected to me would experience a positive externality through this as well. Would have do some more thinking here but it seems that there is a balance to strike.
> If anything, looks like a threat to the current situation with huge
> mining subsidies coming from the seigniorage, not a problem that you
> would have when the the seigniorage is gone.
The incentives remain so long as the ratio of the seignorage revenues to transaction fees remain very high. Even though the dollar price does not change that relationship it does mean that Bitcoin becomes more expensive in USD terms as the USD price of Bitcoin rises.
> I think the most important part is that nodes can reliably decide on
> "first received", regardless of how they subsequently act on it.
If we want to limit the amount of network time spent on redundant problems it would be best for miners to act on this information? What is the benefit of serialisation? Is it that the miner would consider it more likely to make it into the main chain rather than the block that came second?
> But I don't see how miners mining headers first would result in empty
> blocks either.
I guess it is due to the fact that this is the only way a miner can be certain that none of the transactions have been spent already resulting in an orphan block.
On 21 Apr 2014, at 17:00, Mark Friedenbach <mark at monetize.io> wrote:
> That wasn't what I was saying. Right now the primacy of a block is
> determined by the time at which the `block` message is received, which
> is delays due to both the time it takes to transmit the block data and
> the time it takes to validate. Headers-first, on the other hand, has the
> option of basing primacy on the time the block header is received, which
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and validated.
>
> To see how this works, take an example: two blocks with a common parent
> are found relatively close to each other, block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B, the later but
> smaller block, would get received and processed first by more mining
> peers than the larger block A, exactly as described in Jonathan Levin's
> email.
>
> With headers-first, however, the cost of propagation of the block header
> is the same and we should expect block A to win out over block B nearly
> every time. Miners will continue working on the old, known valid parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found, and since it's data moves across the
> network faster, miners even briefly mine on block B. But as soon as they
> receive and process the contents of block A, they switch to that.
>
> The earlier, larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk, and probably a negligible
> concern to most miners.
>
> On 04/20/2014 09:06 PM, Peter Todd 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.
>>
>> Of course, in reality smaller miners can just mine on top of block
>> headers and include no transactions and do no validation, but that is
>> extremely harmful to the security of Bitcoin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/6994ddfc/attachment.sig>;
Jonathan Levin [ARCHIVE] /
npub15f…xzqzn
2023-06-07 15:19:14
in reply to nevent1q…ufeu
Author Public Key
npub15f7el33va8g2vtj3ls52fzqyf9ud9s0knyjg07nf4ycexnawuj3q8xzqznPublished at
2023-06-07 15:19:14Event JSON
{
"id": "6e5c1f1699ed48962fe563b797cc6441d7ef5359e2d68481ccc3e3c3287b0df4",
"pubkey": "a27d9fc62ce9d0a62e51fc28a488044978d2c1f6992487fa69a931934faee4a2",
"created_at": 1686151154,
"kind": 1,
"tags": [
[
"e",
"225542fbb0416409e03eda129471630d31d92ef89928ee3f68c485123513f923",
"",
"root"
],
[
"e",
"a1d9c74dad00cc3ee01271c0717f9172ac17b1a3c640bf5e4e60288fd6492f3a",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-04-21\n📝 Original message:Thank you for your thoughts. \n\n\u003e The earlier, larger block A will only become stale if *two* blocks are\n\u003e found in the extra time it takes for block A to propagate the network.\n\u003e That is a substantially different risk, and probably a negligible\n\u003e concern to most miners.\n\nI really like Mark’s suggestion but one concern is that it might tip the needle too far. Currently, there is a private cost to include more transactions, which might be too high, but limit the amount of negative externalities that this creates on other miners. If I am able to create blocks that are very likely to be on the main chain with the maximum number of transactions then this makes imposing negative externalities on other miners less costly. Other nodes that are closely connected to me would experience a positive externality through this as well. Would have do some more thinking here but it seems that there is a balance to strike.\n\n\u003e If anything, looks like a threat to the current situation with huge\n\u003e mining subsidies coming from the seigniorage, not a problem that you\n\u003e would have when the the seigniorage is gone.\n\nThe incentives remain so long as the ratio of the seignorage revenues to transaction fees remain very high. Even though the dollar price does not change that relationship it does mean that Bitcoin becomes more expensive in USD terms as the USD price of Bitcoin rises.\n\n\u003e I think the most important part is that nodes can reliably decide on\n\u003e \"first received\", regardless of how they subsequently act on it. \n\nIf we want to limit the amount of network time spent on redundant problems it would be best for miners to act on this information? What is the benefit of serialisation? Is it that the miner would consider it more likely to make it into the main chain rather than the block that came second?\n\n\u003e But I don't see how miners mining headers first would result in empty\n\u003e blocks either.\n\nI guess it is due to the fact that this is the only way a miner can be certain that none of the transactions have been spent already resulting in an orphan block.\n\nOn 21 Apr 2014, at 17:00, Mark Friedenbach \u003cmark at monetize.io\u003e wrote:\n\n\u003e That wasn't what I was saying. Right now the primacy of a block is\n\u003e determined by the time at which the `block` message is received, which\n\u003e is delays due to both the time it takes to transmit the block data and\n\u003e the time it takes to validate. Headers-first, on the other hand, has the\n\u003e option of basing primacy on the time the block header is received, which\n\u003e is O(1) time to transmit and to SPV-validate. Mining on that block\n\u003e doesn't actually commence until the full block is received and validated.\n\u003e \n\u003e To see how this works, take an example: two blocks with a common parent\n\u003e are found relatively close to each other, block A and block B. A is\n\u003e found first but is a large block with the maximum block size and many\n\u003e slow scripts. B is found a few seconds later and is an empty block. In\n\u003e the current regime it is entirely possible that block B, the later but\n\u003e smaller block, would get received and processed first by more mining\n\u003e peers than the larger block A, exactly as described in Jonathan Levin's\n\u003e email.\n\u003e \n\u003e With headers-first, however, the cost of propagation of the block header\n\u003e is the same and we should expect block A to win out over block B nearly\n\u003e every time. Miners will continue working on the old, known valid parent\n\u003e block until the contents of block A are received and processed. So the\n\u003e smaller block B is still found, and since it's data moves across the\n\u003e network faster, miners even briefly mine on block B. But as soon as they\n\u003e receive and process the contents of block A, they switch to that.\n\u003e \n\u003e The earlier, larger block A will only become stale if *two* blocks are\n\u003e found in the extra time it takes for block A to propagate the network.\n\u003e That is a substantially different risk, and probably a negligible\n\u003e concern to most miners.\n\u003e \n\u003e On 04/20/2014 09:06 PM, Peter Todd wrote:\n\u003e\u003e That is mistaken: you can't mine on top of just a block header,\n\u003e\u003e leaving small miners disadvantaged as they are earning no profit\n\u003e\u003e while they wait for the information to validate the block and update\n\u003e\u003e their UTXO sets. This results in the same problem as before, as the\n\u003e\u003e large pools who mine most blocks can validate either instantly - the\n\u003e\u003e self-mine case - or more quickly than the smaller miners.\n\u003e\u003e \n\u003e\u003e Of course, in reality smaller miners can just mine on top of block\n\u003e\u003e headers and include no transactions and do no validation, but that is\n\u003e\u003e extremely harmful to the security of Bitcoin.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140421/6994ddfc/attachment.sig\u003e",
"sig": "2a77a69d11d440b8286800855df7fb63395f9d91efc933976aaf90439784ad677d2d9f2fc9bc132118ed33c83772229f1406082adcda95edf707175b9f1301de"
}