Imagine if there was NXTcash, the next form of cash!
zerocoin created a whitepaper http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf and alpha code that implements it on top of bitcoin.

From what I can tell, there is no reason we can't implement this on top of NXT

However, it is not as simple as cutting and pasting code, it is a project. To do this right, it needs funding and staffing.

If we had a way of converting NXT into NXTcash to spend, it would be a fantastic feature. Most of the NXT stays in normal acct, but if you want to spend some cash on things you would rather be private about (right to privacy anybody), then just convert it to NXTcash and no worries that it can be traced back to you.

This will clearly be a big, significant feature as no other crypto has it. It should dramatically increase the value of NXT.

We have funding available from community fund. Additional bounties have been added to it. I am not sure how much it will cost to get this done. Maybe we need to get project bids? I am not sure if we have the people who can get it done already here, or if we need to recruit.

Either way, we really should get this done.

James

P.S. I put this at the top of the list of desired technical features after official client and account control. Best to use non-overlapping persons whenever possible.

I think the first step is for someone to get libzerocoin running on a NXT testnet. It is C++ so there is task of getting it so the Java can use it on a cross platform basis. This means some nodes won't be able to run the zeroNXT module until the libzerocoin is ported to Java, but I don't think that is a big issue.

CfB or ricot to figure out how to properly integrate the libzerocoin calls on top of NXT blockchain.

The client side functions sounds like a separate task, so one or two of the client devs to see what it would take to get them implemented.

Probably need BCNext to figure out how to cleverly generate the magic prime numbers without anybody being able to store it.

With a divide and conquer approach, we might be able to get zerocoin functionality for NXT before zerocoin!

James

The following is from zerocoin site. It seems to be nicely documented and also has different things that need to be done. We can have different people doing the different integration tasks in parallel and get this done reasonably quickly.

If there really is 2 million NXT, I bet we can get quite a few very talented people to take long vacations from their real world jobs, or maybe get "sick" and be able to work on this 100%.

James

**********


Integrating with bitcoin clients
libzerocoin provides the core cryptographic routines for the Zerocoin protocol. It is not, however, a complete Zerocoin implementation. On this page we provide a short overview of the additional transaction types and functionality required to add Zerocoin to a Bitcoin client.

Note that this is a high level overview and not a precise description of the message format. We believe those decisions are best left to the Bitcoin/altcoin community.

Note: See the Advanced Integration page for details on incremental deployment, reducing proof bandwidth, etc.

Choosing zerocoin denomination(s)
Unlike Bitcoin, Zerocoin is a coin-based protocol where all coins have some fixed denomination. For example, the value of 1 zerocoin (ZC) might be set at 1 BTC. This value is arbitrary and should be set by protocol convention.

In practice it may be convenient to run several independent Zerocoin instances, where each instance uses a different coin denomination (this is analogous to issuing $1, $5 and $10 bills.) libzerocoin provides native support for multiple denominations. See supporting multiple denominations (TODO) for more on the tradeoffs involved.

Parameter generation
All parties in a Zerocoin deployment must share a common public parameter N. This parameter must be generated by a trusted party and distributed with all clients. See generating Zerocoin parameters for more details.

Coin Minting
To mint a new zerocoin, the user first constructs a new PrivateCoin object, then extracts the public portion of the coin using the getPublicCoin() method. The resulting PublicCoin object can be serialized using the << constructor to obtain a binary array.

The client must now formulate a new ZEROCOIN_MINT transaction to send to the network. This transaction will include:

Bitcoin inputs summing to the denomination of one zerocoin + transaction fees
(OPTIONAL) the denomination of the coin, if more than one denomination is in use
The serialized PublicCoin.
The precise format of the ZEROCOIN_MINT message is left to implementers. Since public coins are relatively small, it may even be possible to 'hack' this capability into a standard Bitcoin transaction without changing the protocol. However you choose to do it, there must be no way for users to redeem the inputs except via a Zerocoin spend transaction.

The client must store the PrivateCoin object in a secure wallet. This object contains the secrets required to spend the coin. NOTE: IF THESE SECRETS ARE COMPROMISED (EVEN AFTER YOU SPEND THE COIN) YOU COULD LOSE BOTH THE COIN AND THE ANONYMITY OF THE COIN. THEY SHOULD BE DESTROYED IMMEDIATELY UPON SPENDING.

