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

Building the foundation while waiting for some external developments that will really help this project, like the new zerocash and Parallel Chains

discussion has been moved to: https://nxtforum.org/multigateway-(third-party)/nxtcash-and-nxtmixer/

James

Any progress yet?

Never used coin mixers, but I suppose they will take some fees? So if you'll send them 24.79, you'll get back less. I can't imagine someone will run such service, that can be heavily used by criminals, for free or I don't understand something?

PS: As for this project, development of decentralized anonymous transactions seems legit enterprise for me, but I can be wrong of course

800 nxt sent
Transaction id: 11665090002745715591

good luck!

guys- just do start something  - can be moved elsewhere later.

testCase2 - sending 10 BID orders with time delay of 10ms to NRS - result: ONE BID order on the order book, 10 identical requests sent.

so sending ten identical BID order queries is processed as one only by NRS



########### balances before start:
bal: 1698833
unconfBal: 1617955
effBal: 1698800




emitter - nxtUCTest2 here

timestamp - 1394895608.0248673

queryNum - 9

fullQuery - {'asset': '16739598998421896224', 'deadline': 180, 'secretPhrase': 'xxxxxxxxxxxxxxxx', 'price': 100, 'fee': 1, 'requestType': 'placeBidOrder', 'quantity': 1}

########### NRS Reply:

transaction = 4525878627944622113
 balances during testt:

( repeat 9x)

Do you need testers/developers?

The acct which receives payment is never revealed in the clear. Neither are the accts that send the payments.

The initial condition where nobody has any funds is tricky and still a bit unsolved, but at worst a bunch of people send to the mixer the same amount and it funds each persons shadow acct.

From then on, payments are encrypted, the destination is not correlated with the normal acct of the recipient, etc.

This is more than normal mixing with the indirections on both sending and receiving

Edit: just to make it that much harder to correlate, payments can be broken up into standard denominations and stretched out over several sessions, this would be useful for larger payments that would have a hard time blending. Maybe a globally determined max that can be sent based on the sessions exact transactions

What if the user never directly touches the "shadow" accts after initial funding?
all payments and deposits are under encryption, so all that is known is that money went into the shadow economy, but nothing else as long as the shadow acct is never linked to normal acct

The activity with the shadow accts are visible, but with all the spending under encryption, no correlation to who is controlling it.

You will see $24.79 appear in an acct, but nobody knows whose acct it is.

If I see 24.79 spent and later 24.79 credited. It doesn't matter what you hide in between, I can still correlate them. Even if the user splits the amounts, i.e. 24.79 spent then 13.38 and 11.41 get credited to separate accounts, pattern analysis may still identify them.

So obscuring the process in the middle with a mixer that obscures IP address and/or links between spends and credits doesn't necessarily provide anonymity.

Using constant amounts (e.g. 0.001 BTC, 0.1 BTC, 1 BTC, 10 BTC) with the Zerocoin mixer would provide a much larger anonymity set, but only if these split amounts aren't recombined into a credit to one address.

Thus the multiple inputs for a transaction in Bitcoin can be considered a flaw in this application.

But imagine how much more complicated your wallet becomes will 1000s of keys. Perhaps hierarchical deterministic wallets is a solution.

My approach for NXTcash requires using a separate location to cash in the minted zerocoins and funding a totally new account. by using that account for the payment account in NXTmixer I think we get both cleanly integrated.

I think the biggest problem is user error and inadvertently creating a link between accounts that should be separate. By adding a layer of software to manage access, it should be possible to ensure the user doesnt goof up

James

Sound up to your scaling limits but we must trust your server is honest which is the antithesis of decentralized currency, unless I've misunderstood your design points.

Zerocoin has flaws I enumerated. And it targets a different problem, which is long-term anonymity of the blockchain.

