feat(base_layer)!: new output field for minimum value range proof

[mrnaveira]

Warning: this PR includes consensus breaking changes

Description

• New field minimum_value_promise for:
  • Struct UnblindedOutput, the range proof gets calculated automatically
  • Struct TransactionOutput, the range proof for the minimum value is verified in the existing verify_range_proof function
• Adding the new field cascades into the following changes:
  • Created a new TransactionOutputVersion::V2 to isolate the breaking changes of the new field. Used to differentiate when calculating the consensus hashing.
  • Updated the gRPC definitions
  • Updated the lmdb block storage
  • For the wallet:
    • Updated multiple services
    • Updated the Sqlite storage (including a new migration)
    • Changed the FFI function wallet_import_external_utxo_as_non_rewindable with the new parameter
  • Used the default value whenever necessary: genesis block, faucet, etc.
  • Updated multiple test helpers across the project

Motivation and Context

The new Bulletproof+ allows us to create range proofs to demonstrate that a commitment value is greater than a particular value. This is very useful for future stake validation.

The purpose of this PR is to include a convenience new field (minimum_value_promise) in transaction outputs to specify a minimum value for range proofs. Range proofs should be automatically created and verified with minimum changes to existing code. The default value should be 0 so it behaves as current proofs.

How Has This Been Tested?

• New unit test that builds a TransactionOutput from a UnblindedOutput with the new field, and verifies the range proof, metadata and mask

BREAKING CHANGE: Will not sync with existing dibbler genesis block

[sdbondi]

Looks good - two minor comments

[sdbondi]

Nice!

[SWvheerden]

This is going to break on running the actual test net.
We can default the min_output_value everywhere.
We have to properly map it in.
Currently, its mapped to some outputs, but the inputs are all default. This will cause a hash imbalance and the outputs will not be recognised.

[hansieodendaal]

Hi there,

Looking good, except some changes required where the range proofs are constructed and verified.

Regards