Coin validation
Each client (or miner) who receives a ZEROCOIN_MINT transaction must validate the transaction before performing any operations on it. Validation involves the following steps:

Verifying that all Bitcoin inputs are correct and unspent. (These should also authenticate the rest of the transaction including PublicCoin.)
Verifying that all inputs total to the denomination of the coin requested (+ fees).
Deserializing and validating the PublicCoin.
Verifying that this PublicCoin has not appeared in any previous ZEROCOIN_MINT transactions.
Steps (1) and (2) are Bitcoin-specific and require no Zerocoin cryptography. Step (4) requires the client/miner to keep a list of previously minted coins. libzerocoin currently does not provide a data structure for this purpose.

The validation in step (3) will be performed automatically if you use the stream (deserialization) constructor for PublicCoin. If for some reason you don't, you can manually perform validation using the validate() method of that class.

A ZEROCOIN_MINT transaction should be considered confirmed only after it has been included in a certain number of blocks. This number is at the discretion of the implementer.

Validation is as important as normal Bitcoin transaction validation and should happen at the same points. Failure to validate a new Zerocoin could allow double-spending.

Overview of the Spend process
Spending a Zerocoin involves several steps. We first provide a brief overview of the full process, then break out each step in the sections that follow.

The client (spender) first identifies a set of confirmed ZEROCOIN_MINT transactions (by all users) in the block chain (this set must include the zerocoin she intends to spend). We'll call this the confirmed transaction set. She chooses one of these transactions at random and verifies that it has not been redeemed (i.e., it is not referenced in another ZEROCOIN_SPEND transaction). We'll refer to this as the redemption transaction.

She then computes an Accumulator over all the PublicCoin values in the confirmed transaction set. The network can assist with the Accumulator calculation (see 'Calculating the Accumulator' below).

She computes a Witness over the confirmed transaction set and the PrivateCoin she intends to spend.

She then computes a ZEROCOIN_SPEND transaction that includes (A) the identity of the redemption transaction as a Bitcoin input, (B) one or more arbitrary destination Bitcoin addresses as a Bitcoin output, (C) a serial number and signature on the transaction, both of which are computed using the CoinSpend class. The computation of CoinSpend is based on the hash of the transaction, the Accumulator and Witness as well as the unspent PrivateCoin.

The network (particularly the miners) compute the Accumulator over the same transaction set. They perform the following checks: (A) extract the serial number from the CoinSpend object and verify that it has not been used in any other (valid) ZEROCOIN_SPEND transaction, (B) verify the CoinSpend signature (using the included libzerocoin CoinSpend.Verify() method), (C) verify that the specified Bitcoin inputs (referenced in the redemption transaction) have not previously been redeemed by another ZEROCOIN_SPEND.

The network (particularly the miners) confirm the checks of Step [5]. If all checks pass, the ZEROCOIN_SPEND transaction is accepted and confirmed into the block chain. The transaction represents a transfer of value from the inputs of the redemption transaction to the destination Bitcoin addresses specified in the ZEROCOIN_SPEND outputs. Any unclaimed bitcoins are retained by the miner as transaction fees.

The following sections elaborate on each of the steps above.

Calculating the Accumulator
In order to generate or verify ZEROCOIN_SPEND transactions each participant must first compute an Accumulator on the set of confirmed ZEROCOIN_MINT transactions. The accumulator is deterministic (non-randomized) and can be incrementally computed. Calculation can be accomplished in two ways:

The spender/verifier can compute the full accumulator themselves. This is accomplished by instantiating a fresh Accumulator object and using the += or accumulate() methods to add the PublicCoin value from all confirmed ZEROCOIN_MINT transactions.

To reduce clients' computational burden, the miners can incrementally compute the accumulator. This is accomplished by placing an 'Accumulator Checkpoint' within each block. The Accumulator Checkpoint for block i is computed by deserializing the Accumulator Checkpoint in block i-1 into an Accumulator class, then accumulating all valid ZEROCOIN_MINT (PublicCoin) values in block i. If i = 0 an empty Accumulator class is used for the previous Checkpoint.