Your mixer is perfectly obscuring the IP address (assuming the server is honest or you've designed a work around for trusting the server) by employing the concept of BitMessage, which is also necessary but can't possibly address the long-term leakage of identities.

In short, we need both. And we need to fix all the issues. As far as I know, no one has yet published how to do that.

Any thing you learn from your efforts can only help. So I encourage you to continue to work on this.

Thanks!

So, basic concept is sound? Would you say NXTmixer could be a bit better than zerocoin?

I guess proceed with your experiment. You may learn new helpful insights in the process. Best wishes. I've added your name to list of developers to contact soon.

Server centralization is temporary until NXT get AT (Automated Transactions).

With NXTmixer, zerocoin seems like a lot of work for little benefit.

With everybody broadcasting, it would really push the network to the limits, but NXT should be able to get to 1000 transactions per minute pretty easily, so that would 10 minutes for the broadcast phase with 10,000 participating accounts. If we did an hourly clearing, I think that is a reasonable timeframe, so we start running into limits at 100,000 participants, but I am not so worried about these big success scenarios. Those are good problems to have.

I would love to implement a truly anonymous solution!!

James

Exactly as I expected. You are correct that my key mixing innovation has something to do with "everyone sends everything", but you've missed some of the key issues with such a design. For one thing, it doesn't scale the way you have it designed.

And you still need fast verification time, so scratch Zerocoin.

Also there are other issues. How do we trust your server?

Yes you are correct that obscuring the IP address perfectly would prevent correlating thus you don't even need Zerocoin for that purpose. So what purpose does Zerocoin serve? Well some people screw up and reveal their identity (even years later ex post facto when the authorities lean on them) and this allows finding the others via a process of elimination.

But Zerocoin can't work if you vary the amount in/out of it per transaction. And as I said, Zerocoin relies on an algebraic trap-door, thus is vulnerable to mathematical attack or quantum computing.

Perhaps you'd like to work on implementing my design since I have already solved many of these issues and have written proofs and white papers?

Also I have designed many other innovations such a cpu-only proof-of-work.

Isn't NXT proof-of-stake? I think PoS is not viable. My logic is buried in my thread.

You've impressed me enough that we should work together.

NXTmixer is a server that monitors the blockchain for broadcasts that all the participating nodes are doing.

Every session, all nodes broadcast their public key and an encrypted payment packet, even if they dont have any payments to make. This makes all of them look the same and there is no timing attack.

The NXTmixer decrypts the payment packets and in there is payment instructions and password to a funded acct. It verifies the funds clear by sending it to a common account. With NXT, this process makes all the NXT fungible because it doesnt have txouts. At the end of a session, the NXTmixer sends payment to a designated account for each account that received payment.

The source of funds is arms length from the sender. The destination of funds is arms length away from recipient.

How can you correlate payments as long as the user doesnt blunder by directly accessing funds from the destination acct?

James

Edit: I can further constrain things by requiring fixed denominations, but if the accounts cant be correlated I dont think this is necessary

I had already read something like that from you.

I can't easily follow that description. What is a NXT mixer? Is it a mining peer who won the right to process the next transaction block? Is it a decentralized mixing protocol between all mining nodes?

You are explaining in terms of coding details. Can you make an algorithmic description instead?

I hope you realize that "everyone sends everything" protocols can't scale well.

NXTmixer has nothing to do with zerocoin. Forget about zerocoin for now.

The following is a high level summary of NXTmixer. 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. 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.

Every session all nodes behave the same, they all broadcast their public key and encrypted payment bundle. the payment details including the deposit address are inside the encrypted bundle. By using the same account as a deposit account one session and a payment account the next session, it is possible to make payments without ever touching the account directly. As long as the public/private key encryption is solid, only the mixing server will know the payment paths. This centralized server will be decentralized when Automated Transactions become available, so we can ignore this weakness for the time being.

James

You mean to say you need Zero-knowledge proof functionality. As far as I know, currently there are no ZKPs which don't use algebraic trap-doors (i.e. they don't use only cryptographic hashing).


As I wrote in my prior post, kudos you are remarkably close to the correct solution on this, but not quite there.
 

It is possible to correlate inputs into the Zerocoin to outputs coming about the other side because the amounts of each such pair are (usually) different from all the other such in/out pairs.


Please explain why so I can critique.


Huh? The Zerocoin proof requires the accumulator to have a pre-generated n,p,q when the accumulator is first initialized. Who ever created these values could steal all the coins. This is a fundamental flaw in Zerocoin. Have you fixed it? Or did the latest Zerocoin paper fix it?


Then apparently you don't understand the inner workings of Zerocoin crypto library that you are using.



I would have to dig into the design and I don't have time for that. But I already see one flaw "synchronize clients". But I am not going to tell you, because then I give away my secret design.

I will critique some of the details, if you provide more. I can't quickly (and I am lacking time) follow what you've written so far about it. Perhaps you can explain your algorithms in English text. I am a C programmer but I am not going to try to gleem a high-level flowchart from C structures.

I am agnostic toward specific encryption algos used, I just need public/private key functionality.

I believe embedding the source of funds and destination of funds inside the encrypted data eliminates the need for obscuring IP address. Everybody is broadcasting to blockchain, so everybody is communicating with everybody else. No information leaked.
 
All payments are sent at the same time by synchronizing the beginning and ending of sessions. There will need to be some delays to fit the transactions into the blocks, but that will be done randomly. No information leaked.

Not an issue with NXTmixer

Not an issue with NXTmixer, but initial implementation is centralized on one server at least for the mixing. The point to point is fully decentralized. Also, there is every reason to believe that NXTmixer can be ported to Automated Transactions when that comes out.

I am a simple C programmer and I designed something I can understand.

Most interested in how NXTmixer is vulnerable

James