Topic: NXT :: descendant of Bitcoin - Updated Information - page 1263. (Read 2761629 times)

It's definitely doable (assuming their math checks out).

What I can gather so far is they base it on a variation of the zero-knowledge proof - some mathematical magic that allows you to prove that you own a secret in multiple ways, thus decoupling one check from another.

So you mint an off-chain coin and then spend it again, this time revealing the secret, so there are no double spends.

It's like having a special challenge-response chip. No point in saving challenge or response and no way of linking several challenge/responses to your chip. Once you spend it, the "chip" is destroyed.

Nice!  

If the STL file is small enough, would you be willing to put the STL on the blockchain as a AM payload?   You know, for history's sake.

Tell us CfB and JL, please.

I love it. hat's why I read everything here hehehe I don't work as an engineer only because my income is much higher with my current job. /Offtopic!

Maybe, I am a bit rusty when it comes to theoretical computer science. Let's flush my brain a bit.

I don't know why splitting up larger transactions into smaller chunks couldn't be a valid way to fulfill larger transactions in the long run without any traces?

Let me give you an example:

Let's assume, we have a secure way to make transactions from one account to another. For instance, via a escrow account.
w, x, y, z are balances of the respective accounts; t1, t2 are points in time

Who paid what to whom? I can't tell. Maybe, anyone else can.

One could say, well this example is really artificial and a real transaction graph is actually sparse with completely different amounts. So you actually get something like that:

Well, that is why I ask why splitting up larger transaction in to smaller pieces in order to cover them up into the masses. In this case, if you really want to transfer money anonymously from one account to another you must either wait or pay a variable fee. The variable fee results from dismissing the remainder of a larger transaction if you aren't willing to wait for the completion.

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

Sorry. I do not believe in ETAs. They do not work.

Nice

regarding the mixing.

BCNext once said:
- may be now is time for him to reveal details (to developers).

not bad

Since it's January, would you happen to have a better estimate?

I just designed and 3d-printed a NXT-keychain

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.

Here is version 1.4 of my Windows NXT client "NXT Solaris". Still closed-source, so relax...

Download
64-bit Version: NXTSolaris-v1.4-64bit.zip (44.6 MB) – Download here
SHA256 checksum for NXTSolaris-v1.4-64bit.zip: 6C603D8EB47CDF7A054DCEC950E4B08A134A9D2C623C29DC8EB37632DEC6977F

32-bit Version: NXTSolaris-v1.4-32bit.zip (43.8 MB) – Download here
SHA256 checksum for NXTSolaris-v1.4-32bit.zip: 256CF00E1A6C1242556CA4ECAEBB2D0E0C6FAA04CD14CC68B8E850D02C966EAD


For screenshots and everything else please visit: http://nxtsolaris.wordpress.com/


Installation
Simply unzip the archive and run the NXTSolaris.exe file.

The current version 1.4 is not compatible with previous versions, so please delete any existing NXT Solaris files before updating to 1.4.

Roadmap
1.) Move current version of my code to XE5 and release closed source 32-bit and 64-bit versions for Windows. [DONE]
2.) Refactor code to a MVC architecture, so that I can create separate GUIs while using the same version of the business logic code. [90% DONE - Remaining necessary work will show up while doing 3.) ]
3.) Create new GUIs for Windows and OS X using the same business logic, but based on the cross-platform Firemonkey libraries.
4.) Release Windows version (32 and 64 bit) based on FireMonkey.
5.) Release source-code for FireMonkey Windows version.
7.) Release OSX version based on FireMonkey.
8.) Release source code for FireMonkey OSX version.


Changes for v1.4
-Added market charts (DGEX, Bter, NxtChg, Vircurex) and exchange rates (from cyptocoincharts.info)
-Added feature to show NXT assets in other currencies in the personal account management
-You can now synchronize your address book after a NXT Solaris update with default address book that I ship that holds account numbers of exchnages, faucets and such
-Implemented orphan block cleanup
-Moved to Delphi XE5 in preparation for multiplatform support and open-source FireMonkey GUIs
-Windows 32-bit and 64-bit versions are now available

Thanks to NxtChg.com for doing the small animation in the status bar!

Donations
I hope you like my client and I’d be extremely happy to see some donations for the future of this project!

NXT: 1758531264253431177

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

Agree.

What will protect users would be if the client (by default) creates a very strong (but easy to memorize and type) password that the user must retype in the "next screen".  The user should have the option to override that and create their own password, but by default the client should create one for them Electrum style. Just copy the word list and code from Electrum


https://raw.github.com/spesmilo/electrum/master/lib/mnemonic.py

Electrum 12 random word passwords are very strong, easy to type, and easy to memorize

If anyone has never used Electrum, just download the portable version

https://electrum.org/download.html

and rum it first time and see how it creates 12 word password ("seed") on the first run.


Something like this should be integrated with a client. 

Thank u, but I'll read the whitepaper and google around.

Don't worry. Remember the days when BTC was less than a dollar? These are those days for NXT. These drops are all excellent opportunities to buy. Don't look back some day and kick yourself for not buying now.