DBC Mint interactive CLI

[danda]

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”.

GitHub - dan-da/sn_dbc_mint

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:

sn_dbc_mint/doc/examples at master · dan-da/sn_dbc_mint

The sn_dbc library it is built on is still being built, so the commands will change a bit in future releases.

Let me know if any q’s or bug reports.

[19eddyjohn75]

Please if somebody got this to work who’s not a Maidsafe dev “help”

I get stuck at

cargo build

I know I need these

• sn_dbc - Safe Network DBC library
• threshold_crypto - BLS key library

Can’t figure it out yet… I get this error on Ubuntu

eddy@hal9000:~$ cargo build
error: could not find Cargo.toml in /home/eddy or any parent directory

[happybeing]

It’s not your fault, the README instructions are not clear:

$ sudo apt install build-essential
$ sudo apt install pkg-config
$ cargo build

I suspect what you need is:

sudo apt install build-essential
sudo apt install pkg-config
git clone https://github.com/dan-da/sn_dbc_mint
cd sn_dbc_mint
cargo build

Testing the above now… yep, builds for me on Ubuntu 20.04. Then:

target/debug/sn_dbc_mint

 __     _                        
(_  _._|__  |\ | __|_     _ ._|  
__)(_| |(/_ | \|(/_|_\/\/(_)| |< 
 ____  ____   ____   __  __ _       _   
|  _ \| __ ) / ___| |  \/  (_)_ __ | |_ 
| | | |  _ \| |     | |\/| | | '_ \| __|
| |_| | |_) | |___  | |  | | | | | | |_ 
|____/|____/ \____| |_|  |_|_|_| |_|\__|        
  
Type 'help' to get started.

>>

[19eddyjohn75]

@happybeing

It’s not your fault

Unfortunately it is my fault, I’m a clueless consumer thx @happybeing let’s break this mint

[Southside]

It Just Works here with the commands @happybeing posted

Now to see if I can understand enough of the mechanism to find a way of breaking it

thanks @danda and @happybeing – keep at it @19eddyjohn75

[Josh]

super exciting way to wake up. Thanks @danda

[19eddyjohn75]

Wow pretty neat indeed
Some feedback, you can’t mint decimals

Total Money Supply Amount: 0.99
Error: invalid digit found in string

[danda]

Correct. The internal representation of an amount is presently a u64. Apps could break that into decimals, but the CLI doesn’t bother.

Just think of it as whole satoshis, or SafeCoin equivalent.

[Traktion]

It works for me! I’m not sure what to do with it, but it builds are runs fine!

[danda]

A few exercises I’d suggest to sort of internalize how DBCs work:

1. 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.

2. 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.

3. 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.

4. Bonus, extra credit: Perform the manual reissue with one or more multisig input DBCs. Perform each signature on a different machine (or terminal).

[Josh]

This DBC is valid. (note: spent/unspent validation not yet implemented.)

Will validating the DBC show the balance? if not how do I check the balance with a PublicKey?
Figured it out by reading

This is awesome!

[danda]

@Josh

This DBC is valid. (note: spent/unspent validation not yet implemented.)

This is a subtle thing. There are two types of validation:

1. 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.
2. 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.

[danda]

@Josh

if not how do I check the balance with a PublicKey?

For anyone else reading, one can view a DBC’s content, including amount via the decode command. eg:

>> decode

[d: DBC, mt: MintTransaction, s: SignatureSharesMap, mr: MintRequest, pks: PublicKeySet, sks: SecretKeySet]
Type: d

Paste Data: 
04f33c389748fbfa800ddf15f2968fb176a2fc54d7e0e11b0574d5f248de781f34d9be97a6c3fdda280d6553e117896fbcbe99a7761e612d8c8c6fbe97692ffcd96f811a316f2581acb2f53bba4ee91a9d7d53cb55e7d7be813c720bacee7d830000000000000020b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbf04f33c389748fbfa800ddf15f2968fb176a2fc54d7e0e11b0574d5f248de781f34d9be97a6c3fdda280d6553e117896fbcbe99a7761e612d8c8c6fbe97692ffcd96f811a316f2581acb2f53bba4ee91a9d7d53cb55e7d7be813c720bacee7d830000000000000020ba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002e9a6015cc78d18e1a5ae26e3e5a0f0d48515bf41456defca199aea7180a51c2a0000000000000001b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbfba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002296b3aad27fac33e10e7ed97600974677b978427c6498a71a233c94dbaf82e193a9f0919c2fadcf3fab070ad055559a85b3917a112684c3f5c0713d68f3d01742c64d884d9a7bc382763e680c363ff7043b02013a88ea49afdc90ce1b69434ad0514c52ca6c1ecb91d9e4e70f2924007afb4881ea4576f793d15b3daca2b86207b7ef8c0db333f1f7dee538f6a73dc8600000000000000030000000000000003e8b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbfba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002


-- Start DBC --

id: 2a1ca58071ea9a19caef6d4541bf1585d4f0a0e5e326aea5e1188dc75c01a6e9

amount: 1000

output_number: 0

owner: 296b3aad27fac33e10e7ed97600974677b978427c6498a71a233c94dbaf82e193a9f0919c2fadcf3fab070ad055559a85b3917a112684c3f5c0713d68f3d01742c64d884d9a7bc382763e680c363ff7043b02013a88ea49afdc90ce1b69434ad0514c52ca6c1ecb91d9e4e70f2924007afb4881ea4576f793d15b3daca2b86207b7ef8c0db333f1f7dee538f6a73dc860000000000000003

inputs:
  1a2257bcbecd1690b26ab382f9a0c2e275344d69ec6a46339b46f21e054f90ba
  bf2dc176c642936798b7f1cb367baf84e2a4fafddd00d9ccbd9c321c93b921b7

outputs:
  2a1ca58071ea9a19caef6d4541bf1585d4f0a0e5e326aea5e1188dc75c01a6e9

Data:
04f33c389748fbfa800ddf15f2968fb176a2fc54d7e0e11b0574d5f248de781f34d9be97a6c3fdda280d6553e117896fbcbe99a7761e612d8c8c6fbe97692ffcd96f811a316f2581acb2f53bba4ee91a9d7d53cb55e7d7be813c720bacee7d830000000000000020b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbf04f33c389748fbfa800ddf15f2968fb176a2fc54d7e0e11b0574d5f248de781f34d9be97a6c3fdda280d6553e117896fbcbe99a7761e612d8c8c6fbe97692ffcd96f811a316f2581acb2f53bba4ee91a9d7d53cb55e7d7be813c720bacee7d830000000000000020ba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002e9a6015cc78d18e1a5ae26e3e5a0f0d48515bf41456defca199aea7180a51c2a0000000000000001b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbfba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002296b3aad27fac33e10e7ed97600974677b978427c6498a71a233c94dbaf82e193a9f0919c2fadcf3fab070ad055559a85b3917a112684c3f5c0713d68f3d01742c64d884d9a7bc382763e680c363ff7043b02013a88ea49afdc90ce1b69434ad0514c52ca6c1ecb91d9e4e70f2924007afb4881ea4576f793d15b3daca2b86207b7ef8c0db333f1f7dee538f6a73dc8600000000000000030000000000000003e8b721b9931c329cbdccd900ddfdfaa4e284af7b36cbf1b798679342c676c12dbfba904f051ef2469b33466aec694d3475e2c2a0f982b36ab29016cdbebc57221a0000000000000002

-- End DBC --

[dask]

@danda

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.

!!! *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.

[bones]

It does, but will it happen?
Wouldn’t they need to be money transmitters and follow kyc etc?
In some jurisdictions I’d say most likely yes.

I doubt this will happen unless we get some major changes in regs.

[intrz]

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?

What is the SignatureSharesMap for?

MintTransaction + SecretKeyShares = SignatureSharesMap

then for reissue
MintTransaction + SignatureSharesMap = MintRequest

Why not this for reissue?
MintTransaction + SecretKeyShares = MintRequest

[dirvine]

@intrz

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?

Yes that’s right.

I am looking to naming here too (as we all are). I think we need validate_dbc, spent->bool and validate_transaction to make this more clear.

For the last part of the question I am not sure, @danda knows more of the impl there.

[danda]

@intrz

What is the SignatureSharesMap for?

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:

struct SignatureSharesMap(HashMap<Hash, HashMap<usize, SignatureShare>>)

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.

[JimCollinson]

To early to tell I think, but it wouldn’t surprise me.

Yet I can buy and Amazon gift card, or an Apple App Store voucher at the local store.

[bones]

But they’re not crypto regulated , hell of a difference, time will tell.