Starting this thread due to @danda’s request to keep the original thread to links and resources regarding the issue of fungibility.
So here we can discuss without watering down useful sources of information.
2 Likes
I’m not super fond of blockchains for a fungible currency solution. I’m not entirely aware of all the meta data in a transaction but by default your IP address, unique amount, transaction ID, date/time/block, sending and receiving address, the possibility to link to your other spending behavior and possibly your real world identity. Chainalysis is already disturbing IMO and it probably won’t get any better.
I do like the idea of the health of a monetary network being able to be viewed transparently, or governments having to only use transparent forms of transacting but the latter is a pipe dream. I almost feel as if society is walking into the bitcoin trap. The fact it is “hard money” with a set supply and not at the whimsy of modern monetary policy is very nice but without going above and beyond to gain some level of privacy on most blockchain networks, I find them falling short.
There are obviously some good alternatives out there to make privacy minded blockchains more, well private but it seems like a car being pushed by a horse.
Zk snarks are apparently quite computationally expensive compared to what is being done with the SN DBC implementation. DBCs on their own are very interesting but not compelling in their traditional form. Nothing is private and the mint being centralized and to be trusted.
What is happening here that @danda, @oetyng, Rusu, and @mav have been contributing to is absolute genius.
I think one of the most interesting bits is the obscurity provided by denominations. Totally unique in the cryptocurrency space, useful, and familiar to the general public.
No meta data, denominations, no public historical record of your transaction so perfectly fungible but yet you could still prove you sent or received a payment, half offline capability. There is probably something I’m missing but side by side comparison to bitcoin is apples and oranges.
SN DBCs are a cypherpunks wet dream.
10 Likes
I do wonder if denominations will help. Like giving 5 x 0.01 SNT DBC and giving a 3 x 0.001 DBC and giving a 8 x 0.0001 DBC in order to pay 0.0538 SNT
This way tracing movements by the value becomes like trying to trace by how many dollar notes/coins are in use and so on. So it adds yet another layer of being like actual cash (or objects of value)
Also trying to trace when DBCs are split since its just a denomination. Like receiving the 0.0538SNT then wanting to spend say 0.02 means splitting the 5 x 0.01 into 2 DBCs (3 & 2 x 0.01). Not really meaningful if trying to trace things. Also when combining/splitting in order to get different denominations is not that meaningful.
4 Likes
Yes, this is a worry. For years I kept hoping that bitcoin would integrate better privacy, but it is really difficult to do right. And there is also a strong argument to be made that once people have invested in a cryptocurrency with a given set of rules, it is actually unethical to change those rules, even if a majority agree to do so. Else you get tyranny of the majority. That’s an issue that SN will have to deal with later on, after launch. Another argument against consensus change is that the market values stability and predictability. In a sense, the more “boring” and unchanging a cryptocurrency is, the more potentially useful that makes it as a money. Because it is dependable and one can be secure in eg writing 10 year contracts payable in that currency. So for these reasons, I think it is best for bitcoin to ossify, as tcp/ip has, and innovation can and should take place in its competitors.
But yes, that does mean btc has potential to become a fungibility and privacy trap for society.
My hope as always been that a better privacy coin will come along to replace or at least complement it. To me, the killer app for a cryptocurrency is money. It doesn’t need to have a scripting language for smart contracts or “silly” nfts. It just needs to have the well known properties of a sound money. Durability, Fungibility, Divisibility, Scarcity, etc, etc. The hardest ones for a digital currency are scalability (efficiency), censorship resistance, and fungibility. Nothing has really nailed the monetary use case yet. So sn_dbc is aiming at those properties first and foremost.
Yes, we’ve made some advancements with regards to denominations and have come up with, I think, an interesting and novel setup that also enables extreme divisibility and even disincentivizes dust transactions. I intend to make a community writeup about it soon™.
15 Likes
Really hard to trace on SN I guess … no wallets (at least not like with blockchains) … so have to track accounts, but if you can just create a new one and move your funds from old to new ?? Seems like no way to permanently blacklist SNT. Or am I missing something. I’m guessing your account itself could only be discovered if you trade with a honeypot that then put’s it on a list. Not sure though.
3 Likes
If there is, we failed. 
12 Likes
Haha, always get a crack out that. Looking forward to the write up!
6 Likes
the dbc’s themselves have an owner, but with blind sigs it is never known who sent to the owner. And the owner should always be a one-time key.
Having an owner eliminates the need for recipient to immediately re-issue upon receipt, as is necessary with ownerless dbcs.
So there isn’t precisely a concept of a DBC account at the “digital cash” layer we are building now. Though it might get introduced in a higher level payments layer, for actually storing received DBCs.
10 Likes
So then, it seems like the combination of difficulty searching forward in the tree would be one primary impediment to tracing them.
Thinking about attempts to trace, If one somehow knew the owner-onetimekey of a DBC you could monitor the spendbook to see when it gets spent and sort of do a rough timing attack that way, but you wouldn’t know how to look up the spending transaction, which could also be a split/combine obfuscating the denominations. If you had a compromised elder, you could observe the resigning and start building a spend graph, but you would need one such elder in all sections at all times to get complete visibility.
How possible would it be to take a final transaction of interest (say SNT to a KYC exchange), and work backwards from the DBC to the previous DBC? Are the dbc hashes that were spent recorded in the DBC and/or recoverable from say a spend query?
The last thing that, say Monero, does really well is obscure the IP of all transaction originations via Dandelion… I know that the original design for SAFE was via hops, but there was some indication that this is removed for direct connections IIRC. I guess then that some TOR based or something connection might be essential to maintain this aspect of privacy?
It will be funny to see how this works out, because our SNapp incentivizes dust transactions. Dust transactions makes no sense on most blockchains, but imho does on the SAFE Network where tx’s are free. Satoshi’s could replace game points, for some devs in the future and serve as a token distribution mechanism.
Luckily for us the SAFE Network, will just provide services to whoever holds money. 
3 Likes
Curious about this too. Our dust is at work very very small? Or unobscuring level of denomination?
I would imagine for how small storage costs should be etc that micro transactions will be feasible without negatively affecting denominations main purpose.
1 Like
Above I am using “dust” amount in a relative sense only. There is no fixed dust limit in the sense that bitcoin has.
So if you are exchanging with others using similarly sized (very small) amounts, no prob. But if you are trying to use amounts that are eg 10^15 smaller than your trading partners, you would not have those denoms on hand because practically nobody uses them. You would have to make a series of reissues to even obtain them. They could then be “spent”, but only with similarly small denoms, not with any that are 10^9 larger. So you can never send a tiny dust amount with a larger normal amount.
Interestingly, this dust limit (or nearness limit) was an accidental side-effect of our approach to minimize the number of required change outputs.
I don’t want to go into it any deeper here, as the denominations subject is more complex than one might first expect. The writeup will make things clearer.
6 Likes
The way we are looking at things now, the spentbook is public and the MintNodes do not have a privileged view of the data. In other words, what mintnodes can see, everyone can see. The key is to avoid having any links such that anyone can build a graph.
Presently, with blind sigs approach there remains a vector for dust attacks to cause an owner key to be reissued to (as a blinded output) more than once. But unless the owner actually receives the “physical” dbc from the attacker and subsequently spends it, the dust input would never appear in the spentbook. Anyway, it is a todo to see if we can make owner keys guaranteed one-time, which would end this attack.
With blind sigs, there is no direct link, not even for single input, single output reissues. That’s the beauty. The only thing one can do is look at the amounts transacted. So the questions then become:
- Are the denominations unique somehow?
- Can we use timing information?
Let’s look at (2) first. The spentbook is not recording any time information. Presently, there is not even an ordering or hash chain. It is as if every dbc was spent at the same time. We might have to implement ordering (but not timestamps) to make auditing work. Likewise, there isn’t presently even a way to iterate over the spentbook. But again, we will need it for auditing, so let’s say it exists. So an attacker could conceivably iterate the spentbook regularly to create snapshots correlated with time, eg every hour or day. So we can say that timing information is obtainable, in theory.
But still, the attacker must look at the denominations used. If the attacker has 1 hour snapshots and 10000 of the same denomination was spent during that 1 hour, then the anonymity set for that DBC is 1 amongst 10000 exactly alike.
Denomination usage will tend to have a bell curve distribution. If one is using very large or very small denoms, those will tend to stand out more, and that is where an analyst could have more hope to link tx together. Wallet software should of course be aware of that, and attempt to use common denoms only, eg by reissuing large received denoms into smaller ones.
6 Likes
Great answer, thanks. It is indeed really damn promising.
1 Like
I should note that an alternative would be to provide no mechanism to iterate over the (distributed) spentbook. In which case, it becomes difficult or maybe impossible for anyone to have a full copy. Which foils all such analysis.
The downside is that it also foils auditing, so no one can verify that a mint section has not cheated. Such a money should not be trusted.
Another (minor?) downside is that it again creates an asymmetry between what MintNodes can see (all input DBCs passing through their section) vs what the public can see (DBC(s) which an individual sent or received). This could become saleable data in the future, etc.
2 Likes
This was the scenario I had in my head until your comment. I agree that auditability is too important to pass up, particularly for a network like this.
3 Likes
Changing mint nodes more often would help in this area, but is that even a reasonable possibility.
The obvious solution to auditability, but adds to work a little. Have a one way object where the object can be written to by the client and only “audit” (elders?) nodes can read. Maybe also limited to their section too, so a bad elder cannot scan the network. So either the spend book is of that type or the client writes a second record into the write-only type. Are addresses still made up of XOR address and 64 bit ?type? field.
EDIT: That was a little muddled paragraph above - sorry
So this second store could be a balance book, a second hash of the spend book address+another value as the address. The in & out amounts signed. So the spend book is not able to be iterated over but this one is. (written by client too and signed by mint)
If the amount is the actual amount for the DBC and only a simply hash of the spend book address then we are back to the problem albeit a little more work
So
- randomly split the amount into say 2 or 3 values that add up to the original.
- before hashing the spend book address we append the random split factor (say 64 bits in the random split fraction)
This way the audit book address is not reversible without trying on average 63 bits worth of split values.
But by iterating over the audit book you can see what you need.
2 Likes
@danda How would this auditing be done anyhow since there is no time factor?
After a while you certainly cannot be iterating over the whole since that would take too long and too much wasted network resources. To keep a list of addresses already checked also has similar issues but quicker.
It seems to me that auditing by checking/iterating the spend book is really not feasible for a network that has been running for a while, thousands of billions of transactions, increasing by huge amounts every day seems an impossible task with foreseeable technology.
3 Likes
It may be possible to create a “snapshot” of only the latest spent entries. or even the latest (blinded) outputs. Sort of equivalent to the utxo set in bitcoin.
Then we can check that: sum(all latest spent) == genesis_dbc.amount. If not, some cheating has occurred. If these are all that can be iterated/checked, it has the nice property that older reissue form a single large anonymity set, per denomination.
We haven’t really sat down and tackled auditing just yet. So far just having some preliminary/side discussions like this.
7 Likes