Three to seven weeks.
6 Likes
For example, if:
0.001 safe = 1 (10^0) millisafe
0.01 safe = 1 centisafe, i.e., 10 (10^1) millisafes
0.1 safe = 1 decasafe, i.e., 10 centisafes or 100 (10^2) millisafes
1 safe = 10 decasafes, i.e., 100 centisafes or 1000 (10^3) millisafes
Then:
0.5 safe = 5 decasafes or 50 centisafes or 500 millisafes or 4 decasafes + 10 centisafes or, etc.
0.504 safe = 5 decasafes + 4 millisafes or 50 centisafes + 4 millisafes or 504 millisafes or, etc.
0.052 safe = 5 centisafes + 2 millisafes or 52 millisafes or 4 centisafes + 12 millisafes or, etc.
You could do something like this to a very large divisibility. So divisibility isn’t an issue. The issue seems to become the large number of possible combinations of denominations that can result in correct change and consistent/efficient denomination combination choice thereof.
6 Likes
Thanks, but I’m not sure what issue you’re addressing. Are you showing how different amounts can be composited?
My question is about the smallest denomination and it becoming too large for the smallest kind of transfer people might want to make through deflation (lost tokens), reductions in the price of goods over time, or new applications where ever smaller transfers might be desirable (such as IoT).
We can make estimates for how likely it is to be a problem, but in time there’s always the possibility of an IPv4 address style problem. So I want to understand if this might be an issue, and how we might respond to it if it does.
2 Likes
Great idea, So does each client in the section monitor each transaction?
1 Like
They don’t monitor any transactions, but they could look at the spentbook, but it’s a lot of work for them. As senders and receivers will speak, they will see those transactions but not be told of others. We may have mints publish logs, but unclear yet. Logs would be to audit supply and no more though as commitments hide values and forced single use (unlikable) keys break ownership chains.
We also have blind sigs and perhaps another ZK algo to check out, so a lot happening here and all great.
9 Likes
Great job, I think you’ve removed consensus, or order, from asset transfers. I can understand this is a very big achievement. Thank for @dirvine
9 Likes
The matter of fixed denominations is a deeper topic than one might expect and I’ve been exploring it (with code) all week. I think it will be best to address the topic more deeply in a forthcoming (maybe next week?) update.
So for now I will just say that we are absolutely considering divisibility, how best to choose denomination units and how they affect number of Dbc outputs, and also what is the 1.0 unit? hint: we’re not making an arbitrary choice where to put the decimal the way “satoshi” did.
14 Likes
But if the clients manages only the spendbook, how do the Elders in this section know if every transaction of clients is double-spending or not?
1 Like
Just a guess, but If spend-book is public, then you check to see if what you are being paid was already spent before accepting the transaction … public spend-book means everyone can detect a potential double spend.
5 Likes
What’s the issue? Past forum discussions considered 128bit divisibility of the total supply to be the minimum number to handle those concerns (like ipv6 rationale). This is roughly the same as a 1E-30 minimum denomination value.
If you use 1 byte for the denomination then you have approx 255 denominations. Max of nine for >= 1.0 and approx 245 for smaller (0.1, 0.01, 0.001)
And if that is not enough a new version uses 2 bytes and approx 65K. So use bit 7 to say this is a 2 byte so 1 byte allows upto 127 denominations and 2 bytes approx 32K denominations.
The number of denominations does not seem to the issue but rather the implementation and extra code/storage to store something like 1.1232356456457474523 One value pair for each of those denominations.
What was suggested before is that they can be combined and split so there is not the issue of running out of a particular denomination. Just split a larger one or if possible combine smaller ones into the larger one.
3 Likes
I like that.
This doesn’t seem like much of a problem for a wallet app. Each wallet could have 256 slots to organize the incoming and outgoing dbc, then just sum up the slot totals and display a balance…
The wallet app could also do the organizing for you to make change and reissue dbcs to higher or lower denominations for groups of 10 dbc. Seems pretty elegant imo.
1 Like
Still extra coding, even if easy enough.
I’d think it would be stored as value pairs. So 1.001 would be stored as two value pairs. 1 x “1.0” and 1 x “0.001”
With the ease of joining/splitting the value pairs could be held as two single byte values. Allowing up to 255 of each denomination and only using the denominations needed. Normal operations only need 0-9 of any denomination and use joining if over 9 of any one denomination. But by allowing up to 255 in any denomination then there is a lot of flexibility saving joining in nigh on all cases for the transaction
I understand your query better. Thanks for clarifying. So you know that with denominations, you can reach the same divisibility levels as with accounts. But are you saying that with accounts, if such a point were to be reached in the future (where the smallest unit is too large in value) that the account system could more easily be updated to further split the smallest unit?
If that’s the case, additional smaller denominations could similarly be added in the denomination system. Both systems would have the problem you’re describing and address it similarly.
2 Likes
The DBC stuff is incredible, it’s a joy to follow such groundbreaking work.
The larger picture in terms of engineering and design here is fascinating too though - reading this very clear statement of the way of looking at things now, I couldn’t help thinking back on the evolution of that over the years.
The post-parsec design comes across in the language used to describe it as natural, resilient and robust? I wonder if I’m reading that correctly, and how it feels to be engineering with that mindset. Certainly looks fun (and probably very challenging).
7 Likes
Missed, this. The SpentBook is public data, almost like a key revocation packet on the network. That packet contains the transaction. So the mints check the XOR network at the address of the key and confirm the transaction is what they have been asked to sign. IF so then we are all good.
8 Likes
Yes you are indeed. This was the original thinking too but it’s actually very deeply different from normal Engineering and this is where myself and some of the team suffered as some traditional Engineering creeped in and parsec actually amplified that to be the only way to think. I am delighted we are back to our roots. It’s so much more interesting with a lot more simple code. Fascinating
18 Likes
Thx for the update Maidsafe devs.
To be real honest, the current testnet denominations works pretty fine for our SNapp. The smallest denomination already has a usable value, so we won’t distract users with…
It would be fun to see if the denominations of blockchain assets will be maintained, even 18 decimal values can be usefull.
Really love the constant forward moving progress of code and ideas, keep hacking super ants. 
9 Likes
Yeah, I was thinking the same. A lot of flexibility there.
1 Like
We don’t need to define denominations at the network level. This is just a matter of client side UI and no digital payment systems are internally based on denominations (either fiat or crypto).
For simplicity the network should only use a base unit which is the smallest unit which has value 1 (like Satoshi for Bitcoin network).
If I own a DBC with 253478000000000000000000000000 base units (number of 0s is arbitrary) and I want to pay 235000000000000000000000000 base units, then my wallet program will just split the DBC in 2:
- one DBC with this value for the merchant
- and the other DBC with 253243000000000000000000000000 base units as change for myself.
There is no need to use predefine denominations and pay the amount with 10 “notes”:
- 2 * 100000000000000000000000000
- 3 * 10000000000000000000000000
- 5 * 1000000000000000000000000
We don’t even know the number of 0s that will be commonly used and this number will probably change over time.
The wallet can dim the 0s on the right, or display the count of 0s (like 1024), or use standard large prefix like yotta, zetta, exa, peta, …, or nicknames that will naturally arise. But this is not the network problem.
Of course, at launch, Maidsafe will have to define a high level value which corresponds to number of base units exchangeable for one Maid, but this isn’t a denomination.
I don’t understand. Do you mean the base unit is not fixed and can vary over time?
Then how would all nodes and clients agree technically on such a change network wide? How would users agree on the principle of such a change? They might feel robbed, either after or before they convert from Maids, or other currencies.
2 Likes