NOTE: When using Accumulator Checkpoints, all nodes in the network MUST validate each Accumulator Checkpoint before accepting a proposed block. This is done by re-computing the Accumulator Checkpoint using the identical inputs. FAILURE TO VERIFY THE CORRECTNESS OF ACCUMULATOR CHECKPOINTS COULD LEAD TO DOUBLE SPENDING.

Coin spending (detailed)
This section elaborates on Steps [1-4] of the overview above.

The client (spender) first identifies the confirmed transaction set, i.e. the set of confirmed ZEROCOIN_MINT transactions in the block chain. In our expected usage this set will consist of all confirmed transactions. However some clients might choose to use a smaller set -- for example, by selecting only transactions within a specific block range (see 'Using Transaction Windows' on the Advanced Integration page).

The client (spender) now picks at random one confirmed ZEROCOIN_MINT transaction that has not been redeemed (spent) by any ZEROCOIN_SPEND transaction in the block chain. This is the redemption transaction. Note that the redemption transaction is not (except by random chance) the same as the original MINT transaction.

The client (spender) calculates an Accumulator over all confirmed ZEROCOIN_MINT transactions in the first set (specifically, she accumulates the PublicCoin values from each transaction.) She can do this independently, or with the assistance of the Bitcoin network (see 'Calculating the Accumulator').

The client (spender) formats a ZEROCOIN_SPEND transaction. This transaction specifies the set of ZEROCOIN_MINT transactions used to compute the Accumulator (i.e., it might specify block numbers 0-B for some block number B). It also includes the identity of the ZEROCOIN_MINT transaction selected in step (2) as a Bitcoin input. It embeds an arbitrary set of Bitcoin outputs.

The client (spender) generates a CoinSpend signature on the transaction that includes the hash of the transaction as well as the Accumulator and PrivateCoin object. The resulting CoinSpend embeds both a coin serial number and a set of zero-knowledge proofs that prove (A) that the spender knows a coin in the transaction set, (B) that the serial number is consistent with the coin, and (C) the spender knows the secret values for the coin. These are all tied to the transaction hash. The client (spender) serializes the CoinSpend object and transmits the completed ZEROCOIN_SPEND transaction to the network.

Once the ZEROCOIN_SPEND transaction has been confirmed by the network, the spender MUST destroy the PrivateCoin and all secrets to prevent later compromise and de-anonymization.

Coin spend verification (detailed)
This section elaborates on Steps [5, 6] of the overview above.

