Nxt :: NXTcash - progress and discussion

[jl777]

We are adding zerocoin to NXT in a way that will allow us to identify and fix any fundamental issues regarding incorporating zeroknowledge proofs within the NXT core.

This project is at the proof of concept stage, eg. can this even be done on a small scale demo basis. We are currently very close to an internal release of NXT core that integrates with Tutorial.java, which is a layer that hooks up to Tutorial.cpp from https://github.com/Zerocoin/libzerocoin

The proof of concept version will be deployed on zeronet for internal testing. Runtime performance and size of data is not a concern for now. In order to accomodate the 30K size of zeroknowledge proof in libzerocoin alpha, bloodyrookie has made a version that has a larger blocksize. This means that during development NXTcash will not be compatible with mainnet blockchain.

NXTcash will be fully opensourced upon completion, but during development, releases will be made internally only. PM me if you want access.

zerocoin.org says that they want somebody to actually use libzerocoin alpha. If anybody is able to contact them and let them know we are doing this, that would be fantastic. We want to integrate in the upcoming zerocash into the proof of concept version, which will help find any issues with zerocash. In order to help convince the zerocoin team, I want to be able to demonstrate a working NXTcash proof of concept, so as soon as we get it debugged, we will load it on a portable computer and fly it to wherever Matt Green is for the demo!

I know zerocoin is working on their own coin, so I hope they are still open to cooperating. It would save them a lot of work if they built zerocash on top of NXT, especially after we have done all the higher level changes to integrate libzerocoin alpha.

Task List
1. port Tutorial.cpp to Tutorial.java - completed by Bloodyrookie
2. integrate NXT core 4.7 and Tutorial.java - almost completed by Bloodyrookie
3. create NXTcash API - completed by Bloodyrookie
4. setup zeronet (testnet for NXTcash) - in progress by klee's team
5. create modified NXT client to support NXTcash API - undebugged release made my marcus03
6. deploy NXTcash proof of concept onto zeronet and debug NXTcash client
7. create demo machine with NXTcash and fly it to demonstrate to Matt Green
8. obtain pre-release libzerocash.cpp (or even object file) to start porting effort
9. debug NXTcash with libzerocash
10. refactor libzerocash into java for inclusion into proposed NXT core

We are developing this using klee's 1 million NXT donation to NXTcashoperatingfund 18388470681791198265
Please donate to NXTcashcompletionbonusfund 13313092584524529006

Since klee is funding the operating costs for this project and taking the risk of 1 million NXT, he will allocate the completion bounty. In the event that we cannot make a NXTcash release acceptable to the NXT community, all donations to the completion bounty fund will be returned.

James

[1715445904]

1715445904

[1715445904]

1715445904

[1715445904]

1715445904

[1715445904]

1715445904

[BldSwtTrs]

As far I know Zerocoin team came up with a new version which reduces the size of the proof by 98%. They will release that version in altcoin (Zerocash) but they don't reveal any detail about it.

So just to be sure my understanding is correct, your plan is to integrate the old version, the one with the big proof size?

[bitcoinpaul]

As I understand:

1. Integrate the old version to have a working code
2. After the release of the new code, the integration of the new code begins.

[superresistant]

As I understand:
1. Integrate the old version to have a working code
2. After the release of the new code, the integration of the new code begins.

Really ? When is the next release of the zerocoin ?

[jl777]

As far I know Zerocoin team came up with a new version which reduces the size of the proof by 98%. They will release that version in altcoin (Zerocash) but they don't reveal any detail about it.

So just to be sure my understanding is correct, your plan is to integrate the old version, the one with the big proof size?

We are scheduled to make an internal release of the old version integrated with NXT this week. yes, it has big proof size, but we made NXT block size bigger to handle it.

[jl777]

As I understand:
1. Integrate the old version to have a working code
2. After the release of the new code, the integration of the new code begins.

Really ? When is the next release of the zerocoin ?

Scheduled in May, that is why I want to create a portable demo machine to demo in front of Matt Green personally. Then he will know we are first to actually use the alpha version of zerocoin, bloated 30K proof size and all. I hope he will maintain his academic viewpoint and not put on his coin creator hat. The more coins that have the newest zerocash tech, the better.

James

[bitcoinpaul]

As I understand:
1. Integrate the old version to have a working code
2. After the release of the new code, the integration of the new code begins.

Really ? When is the next release of the zerocoin ?

