Topic: Nxt :: NXTcash - progress and discussion - page 2. (Read 12366 times)

NXTcash is zerocoin added to NXT, but NXTmixer is a totally different approach that doesnt rely on zerocoin at all.

The initial model supports both a mixing service using the gateway and a totally decentralized direct "payment" path. However, since NXT doesnt support multisig the mixing is totally centralized on one of the gateway servers. The decentralized part allows (nearly?) undetectable transmission of NXT acct password (or any other data) directly to the destination acct.

Even though I am adding this functionality to the gateway, it is totally independent of the multisig DOGE gateway and also NXTcash. It just shares a lot of the code base, so it was easiest to add to the existing multigateway code. I am using libnacl http://nacl.cr.yp.to/index.html that xyzzyx recommended.


I added the following to the gateway_AM structure:
Code:
struct payment_bundle
{
    unsigned char escrow_pubkey[crypto_box_PUBLICKEYBYTES];
    unsigned char depositaddr[MAX_NXTADDR_LEN];
    unsigned char paymentacct_key[crypto_box_SECRETKEYBYTES];
    unsigned char txouts[8][MAX_NXTADDR_LEN];
    int64_t amounts[8],sessionid;
};

added to gateway_AM:
        struct
        {
            unsigned char publickey[crypto_box_PUBLICKEYBYTES];
            unsigned char nonce[crypto_box_NONCEBYTES];
            unsigned char paymentkey_by_prevrecv[crypto_box_PUBLICKEYBYTES + crypto_box_SECRETKEYBYTES + crypto_box_ZEROBYTES];
            unsigned char payload_by_escrow[sizeof(struct payment_bundle) + crypto_box_ZEROBYTES];
        };

At the high level there are what I call sessions. Initially, when the activity is low, a session might be as long as a day, but as activity grows, the duration of a session will shrink. It is critical that your transaction isnt the only one in a session, otherwise no amount of anything will help anonymity. If there are 1000 transactions, then with a good system, the best anybody should be able to do is 0.1% accuracy, eg. random guessing.

Each session goes as follows:
A. NXTmixer pays out all the funds that cleared during the last session to the depositaddrs for each NXT addr that received anonymous payment during the session

B. NXTmixer publishes new sessionid and its public key for this session

C. ALL participating nodes publish a SEND_ANONYMOUS_PAYMENTS AM. Yes, I said ALL nodes.

D2. ALL nodes process all of the SEND_ANONYMOUS_PAYMENTS from C and they try to decrypt every paymentkey_by_prevrecv. If they are able to decrypt it (first half matches their previous public key) then they have access to the NXTacct that the password in the rest of the message contains.

D2. NXTmixer also scans all SEND_ANONYMOUS_PAYMENTS from C and processes all payment bundles that properly decrypt. paymentacct_key is for a (temporary) account that is funded with the amount necessary to make all the payments specified in the payment bundle. In order to make sure it wont be emptied and to MIX all the NXT together, the funds required to make all the payments are sent to a shared account. Since NXT is totally fungible, this step is actually VERY effective in removing payment source information.

The NXTmixer updates the credits for each NXTacct during session and when there is enough different payments or max time elapsed, the session ends and we go back to A, where the payments are made.

************
The NXTmixer cannot implement all parts of this by itself, the clients need to implement code that synchronizes all participating nodes. The reason for this is that if everybody is broadcasting, then there is no information leaked when you publish your public key and payment bundle. Since everything is on the same broadcast, anybody can receive the message, but nobody knows if they did or not. This allows a direct transmission of a funded NXT acct to somebody else. Let us assume you will trust them to not drain the account during the next two sessions. Since he is the one paying you, if he does, then whatever deal was in place is off.

userA funds acct A with 10000 NXT
userA encrypts password for acct A using public key of B and it goes into paymentkey_by_prevrecv

userB decrypts the AM and gets the password for acctA and locally verifies that it has 10000 NXT
Now, for the next session, userB sets the paymentacct_key to be the key for acctA and payments can be made from this acctA on behalf of userB, even though userB has NEVER used the password for acctA other than locally to encrypt it into the payment_bundle.

Similarly, you can specify your depositaddr to be an acct that you have never used, but know the password for. Then in later sessions, you can use depositaddr's password as the paymentacct_key. As long as you are receiving payments, you are able to make pretty anonymous payments as I am finding it hard to figure out how anybody can determine payment paths.

I was told that knapsacking can penetrate the anonymity of most mixing, but with my design it is possible to set things up so that both the source and destination accounts are inside the encryption.

James

I was sent a private message asking me to comment on the following posts.


I have several posts about the issues with Zerocoin:

https://bitcointalksearch.org/topic/m.5023887
https://bitcointalksearch.org/topic/m.5128980
https://bitcointalksearch.org/topic/m.5147817
https://bitcointalksearch.org/topic/m.5466558
https://bitcointalksearch.org/topic/m.5474960
https://bitcointalksearch.org/topic/m.5519196
https://bitcointalksearch.org/topic/m.5521333
https://bitcointalksearch.org/topic/m.5539088
https://bitcointalksearch.org/topic/m.5540317
https://bitcointalksearch.org/topic/m.5562422

