Prevent headers and blocks spamming. Add VIP-1 soft fork.

[presstab]

VIP-1 Soft Fork:

VIP link: VIP-0001

Implementation Detail: The default wallet will now use no stake weight reduction for any denomination of zerocoin, since enforcement was not properly added to the codebase. Once the enforcement threshold is met, stake weight will automatically revert back to reduced weight for larger denomination.

Soft Fork Detail:

• Bit signal on version bit 2
• Each voting period 1440 blocks (1 day)
• Activation threshold 75% 1080 blocks

Spam and DoS Prevention

Background Information: A recent security analysis and associated research paper have identified some areas of concern for DoS attacks against many Proof of Stake based cryptocurrencies (link). The majority of these attacks focus on headers first syncing and spamming fake headers and invalid blocks. These spam attacks rely on headers because in most headers first implementations you are not able to identify the validity of proof of stake based solely on headers.

While Veil is less vulnerable than some other blockchains, there were a few areas that have been hardened against such attacks, and a few areas where Veil has decided to place more emphasis on the Proof of Work side of Veil's dual consensus system.

Long Range Headers Syncing: Veil will now only do "long range" headers syncing if the headers chain has a higher amount of PoW specific work than the client's best known header. This is important because it means that in order to create a spam side chain that might fill up the client's memory (or at least be monitored actively as a potential reorg) the chain would need to have spent money/resources/hash power on the spam chain, which causes a major barrier to entry and significant hurdle to launch such an attack.

Short Range Headers Syncing: If there is no established chain with more PoW work than the current main chain, then the Veil client will revert to short range syncing. With short range syncing Veil will only run 50 headers above the current active chain. These 50 headers may in fact be invalid (since they would only be PoS and thus unable to be validated without more information). Since the headers will be a higher dual-consensus work chain, the client will request the blocks for the chain. Once any of the blocks are seen as invalid, the headers chain will be disconnected.

Active Collection of Headers Garbage: One of the described attacks relies primarily on filling up the memory of a node by giving them too many headers. Veil's default client will now actively prune irrelevant block indexes that are not candidates for reorg once there are in excess of 1,000 non-main chain indexes.

Disk Exhaustion: Veil does full validation of stakes during AcceptBlock(), this means that a block will not be stored to disk unless it is associated with a valid stake. Since Veil does not rely on UTXO database for staking and instead relies on cryptographic accumulators (which can be easily instantiated on the fly to a certain block without impacting the state of the mainchain) Veil is able to check that a stake is in fact valid. The Veil client also keeps full indexing of spent zerocoins and the block they were spent on, which allows for quick checking of whether the zerocoin being spent was spent on the chain it is reorganizing to.

A possible disk attack could occur with the following scenario:

An attack could exhaust disk resources by using at least 1 valid stake and continuously repackaging that stake into different variations of the same block, which from the blockchain's perspective gives unique valid blocks. As seen in Block 98-s3 and Block 98'-s3, without proper handling the same stake could be repackaged and have new invalid headers added on top to give the impression of a valid new chain to reorganize to, resulting in each modified version of Block 98 being stored to disk.

Veil will now circumvent such an attack by keeping track of stakes. If a repacked block with the same stake comes in, the block will be ignored unless a valid Proof of Work header is also on the reorg chain, creating much less likelihood for an exhaustion attack to occur without spending significant resources on the attack. This system will allow for the valid chain with Block 98'' to be reorganized to.

Other Miscellaneous Items Included In Pull Request:

• Reduce the likelihood of validating the same zeroknowledge proof multiple times.
• Don't assign DoS score for out of order headers received from peers (will add once root cause is identified)
• Fix some edge cases with block staging slowing down syncing of certain blocks.
• New hard checkpoint added block 29000.
• Don't accept transactions to mempool unless both blocks and headers are synced.
• Fix bad block index and a few timing issues in stake miner.
• Add rescanringctwallet rpc.
• Add subwallet seed hash and address counts to getwalletinfo rpc.