Scheduled in May, that is why I want to create a portable demo machine to demo in front of Matt Green personally. Then he will know we are first to actually use the alpha version of zerocoin, bloated 30K proof size and all. I hope he will maintain his academic viewpoint and not put on his coin creator hat. The more coins that have the newest zerocash tech, the better.

James

+1

If we have time and energy for this (we have a big community), we should go this route.

[superresistant]

You said in the thread that the team require 1 Million additional Nxt at least to fund the project, correct ?

[jl777]

You said in the thread that the team require 1 Million additional Nxt at least to fund the project, correct ?

project has funds for operating costs, including plane ticket to fly someone to demo to Matt Green.

However, it is likely that little will remain of klees operating funds and I want there to be a strong incentive for the NXTcash team to push through and do whatever it takes to get this project done.

It is a relatively risky project as we require external help and it is cutting edge tech, so the model I proposed was to cover costs as we go with completion bounty as carrot. klee has funded the operating costs with the expectations that the community will provide the carrot.

Since many people never seemed to get tired telling me that it was impossible, impractical, etc. about this project, it is clear we will run into unforseen obstacles. The foreseen obstacles are intimidating enough, but I am just looking at one step at a time, well ok, so maybe several steps ahead, but concentrating on one step at a time.

James

[hvezdasmrti]

: Nxt :: NXTcrash - progress and discussion

 

[marcus03]

I'm in. :-)

[idev]

Great news, this is badly needed.

[Zahlen]

This is super sexy. Best wishes to the team!

[josephliton]

Good news.

[abctc]

- interested!  some donation sent to address 13313092584524529006.

[superresistant]

just sent 5K

[klee]

Good luck James et al!

[upekha]

interested

[bitcoinpaul]

interested

lol

[allwelder]

Interested,good luck to you and your project.

[utopianfuture]

Looks good. Good luck to the project.

[jl777]

Initial release has been sent to be put on zeronet, testnet for NXTcash.
Hopefully by next week, we can open it up to some larger scale testing.

The perfomance will not be fast due to size of zeroknowledge proofs. Functionality is what we need to concentrate on with alpha (proof of concept) version.

James

[jl777]

Initial release has been sent to be put on zeronet, testnet for NXTcash.
Hopefully by next week, we can open it up to some larger scale testing.

The perfomance will not be fast due to size of zeroknowledge proofs. Functionality is what we need to concentrate on with alpha (proof of concept) version.

James

You just went ahead and DONE DID IT...  didn't ya James?!?    

Truly amazing stuff going on in Nxt... I always try my best not to get overly excited... but I am beginning to fail miserably with Nxt!!!    

Bloodyrookie is doing the heavy lifting, with an assist from marcus03. I am more of the vision thing so far. Now I just have to figure out how to get Matt Green's attention and hopefully a bit of help. Then you have permission to get excited

James

[danzilla]

There's some amazing stuff going on with NXT.  Keep up the good work!

[superresistant]

Do you need NXTcash client testers ?

[check07]

Do you need NXTcash - Zerocoin Stakeholders? 

[clarkebar]

Sent 1,000 from 14230624058877295231.

My first outgoing NXT transaction! I wish it could be more but it's nearly 25% of all the NXT that I have. Best of luck with this exciting project!

-Clarkebar

[jl777]

Sent 1,000 from 14230624058877295231.

My first outgoing NXT transaction! I wish it could be more but it's nearly 25% of all the NXT that I have. Best of luck with this exciting project!

-Clarkebar

Thanks for the support!
We are running into some issues in getting the zeronet (testnet for NXTcash) setup, probably due to the alpha release based on the 4.7 source release. I am hoping that next week we will be ready for a few dozen people testing.

Do not expect too much, if it just functions, I will be happy. Due to the nature of this project, I had to plot a path that requires some large tradeoffs at the initial stages. It is the end result that is important, and the key achievement so far is the integration into the NXT core of an escrow like mechanism to mint and spend NXTcash. This method would be applicable for purely escrow usage, but that is a separate project.

James

[xyzzyx]

Sent 1000 NXT to the carrot account.

http://nxtexplorer.com/nxt/nxt.cgi?action=2000&tra=24916905271134361

[Sanglotslongs]

Zerocoin will be added to Anoncoin too ?

http://www.cryptocoinsnews.com/2014/02/24/interview-anoncoin-developer-speaks-zerocoin-implementation/

[superresistant]

Zerocoin will be added to Anoncoin too ?
http://www.cryptocoinsnews.com/2014/02/24/interview-anoncoin-developer-speaks-zerocoin-implementation/

in about a month, I expect to have something early adopters can test

