Update 21 October, 2021

[happybeing]

I think the question is whether the total can be used in some way to gather information on a sender. Rather than the denominations, which as you say aren’t determined by the recipient.

[danda]

The total (sum) of a reissue is usually a more unique number than the individual inputs/outputs themselves. As such, it could sometimes be linked to a number in a database somewhere, such as an exchange, which records outgoing payments.

However, this is mitigated by a few things:

1. Their is no sending address that can be associated with anything.
2. This reissue stands in isolation. It cannot be linked to a previous or future transaction. This is key.
3. The summed amount may not be totally unique.
4. There are no timestamps anywhere, not even in the spentbook. All spends appear to have occurred at the same time.

edit: note that above I am talking about the properties of DBCs themselves (with a blind sig mint), which are designed to be like cash. Sometimes a proof-of-payment is desired. We are still discussing this, but most likely it will take place within a higher level payments system. Just as with cash, there are the bills themselves, but people also use invoices, contracts, and receipts.

[davidpbrown]

Denomination is a nice simple relatable idea.

@maidsafe

Deep divisibility is a nice property which enables tiny micropayments

What I didn’t get from that was a suggestion of trim, for where there is no relative value.

So, a request to split £100000 three ways might reasonable expect to see 33333.33 each and the dust is pooled to the network.

[happybeing]

Using denominations eliminates this. You have to choose the value rather than expect a fraction to be honoured, just like with fiat currencies: you can’t split a pound three ways.

[danda]

@davidpbrown

So, a request to split £100000 three ways might reasonable expect to see 33333.33 each and the dust is pooled to the network

Any such splitting would be done by a user or their wallet/app. It is up to them how to deal with the extra “penny”. sum(inputs) must always equal sum(outputs). Nothing goes to the network… that would be a fee.

inputs: 
  100000
outputs: 
  3333333*10^-2
  3333333*10^-2
  3333333*10^-2
  1*10^-2

proof:

$ calc "((3333333*10^-2)*3)+1*10^-2"
        100000

Alternatively:

inputs: 
  100000
outputs: 
  33333, 33*10^-2
  33333, 33*10^-2
  33333, 33*10^-2
  1*10^-2

proof:

$ calc "(33333*3)+((33*10^-2)*3)+1*10^-2"
        100000

edit: the output amounts I used above eg 33333 represent logical outputs, ie TransactableAmounts. In reality, 3333333 would itself require 7 coins to represent, because it is 7 digits with no zeros. So the first alternative would have 22 total outputs (7*3+1).

edit: and note also that even the 1*10^-2 output (.01) could be sub-divided over and over again (126 more divisions by 10).

[Blindsite2k]

I have a couple thoughts on this and will probably be editing this comment as I add more later but off I go.

1. If you can’t buy a soda (or whatever) with $1.0000000000000000000000000001 Or however it works then do we have dust collector? That is if the network has a minimum tolerance for the size of your change on a given transaction then is there a way to collect all your change and have it converted to a higher demononation similar to how you would with normal cash? I find one of the most annoying things with cryptocurrencies is I have dozens of wallets with fractions of coins that can’t be sent hither and yon because they’re too small to pay the transaction fees or whatever and are just scattered all about. Hence is there a “dust collector” feature?

2. How will this look on the user’s wallet? Will you just see a 10 digit numerical string (if I got this wrong I appologize between all the descriptions it was kind of confusing), or several of different labeled demononations? Or will one’s wallet balance be displayed as a single numerical balance? How will the denomination system affect the user in practical terms? Which brings me to my next thought.

3. This kind of thing should be worked into some stand alone documentation or into the SAFE Network primer. As it’s very relevent to users looking to use the network. Also list the new denomination vocabulary if the user is at any point going to use it.

4. There seems to be an assumption for very large and very small numbers that they are so big users will never exceed them for practical purposes. That’s what they said about phone area codes and IP addresses not too long ago. Not saying it’s going to happen tomorrow but you might want to make sure such things can be upgraded in the future somehow.

[Future]

We need forced privacy by design, not an optional one.
Look at Monero, they provide a proof of payment mechanism while keeping at the same time the users’ onchain activity private

[JPL]

Started replying but I see @danda is typing away so I’ll let the organ grinder provide the answer rather than the monkey (not sure how well that translates outside the UK)

@Blindsite2k

This kind of thing should be worked into some stand alone documentation or into the SAFE Network primer.

Will certainly be looking to do the latter in the near future

[danda]

@Blindsite2k

then is there a way to collect all your change and have it converted to a higher demononation similar to how you would with normal cash?

yes, you can always reissue compatible amounts into smaller or larger amounts. And you can repeat this to go even smaller or larger. You could also send these between wallets and consolidate into larger in a “final wallet”. Basically, the problem does not exist in the same way it does with bitcoin, et al.

