<p>If the attacker has minority hashrate, I don't think this is much of a problem. If he excludes all transactions in his blocks but doesn't try to orphan other blocks, the worst thing that can happen is a x2 increase in the average time until first confirmation (no effect on subsequent confirmations). This is fairly minor.</p>

<p>If the attacker has majority hashrate, he can orphan all other blocks and exclude all transactions, and then transactions will never be confirmed. This is a problem and the main variant of the >50% attack. Possible solutions include modifying the branch selection mechanism to prefer blocks with more high-priority transactions - meaning that even with majority hashrate, if you try to deny transaction you're not guaranteed to beat the honest branch.</p>

<p>Incidentally, if the attacker has >40% hashrate, there is a technique to amplify his hashrate and get more than his fair share of blocks. So if, say, he has 49% hashrate and used this technique, he can get close to 100% of blocks, significantly delaying tx confirmation.</p>

CC BY-SA 3.0
2013-10-14T06:29:16.857Z
2013-10-14T06:29:16.857Z
Meni Rosenfeld
<p>I disagree with your premise "This would slow down the rate a block would be included in the chain".  Every other miner or pool has just as much a shot at discovering a block as the evil one.  Unless the evil one is so powerful that he is singlehandedly effecting the difficulty in a signficant way, his blank blocks will not prevent other miners from discovering normal blocks.</p>

<p>I think your question is simply a restatement of the "51%" problem.</p>

CC BY-SA 3.0
2013-08-15T03:20:38.463Z
Or rather a porportional problem... if the pool owns 25% of the hash, then the maximum detriment is 25%.  (etc)
makerofthings7
CC BY-SA 3.0
2013-08-15T03:13:03.420Z
2013-08-15T03:13:03.420Z
RentFree
<p>As it stands now, a miner (or mining pool) can discriminate any transaction for any reason if they are running a custom version of code.</p>

<p>Suppose an evil and powerful mining pool decided to hash blocks, but not include any transactions even if a fee was included.  This would slow down the rate a block would be included in the chain.. effectively causing a DOS against certain transactions.</p>

<p>This is intended behavior to encourage transactions to include fees (or soon will be the behavior).  But suppose a pool operator (or powerful mining consortium) decide that they want to kill off Bitcoin and not include any transactions ... at all.</p>

<p><strong>Question</strong></p>

<ul>
<li>What technical solutions are there to require blocks to have transactions?</li>
</ul>

<p><strong>Challenge</strong></p>

<ul>
<li><p>We don't want the attacker to only include transactions the evil mining pool themselves create, but also transactions that others create as well.</p></li>
<li><p>I don't want to encourage too many low-fee transactions in this model, thus de-incentivising mining activity </p></li>
</ul>

<p>Is there any solution that addresses these goals in a fair and balanced way?</p>

CC BY-SA 3.0
2013-10-14T07:13:53.697Z
Such a consortium would be reducing the value of the Bitcoin system and thus reducing the total value of all Bitcoin mining. It's hard to imagine a scenario where someone with a significant investment in Bitcoin mining hardware has an incentive to reduce the total value of all Bitcoin mining.
David Schwartz
CC BY-SA 3.0
2013-10-14T07:37:10.530Z
It's not that hard to imagine for one person (extortion, paid sabotage, spite), but if it is a pool the other miners would jump ship when they come to realize what is happening. I don't think such an attack could be sustained unless the malevolent mining power is under control of one entity. Then though, I find it improbable for one person to have a sufficient share of the mining power to have a major impact.
Murch
<transactions><transaction-fees><block><weaknesses><risk-mitigation>
Techniques or proposais to require transactions to be included in a block?
makerofthings7
# Techniques or proposais to require transactions to be included in a block?

(Asked by: username_0 on 2013-08-15)

As it stands now, a miner (or mining pool) can discriminate any transaction for any reason if they are running a custom version of code.

Suppose an evil and powerful mining pool decided to hash blocks, but not include any transactions even if a fee was included. This would slow down the rate a block would be included in the chain.. effectively causing a DOS against certain transactions.

This is intended behavior to encourage transactions to include fees (or soon will be the behavior). But suppose a pool operator (or powerful mining consortium) decide that they want to kill off Bitcoin and not include any transactions ... at all.

**Question**

* What technical solutions are there to require blocks to have transactions?

**Challenge**

* We don't want the attacker to only include transactions the evil mining pool themselves create, but also transactions that others create as well.
* I don't want to encourage too many low-fee transactions in this model, thus de-incentivising mining activity

Is there any solution that addresses these goals in a fair and balanced way?

**Tags:** transactions, transaction-fees, block, weaknesses, risk-mitigation

> **Comments:**
> **username_1**: Such a consortium would be reducing the value of the Bitcoin system and thus reducing the total value of all Bitcoin mining. It's hard to imagine a scenario where someone with a significant investment in Bitcoin mining hardware has an incentive to reduce the total value of all Bitcoin mining.  
> **username_2**: It's not that hard to imagine for one person (extortion, paid sabotage, spite), but if it is a pool the other miners would jump ship when they come to realize what is happening. I don't think such an attack could be sustained unless the malevolent mining power is under control of one entity. Then though, I find it improbable for one person to have a sufficient share of the mining power to have a major impact.  

---

## 2 answers

### Answer by username_3 on 2013-10-14. Score: 2

If the attacker has minority hashrate, I don't think this is much of a problem. If he excludes all transactions in his blocks but doesn't try to orphan other blocks, the worst thing that can happen is a x2 increase in the average time until first confirmation (no effect on subsequent confirmations). This is fairly minor.

If the attacker has majority hashrate, he can orphan all other blocks and exclude all transactions, and then transactions will never be confirmed. This is a problem and the main variant of the >50% attack. Possible solutions include modifying the branch selection mechanism to prefer blocks with more high-priority transactions - meaning that even with majority hashrate, if you try to deny transaction you're not guaranteed to beat the honest branch.

Incidentally, if the attacker has >40% hashrate, there is a technique to amplify his hashrate and get more than his fair share of blocks. So if, say, he has 49% hashrate and used this technique, he can get close to 100% of blocks, significantly delaying tx confirmation.


---

### Answer by username_4 on 2013-08-15. Score: 0

I disagree with your premise "This would slow down the rate a block would be included in the chain". Every other miner or pool has just as much a shot at discovering a block as the evil one. Unless the evil one is so powerful that he is singlehandedly effecting the difficulty in a signficant way, his blank blocks will not prevent other miners from discovering normal blocks.

I think your question is simply a restatement of the "51%" problem.

> **Comments:**
> **username_0**: Or rather a porportional problem... if the pool owns 25% of the hash, then the maximum detriment is 25%.  (etc)  

---