What are they smoking ?

[klee]

Zerocoin will be added to Anoncoin too ?
http://www.cryptocoinsnews.com/2014/02/24/interview-anoncoin-developer-speaks-zerocoin-implementation/

in about a month, I expect to have something early adopters can test

What are they smoking ?

They have been working on it months now (from last summer I think)..

[jl777]

Now, here comes a totally unexpected possibility. What if the automated gateway was able to handle NXTcash? All this gateway coding made me realize it just might be able to be done, which means we could get NXTcash much, much sooner as we dont have to port it to Java.

User mints NXTcash and sends public part + corresponding NXT to gateway, which issues NXTcash Asset to the gateway account. At this point nobody can trade the NXTcash asset.

User now has all that is needed to redeem the NXTcash in the private files from the minting process. For privacy, he copies it to a flash drive and goes to a public data center. From there he starts a NXTcash spend process, which only requires the private data on the flash drive and designates a brand new NXT acct to receive the NXTcash asset. Now the NXTcash asset can trade and the gateway would always have a minimum bid of 1:1 so the original amount spent is available (minus whatever fees)

This is certainly not as good as having it built into the protocol as it relies on the gateways being operational and also that the gateways will always have a 1:1 repurchase bid in Asset Exchange. Also, the NXTcash trading on AE is not anonymous. This actually might really help avoid any stigma attached to using this tech. Only if you went out of your way to redeem the NXTcash on a different computer will you have true anonymity.

James

[superresistant]

Now, here comes a totally unexpected possibility. What if the automated gateway was able to handle NXTcash? All this gateway coding made me realize it just might be able to be done, which means we could get NXTcash much, much sooner as we dont have to port it to Java.
User mints NXTcash and sends public part + corresponding NXT to gateway, which issues NXTcash Asset to the gateway account. At this point nobody can trade the NXTcash asset.
User now has all that is needed to redeem the NXTcash in the private files from the minting process. For privacy, he copies it to a flash drive and goes to a public data center. From there he starts a NXTcash spend process, which only requires the private data on the flash drive and designates a brand new NXT acct to receive the NXTcash asset. Now the NXTcash asset can trade and the gateway would always have a minimum bid of 1:1 so the original amount spent is available (minus whatever fees)

This is a great idea. The sooner it is working, the better.

This is certainly not as good as having it built into the protocol as it relies on the gateways being operational and also that the gateways will always have a 1:1 repurchase bid in Asset Exchange. Also, the NXTcash trading on AE is not anonymous. This actually might really help avoid any stigma attached to using this tech. Only if you went out of your way to redeem the NXTcash on a different computer will you have true anonymity.

What does "NXTcash trading" refer to ? What will be anonymous and what will not ?

[jl777]

Now, here comes a totally unexpected possibility. What if the automated gateway was able to handle NXTcash? All this gateway coding made me realize it just might be able to be done, which means we could get NXTcash much, much sooner as we dont have to port it to Java.
User mints NXTcash and sends public part + corresponding NXT to gateway, which issues NXTcash Asset to the gateway account. At this point nobody can trade the NXTcash asset.
User now has all that is needed to redeem the NXTcash in the private files from the minting process. For privacy, he copies it to a flash drive and goes to a public data center. From there he starts a NXTcash spend process, which only requires the private data on the flash drive and designates a brand new NXT acct to receive the NXTcash asset. Now the NXTcash asset can trade and the gateway would always have a minimum bid of 1:1 so the original amount spent is available (minus whatever fees)

This is a great idea. The sooner it is working, the better.

This is certainly not as good as having it built into the protocol as it relies on the gateways being operational and also that the gateways will always have a 1:1 repurchase bid in Asset Exchange. Also, the NXTcash trading on AE is not anonymous. This actually might really help avoid any stigma attached to using this tech. Only if you went out of your way to redeem the NXTcash on a different computer will you have true anonymity.

What does "NXTcash trading" refer to ? What will be anonymous and what will not ?

The "teleporting" happens when you take the private info and redeem it for previously minted NXTcash assets. It is the private info generated on your computer and presumably being redeemed via USB drive on a physically different computer and the redemption randomly chooses from all the previously minted, but unclaimed NXTcash assets.

So what is visible on the blockchain is:

Temporarily "burning" NXT to register public data, which also adds NXTcash assets to a global pool. We see the NXT coming in. We know that private data was created, but not the actual data. public data mathemagically gets added to Accumulator. We also see that the amount of NXTcash assets available increased, but this is not a surprise because it matches the amount of NXT "burned"

