<p>In principle, a node knows the date and time at which transactions in the new block were added to this node's mempool. That provides an approximate upper limit to the time the block might have been withheld.</p>
<p>For example if at 10:00 the node receives a block which contains a transaction the node had received at 9:00 it is unlikely the block could have been withheld more than an hour.</p>

CC BY-SA 4.0
2022-01-01T09:03:19.890Z
2022-01-01T09:11:16.620Z
2022-01-01T09:11:16.620Z
RedGrittyBrick
<blockquote>
<p>But do Bitcoin nodes receive enough information to determine the amount of time that has passed from the time the block was found to the time it was published?</p>
</blockquote>
<p>There is no feature of a block which would reveal this information. A block can be created at any time, with any details within, and it will be accepted by the network as valid so long as it passes the consensus rules. There are no changes that could be made to Bitcoin in order to make this sort of thing possible.</p>

CC BY-SA 4.0
2022-01-01T06:28:18.907Z
This answer is not correct. The time a block was withheld can be determined (not necessarily with perfect accuracy, but that doesn't matter) by looking at how much time elapsed between when the block could have been mined (which you *can* determine based) and when you first saw it. You can penalize blocks that could have been mined long ago. (I don't see any point in doing so, but whether it would serve any purpose is another question.)
David Schwartz
CC BY-SA 4.0
2022-01-01T11:19:16.450Z
This answer is correct. You can not prove when a block was received, or when other transactions were received to any other participant on the network, so details like that can't be part of the consensus system. If nodes were to "penalize" blocks they received based on local observation the consensus system would fail. A node can make a guess that a block is new only if it contains a transaction they produced, as they have knowledge of when it was signed, which is completely meaningless.
Claris
CC BY-SA 4.0
2022-01-02T01:42:53.057Z
This question isn't about the consensus system at all. It's about the eventual agreement part of it. You're absolutely wrong that it can make the consensus system fail for two reasons: 1. The consensus system is independent. 2. Nothing with purely local effects can make the consensus system fail. (continued)
David Schwartz
CC BY-SA 4.0
2022-01-02T01:44:20.580Z
For example, consider a rule that says you don't treat any new transactions as confirmed if you haven't seen a newly-mined block for twenty minutes until you see at least two blocks mined with 15 minutes. That will cause nodes to disagree over which blocks are confirmed, *but that's perfectly normal* and would in no way break the consensus scheme. A node's decision to wait longer before trusting a transaction or refuse to mine on the "longest chain" because it seems suspicious *cannot* break consensus.
David Schwartz
CC BY-SA 4.0
2022-01-02T01:47:33.557Z
`this attack could be dealt with by a soft fork that disregards any block that the applicable miner did not publish within a certain amount of time after it was found` The discussion is about consensus rules.
Claris
CC BY-SA 4.0
2022-01-02T01:49:29.467Z
So your answer isn't a response to the part of the question you cited in your response? If so, why cite it? In any event, that suggestion *is* already implemented in nearly all bitcoin nodes. Checkpoints do exactly this. So if that breaks consensus rules, it's a break that most people consider acceptable once a block is "old enough".
David Schwartz
CC BY-SA 4.0
2022-01-02T01:51:52.100Z
It's literally part of the same paragraph, I quoted the part with the direct question of if it is possible or not, which it isn't. The checkpoint code doesn't do what you think it does.
Claris
CC BY-SA 4.0
2022-01-02T01:55:45.327Z
I know precisely what the checkpoint code does. Among other things, it causes nodes to ignore other blocks with the same sequence as the checkpoint if their hash is different -- even if they are part of a longer chain than the chain the node is on. This is *precisely* what you said could not be done. And the rationale is the same -- because there is a conflicting block that has been accepted for a long enough time.
David Schwartz
CC BY-SA 4.0
2022-01-03T04:13:15.523Z
The question was about nodes being able to do this dynamically, within these bounds arguing that checkpoints (which don't meaningfully exist in modern Bitcoin Core, they haven't been touched in 7 years) somehow fits the description is idiotic. This bottom-shelf, belligerent, and wholly incorrect argument is explicitly why I'm not interested in contributing to this Stack Exchange further.
Claris
CC BY-SA 4.0
2022-01-03T04:51:09.317Z
If you wish to continue to remain wrong, I can't stop you. But you are wrong. Nodes can absolutely make local changes in how they decide when to consider a block accepted and it has no effect at all on the stability of consensus. They're completely logically independent functions. (This is the same reason a bitcoin node can accept transactions (or blocks!) after 1 confirmation, 6 confirmations, or 80 confirmations and it has no effect on consensus.)
David Schwartz
CC BY-SA 4.0
2022-01-01T01:23:28.417Z
2022-01-01T01:23:28.417Z
Claris
<p>In a recently Medium article, Joe Kelly described an attack that he calls &quot;Monopoly Mining&quot; in which a state actor or some other very well resourced party that obtains majority hashpower does more than double-spend, they deny all other miners block rewards and thus disrupt the network (<a href="https://joekelly100.medium.com/how-to-kill-bitcoin-part-3-no-can-defend-cd6affe3fc44" rel="nofollow noreferrer">https://joekelly100.medium.com/how-to-kill-bitcoin-part-3-no-can-defend-cd6affe3fc44</a>). The attack requires mining ahead but not publishing the chain being created until an opportune time when the majority miner's secret chain is sufficiently far ahead of the canonical chain. Then the majority miner publishes enough of the blocks to establish the new canonical chain taking away all of the block rewards of the now orphaned blocks. Then when any other miner tries to add a new block, the majority miner releases two more withheld blocks to keep denying any other miner block rewards.</p>
<p>Disregarding for the moment the expense required to carry out this attack and the question of whether any entity could attain majority hashpower and build a sufficiently long alternate chain to execute this attack in secret, it seems to me that withholding discovered blocks serves no useful purpose and that this attack could be dealt with by a soft fork that disregards any block that the applicable miner did not publish within a certain amount of time after it was found. But do Bitcoin nodes receive enough information to determine the amount of time that has passed from the time the block was found to the time it was published?</p>
<p>An Ivan on Tech article describes how the Horizen protocol penalizes nodes that delay publishing blocks (<a href="https://academy.moralis.io/blog/breaking-down-proof-of-work-mining-and-51-attacks" rel="nofollow noreferrer">https://academy.moralis.io/blog/breaking-down-proof-of-work-mining-and-51-attacks</a>). Has anything similar been seriously considered for Bitcoin?</p>

<majority-attack>
Do nodes receive information from which they can discern how long a miner has withheld publishing a block from the time it found it?
ProofofAwesome
# Do nodes receive information from which they can discern how long a miner has withheld publishing a block from the time it found it?

(Asked by: username_0 on 2022-01-01)

In a recently Medium article, Joe Kelly described an attack that he calls "Monopoly Mining" in which a state actor or some other very well resourced party that obtains majority hashpower does more than double-spend, they deny all other miners block rewards and thus disrupt the network (<https://joekelly100.medium.com/how-to-kill-bitcoin-part-3-no-can-defend-cd6affe3fc44>). The attack requires mining ahead but not publishing the chain being created until an opportune time when the majority miner's secret chain is sufficiently far ahead of the canonical chain. Then the majority miner publishes enough of the blocks to establish the new canonical chain taking away all of the block rewards of the now orphaned blocks. Then when any other miner tries to add a new block, the majority miner releases two more withheld blocks to keep denying any other miner block rewards.

Disregarding for the moment the expense required to carry out this attack and the question of whether any entity could attain majority hashpower and build a sufficiently long alternate chain to execute this attack in secret, it seems to me that withholding discovered blocks serves no useful purpose and that this attack could be dealt with by a soft fork that disregards any block that the applicable miner did not publish within a certain amount of time after it was found. But do Bitcoin nodes receive enough information to determine the amount of time that has passed from the time the block was found to the time it was published?

An Ivan on Tech article describes how the Horizen protocol penalizes nodes that delay publishing blocks (<https://academy.moralis.io/blog/breaking-down-proof-of-work-mining-and-51-attacks>). Has anything similar been seriously considered for Bitcoin?

**Tags:** majority-attack


---

## 2 answers

### Answer by username_1 on 2022-01-01. Score: 2

In principle, a node knows the date and time at which transactions in the new block were added to this node's mempool. That provides an approximate upper limit to the time the block might have been withheld.

For example if at 10:00 the node receives a block which contains a transaction the node had received at 9:00 it is unlikely the block could have been withheld more than an hour.


---

### Answer by username_2 on 2022-01-01. Score: -1

> But do Bitcoin nodes receive enough information to determine the amount of time that has passed from the time the block was found to the time it was published?

There is no feature of a block which would reveal this information. A block can be created at any time, with any details within, and it will be accepted by the network as valid so long as it passes the consensus rules. There are no changes that could be made to Bitcoin in order to make this sort of thing possible.

> **Comments:**
> **username_3**: This answer is not correct. The time a block was withheld can be determined (not necessarily with perfect accuracy, but that doesn't matter) by looking at how much time elapsed between when the block could have been mined (which you *can* determine based) and when you first saw it. You can penalize blocks that could have been mined long ago. (I don't see any point in doing so, but whether it would serve any purpose is another question.)  
> **username_2**: This answer is correct. You can not prove when a block was received, or when other transactions were received to any other participant on the network, so details like that can't be part of the consensus system. If nodes were to "penalize" blocks they received based on local observation the consensus system would fail. A node can make a guess that a block is new only if it contains a transaction they produced, as they have knowledge of when it was signed, which is completely meaningless.  
> **username_3**: This question isn't about the consensus system at all. It's about the eventual agreement part of it. You're absolutely wrong that it can make the consensus system fail for two reasons: 1. The consensus system is independent. 2. Nothing with purely local effects can make the consensus system fail. (continued)  
> **username_3**: For example, consider a rule that says you don't treat any new transactions as confirmed if you haven't seen a newly-mined block for twenty minutes until you see at least two blocks mined with 15 minutes. That will cause nodes to disagree over which blocks are confirmed, *but that's perfectly normal* and would in no way break the consensus scheme. A node's decision to wait longer before trusting a transaction or refuse to mine on the "longest chain" because it seems suspicious *cannot* break consensus.  
> **username_2**: `this attack could be dealt with by a soft fork that disregards any block that the applicable miner did not publish within a certain amount of time after it was found` The discussion is about consensus rules.  
> **username_3**: So your answer isn't a response to the part of the question you cited in your response? If so, why cite it? In any event, that suggestion *is* already implemented in nearly all bitcoin nodes. Checkpoints do exactly this. So if that breaks consensus rules, it's a break that most people consider acceptable once a block is "old enough".  
> **username_2**: It's literally part of the same paragraph, I quoted the part with the direct question of if it is possible or not, which it isn't. The checkpoint code doesn't do what you think it does.  
> **username_3**: I know precisely what the checkpoint code does. Among other things, it causes nodes to ignore other blocks with the same sequence as the checkpoint if their hash is different -- even if they are part of a longer chain than the chain the node is on. This is *precisely* what you said could not be done. And the rationale is the same -- because there is a conflicting block that has been accepted for a long enough time.  
> **username_2**: The question was about nodes being able to do this dynamically, within these bounds arguing that checkpoints (which don't meaningfully exist in modern Bitcoin Core, they haven't been touched in 7 years) somehow fits the description is idiotic. This bottom-shelf, belligerent, and wholly incorrect argument is explicitly why I'm not interested in contributing to this Stack Exchange further.  
> **username_3**: If you wish to continue to remain wrong, I can't stop you. But you are wrong. Nodes can absolutely make local changes in how they decide when to consider a block accepted and it has no effect at all on the stability of consensus. They're completely logically independent functions. (This is the same reason a bitcoin node can accept transactions (or blocks!) after 1 confirmation, 6 confirmations, or 80 confirmations and it has no effect on consensus.)  

---

