Another way an entity could destroy Bitcoin could be to broadcast a sufficient number of transactions to bid up the cost of getting a transaction confirmed to be uneconomical. The entity could first broadcast 1 MB worth of transactions every 10 minutes with fees averaging 70 sat/byte, then increase this average to 80 sat/byte, and so on.
This attack could have little to no cost to an attacker with a small minority of the network hashpower (or even be net profitable).
If you are paying X per byte in fees then how on earth can that possibly have *no cost*?
(five left - not sure I should waste them on stupid things)
Say for example, that miners can include 1,000,000 bytes worth of transactions in each found block (the actual number is slightly less, however this makes the math a little bit easier).
Conforming with the OP's scenario, say that the attacker/spammer controls ~10.416% (15 blocks found per day) -- this is slightly above the 10% indicated by the OP to make the math simpler -- of the network hashrate. Also assume that the average cost of including a transaction into a block is 50 sats/byte, which means that blocks will have, on average 0.5
BTC worth of tx fees in each found block. Also assume that there is demand of 950kb worth of transactions every 10 minutes that is willing to pay up to 201 sats/byte to have their transactions included in a block, but will only pay the average fee necessary to have their transactions included in a block -- there is also a demand of 50 kb worth of transactions every 10 minutes that is willing to pay no more then 50 sats/byte ("spam transactions").
Prior to the attacker launching the attack, his income from mining would be as follows:
*Found blocks: 15
*TX fee revenue: 7.5
BTC*cost of attack: 0.0
BTC*revenue from attack: 0.0
BTC*net income from attack: 0.0
BTCAt first the attacker creates transactions so that users need to pay at least 70 sats/byte to get their transactions confirmed -- they do this by creating 1 MB worth of transactions every 10 minutes that include tx fees in the amount of 70 sats/byte. Users are slow to react, so, on the first day of the attack, 50% of confirmed transactions are that of the attacker, however the other 50% of transactions do in fact include tx fees averaging 70 sats/byte.
After one day, the attackers revenue is as follows(per day):
*Found blocks: 15
*TX fee revenue: 10.5
BTC*revenue from attack: 3
BTC*cost of attack: 50.4
BTC*net income from attack: (47.4
BTC)
*transaction backlog: 64,800,000 bytes = 64,800 kb
The attacker will have spent 50.4
BTC in transaction fees, however some of that is mitigated by the fact that the attacker received 10.5
BTC worth of transaction fees in the blocks they confirmed, which is 3
BTC more then what the attacker would have received had the attack not happened.
On day two, users realize they must now pay a higher transaction fee, and start paying 70 sats/byte to get their transactions confirmed. Since the current price of transaction fees is too high for the spam transactions, there is only 950 kbs worth of demand for block space that is paying 70 sats/byte (excluding the attacker's transactions). This means that the attacker only has 5 kbs worth of transactions paying 70 sats/byte included in their transactions.
After day two, the attacker's revenue is as follows (per day):
*Found blocks: 15
*TX fee revenue: 10.5
BTC*revenue from attack: 3
BTC*cost of attack: 5.04
BTC*net income from attack: (2.04
BTC)
*transaction backlog : 64,800,000 bytes = 64,800 kb -- unchanged
On day two, the transaction backlog remained unchanged because users who attempted to send transactions on day one used RBF to pay a higher fee, however a similar number of additional transactions are unable to get confirmed. The transaction backlog does not include transactions from the attacker.
On day three, the attacker increases the tx fees on the transactions they broadcast to 90 sats/byte. Again, users are slow to react, although not as much as they were on day one because they are aware that transaction fees are rising, so only 30% of the transactions confirmed on day three are that of the attacker, and 70% are that of other users, that are paying an average fee of 90 sats/byte.
After day three, the attacker's revenue is as follows (per day):
*Found blocks: 15
*TX fee revenue: 13.5
BTC*revenue from attack: 6
BTC*cost of attack: 38.88
BTC*net income from attack: (32.88
BTC)
*transaction backlog: 108,000,000 = 108,000 kb -- an increase of 43,200,000 = 43,200 kb
On day four, users start paying 90 sats/byte in masse, and the attacker again only has 5% of the transactions confirmed on day four belong to him. The increase in the transaction backlog is that of the transactions that the attacker outbid that otherwise needed to get included in blocks.
After day four, the attacker's revenue is as follows (per day):
*Found blocks: 15
*TX fee revenue: 13.5
BTC*revenue from attack: 6
BTC*cost of attack: 6.48
BTC*net income from attack: (0.48
BTC).
On day 5, the attacker increases the tx fees on the transactions they broadcast to 120 sats/byte. Again, users are slow to react, so only 30% of the transactions confirmed on day three are that of the attacker, and 70% are that of other users, that are paying an average fee of 120 sats/byte.
After day 5, the attacker's revenue is as follow (per day):
*Found blocks: 15
*TX fee revenue: 18
BTC*revenue from attack: 10.5
BTC*cost of attack: 51.84
BTC*net income from attack: (41.34[btc)
*transaction backlog: 151,200 kb -- an increase of 43,200,000 = 43,200 kb
On day 6, users start paying 120 sats/byte in masse, and the attacker again only has 5% of the transactions confirmed on day four belong to him. The increase in the transaction backlog is that of the transactions that the attacker outbid that otherwise needed to get included in blocks.
After day 6, the attacker's revenue is as follows: (per day):
*found blocks: 15
*TX fee revenue: 18
BTC*revenue from attack: 10.5
BTC*cost of attack: 8.64
BTC*net income from attack: 1.86
BTCAt this point, the attacker is making 1.86
BTC per day from the attack -- this is because they would make 7.5
BTC worth of tx fees absent their attack, and is making 18
BTC worth of transaction fees as a result of the attack, and is only paying 8.64
BTC worth of transaction fees in order to keep the average transaction fee as high as it is. Prior to the this day, the attacker has already "invested" 82.8
BTC into the attack, and does not want to wait 1.5 months to break even, so they continue to raise the TX fees of their transactions.
On day 7, the attacker increases the tx fees on the transactions they broadcast to 150 sats/byte. Again, users are slow to react, so only 30% of the transactions confirmed on day three are that of the attacker, and 70% are that of other users, that are paying an average fee of 150 sats/byte.
After day 7, the attacker's revenue is as follows (per day):
*found blocks: 15
*TX fee revenue: 22.5
BTC*revenue from attack: 15
BTC*cost of attack: 64.8
BTC*net income from attack: (49.8
BTC)
*transaction backlog: 194,400 kb -- an increase of 43,200,000 = 43,200 kb
On day 8, users start paying 150 sats/byte in masse, and the attacker again only has 5% of the transactions confirmed on day four belong to him. The increase in the transaction backlog is that of the transactions that the attacker outbid that otherwise needed to get included in blocks.
After day 8, the attacker's revenue is as follows (per day):
*found blocks: 15
*TX fee revenue: 22.5
BTC*revenue from attack: 15
BTC*cost of attack: 10.8
BTC*net income from attack: 4.2
BTC*total income from attack: (126.54
BTC)
On day 9, the attacker increases the tx fees on the transactions they broadcast to 200 sats/byte. Again, users are slow to react, so only 30% of the transactions confirmed on day three are that of the attacker, and 70% are that of other users, that are paying an average fee of 200 sats/byte.
After day 9, the attacker's revenue is as follows (per day):
*found blocks: 15
*TX fee revenue: 30
BTC*revenue from attack: 22.5
BTC*cost of attack: 86.4
BTC*net income from attack: (63.9
BTC)
*total income from attack: (190.44
BTC)
*transaction backlog: 237,600 kb -- an increase of 43,200,000 = 43,200 kb
On day 10, users start paying 200 sats/byte in masse, and the attacker again only has 5% of the transactions confirmed on day four belong to him. The increase in the transaction backlog is that of the transactions that the attacker outbid that otherwise needed to get included in blocks.
After day 10, the attacker's revenue is as follows (per day):
*found blocks: 15
*TX fee revenue: 30
BTC*revenue from attack: 22.5
BTC*cost of attack: 14.4
BTC*net income from attack: 8.1
BTC*total income from attack: (182.34
BTC)
The attacker would need to continue to keep broadcasting transactions with an average tx fee of 200 sats/byte for ~22.5 additional days until he breaks even on the attack. After the attacker stops broadcasting his attack transactions, an additional 50 kb worth of block space (per block) would become available to reduce the backlog, or roughly 7,200 kb per day. This results in it taking roughly 33 days to clear the backlog, during which time, transaction fees should stay at roughly 200 sats/byte, and after the backlog is cleared, the average necessary TX fee should crash back to 50 sats/byte that it was originally.
tl;dr -- you control a small portion of the miners, benefit from the increased transaction fees that everyone else is forced to pay because you bid up the price of transactions for everyone.