The network nodes compute the Accumulator over the same transaction set as the spender (this information is taken from the sender's COIN_SPEND transaction).

They now perform the following checks: (A) they extract the serial number from the CoinSpend object and verify that it has not been used in any other (valid) ZEROCOIN_SPEND transaction, (B) verify the CoinSpend signature (using the included libzerocoin CoinSpend.Verify() method), (C) verify that the Bitcoins from the redemption transaction have not previously been redeemed by another ZEROCOIN_SPEND and (D) verify that the Bitcoin input and outputs are consistent.

The network (particularly the miners) confirm the checks of Step [2]. If all checks pass, the ZEROCOIN_SPEND transaction is accepted and confirmed into the block chain. The transaction represents a transfer of value from the inputs of the redemption transaction to the destination Bitcoin address. Any unclaimed bitcoins are retained by the miner as transaction fees.

I am saying that we now have 2 million NXT bounty. NXT developers here can do this project!

James

https://github.com/zerocoin

reference source code for alpha zerocoin implementation

I think the above is the algo for zerocoin: http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf

They even have source code on top of bitcoin released, though my understanding is that it is a slow inefficient version.

I believe their algo is 100% annonymity and 100% coins received and implements a fully cash like behavior

1M NXT to port this to NXT does not sound unreasonable, it is a significant effort to understand the algo enough to port it properly.

Ripple can do fiat exchange, but almost nobody wants to use ripple.

YES!

Everyone that is developing code to work on top of NXT, eg. clients, AM, etc., when you publish the open source make sure you restrict its usage to NXT and specifically prohibit using it with NXT clones.

It will be totally open source as far as NXT usage is concerned, but no other clone will be able to use it as is. They would need to refactor it so much so that none of the original code is recognizable. Otherwise they would be open to copyright infringement.

Is there an international copyright lawyer lurking that can post a decent legalese paragraph for this?

Something like:

Usage of this software is prohibited for any platform other than NXT, specifically any and all NXT clones. You are free to look at the source code, but you are not allowed to run it on a public network other than the NXT network or NXT testnet. Doing so will violate this license and you will forfeit all other rights and be open to copyright infringement and any other legal remedy open to any NXT stakeholder.

As long as this software is run on the NXT network, the following applies. [insert standard license]

James

why not implement zerocoin's zero knowledge proof on top of NXT blockchain using AM?

James

Not a lawyer, but using common sense, when someone forges a block, he is simply receiving a fee. Sometimes no fee, sometimes big fee, but always the NXT already existed. There can be no printing of money if it is an earned fee. Anyway, the direction is the wrong way, they are receiving not sending, so not money emitter.

Now even for leasing forging power, unless NXT is categorized as money, I don't see how pooling forging power makes anyone a money processor. Leasing forging power does not involve sending NXT, so even if NXT is classified as money, that does not transmit money. I guess the entity that is forging could be attacked as the one that is transmitting NXT, but if it is just paying a contractual fee to the people who leased the forging, it wouldn't seem to be a money transmitter. After all any amount forged is a earned fee and if the agreement to lease forging power says that the people who loan the forging are owed a prorata share of the forging, the distribution of the forged fees is a distribution of earned fees. It would be like if Amazon had a program where a bunch of people could pool their affiliate income and all agreed to share based on number of clicks sent, instead of actual books sold. Any amounts Amazon sends back to the affiliates would be earned income, subject to taxation as revenue and not money transmission. At least that is my educated guess.

The only thing that could ever be construed as anything close to printing money would be BCNext creating the genesis block. However, the clever thing is that at the time of genesis block, the cost basis was 21 BTC, I don't have exact value of BTC at the moment of genesis block, but I think the total would have been less than $5000

Due to the minimal amount, I would think that it would fall under the De Minimis exemptions in most all jurisdictions, basically if the amount is small the law doesn't care too much. This compares to both emunies and etheriums million dollar plus fund raising. The law most certainly care and will do its best to get a share of that sort of windfall.

This could well be the reason the NXT genesis block was closed, $5000 might be the threshold for some jurisdictions.

James

I don't mind if anybody just takes what I write. There are bounties for writing for wiki, but since I was strongly advocating for marketing budget, I don't feel right working for bounties from that. Of course, if nobody writes articles that are needed, I would write whatever I can help with no bounty needed. I want more people to earn bounties as it will get more people involved.

I am hoping for my share of white paper bounty though.

James

rippled source code has been open for a while. My guess is that ripple needs to have 2/3'rds of the nodes following the rules to avoid the traitor general problem, so like bitcoin it can be attacked with 33%

ripple is summarized as colored coins implemented ontop of firstgen blockchain algos

James

No, you have it not quite right.

The trust relationships are purely between gateways and the customers. This is the way Ripple avoids darkNXT equivalent. Not only does an account have to be funded with a minimal amount of XRP (currently 20 XRP min), in order to accept a specific IOU, the user has to specifically set a trust line for that specific issue from that specific issuer with a specific maximum.

It is a real pain in the ass, but it pretty much eliminates any chance of ending up sending something to the wrong address.

So, once you get your acct funded and establish a trust line (just filling out a form from your wallet), then you can receive the IOU. You make a fiat deposit to your gateway, then the fiat is exchanged for the IOU.

Similar to NXT's Asset Exchange at the high level, with some very big differences.

a) In ripple anybody can issue any asset, I think three characters is the limit for Asset name. So in essence each asset gets variants, eg. BTC.bitstamp, NXT.peercover, etc

b) Ripple requires minimal XRP balance to do anything, including establishing a trust line or making a trade offer, so really 30 XRP is the practical minimum.

c) Ripple requires a trust line to be established before anybody can receive that issue. However, you can directly purchase it from the orderbook without any trustline

d) There is this thing called "rippling", which allows the ripple network to automatically convert IOU from one issuer to another issuer of the same asset, if you have it enabled. Pretty nasty if your USD.bitstamp gets rippled into USD.snapswap! USD.snapswap trades at 10% discount to USD.bitstamp. There is even an evil bot in ripple land that searches for hapless newbies that allow rippling between USD.bitstamp and USD.snapswap and automatically converts it. The bot makes an immediate gain of 5% to 10%

