v1.0.1.2

Release Notes: v1.0.1.2

New Wallet Features and Tools

RPC/Console:

• getwalletinfo adds wallet_seeds section, providing information about the wallet's current sub-wallet key seeds in and how many addresses or coins have been derived from each seed.

• rescanringctwallet will scan through every RingCT and CT coin that is in the wallet's database. It will attempt to repair any metadata that is incorrect.

• gettransaction now has an additional section debug which displays information about the wallet databases metadata for that specific transaction.

GUI

• Coin Control now displays the wallet's available RingCT and CT outputs. Coin control is accessed on the send dialog using the Coin Control button. Users can select which output(s) they would like to use in their transaction, and they will be carried forward to the send dialog. Transactions are invalid if they contain different types of inputs (for example RingCT and Basecoin), so Coin Control will prevent different types from being selected at the same time. In this wallet release, the labels at the top of the dialog are not being updated, this functionality is still being worked on and tested.

• Transaction Fees displayed clearly in the transaction list on the Overview Dialog.

• RingCT Balance displayed on the Zerocoin Minting Dialog.

VIP-1 Soft Fork

Version 1.0.1 of the Veil wallet adds support for a soft fork to include support for VIP-1. This Veil Improvement Proposal adds enforcement of reduced stake weight for large denomination zerocoin denominations (100, 1000, and 10000). This reduction of stake weight (the likelihood of the coin to successfully stake) was advertised as a feature in Veil, and has been active in all wallets, but the enforcement of the reduction was not being done properly. This allowed for editing certain lines of the stake mining code out, allowing for full weight stakes. This gave the 100 denom about 10% more chance to stake than it is supposed to have, 20% for 1,000, and 30% for 10,000.

Since people are actively staking with the higher weight, Veil's default stake miner now removes the reduction as well. The Veil Project believes that if one person can edit the code out to increase their chances, then everyone should be able to have it by default. When enforcement of the decreased weighting goes into effect (successful activation of VIP-1 soft fork), Veil's default stake miner will revert back to using decreased weights as is required.

How soft forks work:
Each new block that is added to the blockchain has the ability to signal support for VIP-1. By default any wallet running on v1.0.1.2 will signal yes in the blocks that are produced from it.

A new voting period starts every 1440 blocks, which is approximately one day. If the day has 75% of the created blocks signalling VIP-1 support then it will consider the soft fork "locked in". After VIP-1 is locked in, there will be one day until the soft fork is activated.

As this is a soft fork, it is not mandatory for users to upgrade, but they should upgrade.

The softfork status/block signalling can be seen using getblockchaininfo:

  "bip9_softforks": {
    "pos_weight": {
      "status": "started",
      "bit": 2,
      "startTime": 1548161817,
      "timeout": 1579805817,
      "since": 27360,
      "statistics": {
        "period": 1440,
        "threshold": 1080,
        "elapsed": 819,
        "count": 24,
        "support": 0.0293040293040293,
        "possible": false
      }
    }
  }

Increased Spam and Denial of Service Protection

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.