Update 31 March, 2022

I think most of them will sell maybe 90% of all SNT assets within the first year of release, cash in and put gains in more safer assets. So the SNT coins will be distributed between more addresses, more even, within 1 year after release.

1 Like

Actually what makes it harder is that some hold their MAID in multiple addresses.

And the Exchange Address holds many people’s MAID.

So the distribution though is likely amongst even less people than addresses.


I get what you’re saying, but I might try and add some nuance here, in that lockboxes would be a separate layer/component from DBCs. So the DBC system remains small, lean, and easy(ish) to review/audit, in itself. ie, there is a genesis DBC representing all tokens and tx commitments must add up. That’s it. No proof-of-work, no proof-of-stake, no proof-of-storage complicating the core.


Yes, good to clarify for all readers:
The added complexity I talk about is not in the DBC layer, but in the code that would use it - i.e. the node.


Just spitballin’ here …

What if adults could ‘stake’ their coin for a random chance of spawning some DBC from the lockbox. In return they get 1% from the spawn, with 99% going to farmers.

This further incentivises nodes and would facilitate coin price stability without the ‘dreaded’ proof of work.

1 Like

Can someone please point me at a guide to how DBCs work.

1 Like

There used to be a super guide at an “opaque.link” URL (search here to find it) but unfortunately that domain is no longer working.


Good old Wayback Machine Digital Money and DBCs •


that is a good writeup of “classic” DBCs for background understanding. Our implementation diverges quite a bit. I am keeping a list of writeups here:



Thanks John, I looked for it there but didn’t find it so you’re a better web searcher than me!


yes, I was finally able to reproduce by killing a spentbook node and then attempting to reissue. The communication with that spentbook node times out so the wallet detects the error and cancels the entire spend operation.

However the other 2 spentbooks have marked the input DBC(s) as spent. So when all nodes are running again and the client tries to create a new Tx involving those inputs, two spentbooks say “sorry, no it was already spent”.

Basically then, this is a wallet logic error, or a couple of them:

  1. If supermajority (2/3) of spentbooks agree on the original Tx, then wallet should continue without erroring out.
  2. It should write the Tx to disk before attempting, in case of any error, even a crash, so that it can attempt again later if necessary.

The example wallet code was a “quick hack”, so the error handling is not robust (yet). Still, I will make a fix as the ultimate goal is for others to use this as example code when implementing “real” wallets. And of course we need to prove to ourselves that the system operates robustly.

thx for the report @19eddyjohn75!


I guess in the future the wallets could have the visual option of Safe bills where people could count , stack them , as they place some payment so there won’t be mistakes as the so many cases we have seen happening in the crypto world!

cargo install --path .
error[E0599]: no function or associated item named `from_str` found for struct `proc_macro::Literal` in the current scope
   --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.36/src/wrapper.rs:943:30
943 |         proc_macro::Literal::from_str(repr).map_err(LexError::Compiler)
    |                              ^^^^^^^^ function or associated item not found in `proc_macro::Literal`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `proc-macro2`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `ultraman v0.1.2 (/home/user/Projects/ultraman)`, intermediate artifacts can be found at `/home/user/Projects/ultraman/target`

Caused by:
  build failed


possibly need a rustup update to get the latest versions. I suspect an old rustc


Thank you for the heavy work team MaidSafe! I add the translations in the first post :dragon:

Privacy. Security. Freedom


Hopefully a dumb question, but,

Is there any possibility that a memory corruption / packet corruption / combination of corruptions could lead to a 0 becoming a 1, or a 1 becoming a 2 etc? Like, if I try to send 10 snt to someone, will it generate a DBC that could only be generated by me sending 10 snt, and then will it ask me to confirm I’m sending the amount specified by the DBC (in case I type in 10 but the terminal program’s memory is corrupted or something and it tries to send 20)?

It is impossible or so improbable you can consider it impossible.


peca is right, because one bit change would not be enough. Things are encrypted and signed so lots of bits would have to change in exactly the right way to change the value of a DBC. A single bit change would just invalidate the copy.


Think I’m missing something here. Say I type in 200 in a text entry box, and then a single bit of memory flips, changing the stored text to 600, before this even becomes a DBC, then how would that corruption get caught without a user confirmation?

And sure, memory corruption like that is rare now, but in the future when we have more people using personal computers in high radiation environments, and when the design of computers changes so that memory corruption is common and expected to be handled by fault-tolerant networks rather than by expending money on more robust hardware and compilers, it should a more pressing concern.

Just asking as I don’t understand DBCs well enough to tell if it’s possible to insert a confirmatory user prompt after the DBC has been created.


That’ll be something for the User interface.

Like online banking, any payment or transfer will confirm the payment before it is done. The user interface can have created the DBC and confirmation will issue it. Thus the amount is locked in before its confirmed. If not confirmed then its scraped.

Another protection could be that the creation of the DBC is done again on confirmation and if the orig is different to the confirmation created one then its reported to the user as a error of some sort and another confirmation has to be done in the really rare case something went wrong.

EDIT: Once the DBC is made then as @happybeing any minor bit flips will cause the DBC to be invalid because it cannot be decoded.