We probably want to recommend to people to wait until there are at least <TBD> NXTcash assets in the global pool.

At some point, we see the side effect of the private data being "spent", which will only be seen on the blockchain as an asset transfer from NXTcash global pool to a (brand new) NXT acct.

NXTcash assets trading on Asset Exchange is all visible, but I think this is actually good as there is nothing inherently evil with NXTcash itself. It just gives people the option to utilize the privacy step above.

At some point anybody that purchased NXTcash assets can simply redeem it for NXT by transferring it back to the NXTcash acct. This is also visible.

So, the first step is really a lot like going to the bank and getting a suitcase full of cash, which dont have any serial numbers. The spending step is like depositing the suitcase full of cash and getting fully traceable casino chips. And the final redemption is converting the casino chips back into your "bank" balance, eg. NXT acct.

James

[superresistant]

Perfectly explained. Thank you.

Maybe we can get CIYAM Open involved once he finishes with Automated Transactions ?

[marcus03]

Following up on the request in the main NXT thread: I can setup and maintain one or two ZC testnet VPS. Sent me a link to your NRS version and I set it up.

[jl777]

Following up on the request in the main NXT thread: I can setup and maintain one or two ZC testnet VPS. Sent me a link to your NRS version and I set it up.

Thanks! I PM'ed you the details.

James

[klee]

Following up on the request in the main NXT thread: I can setup and maintain one or two ZC testnet VPS. Sent me a link to your NRS version and I set it up.

Thanks! I PM'ed you the details.

James

Awesome!

[jl777]

Marcus got a zeronet up and running!
Now we need a few testers

[tyz]

interesting project. i will follow the progress and good luck.

[jl777]

What is the feeling of everyone about integrating zerocoin into the NXT mainnet after testing?

Since we cant integrate C++ code into the NXT core, it would have to be put into the gateways and clients for peer validation. If we put NXTcash validation into NODEcoin also, we would get a large scale peer reviewed NXTcash. Essentially it would be a NXTcash blockchain on top of NXT that is enforced by NODEcoin. We might not have to store the large 30K proofs in the blockchain, not sure on this yet but there is a promising approach using gateway that could encapsulate the large proofs. I am hopeful that we will be able to submit to jean-luc and all Java set of mods to the NXT core that will support NXTcash. In March.

This technique could be expanded to add other blockchains that could be totally independent unto themselves, or be interwoven with NXT blockchain via gateway.

I used to think gateways were just boring deposit/withdrawal functionality. Now I am realizing that a gateway can be used to bridge the gap between a lot of things that are not NXT with NXT. By doing so, NXT gets effectively extended.

James

[superresistant]

Please define NODEcoin. Is it going to mix together with NXTcash ?

I've seen some message about it like :

nodecoin has a very good purpose as it will allow all of the non-hallmarked nodes to earn something for being part of the network, even if they wont ever be able to directly forge a block, they will earn nodecoins. Generous donators can then fund a NXT dividend to flow through the nodecoins. Maybe we run forging with a non-profit model. All excess transaction fees after paying for the cost of the hallmarked servers gets distributed to nodecoin owners.

The goal is to get people forging. If we make it in their financial interest to forge with a consistent generation of NODEcoin, then I think a lot of people will forge rather than not forge. Especially if the NODEcoins end up being worth more than the expected forging income, then the whole "pool" issue is moot.

I will be creating NODEcoin 2.0, which in addition to rewarding people for forging, will be actively validating all gateway transactions and will generate alerts if it ever detects any funny business. As long as the gateway monitors are happy, all is well. I dont expect more than an occasional yellow alert, when there is a network glitch and a transaction has to be manually resent. With the malleability issue, we need to be careful about blindly trusting any request for manual payment.

[Armando]

Almost missed it. Idea is great, when should we espect the working version?

[jl777]

Almost missed it. Idea is great, when should we espect the working version?

March

[jl777]

Please define NODEcoin. Is it going to mix together with NXTcash ?

I've seen some message about it like :

nodecoin has a very good purpose as it will allow all of the non-hallmarked nodes to earn something for being part of the network, even if they wont ever be able to directly forge a block, they will earn nodecoins. Generous donators can then fund a NXT dividend to flow through the nodecoins. Maybe we run forging with a non-profit model. All excess transaction fees after paying for the cost of the hallmarked servers gets distributed to nodecoin owners.

The goal is to get people forging. If we make it in their financial interest to forge with a consistent generation of NODEcoin, then I think a lot of people will forge rather than not forge. Especially if the NODEcoins end up being worth more than the expected forging income, then the whole "pool" issue is moot.

