 Miner spam to raise transaction fees. Is this real? This question comes from Ashley. Hi, Andreas. Can miners spam the network with transaction to raise mining 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? Also, how can Bitcoin evolve to address this issue? Ashley, this is really not an easy subject. It's quite a controversial subject, in fact, because there's a lot of conspiracy theory flying around. It's very difficult to draw any firm conclusions. You can't really tell if a transaction is made by a legitimate transaction user who wants to get something paid, or if it was created by a miner or some other party who wants to inflate fees. However, from a theoretical perspective, it is possible to game the system. It is possible to create a lot of transactions with high fees, overpay fees, and use that to push up the fee estimation mechanism. Such an attack gets much more expensive when you have more capacity on the network, because it takes more to fill the network. Segwit made that harder. It becomes more expensive when the companies that are operating legitimate transactions, exchanges, merchants, wallets, etc., and users are directly using fee estimation techniques that are good, that are using technologies like replaced by fee. The more sophisticated the fee management of wallets is, the more expensive it gets to cram the blockchain with fake transactions. Also, as you indicated in your question, in order for this to be affordable for miners, they have to 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 of the mining groups. When mining is very centralized, it is a lot easier to do this kind of attack. When mining is decentralized or more decentralized, it is a lot more difficult to achieve this attack. You may be spending money on raising the mining fees by making transactions, and at the same time not getting to mine those, because somebody else mined the next block, so you lose that money and they gain it. In that case, others can benefit from spam transactions. Other miners can benefit from spam transactions without having to expend the cost of actually spamming the network. It will still raise fees for them, and that makes it an economic tragedy of the commons. In this case, probably a good one. The final question is, how can Bitcoin evolve to address this issue? The problem here is two-fold. One is, you will always have limited capacity. There is no possibility of infinite capacity on any system, especially a system that is 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 really on the back end, which is how centralized or decentralized mining is. Fortunately, we are beginning to see the first effects of the mining chips reaching the limits of Morth law. We are beginning to see other chip manufacturers enter the game, as well as other countries attracting Bitcoin miners in their jurisdictions by offering tax breaks for cheap electricity. We are seeing a lot of interest in Canada, mining, and other places around the world. I have long thought that mining is on the cusp of becoming more decentralized because of various economic pressures. We will see how that happens. Overall, I think the best defense at the moment is to use sophisticated wallets that allow you to estimate fees correctly, and also give you the opportunity to bid for lower fees and replace the fee in your transaction with technologies like Replace by fee and Child Pace for Parent. That brings pressure to lower fees on the whole network. One of the simple solutions to that is if the fees are too expensive and your transaction isn't urgent, you wait. If you are willing to wait, then you are not playing that game. What is Child Pace for Parent? How does it work? Which wallets have this feature? First of all, Gustavo asked this question. Child Pace for Parent isn't really a feature. It is a recognition of the economic incentives that exist for miners in selecting transactions. Meaning that if you have a transaction that is unconfirmed, and that transaction has a child transaction, a dependent transaction that is also unconfirmed, when you are choosing which transactions to include in the block as a miner, you want to look not at the amount of fee per byte paid individually by each transaction, but you want to look at the fees per byte paid jointly by both of those transactions. If the child has a very generous fee, but the parent has a very low fee, the child will never get confirmed because it has an unconfirmed parent, so that won't help. But if you consider the fee jointly between the two, you might be able to collect the very generous fee of the child, by allowing it effectively to subsidize, or taking it into consideration as a whole, the low fee of the parent. Let's say the parent is paying one Satoshi per byte, and the child is paying 100 Satoshi per byte. If you consider them independently, that means don't confirm the parent, yes, confirm the child, but you can't do that because the child doesn't exist without the parent being confirmed. But if you take them together, well, they are paying 50 Satoshi per byte jointly, and that's a great fee, so you confirm both. That strategy is already used by miners. What it means to have that feature in a wallet is to be aware that that strategy is being used by miners, and use it to your advantage. You can use it to your advantage in two ways. One is, if you are receiving a transaction and it's not confirming, you can take one of the outputs that you own, that is sent to you, unconfirmed output, and you can construct a child transaction that uses that as an input, and give it a very big fee. As a result, you are going to make the situation such that the miners will want to select both of those transactions to include them in the next block, and so the transaction that you were expecting, that you were receiving, that was unconfirmed, becomes confirmed because you spent it while it was unconfirmed with a higher fee. You create the child that pays for a parent that has been sent to you, that hasn't confirmed yet. By doing that, essentially what you've done is you've bumped the fee for the parent and made it possible for it to confirm. You can push through a transaction that is stuck. I've done that many times, so I have an incoming payment, it has a low fee on it, 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 you a list right now, but you can maybe do some Google research on that. But there's another way to use this, which is... It's not just a recipient that can use child pays for a parent, the sender can too, because almost always, when you send out a transaction, there is a change payment coming back to you, and you can string a child onto the change output of your own parent and use it to bump the fee. If you haven't used replace-by-fee, so you can't affect the fee of the parent, you can use child pays for parent instead, to accelerate one of your own outgoing transactions by attaching a greater fee to the change output in a child that you control. Even if the person receiving that isn't doing a child pays for a parent, perhaps they don't know how to, you can accelerate the parent by constructing a child with a change transaction. It's an interesting feature, it comes out of the basic economic incentive mechanisms that apply to miners, and you can use it in certain wallets in order to accelerate transactions.