@Blindsite2k

How will this look on the user’s wallet?

tbd I suppose. Wallets could use decimals. But I think we would also encourage use of the SI names. milli, micro, etc. Especially over time as the bulk of transactions shift to the smaller denominations.

@Blindsite2k

This kind of thing should be worked into some stand alone documentation or into the SAFE Network primer

I just created a thread for collecting all these DBC articles. With intent to make something more structured later.

@Blindsite2k

Not saying it’s going to happen tomorrow but you might want to make sure such things can be upgraded in the future somehow

sure, we never want to be short-sighted. But you should realize that this design already supports a range of both large and small numbers that is hugely larger than any other cryptocurrency – larger than I’ve ever heard anyone ask for. It is almost inconceivable that the world economy could ever grow large enough to need such divisibility… perhaps a galactic economy…? Anyway, it can be made even bigger by changing i8 to an i16.

[Nigel]

@dirvine

We have some proof of payment mechanisms that we are going over. That will likely achieve what you want I think?

Was just going to ask if this is verifiable as that would be the main appeal of a proof of payment. Gut tells me obviously yes but am curious how of course.

[steve_smith]

DBC testnet soon…

[nevel]

Default yes, but it would be really nice to have optional some kind of traceability. Everybody happy

[dirvine]

@Nigel

Was just going to ask if this is verifiable

Yes, the existing thought is that it works like this (2 approaches to same thing)

1. Buyer sends Proof request to merchant for X (either state cost or provide SpentBook entry (unsigned))
2. Merchant sends back signed POP for X
3. Buyer makes payment to Merchant (DBC or transaction can be shown to anyone)

So we can see the agreement as it’s signed and the transfer of that amount.

This will not be public, but sender at any time can prove to anyone s/he paid by showing the POP and transaction (or DBC transfers)

[tfa]

@maidsafe

The 10^9 “nearness limit”

I don’t think this limit is acceptable for financial applications because this means transactions like the following ones cannot be done:

• $10 million at the cent precision

• 10 BTC at the Satoshi precision

@maidsafe

there is a tension between optimizing for fungibility and optimizing for efficiency

Another source of tension that complicates things is the range of values: firstly 10^38 and finally 10^256. You impose this constraint to yourself but neither of these ranges is needed in my opinion.

[Blindsite2k]

@danda

yes, you can always reissue compatible amounts into smaller or larger amounts. And you can repeat this to go even smaller or larger. You could also send these between wallets and consolidate into larger in a “final wallet”. Basically, the problem does not exist in the same way it does with bitcoin, et al.

Awesome. My next question is how do you do this? Is there a “Consolidate” and “Reissue” button?

@danda

tbd I suppose. Wallets could use decimals. But I think we would also encourage use of the SI names. milli, micro, etc. Especially over time as the bulk of transactions shift to the smaller denominations.

Fair enough. But if that is the case then having a list of the denominations and perhaps assigning a list of icons that represent them will become more of a priority (documentation and UI). And at some point someone will take a particular interest in the math behind it so as I said clear documentation will be important.

[dirvine]

@Blindsite2k

Awesome. My next question is how do you do this? Is there a “Consolidate” and “Reissue” button?

It’s just a re-issue to you. So a normal transaction to another one of your keys.

[dask]

@dirvine

So we can see the agreement as it’s signed and the transfer of that amount.

This will not be public, but sender at any time can prove to anyone s/he paid by showing the POP and transaction (or DBC transfers)

Beauty. 10 chars.

[jlpell]

@maidsafe

We also came up with short names for each power of ten, based on large number names .

tau → taus
mil → mils

So glad to read soon after that you moved on to SI prefixes. This first naming scheme is something out of Harry Potter… yikes… very hard to grok. The Si functions in the repo look nice. Sticking with SI is very important imo.

@maidsafe

We came up with a simpler, more powerful representation of Denominations.

It looks great. Nice work.

@maidsafe

128 digits of divisibility is huge,

Yeah, you nailed it. That’s the equivalent of 425 bits. No more complaining from me. The use of a single i8 for the exponent is nice imo.

@maidsafe

The nearness limit is a novel concept that should help minimise dust and increase fungibility without requiring any fixed size dust limit.

Cool. Very cool.

[drehb]

@Blindsite2k

My next question is how do you do this? Is there a “Consolidate” and “Reissue” button?

This is an area where different wallets can compete on UX. There won’t ultimately be only one way to interact with the network.

[danda]

@tfa

Another source of tension that complicates things is the range of values: firstly 10^38 and finally 10^256. You impose this constraint to yourself but neither of these ranges is needed in my opinion.

you are welcome to code up an alternative approach and submit a pull request!