I will be creating NODEcoin 2.0, which in addition to rewarding people for forging, will be actively validating all gateway transactions and will generate alerts if it ever detects any funny business. As long as the gateway monitors are happy, all is well. I dont expect more than an occasional yellow alert, when there is a network glitch and a transaction has to be manually resent. With the malleability issue, we need to be careful about blindly trusting any request for manual payment.

NODEcoin will do things to enhance the NXTblockchain and to reinforce forging. The NODEcoin will do valuable things for the NXT network and as such I believe people will bid for them in the NXT Asset Exchange. So, it would have some resale value, but its not like it will become the national currency of <small country>. Of course, who knows what crypto speculators will do.

It wont be very CPU or network intensive, so just let it run in the background and you will start earning NODEcoins. Obviously no premine, no ipo, just launch and let the mining commence. The fewer people mining, the higher the payout and probably a bit of a decline in "block reward" over time. Not exponential decay though, I hate that.

James

P.S. Almost forgot about original question. I am redesigning NXTcash so that it will utilize a gateway for part of the functionality and that will benefit from peer reviewed data, which I plan to put into NODEcoin.

[Sebastien256]

Please define NODEcoin. Is it going to mix together with NXTcash ?

I've seen some message about it like :

nodecoin has a very good purpose as it will allow all of the non-hallmarked nodes to earn something for being part of the network, even if they wont ever be able to directly forge a block, they will earn nodecoins. Generous donators can then fund a NXT dividend to flow through the nodecoins. Maybe we run forging with a non-profit model. All excess transaction fees after paying for the cost of the hallmarked servers gets distributed to nodecoin owners.

The goal is to get people forging. If we make it in their financial interest to forge with a consistent generation of NODEcoin, then I think a lot of people will forge rather than not forge. Especially if the NODEcoins end up being worth more than the expected forging income, then the whole "pool" issue is moot.

I will be creating NODEcoin 2.0, which in addition to rewarding people for forging, will be actively validating all gateway transactions and will generate alerts if it ever detects any funny business. As long as the gateway monitors are happy, all is well. I dont expect more than an occasional yellow alert, when there is a network glitch and a transaction has to be manually resent. With the malleability issue, we need to be careful about blindly trusting any request for manual payment.

NODEcoin will do things to enhance the NXTblockchain and to reinforce forging. The NODEcoin will do valuable things for the NXT network and as such I believe people will bid for them in the NXT Asset Exchange. So, it would have some resale value, but its not like it will become the national currency of <small country>. Of course, who knows what crypto speculators will do.

It wont be very CPU or network intensive, so just let it run in the background and you will start earning NODEcoins. Obviously no premine, no ipo, just launch and let the mining commence. The fewer people mining, the higher the payout and probably a bit of a decline in "block reward" over time. Not exponential decay though, I hate that.

James

P.S. Almost forgot about original question. I am redesigning NXTcash so that it will utilize a gateway for part of the functionality and that will benefit from peer reviewed data, which I plan to put into NODEcoin.

Concerning nodecoin, will there be upper limit to the number of nodecoin? One must be carefull to the initial parameters of the coin because the parameters must be set so that there is always a reason to "mine" nodecoin (always a reason to protect the network). If a upper limit is reach eventually in the number of coin, there will be no reason to mine nodecoin, as no more nodecoin will ever be generate.

I would rather use a reward method inverserly proportional to the number of node "mining". Something like, [reward per block] = X/(number of node mining)^Y, where X and Y are constant. This would be similar to primecoin, which the reward is inversely proportional to the difficulty square (i.e. X=999 and Y=2, for primecoin).

What is your thought on this James.

[jl777]

Please define NODEcoin. Is it going to mix together with NXTcash ?

I've seen some message about it like :

nodecoin has a very good purpose as it will allow all of the non-hallmarked nodes to earn something for being part of the network, even if they wont ever be able to directly forge a block, they will earn nodecoins. Generous donators can then fund a NXT dividend to flow through the nodecoins. Maybe we run forging with a non-profit model. All excess transaction fees after paying for the cost of the hallmarked servers gets distributed to nodecoin owners.

The goal is to get people forging. If we make it in their financial interest to forge with a consistent generation of NODEcoin, then I think a lot of people will forge rather than not forge. Especially if the NODEcoins end up being worth more than the expected forging income, then the whole "pool" issue is moot.

