Nxt :: NXTcash - progress and discussion

[sirnoah]

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

[1715674565]

1715674565

[1715674565]

1715674565

[1715674565]

1715674565

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