I have been invited to post here about stuff,maybe it is applicable directly to inf-com maybe not.
For those not up to date on NXTmixer (not to be confused with NXTcash)
https://bitcointalk.org/index.php?topic=470987.msg5581086#msg5581086 is the start of a discussion with anonymint. He is understandably assuming NXTmixer was zerocoin integrated into NXT, that is NXTcash.
With the original NXTmixer proposal
https://bitcointalk.org/index.php?topic=470987.msg5581929#msg5581929 was where anonymint left off. I have continued to improve the NXTmixer design and I dont think anonymint was fully understanding my initial proposal. Still he was surprisingly optimistic about my proposal, especially considering his usual treatment of any anonymity system.
"Accidentally" (the subconscious has a funny way of doing what is needed) the output of step Z for NXTcash is an account where you effectively teleport NXT into a totally unconnected account. However, each time you use it, you need to be careful not to link this acct with your normal acct. useful for large onetime transactions, but not practical for everyday use.
NXTmixer has two parts. One is totally decentralized encryption path between all nodes to all other nodes. Payment can be sent simply by funding a throwaway acct and encrypting that acct's passphrase with the destination's onetime public key. While this is good from a decentralization standpoint, it is a lot more susceptible to knapsack analysis to correlate payment paths. Even though analysis might be able to deduce that acctA sent funds to acctB, NXTmixer's design does not divulge who is controlling those accts. If acctA and acctB are onetime throwaway accts, knowing a payment was sent isnt really useful to somebody trying to figure out who is paying whom. Remember that after receiving funds in a shadow acct, you can immediately (next session) send it to the mixer to remove any traces of source and fund another throwaway acct to store the deposit.
Using a centralized mixer for NXT makes it almost a perfect process as there are no txouts that leave trails forever into the past. If everybody sent 100NXT to a mixer acct and a bunch of 100NXT payments come out, there is no more than a statistical correlation that is possible. To deal with the centralization weakness I have improved the design to randomly select from 100+ servers to be the designated mixer for that period. If we can have a lot more periods per day, we can further reduce the centralization problem by splitting up the payments into smaller pieces. At some point the risk due to centralization is worth the benefit gained.
"Accidentally" nodecoin is sent to a large number of nodes all at the same time and all in pretty much the same amounts. The current infrastructure cant possibly handle 20,000 AM broadcasts per minute, maybe 20,000 per hour would even be a problem. However, a dedicated set of guardian servers would be able to handle this without much problems.
nodeminer reports the 20 active peers of each NXT node to a pool server. assuming enough nodes are participating this allows the pool server to recreate the exact topology of the NXT network, every block! This was an unexpected bonus and I havent figured out all the implications. Currently the pool server simply tallies up the number of times each node is an active peer and allocates nodecoins based on that. However, it would be possible to create a NXT connections graph and publish that in realtime. The changes are not going to happen very quickly, so there could be full snapshots and incrementals from recent snapshots.
What good is this? Well,for one, it should be possible to detect attack attempts or just generally misbehaving nodes. It could also allow for a much more robust implementation of high TPS processing by identifying the ideal receiving node based on exact topology. No single node would have to be the target of all the blocks transactions. All this is pretty complicated and I am not sure of what specific benefit this has, I just know that for any attempt of dynamically adapting network topology, we need to have this data. nodecoin provides this.
Back to NXTmixer. How does it work?
At the high level, we operate in a series of sessions. Each session is started by that sessions NXTmixing server publishing is public key. immediately after this, ALL nodes broadcast their public key and a set of mixer transactions and a point to point payment, encrypted to the NXTmixer.
Even if a node does not have any transactions, it still sends out the broadcast packet. This eliminates all time based attacks as all the nodes look the same! The point of each node having a public key for each session is that any other node can send it a point to point payment. All the nodes have to decrypt all the broadcast packets as that is the only way to know if a payment was received. I have not done timing tests, but any modern computer should be able to keep up with this as long as sessions arent once per minute.
now the mixer payment packet is where things get really interesting. Keep in mind that it is encrypted so only the designated NXTmixer server can decrypt it. Inside each packet is the designated payment acct and deposit acct.I call these the shadow acct. Any payments are cleared through a common NXT acct thus totally mixing source and all the cleared payments are sent by the mixing server at the end of the session.
By designating an acct to be a deposit acct one session and then the payment acct the next session, it is possible to receive and make payments from an account that you never even access at all. you never even publish the acct in plaintext. By specifying a NXTcash funded acct to be the payment acct, you can do the time consuming step Z once and then after that utilize those funds from your normal acct without any connection to it.
Back to nodecoin.
The problem with NXTmixer is the sheer number of transactions. Each session there would be one AM from every participating acct. This makes it cost prohibitive. Anonymity is nice,but few will pay thousands of NXT per month to have access to this. Now, what if we utilize the NXT topology we have from the nodeminer submissions? We would be able to propagate parallel broadcasts of all nodes to all other nodes with the most efficient path. We wont care about hiding which nodes we are communicating with, as everyone is talking to everyone. Unlike Tor usage which invariably raises red flags, everything with NXTmixer is on public internet. However everybody looks the same, so no information is transmitted.
The source of funds and destination of funds are only revealed inside the encryption. However, each client can monitor the blockchain to verify that payment was taken from their payment acct. This systems works so well that the sender wont know if the funds were received by the destination as the destination acct is unknown. To establish transparency on this, the destination would need to presend the deposit address to the sender. This does leak some information, but if a throwaway acct is used, then the next session, the destination acct can send a payment to itself from the throwaway deposit acct to the main shadow acct. Alternatively, there could be a convention that all deposits received would be acknowledged in one of the encrypted broadcast packets. This would then allow for fully automated minimal trust methods of splitting a payment into small pieces and sending through the mixer, waiting for destination to acknowledge before sending the next piece.
If the time per session is fast enough, this will work pretty seamlessly, though for a 1 million NXT payment you would have to be patient. The trust required is minimized to the size of the pieces the transaction is broken up into. By having servers in the guardian rotation across continents and organizations, it should provide the robustness required for use by a fully decentralized network
In order to maintain full anonymity, the client will have to enforce best practices so that the user does not make a mistake. The services of NXTmixer should be viewed as low level services only meant to be used by client software that understands the issues and manages all the shadow accts, payment streams, etc.
Anyway, these designs for all the different things I am working on are always percolating in my mind and until the code comes out I am not totally sure of all the details. Even after the first version, still many iterations to evolve to a final implementation. I have found this method to be particularly effective when solving "impossible" problems as it is not possible for me to see ahead of time exactly what is needed. I left out the multisig gateway in this discussion, but I do have some ideas on mixing non-NXT deposits, though people will probably say that will destroy NXT
Feedback is welcome. Also if anybody is brave enough to whitepaper'ize this, that would probably be a very useful thing. I am using Daniel Bernstein's
http://nacl.cr.yp.to/index.html encryption library for public/private key,but the design is independent of specific public/private key implementation
James