I will be creating NODEcoin 2.0, which in addition to rewarding people for forging, will be actively validating all gateway transactions and will generate alerts if it ever detects any funny business. As long as the gateway monitors are happy, all is well. I dont expect more than an occasional yellow alert, when there is a network glitch and a transaction has to be manually resent. With the malleability issue, we need to be careful about blindly trusting any request for manual payment.

NODEcoin will do things to enhance the NXTblockchain and to reinforce forging. The NODEcoin will do valuable things for the NXT network and as such I believe people will bid for them in the NXT Asset Exchange. So, it would have some resale value, but its not like it will become the national currency of <small country>. Of course, who knows what crypto speculators will do.

It wont be very CPU or network intensive, so just let it run in the background and you will start earning NODEcoins. Obviously no premine, no ipo, just launch and let the mining commence. The fewer people mining, the higher the payout and probably a bit of a decline in "block reward" over time. Not exponential decay though, I hate that.

James

P.S. Almost forgot about original question. I am redesigning NXTcash so that it will utilize a gateway for part of the functionality and that will benefit from peer reviewed data, which I plan to put into NODEcoin.

Concerning nodecoin, will there be upper limit to the number of nodecoin? One must be carefull to the initial parameters of the coin because the parameters must be set so that there is always a reason to "mine" nodecoin (always a reason to protect the network). If a upper limit is reach eventually in the number of coin, there will be no reason to mine nodecoin, as no more nodecoin will ever be generate.

I would rather use a reward method inverserly proportional to the number of node "mining". Something like, [reward per block] = X/(number of node mining)^Y, where X and Y are constant. This would be similar to primecoin, which the reward is inversely proportional to the difficulty square (i.e. X=999 and Y=2, for primecoin).

What is your thought on this James.

With 1 billion coins, an average of 100,000 per day will last a long time.
I think starting at 250,000/day and gradually reducing to 100,000 per day is a good starting point to think about.
Also, I think it makes sense to scale the payout based on the number of active NXT accts.
Unlike other coins, it is possible to recirculate nodecoins (or any other NXTcoins), by having the issuer buy them back. Kind of like a stock repurchase that corporations do.

I want to make sure nodecoin has a tangible value so I will be calling for donations that will go into a nodecoin repurchase acct, probably the same acct as originally issues the asset. This will provide a price floor and demand.

So, if the network needs a boost, pop in NXT to the repurchase fund and nodecoin price goes up, more miners mine. Though I will make the nodeminer very lightweight so there is no reason not to be running it in the background

James

[BitJohn]

Cryptsy NXT integration almost complete.

[wakasaki808]

Cryptsy NXT integration almost complete.

Woo

[jl777]

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.

<shameless plug>
Show your support for NXTcash, donate to completion bounty fund 13313092584524529006
</shameless plug>

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

[superresistant]

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.

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

[jl777]

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.

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

less changes to NXT core

[superresistant]

less changes to NXT core

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.

[bitcoinpaul]

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?

[chinajsntwzq]

Sent 2,000 from 12348614373637738998.

Best of luck with this exciting project! Good luck!

chinajsntwzq

[CoinTropolis_JustaBitTime]

Cryptsy NXT integration almost complete.

Thanks BitJohn!

[jl777]

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?

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. <time passes, maybe asset changes hands> asset -> NXT core -> credit real NXT

Fewer steps for there to be problems with network.

James

[jl777]

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. <time passes and presumably from a different computer on a different IP address using a different NXT acct>

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

[xyzzyx]

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. <time passes and presumably from a different computer on a different IP address using a different NXT acct>

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

There's another way to pass the NXTcash/zerocoin to another account without it being traceable that doesn't require a USB drive in step Z.

You could issue a mint NXTcash op on account A and specify to the client that account B should receive it.  The client would encrypt with account B's public key the private zerocoin data that would otherwise have been transfered using a USB stick in step Z, and place the encrypted data into the blockchain using AM.  On account B, you could decrypt the AM payload using B's private key when you want to spend/redeem the NXTcash for NXT.

The AM doesn't need to be (mustn't be) casually connected to account B.  You just need to have the client for account B scan the blockchain for all AM payloads generated by account A and attempt to decrypt.  Only the valid ones will decrypt to meaningful NXTcash info that is able to be redeemed.

[sirnoah]

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

[jl777]

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

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

[jl777]

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. <time passes and presumably from a different computer on a different IP address using a different NXT acct>

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

There's another way to pass the NXTcash/zerocoin to another account without it being traceable that doesn't require a USB drive in step Z.

