To make sure these ideas don't get lost on reddit here's a copy of a post created by https://www.reddit.com/user/M00N_R1D3R/ that was titled "Adding privacy to Nano.":
I am currently reading through various Monero whitepapers and trying to understand if it can be applied to the DAG cryptocurrency, like Nano. It seems to me that the answer is "mostly yes". I would like to ask the community a few questions:
(1) As far as I understand, no such major changes are planned in the main protocol (which is great, because Nano is supposed to be lightweight, and this thing would definitely be a bit slower). Is the community OK with the fork? If I would want to peg the private version of Nano to the original 1:1, is it possible to make a gate operating via consensus of original Nano nodes (it would require a small change to the protocol, but less drastic and would not slow down the original network)? //such "gates" could be used for various L2 solutions for Nano, playgrounds adding new possible functionality?
(2) Do you think it is could be a good addition to the Nano ecosystem?
I could sketch the idea of implementation, if any1 is interested.
More info here:
Well, Monero's technology translates to Nano's DAG almost seemlessly.
(1) If you want to mask the balances and transaction amounts, the solution (keeping balances masked in the form private_maskG + balanceH in ed25519 group) already works. The separation of SEND and RECEIVE transactions can be kept intact, along with the core idea that only balance owner can change the balance via signature. The one-time mask of the transaction needs to be published globally in the ledger encoded with receiver's public key, and can be pruned after the transaction is received.
(2) ORV voting it seems can be made anonymous via multilayered ring signatures ( https://eprint.iacr.org/2015/1098.pdf ). Changing representatives would not spoil the balance to the network.
(3) In case one wants to implement anonymous senders, there is a bit of an issue - Monero solves this by sending transaction from "multiple senders", and that would require the fake senders to be online (because of Nano's core idea that only you can change your own balance). Multiple receiveres is also bad if the fake receivers will not take SEND for a long time. I am not sure what is a great workaround, but good one would be requiring any account wanting to participate in this system to submit a small number of "fake transactions" (0-valued transactions) to other addresses in this system, weighted statistically by the activity of the accounts, it would significantly obfuscate the sender and receiver.
Take this with a grain of salt: I'm not a programmer, just a mathematician. There might be some scalability issue or something that I'm just blatantly not seeing.
and here:
Well, the protocol would need the following change: there is a special address which keeps Nano "locked". It can not spend any Nano normally, and transactions from it is sent to the address nano_example in case (parallel blockchain lookup) there is an unmasked transaction from the address xnano_example. Symmetric rule would be made for xnano protocol (and they would use identical address system). It is a very lightweight solution, and such change would also allow adding any amount of features in this "enhanced nano" playground. Moreover, in case developers of this enhanced protocol mess anything up, people would only risk locked nano, not everything.
Basically, one and only one specific smart contract which is the gate to the parallel blockchain.
It is more of a tangential issue to the privacy, I believe it is more of a coherent way of adding features without compromising the efficiency of the mainnet.
Another way would be some kind of multisig, but then funds could be stolen if the securing nodes collaborate, and that kind of sucks.
Because this looks like an interesting addition to the network (with possibilities way beyond optional privacy I figured sparking a discussion here about it could be worth it.
The changes seem to be small enough and problems would be isolated.
But I'm neither programmer nor mathematician 