Hi here
One question is bothering me for a while: is there any plans to create a solution of accepting NXT in e-shop, etc.? I mean payment tool, like bitpay for example.
Now we are spending thousands of NXT for 1 minute on radio, while we could spend on payment tool development. Now we just spend our NXT on exchanges, in other words come like a squirrel in the wheel.
Or did I miss something?
There is 40,000 NXT bounty for project to accept NXT via standard shopping cart modules. wesleyh is working with another guy on this.
James
James, how is the mixing implementation coming along?
What we are working on is NOT mixing. Mixing can be unraveled. I am not smart enough to even attempt to understand all the advanced maths in the zerocoin alpha solution, let alone their upcoming improved version.
However, I am smart enough to know that it is best to leverage what exists, so Jack Needles is in the process of porting the well documented Tutorial.cpp code to Tutorial.java
Unlike incompetent me, Jack is clearly a competent guy and I have full confidence that he will be able to get it to work. Once this is working, I am counting on people much more competent than me, like Bloodyrookie and ricot to figure out how best to splice in the Tutorial.java. Whatever method we come up with will most likely directly be applicable with the upcoming zerocash cpp library.
We can then make a testnet to see if anybody can identify who is paying who. Theoretically, libzerocoin uses the zeroknowledge proof, so we shouldnt be able to.
At this point, we go into a holding pattern waiting for a new libzerocash CPP library. We convert to java, and test the new improved zerocash system. Still all on testnet, but this iteration is expected to go 10 times faster because we already went through the process.
I don't want to touch the zerocoin algos with a ten foot pole. I know my limits and I even have a BS in math from a small university in california. My development plan does require some code to be written and then thrown away (the horror), but it is designed to MINIMIZE the time to market.
Best case scenario is that we will get the cooperation of the zerocoin team and get an early release of the libzerocash, then we can avoid any prolonged holding pattern.
Oh, once we verify that all this is functional and nobody can crack the cashflow paths, we can then port the libzerocash into Java and then submit the pure Java solution to jean-luc to integrate into a release.
This is my incompetent plan that nxtchg says is impossible. Whatever. I am just pushing forward and planning to have a testable testnet with NXTcash in it as soon as possible, even if it is supposed to be impossible. Notice nowhere in my plan do I or anybody have to understand any magical zeroknowlege maths, maybe the guy who refactors libzerocash to Java will have to, but that is the final step and a refactoring.
My assessment was that it would take much longer to decipher the maths and algos of zerocoin/zerocash and I like to be making progress instead of waiting, especially when there is a large overlap of things that we need to do at the higher level like NXT escrow.
James