You could issue a mint NXTcash op on account A and specify to the client that account B should receive it.  The client would encrypt with account B's public key the private zerocoin data that would otherwise have been transfered using a USB stick in step Z, and place the encrypted data into the blockchain using AM.  On account B, you could decrypt the AM payload using B's private key when you want to spend/redeem the NXTcash for NXT.

The AM doesn't need to be (mustn't be) casually connected to account B.  You just need to have the client for account B scan the blockchain for all AM payloads generated by account A and attempt to decrypt.  Only the valid ones will decrypt to meaningful NXTcash info that is able to be redeemed.

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

[xyzzyx]

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.

You're referring to this, I presume:

B. Limited Anonymity and Forward Security

A serious concern in the Bitcoin community is the loss of wallets due to poor endpoint security. In traditional Bitcoin, this results in the theft of coins [4]. However, in the Zerocoin setting it may also allow an attacker to de-anonymize Zerocoin transactions using the stored skc. The obvious solution is to securely delete skc immediately after a coin is spent. Unfortunately, this provides no protection if skc is stolen at some earlier point.

In the encrypted AM scenario, if account A is compromised there is no way to read the secret because it is encrypted with account B's public key.  The AM would look like random data if done correctly.  If account B is compromised, yes, that there was a zerocoin minted from account A for account B and also if it was spent or not would be revealed.

With that said, you can't guarantee the data is destroyed when using the USB method.  Attempting to overwrite the data at the file system level will run up against internal Flash wear-leveling algorithms.  I'm not sure I'd totally trust hardware-level Flash block-erases to not leave residual charges in gates, at least not without seeing documented info on this.  The best you can do is to physically destroy the USB drive.

You also can't guarantee the data will have been destroyed on the generating computer, esp. if it was compromised prior to generating the data, but also with modern SSD drives there is the wear-leveling algorithm problem.  You'd have to make sure the generated data never touches the fixed disks in the generating computer -- a bit of a bother with swap and all.

BTW, one nice thing about using an encrypted AM payload is that account A and account B could be held by different people.  That is, you could do direct payments in NXTcash.  The only hole I see in this at the moment is that since A generated the zerocoin secret, with a little work A could redeem the generated NXTcash before B does.  The same problem exists in the equivalent USB drive scenario, however.  The best solution I see ATM is to encourage B to redeem his NXTcash payment (as NXT or as another NXTcash mint op) before sending the goods.

Maybe some sort of distributed cloud storage, but not sure of ones that cant be correlated based on IP usage.

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

[jl777]

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.

You're referring to this, I presume:

B. Limited Anonymity and Forward Security

A serious concern in the Bitcoin community is the loss of wallets due to poor endpoint security. In traditional Bitcoin, this results in the theft of coins [4]. However, in the Zerocoin setting it may also allow an attacker to de-anonymize Zerocoin transactions using the stored skc. The obvious solution is to securely delete skc immediately after a coin is spent. Unfortunately, this provides no protection if skc is stolen at some earlier point.

In the encrypted AM scenario, if account A is compromised there is no way to read the secret because it is encrypted with account B's public key.  The AM would look like random data if done correctly.  If account B is compromised, yes, that there was a zerocoin minted from account A for account B and also if it was spent or not would be revealed.

With that said, you can't guarantee the data is destroyed when using the USB method.  Attempting to overwrite the data at the file system level will run up against internal Flash wear-leveling algorithms.  I'm not sure I'd totally trust hardware-level Flash block-erases to not leave residual charges in gates, at least not without seeing documented info on this.  The best you can do is to physically destroy the USB drive.

You also can't guarantee the data will have been destroyed on the generating computer, esp. if it was compromised prior to generating the data, but also with modern SSD drives there is the wear-leveling algorithm problem.  You'd have to make sure the generated data never touches the fixed disks in the generating computer -- a bit of a bother with swap and all.

BTW, one nice thing about using an encrypted AM payload is that account A and account B could be held by different people.  That is, you could do direct payments in NXTcash.  The only hole I see in this at the moment is that since A generated the zerocoin secret, with a little work A could redeem the generated NXTcash before B does.  The same problem exists in the equivalent USB drive scenario, however.  The best solution I see ATM is to encourage B to redeem his NXTcash payment (as NXT or as another NXTcash mint op) before sending the goods.

Maybe some sort of distributed cloud storage, but not sure of ones that cant be correlated based on IP usage.

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

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

[xyzzyx]

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

Do you know any good C libraries that lets you do encryption and multisig on data that is easy to use?

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

No multisignature support, though.