The key problems that remain with even the latest Zerocoin re-design are:

• Can't be resistant to quantum computing nor mathematical advance (as the NSA did with differential crypto-analysis in the 1970s and 80s and no one knew they were cracking us) and it can't be retroactively hardened. Once you put all your faith in that, you are screwed if such an advance comes. Whereas, with Lamport signatures instead of ECDSA at least our normal transactions in an altcoin will be safe (the detailed reason is explained in one of the above linked posts). If someone redesigns Zerocoin to use only cryptographic hash functions, then this weakness will be fixed. This does not appear to be easy to do, as I haven't yet found any research attempting to do so. All the research I've found on zero-knowledge proofs involves some algebraic trap-door.
• It doesn't obscure your IP address, thus it is useless tsuris without such. And Tor+VPNs is likely compromised by the NSA et al.
• The timing and amounts of inputs and outputs to the mixer can be analyzed and much of the anonymity can be crack with such timing and pattern analysis. This is especially worsened if you change it to allow specific amounts in/out as you propose. The amounts should rather always be the same, e.g. 1 BTC.
• The verification time is very slow, thus it encourages further centralization of mining (which already a critical problem with Bitcoin). This makes it very costly to deal with denial-of-service attacks.
• At least the first iteration (and perhaps the re-designed one linked below) required a trusted party to sign the initial input values to the accumulator (each time the accumulator is reset), which is the antithesis of decentralized currency. This trusted party could steal all the coins.
• This is very complex new crypto and thus the likelihood of someone finding a weakness and cracking it is very high. For example, to prevent double-spends the design requires the solution C to be a prime. That may be (I haven't studied enough yet to form an opinion) a potential number theoretic hole for double-spends.

Zerocoin could be helpful if:

• it can be used with an always-on IP address obscuring mixer that doesn't have the scaling problems of CoinJoin nor the timing analysis (and compromised servers) weakness of Tor+VPNs
• improved to not depend on algebraic trap-door (and only on cryptograhic hashing)
• no trusted party needed to initialize the accumulator
• verification time can be reduced significantly
• the crypto can be simplified so it is more trusted

That is a lot that needs to be accomplished.


You radically reduce the anonymity set, by allowing the amount in/out of the Zerocoin mixer to vary.


That link is not totally broken, as I explained above.


You are getting remarkably close to the correct solution. But you are not quite there yet.

I'm going to think about your post for a little while.


I haven't given it a good look myself, but try NaCL for encryption:
http://nacl.cr.yp.to/

No multisignature support, though.

The requirement to delete all the private files after a spend is certainly a difficult one to enforce. One approach is to have the client software aggressively prompt the user to delete spent coin's private data as soon as it detects that it was spent.

What if there was a way to do a multisig on the private data? Both the gateway and the user would need to use their private keys to decrypt the private data. The user really doesnt care about the private data itself, just that it can be redeemed anonymously. So, what if the client software multisigs the private data with the public keys of the gateway and the user. [is this even possible?]

This encrypted data is then submitted to the gateway along with NXT, the user can keep a copy as a backup. We dont have to worry about spam as this requires payment of NXT

I think all that is needed to redeem is the user's private key (generated just for this batch of NXTcash by client) so this private key can be sent via secure means to whomever you want to pay anonymously.

We have to be careful here as we cannot indicate what batch of NXTcash to to use the private key with. Doing that will certainly create a traceable link. So the gateway would need to do a decryption on all submissions and find the batch of NXTcash that gets decrypted. I think if there is a very small string that is encrypted, this shouldnt take too long.

Redemption can happen by publishing an AM that contains the private key encrypted with gateways public key. The gateway decrypts it, verifies it conforms to standard NXTcash private key and brute force checks all unspent private files. When it finds it, it does the zeroknowledge proof, verifies it is actually unspent, redeems it and deletes the private data after publishing the serial number.

While all this sounds convenient, everything is centralized in the gateway and there doesnt seem to be the need to do all the zerocoin stuff. Why couldnt the gateway just hold funds in escrow, pending receipt of an AM with a decryption key for one of the encrypted items?

In fact, this ties into your original A + B idea. A can broadcast the private key that unlocks a bundle of NXTcash, but he encrypts it using B's public key, so only B can decrypt it. Everyone's client can monitor all NXTcash AM's to see when they receive an encrypted private key.

If we make a NXTcash bundle have multiple outputs, each with a separate private key, it will make correlating senders with receivers much more difficult. I think this is basically what a mixer does, isnt it? It probably makes sense to have this as an option.

Do you know any good C libraries that lets you do encryption and multisig on data that is easy to use?
Too tired now to think all this through, but I have a feeling this would be a great use case for AT

James

You're referring to this, I presume:


I'll have to give this some thought.  It seems reasonable.

Cool. Sort of a brainwallet version of USB drive. As long as acct A cant be correlated with acct B and proper precautions are taken, blockchain space allowing, this might work. Now you just need to remember the password for acct B at Starbucks and fund the acct via wifi on a new laptop. One issue though, the proper protocol is to destroy the private data after it is spent. Cant destroy it if it is in the blockchain. Maybe some sort of distributed cloud storage, but not sure of ones that cant be correlated based on IP usage.

James

Until the market cap for coin2 achieves a certain level of liquidity, it wouldnt be practical. There needs to be a decent number of transactions, otherwise statistically random correlations would be quite effective. For example, if there are only two transactions in a day, 50% chance of correlation. That defeats all the effort in achieving zeroknowledge transfer in the first place

James

can we have Coin2 as a second alt coin to be trialed to this NXTCash please?

Quote from: Mario123 on Today at 05:45:58 PM
Quote from: jl777 on Today at 05:42:29 PM

NXTcash is zerocoin integrated into NXT. We are finalizing the design for a method that will allow us to use the current libzerocoin alpha without any changes to the NXTcore. A person would mint a zerocoin and pay NXT to register it. He will then have private data that can (should) be used on a different computer with different IP to redeem the private data into NXT into a totally different account.

Theoretically, there would not be any way to get more than a statistically random guess as to who funded the NXTcash redemption.

James

Can you describe in a few simple words, how NXTcash works?

edit: Not how to use it. How it works!
You would need to use a NXTcash enhanced client

1. You would start a command that says "mint X amount of NXT to NXTcash"
This generates private and public data, the public data is broadcast onto the blockchain
Now you have private files that contain the value of the NXTcash that you "minted"

2. The client should have a convenient, "copy NXTcash to USB drive" command

Z.

You start a command that says "redeem X amount of NXTcash"
It prompts you for the USB drive with NXTcash on it, here is where it uses the data on the blockchain and the private files to calculate a zeroknowledge proof. Basically heavy duty math algos that can be submitted for verification that you have indeed paid the matching amount of NXT for the NXTcash private files. Once they are validated, you get the NXT and destroy the private data so nobody can link you to the serial number, which gets published on the blockchain as "spent" serial number

Now the NXT that originally was in the first NXT acct has been teleported to the new NXT acct without anyway for anybody to do more than a statistical random guess as to where the NXTcash that funded the new account came from

Without step Z, there is no way to be anonymous. You certainly dont want to redeem the NXTcash from the same computer or same IP address. Maybe somebody who is expert at using Tor via proxy servers can achieve step Z without changing computers or locations, I dont know, I dont have any experience with those sorts of things. I believe that we have a right to privacy. What we do with our money is our business and NXTcash allows us to do this, which is something no other crypto or any fiat method other than cash itself can do. Actually fiat cash has serial numbers and those can be traced. The NXTcash has serial numbers too, but it is only revealed AFTER it is spent. Nobody knows who minted the specific serial number.

With step Z, the link is totally broken between the source of the NXT and the destination account. So, you could mail the USB drive to somebody you trust and they could do the redemption and other than people that know who you are mailing things to, nobody would know that you sent money.

James

Not that messy, but it also requires an additional handshake step.

User -> gateway -> NXT core -> credit user with real NXT

vs.

User -> gateway credit user with NXTcash asset. asset -> NXT core -> credit real NXT

Fewer steps for there to be problems with network.

James

Thanks BitJohn!

Sent 2,000 from 12348614373637738998.

Best of luck with this exciting project! Good luck!

chinajsntwzq

Noob proof is better. But every code snippet in nxt core must be bullet proof. That's always the ultimate goal. How messy would it get in the nxt core for the no-asset solution?

If no drawback for the user then go for asset but I already see a disadvantage, it is hard for some people to understand the concept of asset (compared to currency). I they don't understand it, they won't use it.

I say this because few people saw me asking questions on this thread and then PMed me to ask what's an asset.

The more noob-proof the better.

less changes to NXT core

What is the advantage of NXTcash-asset instead of funding the new account directly ?

I have made an internal proposal to the NXTcash team using the latest source code that will allow us to make a release that can be considered for mainnet use. Not sure how long it will take as I will need to start and finish Nodecoin 2.0 to fully implement the proposed NXTcash solution, not to mention a fair amount of work in the client code.

Before you say, "but we can't store the giant zeroknowledge proofs in the NXT blockchain!", let me say that the method I am proposing does not need to store the big proof in the blockchain, just the NXTcash minting and spending events. Still working out all the kinks, but I am optimistic.


Show your support for NXTcash, donate to completion bounty fund 13313092584524529006


The way I see this working is that from the client you can directly mint new NXTcash, in increments of 100NXT. This will create private files that are encrypted and stored on your computer (and USB backup). Now the files on your USB are just like cash. You can then go to any other computer and launch the NXTcash spending app. You tell it what NXT acct (different one) to fund with the private files on USB.

At this point, we can go in two possible ways, one way is to have the new NXT acct funded with NXT, or it could be NXTcash asset. We are assessing the tradeoffs between the two approaches, but either way, funds have gone from the initial acct to the new account, without any identifiable information being leaked!

What you do with your NXTcash is your business. Anything you do from the alter-ego acct is all publicly viewable, but the key is that nobody can identify who is controlling that new account.

James

Woo

Cryptsy NXT integration almost complete.