"Miner spam to raise transaction fees. Is this real?"
"Hi Andreas. Can miners spam the network with transactions to raise fees,
mitigating the cost of such an attack by mining their own transactions?"
"If so, could you elaborate on how such a spam attack would work,
and how Bitcoin can evolve to address this issue?"
This is not an easy subject. It is quite controversial. There are a lot of conspiracy theories flying around...
It is very difficult to draw any firm conclusions. You can't really tell if a transaction is made...
by a user [for "legitimate" purposes], if it was created by a miner or some other party to inflate fees.
However, from a theoretical perspective, it is possible to game the system and create lots of transactions...
with high fees, that overpay on fees, which pushes up the fee estimation algorithms.
Such an attack is much more expensive when you have more capacity on the network.
It takes more [transactions] to fill [blocks]. SegWit made that harder.
It becomes even more expensive when companies operating "legitimate" exchanges, merchant [services],
wallets, etc. use good fee estimation [algorithms] and transaction capabilities like replace-by-fee (RBF).
The more sophisticated the fee management of wallets is, the more expensive it becomes...
to cram the blockchain with "fake" transactions.
Also, as you indicated in your question, in order for this [attack] to be affordable for miners,
they must be able to recover some of those fees by mining their own transactions.
That makes it a lot easier to attack the network.
One of the challenges here is the level of centralization among miners.
When mining is very centralized, then it is a lot easier to perform this kind of attack.
When mining is more decentralized, then it is more difficult to perform this attack,
because you may be spending money on raising the mining fees by making transactions,
but then [losing the chance] to mine those because somebody else mined the next block [first].
You would be losing money and they are gaining it. Other miners can benefit from spam transactions...
without needing to expend [resources] on spamming the Bitcoin network.
It will still raise fees for them, making it an economic tragedy of the commons, and probably a good one.
The final question is, how can Bitcoin evolve to address this issue [of spam]?
The problem is two-fold. You will always have limited capacity. There is no infinite capacity on any system,
especially a system attempting to be decentralized and secure.
There will always be opportunities to raise the cost of transactions by filling up the available capacity.
The problem is in the background, [based on] how centralized or decentralized mining is.
Fortunately, we are beginning to see the first effects of mining chips reaching the limits of Moore's Law;
other chip manufacturers are entering the game, and [some] countries trying to attract Bitcoin miners...
in their jurisdictions by offering tax breaks and cheap electricity.
There is a lot of interest in mining from Canada and other places around the world.
I have long thought that mining is on the cusp of...
becoming more decentralized due to various economic [incentives and] pressures.
We will see how that happens. Overall, I think the best defense is to use sophisticated wallets..
for estimating fees correctly, and also give you the opportunity to bid for lower fees with replace-by-fee..
and Child-Pays-For-Parent (CPFP), which lowers the pressure on fees for the whole network.
Another solution is, if the fees are too expensive and your transaction is not urgent, you can wait.
If you are willing to wait, then you aren't playing their game.
"What is Child-Pays-For-Parent? How does it work? Which wallets have this feature?"
First of all, Child-Pays-For-Parent isn't really a feature.
It is a recognition of the economic incentives that exist for miners when selecting transactions.
If you have a transaction that is unconfirmed, and that transaction has a child / dependent transaction..
that is also unconfirmed, when you are choosing which transactions to include in the block as a miner,
you may not want to look at the amount of fee per byte paid by individual transactions,
but the fees per byte paid jointly by both transactions.
If the child [transaction] has a very generous fee, but the parent [transaction] has a very low fee,
the child will never get confirmed because it has an unconfirmed parent.
But if you consider the fee jointly between the two, you might be able to collect the very generous fee...
of the child [transaction] by allowing it to effectively subsidize the lower fee of the parent.
Let's say the parent [transaction] is paying one satoshi per byte, and the child a hundred satoshis per byte.
If you consider them independently, that would result in 'don't confirm the parent, but confirm the child.'
but you can't do that because the child doesn't exist without the parent being confirmed.
If you [confirm] them together, they are jointly [averaging] fifty satoshis per byte.
That is a great fee, so you will want to confirm both. In fact, this strategy is already used by miners.
[When you ask], "Is it a feature in a wallet," that means the wallet is aware of that strategy,
and use it to your own advantage in two ways: if you receive a transaction and it is not confirming,
you can take one of the outputs in that unconfirmed transaction and construct a child transaction...
which uses that [payment] as an input, and then pay a larger fee.
As such, you will [incentivise] the miner to select both of those transactions and include them in the next block.
The transaction that you were expecting to receive that was unconfirmed [due to low fee], becomes confirmed.
You "spent" it while it was unconfirmed, with a higher fee. So, you create a child that pays for the parent...
[transaction] sent to you when it hasn't confirmed yet.
By doing that, you have essentially bumped the fee for the parent and made it possible for it to confirm.
[This is a way to] push through a transaction that is stuck. I have done this many times.
If I have an incoming payment with a low fee, I create a child transaction on purpose and bump the fee.
I use Electrum to do this, but some other wallets also have this feature. I can't give a list right now,
so you can [do some] research [to find which wallets support replace-by-fee and child-pays-for-parent].
There is another way to use [child-pays-for-parent]. It is not just the recipient who can [bump the fee].
The sender can too. Almost always, when you send a transaction, there is a change payment back to you.
You can string a child [transaction] onto the change output of your own parent and use it to bump the fee.
If you haven't used replace-by-fee to affect the fee of the parent, you can use child-pays-for-prent instead..
to accelerate one of your own outgoing transactions by attaching a greater fee to the change output.
Even if the receiver isn't doing child-pays-for-parent because maybe they don't know how to [use it],
you can accelerate the parent by constructing a child [transaction] with a change transaction.
It is an interesting feature based on economic incentive mechanisms that apply to miners.
You can use it in certain wallets in order to accelerate transactions.