[AnonyMint]

James is a machine.

I want this thing that he smokes too.

What do you think of NXTmixer? Let us assume we can ignore quantum computers that can peek inside the encrypted data. With everybody broadcasting, there is no time based correlations. I could even make it so everybody has to send the same multiple of 100NXT, but I dont think that is necessary.

What am I missing? I couldnt have come up with a working mixer in a day?!

James

Please ask AnonyMint to audit everything you do (NXTcash and/or mixing related)...

EDIT: I only trust him for this (he is totally paranoid regarding anonymity)

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

We are adding zerocoin to NXT in a way that will allow us to identify and fix any fundamental issues regarding incorporating zeroknowledge proofs within the NXT core.

I have several posts about the issues with Zerocoin:

https://bitcointalk.org/index.php?topic=455141.msg5023887#msg5023887
https://bitcointalk.org/index.php?topic=455141.msg5128980#msg5128980
https://bitcointalk.org/index.php?topic=455141.msg5147817#msg5147817
https://bitcointalk.org/index.php?topic=455141.msg5466558#msg5466558
https://bitcointalk.org/index.php?topic=455141.msg5474960#msg5474960
https://bitcointalk.org/index.php?topic=455141.msg5519196#msg5519196
https://bitcointalk.org/index.php?topic=455141.msg5521333#msg5521333
https://bitcointalk.org/index.php?topic=455141.msg5539088#msg5539088
https://bitcointalk.org/index.php?topic=455141.msg5540317#msg5540317
https://bitcointalk.org/index.php?topic=455141.msg5562422#msg5562422

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 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"

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

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

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

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.

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

[jl777]

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

We are adding zerocoin to NXT in a way that will allow us to identify and fix any fundamental issues regarding incorporating zeroknowledge proofs within the NXT core.

I have several posts about the issues with Zerocoin:

https://bitcointalk.org/index.php?topic=455141.msg5023887#msg5023887
https://bitcointalk.org/index.php?topic=455141.msg5128980#msg5128980
https://bitcointalk.org/index.php?topic=455141.msg5147817#msg5147817
https://bitcointalk.org/index.php?topic=455141.msg5466558#msg5466558
https://bitcointalk.org/index.php?topic=455141.msg5474960#msg5474960
https://bitcointalk.org/index.php?topic=455141.msg5519196#msg5519196
https://bitcointalk.org/index.php?topic=455141.msg5521333#msg5521333
https://bitcointalk.org/index.php?topic=455141.msg5539088#msg5539088
https://bitcointalk.org/index.php?topic=455141.msg5540317#msg5540317
https://bitcointalk.org/index.php?topic=455141.msg5562422#msg5562422

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.

Please come back...I will be adding MUCH more to this post...

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

[jl777]

• 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.

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

• 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.

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.
 

• 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.

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.

• 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.

Not an issue with NXTmixer

• 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.

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.

• 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.

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

Most interested in how NXTmixer is vulnerable

James

[AnonyMint]

• 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.

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

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).

• 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.

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.

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

• 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.

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.

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.

• 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.

Not an issue with NXTmixer

Please explain why so I can critique.

• 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.

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.

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?

• 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.

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

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

Most interested in how NXTmixer is vulnerable

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.

[jl777]

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.

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

[AnonyMint]

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.

[jl777]

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?

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

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

[AnonyMint]

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?

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

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

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.

[jl777]

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?

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

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

Exactly as I expected. You are correct that my key 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?

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

[AnonyMint]

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.

[jl777]

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.

Thanks!

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

[AnonyMint]

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.

Thanks!

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

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.

[jl777]

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.

Thanks!

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

Sound up to your scaling limits but we must trust your server is honest which is the antithesis of decentralized currency.

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), 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.

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

[AnonyMint]

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.

Thanks!

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

Sound up to your scaling limits but we must trust your server is honest which is the antithesis of decentralized currency.

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), 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.

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

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.

[jl777]

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.

Thanks!

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

Sound up to your scaling limits but we must trust your server is honest which is the antithesis of decentralized currency.

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), 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.

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

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.

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.

[jl777]

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.

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

[lexxus]

Do you need testers/developers?

[l8orre]

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)

[Ziggy]

800 nxt sent
Transaction id: 11665090002745715591

good luck!

[Armando]

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.

Thanks!

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

Sound up to your scaling limits but we must trust your server is honest which is the antithesis of decentralized currency.

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), 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.

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

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.

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

[-Greed-]

Any progress yet?

[jl777]

Any progress yet?

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