Secure Minting

[davebryson]

Question

How can the system support secure minting of currency?

Benefit

A secure minting solution will ensure that only pre-authorized, designated, wallets can mint new currency

Proposed Solution

For an initial solution we will add the ability for sentinels to recognize and validate mint transactions. This will require:

• Adding configuration information to include a list of public keys authorized to sign mint transaction outputs
• Changing the validation logic. Instead of rejecting a transaction with zero inputs. This will signal the logic to use the configured (mint) public keys to validate signatures
• Update the wallet as needed to support the above. For example, the wallet will need to identify and use the pre-authorized public key to sign mint transactions

Possible Difficulties

The proposed solution is a starting point - it may not be the final (best) solution. More research will be needed to ensure minting is as secure as possible.

Prior Work

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[davebryson]

@HalosGhost You can assign this to me. I've started working on it.

[davebryson]

@HalosGhost Working through an implementation of secure minting, I've ran into an issue with the Atomizer sentinel. Minting transactions do not have Tx inputs. However, the Atomizer sentinel expects Tx inputs in order to forward the transaction: https://github.com/mit-dci/opencbdc-tx/blob/trunk/src/uhs/atomizer/sentinel/controller.cpp#L97. It appears the atomizer sentinel uses Tx inputs to validate a shard id.

The logic I've added for secure minting performs specific minting validation if a transaction has no inputs. Otherwise a non-mint transaction, with no inputs, will be rejected. So technically valid non-mint transactions will work with the current sentinel logic.

However, if I adjust the logic to support a mint transaction (no inputs), what's the best way to determine which pid ( https://github.com/mit-dci/opencbdc-tx/blob/trunk/src/uhs/atomizer/sentinel/controller.cpp#L116 ) the transaction should be sent to? Are there any other potential issues with a compact transaction having no inputs in the Atomizer?

UPDATE: On further investigation, it appears the shard also checks for inputs: https://github.com/mit-dci/opencbdc-tx/blob/trunk/src/uhs/atomizer/shard/shard.cpp#L123

[HalosGhost]

@davebryson I just want to double-check, it sounds like you managed to find an answer to the primary question you had; is there anything else tripping you up or blocking you?

[davebryson]

@HalosGhost I don't think so. The only issue I see is I need to remove checking for no inputs in the atomizer architecture: https://github.com/mit-dci/opencbdc-tx/blob/trunk/src/uhs/atomizer/shard/shard.cpp#L123. But this should be ok as the transaction would never get this far if it didn't pass validation.

Right now I'm merging conflicts from latest trunk. So I hope to have the initial pull request very soon. Thanks.