So, if anybody is afraid about ripple competing with NXT, rest assured, it can't. Ripple is designed for mass market consumers to exchange their local currency to another currency, across the world.

As far as the servers go, unless some entity gets control of 51% of servers, I doubt any funny business is possible. Everything is in a public ledger. Ripple is basically firstgen as far as immunity from 51% attack goes, eg. not immune at all. Very unlikely ripple would attack its own network as they need it to expand so they can continue to add the 48 billion XRP stockpile into the network.

Nothing is perfect and ripple is no exception. It does have a lot of corporate backing and it does have some utility, so it won't go away. I just don't see it growing by leaps and bounds. That being said, XRP value could easily double or triple or lose 50%, as it is not very liquid at all. Total daily volume of XRP trades are less than $250,000/day for all issues in ripple.

This is why I keep saying Ripple's function is to be a gateway of fiat <-> crypto, including NXT.

James

Gateways deal with all the govt regulations and the issuing of IOUs into the ripple network. Once in the ripple network, all the trades, etc. are done via consensus of distributed rippled servers. The gateways are not directly involved in ripple network transactions other than redemptions.

Not sure of the number of non-RL servers, but my guess is around 100 total rippled servers are running.

James

Ripples problem is that there are less than 50 active people in their community. The majority work at RL. NXT community at least 10 times bigger and the software releases just keep on coming out. New core releases, client releases, website releases, etc.

With ripple, everything goes through a centralized development process. I think they had one of the first colored coin implementations, but all the delays and now with AE coming out, emunie, etc. Ripple will have a difficult time keeping up.

That being said, Ripple is the only solution that is friendly with governments and like Coinbase it should escape the fiat governments war on bitcoin (crypto). I see ripple's place in the larger crypto universe as the fiat gateway for all the other crypto. That alone will ensure its survival, but it is a niche function. Important, but niche. Oh, they have another 48 billion XRP left to release and this will take literally years. Until then true value of XRP will be unknown.

It is kind of convenient to be able to pull out USD with whatever crypto I want to liquidate.

James

Great plan!

yes!!

OK, replace the word "recruiting" for all my usage of "marketing" in my recent posts.

We need to recruit as many people into the NXT community as possible.

I am not a marketing professional. I just know that marketing works. Let's spend NXT to recruit 100 highly capable people into the NXT community. Whatever you call that, that is a good thing.

msin, is that better?

James

Nearly one month has gone by and we are no closer to consensus. I am very concerned, not just for losing 10 million NXT, but the message that sends to the world.

OK, so lets do tech, lets do organic marketing. Is organic marketing free? Maybe second gen crypto won't exactly follow the Silicon valley model. I am not some marketing dweeb, I am a technical guy with some marketing experience.

I see risk for NXT due to competition and when there is competition, even a superior feature set loses if the competition has strong marketing. Are you saying that Microsoft Windows (not from Silicon Valley) was the better OS than Apple's (from Silicon Valley)?

Without competition, the organic approach is fine. Most Silicon valley organic marketing successes happen in the absence of strong competition because they come up with an entirely new product. Now, is emunie and etherium strong competition? I'm not sure. I think there is a chance they might be.

James

Is there a list of all the things that are needed to "actually build NXT"? Maybe I am totally offbase, but it seems that within a couple of months we get the killer TF functionality, plus all the other nice functionality. Clients much sooner, etc.

Whenever I lobby for spending on marketing, people refuse and say we need so much more tech. OK, please tell me what tech we need? Let's make a list of all the tech we need, come up with reasonable bounties that assures they get done, use the rest for marketing budget for the year.

We then propose the COMBINED tech/marketing list for a vote. We can do both, tech and marketing. Let's just not wait until April comes and CfB sends the 10 million to genesis, because he will if community has no consensus!

James

This is EXACTLY why I recommended we try to recruit people with our LTB spots. Marketing is indirect. Get the high quality people on board the NXT team. How many more jean-luc's are out there who will go into the etherium or other projects because they didn't know enough about NXT.

My guess is that a lot of people only know the anti-NXT propaganda. So they wouldn't even consider researching NXT, let along joining the NXT team.

We need to market this community. That is what sold me on NXT's future.

How can we get more and more quality people without a continual effort (money) spent in marketing. Trade shows cost money. Free rasberrys to influential people costs money. Marketing costs money.

WE are in a competitive situation

James