Preventing Network Spam
The philosophy of Bitcoin with respect to fees is that of 'pay what you will' and it has resulted in direct denial of service (DDoS) for those refusing to pay a high fee and tremendous blockchain bloat as almost every block is filled to the brim with spam transactions. Bitcoin core 0.11.0 came out with a fee estimation feature because there is a demand for a stated Tx fee at which coins can be reliably and efficiently moved.
Peercoin and peer forks take a different philosophy by socializing the cost and enforcing a minimum fee of 0.01 PPC/KB. At the same time, a minimum output size (anti-dust, like litecoin recently implemented) also of 0.01 PPC helps ensure a cost for spamming the network. The burning of the mandatory minimum fee in the peer network is critical for materializing the cost as a feeback loop to the size of the blockchain.
However, a reasonable analysis of the numbers involved will betray how cheap it is in reality to bloat the blockchain and DDoS the network. We could simply raise the fee to a higher level, but we would be punishing legitimate uses of the blockchain at the same level as spam attacks. This problem exists in most standard decentralized cryptocurrencies, and proposed here are some solutions to the problem as it pertains to the peer community.
- 1 Types of spam attacks
- 2 Solution 1: Voting
- 3 Solution 2: Automated Variable Fee
- 4 Reducing Response Time
- 5 Conclusion
Types of spam attacks
- DDoS (Mostly full blocks, Long Tx times)
- Blockchain Bloat (Blockchain grows faster than advances in hardware)
Short Range Attack (Type 1)
Even in the case of a type 1 spam attack with malicious intent, the network is not unusable. A user may feel free to increase their fee above whatever fee the spammer is using (most likely the mandatory minimum) and get their Tx validated with priority. PoS coins also have a concept of coinage that allows minters to prioritize Tx with the same fee. A spammer most likely has not had a stake in the network for long and will not have many coins with high coinage.
In the event of a DDoS at the minimum fee level, an attempt should be made to adjust the minimum level to a more appropriate solution. We want to raise the fees high enough to make the attack economically infeasible and hold them there for enough time to avoid repeat attacks, then bring them back down for normal users. Here, response time to the attack is a figure of merit.
Long Range Attack (Type 2)
Users without hostile intent can still spam the blockchain with unimportant microTx so a method should be used to globally control the speed at which the blockchain grows. The postulate here is that there is a certain number of MB/time that the network is willing to pay which is related to the growing hardware capabilities of the minters and if the network exceeds that it should be compensated with additional coin burning. The logic is as follows:
If the blocks are 100% full all the time, the blockchain will grow much faster than hardware can keep up with. If they are empty, hardware will have no problem keeping up. There must be some target filling amount at which the blockchain is just perfectly keeping up with the hardware. As hardware advances in a staggered fashion, the filling target should have some way of responding to external stimuli.
Solution 1: Voting
By giving stakeholders a direct vote on the fee, the network can respond beautifully to Attack 2. Attack 1 can also be resolved this way, but the response time becomes dodgy. If the voting body is not used to the responsibility of voting and minters do not experience movement on the blockchain much, it may take a long time for the network to respond to DDoS attempts. If the voting body is alert and aware, this solution can be quite useful.
Solution 2: Automated Variable Fee
By adjusting the fee according to verifyable criteria, we can hope to eliminate all ambiguities in the system such that both attacks are highly improbable. As the protocol is responding to events written on the blockchain, response time must be longer than a block.
- FF (Filling Factor)
Average of the size in MB (<1) of the last 10 blocks (window length).
- TFF (Target Filling Factor)
Blocksize desired by network in MB (<1)
- OF and NF (Old fee and New fee)
The old fee is the fee paid in the last block. The new fee will be enforced by the minter for the current block.
- NF = OF + x | if FF>TFF
- NF = OF - x | if FF<TFF
- NF = OF | if FF=TFF
x is the fee step and can also be used as the minimum fee (0.01 PPC/KB) and anti-dust (0.01 PPC). The network will settle down to x during low volume times and can move up at a reasonable clip over the course of a few blocks during a DDoS attack.
Smoothing the Step
If the actual free market volume is above TFF, the fee will adjust until the free market volume is at TFF, thus satisfying Attack 2. However, if the actual desired fee is 1.5x, the stepped fee enters a strangely oscillating solution. A function that allows for a smooth liftoff from the minimum fee and potentially reduces the response time would be as follows:
- NF = OF + x * (FF/TFF-1)
Removing x from the equation
As the price of peercoin reaches the billions that we all know it's worth, the anti-dust and minimum fee will need to be reduced as the economic penalty they impose will be overkill. A truly elegant solution would not require a hardcoded minimum fee, but would instead combine the free market approach of bitcoin with the common fee of the peer network. The basic approach for such a floating fee is like this:
- NF = OF * FF/TFF
There are many issues with implementing a fee like this, for example there must be a minimum non-zero FF and the DDoS response is based on its history. It may be possible to use a clever method of picking TFF to permanently solve the spam problem without ever needing another hard fork, but for now we should try the simpler methods and use voting to set x and TFF.
Setting the target is important, but not critical on the short-term scale. An obvious choice that arises is stakeholder voting, as the responsibility is not nearly as great as manually setting the fee would be. Another option would be automation using a feedback loop. If the Tx volume has been low for a long time, the TFF will settle down lower than hardware dictates. A full block will cause the FF to be many times the TFF and the fee will increase very rapidly over just a few blocks until either the Tx volume returned to normal or the TFF readjusts to the new value. The target would decrease over time if Tx volume is low and increase over time if Tx volume is high. It would need to tie in to something like PoW difficulty to get a sense for the hardware capacities of the tech community. This would require serious study to get it working reliably.
Picking a window length
The window length is a consensus period not unlike peershares motions, however the votes are not directly chosen by the voter (though it's worth mentioning that the minter does have a choice in the size of the block). The difficulty of DDoSing the system is complicated, but scales somewhat linearly with the window length, so an order of magnitude should be an impressive improvement. Further testing may reveal more about this.
Reducing Response Time
The real limitation for response time is actually longer than a block. It is not something under the control of the minter; it is the time it takes for the clients to verify (or at least process) the change and adjust their fee accordingly. The minter can only enforce a fee on Tx in its mempool using something like a timestamp ~10 minutes after the last block was broadcast. Reducing response time below a block isn't as much an issue of minter protocol as it is client protocol. A Tx fee that is voted on by stakeholders, like the one Nu will implement soon, should also feel this limitation.
The Mempool and Verifiability
A minter receives Tx at different times than all other minters and stores them in a pool called the mempool. By definition these Tx are not confirmed, so any use of them in the protocol is unverifiable. Having an unverifiable Tx fee in the protocol is not necessarily a bad thing if the users are aware of the fee, however it is less graceful than a fully verifiable Tx enforced at the blockchain level.
Fortunately for us, bitcoin is being held hostage until it can come up with a solution. However, I suspect the devs will find a way to kick the can down the road, in which case it is our prerogative to find a solution ourselves before we wake up one day and the peercoin blockchain is twice the size.
My suggestion would be that we implement the smoothed step with stakeholder voted TFF and x. Have the default values be 0.5 for TFF and 0.01 for x, such that without voting or spamming the network returns to its current state of a 0.01 common fee for all Tx.
Thank you for your attention, discussion is desired above all else.