Update 21 October, 2021

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.

11 Likes

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

8 Likes

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

  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. :wink: 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.

2 Likes

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

5 Likes

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)

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

7 Likes

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.

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.

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

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…? :slight_smile: Anyway, it can be made even bigger by changing i8 to an i16.

19 Likes

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.

2 Likes

DBC testnet soon…

4 Likes

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

1 Like

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)

7 Likes

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

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.

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

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.

3 Likes

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

3 Likes

Beauty. 10 chars.

4 Likes

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.

It looks great. Nice work. :+1:

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.

Cool. Very cool.

6 Likes

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

2 Likes

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

2 Likes

acceptable or not would be determined by the market of course. Those could easily be done in two separate reissue if desired. People use USD for large tx regularly and generally do not care about 25 cents when sending 10 million dollars.

Further keep in mind that a reissue is not the same as a payment. A payment is p2p (no mint involvement) and can contain an arbitrary list of DBCs, so those could include DBCs of any size.

Look, everything has tradeoffs. Ideally I would like to have all of: unlinkable transactions, arbitrary hidden amounts, instant settlement, and high efficiency (scalability). This particular solution gives us unlinkability, instant settlement and high efficiency. And the denominations work like cash. I think this is a unique set of attributes that the market might like, but it will have to be proven out of course.

Zero-knowledge proofs (eg PLONK) are another possibility that could provide unlinkability, arbitrary hidden amounts, maybe instant settlement, but the efficiency is (probably) much lower than blind sigs. That might be an avenue to pursue later on.

Also, I should clarify that it has not been at all decided that we use the blind sigs and denominations approach. We are maintaining a hidden-amounts fork and also the blind-sigs fork. We are nearing feature parity in both forks, and then can start some performance testing, which will be informative. Later we might even try some kind of A/B testing with the testnets once DBCs are integrated.

ps, anybody want to start work on a ZK fork of sn_dbc? seriously… it would be awesome to be able to test that out against the other two approaches.

20 Likes

Wallet software could implement that yes. Or one could manually reissue larger “coin” inputs into smaller, or vice-versa. I envision that a wallet would present a list of “bills” or “coins” and one could select one or more of them and then click “reissue” and specify 1 or more output amounts. simple as that.

yes absolutely. If this thing takes off there will doubtless be a ton of documentation available, just as there is with bitcoin and clones today. Anyway, these writeups are a first step at information dissemination, and also anyone is free to look at the code, and the API docs. At the moment we are in an iterative design/code phase and api’s are in flux, so it doesn’t make sense to be writing detailed docs as yet.

6 Likes

These features really stand out even more in the current cryptocurrency environment. Especially denominations which fit the majority of the worlds experience with money and might give a lot of crypto folks a duh moment.

Dealing with the decimals, the valuation of fractions in fiat, the value of Satoshis is such a pain point and an intimidating hurdle for newbies. So far the only avenues that seem reasonably usable to the average joe or jane are the lightning network and coinbase.

It’s always interesting to take a step back and realize that even though there is more adoption, there are still so many people out there that don’t care, are too intimidated by crypto and the terminology (like DeFi, NFTs, Satoshis, etc etc), why they should care about decentralized money because they don’t even understand the current monetary system, or they only want exposure through traditional means like an ETF.

Having a cash like digital currency that is easy to send, receive, and earn is of the utmost importance. I think one simple and relevant message is that, there is a war on cash, cash is king, and SN Token is the king of cash. Not having to worry about fees, complex alphanumeric addresses and multi-factor just to feel secure will also be a huge relief to the layman.

When we get deeper into the fungibility that most won’t understand or relate to, in the future if leverage exchanges or out of jurisdiction exchanges are banned then perhaps so will the bitcoins that come from there to wallets in unsupportive jurisdictions. Virgin bitcoins that are freshly mined may trade at a premium. Chainalysis will grow as an industry to the point where there may end up being just short or worse of the level of control over flagging or blocking accounts as there is today.

I can’t speak to the technical approaches much but when reading it all laid out it is obvious that efficiencies and choices for balancing all of the benefits the world would want out of a currency are being made and that is fantastic for all of us in the end. Proud to be here to even witness this kind of innovation.

22 Likes