I’ve made a standalone CLI app for interacting with DBCs and associated BLS keys. I figured I’d drop a link here for any technically inclined folk that might be interested to experiment with DBCs “hands on”.
The app incorporates both server (mint) and client functionality in a single process. The BLS keys are interoperable with @mav’s BLS web tool.
Functionality consists of: creating a mint, creating or importing BLS keys, reissuing a DBC (splitting, merging), and validating a DBC.
There are no binaries at present, so you would need to build it yourself.
Here are usage examples of the available commands:
The sn_dbc library it is built on is still being built, so the commands will change a bit in future releases.
A few exercises I’d suggest to sort of internalize how DBCs work:
Walk through the provided examples, running each command yourself and copy/pasting the necessary values from prior command(s) output. In particular, the reissue_manual example really walks through the steps of: creating a tx, signing it, creating a mintrequest, and finally reissuing.
Try out Ian’s BLS tool, and use it for generating keys. This makes the process a bit easier because one doesn’t have to scroll back in the CLI output to find eg PublicKeySet.
Try splitting a DBC into several parts, at least 5… perhaps a couple splits in a row. Then combine a subset of say 3 inputs into 2 outputs. Verify in mint’s spendbook that all input DBCs have been spent.
Bonus, extra credit: Perform the manual reissue with one or more multisig input DBCs. Perform each signature on a different machine (or terminal).
This is a subtle thing. There are two types of validation:
checking that the DBC is well formed and that all signatures are correct. This can be performed offline, if one has a copy of the MInt’s KeyCache. It should be all you need when receiving a DBC.
checking if the DBC has been spent or not. This would typically be performed online by querying a Mint node.
Presently the former is implemented in sn_dbc and the latter is not.
Since these DBCs have owners the second type of validation is not really necessary when receiving a DBC to your PublicKey, since no one else can spend it. It is more for the case where you have a mixed pile of DBCs that you own (spent and unspent) and you wish to check which are actually spendable.
!!! *Slaps head … of course you can do this. I was wondering and a bit skeptical, but once again you guys are on it. This fills a big hole in my understanding.
This actually allows a secure transfer if only the sender can get online. If you can scan e.g. a QR code of the receiver, rekey the DBC and have the network sign it, you can show a well formed and timestamped DBC that the receiver can verify is network signed and can accept with confidence. That’s amazing. That lets you buy SAFE at e.g. convenience stores.
So for farming, will each section have a mint and the mint will be made up of the elders in a section, so that each elder will have one SecretKeyShare and the corresponding PublicKeyShare? Then the elders use this to sign new DBCs given to farmers?
Firstly, the SignatureSharesMap is not part of the sn_dbc API. It is something I created in the CLI app to facilitate the manual prepare_tx → sign_tx → prepare_reissue → reissue flow.
The MintRequest (now renamed to ReissueRequest) requires a SignatureShare corresponding to each SecretKeyShare used to sign a given input. Further, the derivation index of the SecretKeyShare (and thus SignatureShare) must be provided. So the SignatureSharesMap is just a mapping of each Dbc’s hash identifier to the SecretKeyIndex and SignatureShare. In the code it is defined as:
Why not this for reissue?
MintTransaction + SecretKeyShares = MintRequest
Because the reissue API requires a signature (result of combining SignatureShares) not SecretKeyShares. The manual flow in the CLI is trying to reflect the API as closely as possible. The API is designed to work for multisig/multiparty. So one party should never collect all the SecretKeyShare. But they can collect and combine all the SignatureShares.