DoS on transactions

[b99999]

I've been thinking of a potential attack on the number of transactions that get processed.

Since a miner basically have an option of including transactions up to a maximum number (limited by the maximum block size at the moment, which is 1 MB (static const unsigned int MAX_BLOCK_SIZE = 1000000;), what is preventing a bad miner from not including any transactions?

For example, if an organization which wants to interrupt Bitcoin's operations comes into the game, they could have huge processing power and just keep on generating new blocks without any transactions? Yes, they are not getting the fee, but no transactions are getting processed either.

Is this possible or I'm missing something?

[1715158637]

1715158637

[1715158637]

1715158637

[1715158637]

1715158637

[1715158637]

1715158637

[1715158637]

1715158637

[memvola]

Not an expert, but AFAIK it's possible. And there is a system in place to discourage such blocks, but it's not active:

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.  A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.  I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.

From https://en.bitcoin.it/wiki/Vocabulary:

A discouraged block is considered to be a valid part of the chain, but blocks you generate will build onto the block before it instead of that block. If most of the network is discouraging a block, then it will almost always be replaced by another block and not end up making it into the final block chain. Unlike rejecting a block, discouraging a block has no risk of splitting the network. Bitcoin currently doesn't discourage any blocks, but the mechanism may be used in the future to handle certain issues such as unreasonably high or low fees.

[etotheipi]

This would simply dilute the rate at which transactions are confirmed.  In fact, the only thing it would do is make the first confirmation of a transaction take (statistically) twice as long.

If someone came in with 50% of the network and started computing blocks with no transactions, then before the next retarget (difficulty change), one block would be generated every 5 minutes, with half of them containing transactions.  After the difficulty change it goes up to 10 minutes.  Now if you send a tx at this point, it will be (on average) 10 minutes until the next block is produced.  Half the time this won't contain your transaction, half the time it will.  So you could wait 1-4 blocks for your confirmation instead of one (with the higher numbers being more unlikely).

However, after that first confirmation, all blocks produced after it will count as confirmations, so you'll continue to to accumulate transactions normally after that.

On the other hand, "difficulty" is not just difficulty of producing blocks, but also difficulty of someone attacking the network.  So if this person who has 50% of the network decided to use their power to do this, instead of executing a "real" attack on the network, we should be lucky.  They're making the next person who wants to attack the network double their computing power requirements.

Although, as memvola said, the way the blockchain is structured, there's no good reason not to include tx's in the block the miner is working on.  If you have ill-intentions towards the network, there's a lot nastier stuff you could do with 50% of the computing power.  If you don't have ill-intentions, you would just include the tx's and collect your fees.

[koin]

If someone came in with 50% of the network and started computing blocks with no transactions, then before the next retarget (difficulty change), one block would be generated every 5 minutes, with half of them containing transactions.

the miner with 50%+ could also ignore blocks from any other miners though and maintain the longest chain -- thus those transactions would still not be included.  so technically possible to deny service but there's no economic incentive to do so and with the current network size not only would an incredible amount of computing resources be necessary, that denial of service would be a criminal offense and the miner would be easily identifiable.

[evoorhees]

This would simply dilute the rate at which transactions are confirmed.  In fact, the only thing it would do is make the first confirmation of a transaction take (statistically) twice as long.

If someone came in with 50% of the network and started computing blocks with no transactions, then before the next retarget (difficulty change), one block would be generated every 5 minutes, with half of them containing transactions.  After the difficulty change it goes up to 10 minutes.  Now if you send a tx at this point, it will be (on average) 10 minutes until the next block is produced.  Half the time this won't contain your transaction, half the time it will.  So you could wait 1-4 blocks for your confirmation instead of one (with the higher numbers being more unlikely).

However, after that first confirmation, all blocks produced after it will count as confirmations, so you'll continue to to accumulate transactions normally after that.

On the other hand, "difficulty" is not just difficulty of producing blocks, but also difficulty of someone attacking the network.  So if this person who has 50% of the network decided to use their power to do this, instead of executing a "real" attack on the network, we should be lucky.  They're making the next person who wants to attack the network double their computing power requirements.

Although, as memvola said, the way the blockchain is structured, there's no good reason not to include tx's in the block the miner is working on.  If you have ill-intentions towards the network, there's a lot nastier stuff you could do with 50% of the computing power.  If you don't have ill-intentions, you would just include the tx's and collect your fees.

Really well said!