Jumblr - decentralized bitcoin mixer with 0.1% fee

[mobnepal]

What actually is the mixer means? As i haven't heard this before so i came to this thread but after reading all post i can't get any clue about what the mixer is actually. If anybody don't mind to explain me can you?

[1714842944]

1714842944

[1714842944]

1714842944

[Patejl]

What actually is the mixer means? As i haven't heard this before so i came to this thread but after reading all post i can't get any clue about what the mixer is actually. If anybody don't mind to explain me can you?

Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
Of course this is just the simplified version of it, most mixer noawadays provide many customizations for added privacy. As as you can probably guess, people do it to hide their tracks that people can track through their transactions.

[iCEBREAKER]

What actually is the mixer means? As i haven't heard this before so i came to this thread but after reading all post i can't get any clue about what the mixer is actually. If anybody don't mind to explain me can you?

Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
Of course this is just the simplified version of it, most mixer noawadays provide many customizations for added privacy. As as you can probably guess, people do it to hide their tracks that people can track through their transactions.

Step 0) You make the brave decision to trust a third party won't steal your coins, isn't a honeypot, and isn't compromised by hackers/TLAs.

[TimRuffing]

For the encryption, for each sender we generate a new public/private key pair using curve25519, unique for each sender/shuffle/recipient combination, and then use this plus the recipient public key to generate a DH shared key, then use AES for the actual encryption.

Looks good. How exactly do you use AES? It must be something that provides authentication, i.e., either an authenticated mode (such as GCM) or a MAC must be added in the proper way.

Independently of James' work, we are also working on implementing coin shuffling using your algorithm in the upcoming version of Nxt. The blame phase is really the complicated part to get right, and here we are taking the approach to disclose the one-time keys used by each participant, to find and penalize the rogue participant. When ready, we would certainly welcome you to have a look at our implementation too.

Sorry, I forgot to reply to that. I offered that already to lyaffe some time ago. I'm not sure if I have the time to go through it line-by-line but I can certainly have a close look.

[jl777]

What actually is the mixer means? As i haven't heard this before so i came to this thread but after reading all post i can't get any clue about what the mixer is actually. If anybody don't mind to explain me can you?

Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
Of course this is just the simplified version of it, most mixer noawadays provide many customizations for added privacy. As as you can probably guess, people do it to hide their tracks that people can track through their transactions.

Step 0) You make the brave decision to trust a third party won't steal your coins, isn't a honeypot, and isn't compromised by hackers/TLAs.

Do you realize with Jumblr, there is no third party that you have to trust?
You dont send coins to any address other than one that you specifiy
plz read the coinshuffle whitepaper for the details.

decentralized mixer != centralized mixer

[Jean-Luc]

Actually, I don't think we use AES in authenticated mode, here is how it is called, using the BouncyCastle library:

Code:

    public static byte[] aesEncrypt(byte[] plaintext, byte[] key) {
        try {
            byte[] iv = new byte[16];
            secureRandom.get().nextBytes(iv);
            PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
                    new AESEngine()));
            CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
            aes.init(true, ivAndKey);
            byte[] output = new byte[aes.getOutputSize(plaintext.length)];
            int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
            ciphertextLength += aes.doFinal(output, ciphertextLength);
            byte[] result = new byte[iv.length + ciphertextLength];
            System.arraycopy(iv, 0, result, 0, iv.length);
            System.arraycopy(output, 0, result, iv.length, ciphertextLength);
            return result;
        } catch (InvalidCipherTextException e) {
            throw new RuntimeException(e.getMessage(), e);
        }
    }

where the shared key is obtained as:

Code:

    public static byte[] getSharedKey(byte[] myPrivateKey, byte[] theirPublicKey) {
        return sha256().digest(getSharedSecret(myPrivateKey, theirPublicKey));
    }
    private static byte[] getSharedSecret(byte[] myPrivateKey, byte[] theirPublicKey) {
        try {
            byte[] sharedSecret = new byte[32];
            Curve25519.curve(sharedSecret, myPrivateKey, theirPublicKey);
            return sharedSecret;
        } catch (RuntimeException e) {
            Logger.logMessage("Error getting shared secret", e);
            throw e;
        }
    }

However, after encryption, the full list of ciphertexts that each participant sends to the next becomes a part of the transaction bytes that are signed by this participant (using his regular private key, as derived from the secret phrase without additional nonces, as done for all Nxt transactions). So modifying anything inside the encrypted payload will invalidate the transaction and it will no longer be acceptable in the blockchain. And the transaction that the next participant submits, includes the hash of this previous transaction, so is only valid as a response for this specific encrypted payload.

Note that we use the same method for encrypting messages between Nxt accounts, with the difference that the shared key is derived adding a random nonce for each message, and the regular secret phrase, same for every transaction of this account, is used:

Code:

    public static byte[] getSharedKey(byte[] myPrivateKey, byte[] theirPublicKey, byte[] nonce) {
        byte[] dhSharedSecret = getSharedSecret(myPrivateKey, theirPublicKey);
        for (int i = 0; i < 32; i++) {
            dhSharedSecret[i] ^= nonce[i];
        }
        return sha256().digest(dhSharedSecret);
    }

and after the AES encryption step, same as above, the encrypted text becomes part of the transaction bytes that are signed by the sender.

[Jean-Luc]

Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.

This is how a centralized mixer works. The way coin shuffling will work in Nxt is a bit different:

You announce that you want to shuffle for example 10,000 NXT, or join an existing shuffle that somebody else started. You enter in your wallet the recipient address, known only to you, where those 10,000 NXT should be sent. Those are deducted from your account. Each shuffle participant does the same (shuffling exactly the same amount), and each shuffle when created is set to require a certain number of participants (say 20) and the amount being shuffled. When the shuffle completes, each participant finds that amount in the recipient account he specified, yet none of the other participants, and no external observer, can find out which recipient account belongs to which participant.

Shuffling will be possible not only for the NXT coin itself, but for any asset on the NXT Asset Exchange too.

The jumblr service that James is working on is for BTC and similar coins, but the idea is the same.

[jl777]

@TimRuffing

in your paper you say that the change can also be shuffled, but I do not see how it can avoid being correlated due to the specific amount of the change relative to the input. What I have done is separate the outputs into the shuffled amounts and change amounts and treat the change outputs at just one step above the normal unspents.

This is a misunderstanding actually. You don't get any privacy for the change, so we don't say that the change can be shuffled. The paragraph in the paper just clarifies that you can add change addresses to the list of output of the CoinJoin transaction in case some peer does not have the exact shuffle amount (which will be almost always the case, just as for ordinary transactions). As far as I understand, this is what your implementation does?

yes, I shuffle the change treating them as ordinary outputs, but categorize it as "jumblrchange", so it is not counted as being shuffled. though i think it is marginally more private than normal outputs, so given a choice for using inputs it seems the jumblrchange would be a bit better than ordinary unspents

I think you missed that I am generating onetime keypair from the sender side. Only the receiver's pubkey is known.
    crypto_box_keypair(onetime_pubkey.bytes,onetime_privkey.bytes);
    if ( (cipher= encode_str(&cipherlen,src,len,destpubkey,onetime_privkey,onetime_pubkey)) != 0 )

Since this onetime keypair is generated for each packet, I do not see how this is linkable.

I missed that indeed. However, it is still linkable even with new keypairs: assume again that the attacker controls P2 and P50. Then P2 sees which key belongs to P1, and P50 can use that knowledge the determine P1's output address.

You say that this is fixed now by using a common account. How does that work? Did you also change the encryption scheme? The current scheme needs a the secret key even for encrypting. So I don't see how that should work, because you obviously cannot give that secret key to everybody.

Actually I think you assume that it is obvious the secret key cannot be given to everybody, however there is not basis for this assumption.

#define GENESISPRIVKEYSTR "1259ec21d31a30898d7cd1609f80d9668b4778e3d97e941044b39f0c44d2e51b"

The genesis account in NXT is a special account and its privkey is known. So I can use the genesis privkey to encrypt all messages and for decrypting, all nodes use the genesis pubkey (in addition to their privkey)

I did feel there was some sort of clever attack like your P2+Plast and so it is good to go to no leakage at all. If everybody is using the same account, it is like a public payphone, a call from that number doesnt link to any specific person (we ignore the cameras recording the payphone as it is only an analogy)

James

[TimRuffing]

Actually, I don't think we use AES in authenticated mode, here is how it is called, using the BouncyCastle library:

Code:

    public static byte[] aesEncrypt(byte[] plaintext, byte[] key) {
        try {
            byte[] iv = new byte[16];
            secureRandom.get().nextBytes(iv);
            PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
                    new AESEngine()));
            CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
            aes.init(true, ivAndKey);
            byte[] output = new byte[aes.getOutputSize(plaintext.length)];
            int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
            ciphertextLength += aes.doFinal(output, ciphertextLength);
            byte[] result = new byte[iv.length + ciphertextLength];
            System.arraycopy(iv, 0, result, 0, iv.length);
            System.arraycopy(output, 0, result, iv.length, ciphertextLength);
            return result;
        } catch (InvalidCipherTextException e) {
            throw new RuntimeException(e.getMessage(), e);
        }
    }

Hm, the security argument depends on the fact that the whole encryption scheme is IND-CCA secure, and CBC does not ensure that. I have even a concrete attack idea with CBC in mind but that would require some additional thinking... (and I prefer to think about countermeasures. ). The general problem is similar to the one with the duplicates. Instead of just duplicating a ciphertext, P2 can try to duplicate and change it such that it decrypts to something similar not exactly the same plaintext. Because it is not exactly the same plaintext, the duplicate check does not help here. A later peer then sees that there are two related plaintexts.
IND-CCA provides exactly the property that you cannot change the ciphertext in a meaningful way. If you try to change it, it does not decrypt at all (decryption error) or it decrypts to garbage, which is not related to the original plaintext anymore. 

Note that the signing that you've described does not help either, because the attacker is one of peers and not just in the network. 

The safe choice is to use GCM mode, which is available in BouncyCastle. Probably you just have to replace CBCBlockCipher by GCMBlockCipher but I haven't read the docs.

Actually I think you assume that it is obvious the secret key cannot be given to everybody, however there is not basis for this assumption.

Okay, my point was the other way: I assume it's not obvious that it is okay to give out the secret key. Indeed, if you look at the description of NaCl, the security model section (http://nacl.cr.yp.to/box.html) and the referenced paper do not claim that the message stays secret in a situation where the senders's secret key is known, even if the recipient's secret key is not.

Still, publishing the sender's key seems to be for that NaCl scheme, and everything else would surprise me, but I haven't looked at it in detail...

[mobnepal]

What actually is the mixer means? As i haven't heard this before so i came to this thread but after reading all post i can't get any clue about what the mixer is actually. If anybody don't mind to explain me can you?

Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
Of course this is just the simplified version of it, most mixer noawadays provide many customizations for added privacy. As as you can probably guess, people do it to hide their tracks that people can track through their transactions.

Thanks for good explanation brother. Maybe i will also try to giveaway bitcoin payouts from my site.

[jl777]

Okay, my point was the other way: I assume it's not obvious that it is okay to give out the secret key. Indeed, if you look at the description of NaCl, the security model section (http://nacl.cr.yp.to/box.html) and the referenced paper do not claim that the message stays secret in a situation where the senders's secret key is known, even if the recipient's secret key is not.

Still, publishing the sender's key seems to be for that NaCl scheme, and everything else would surprise me, but I haven't looked at it in detail...

OK, it seems safer to just use GCM mode of AES using standard shared secret with a onetime sender keypair

Thanks for the feedback.

James

[jl777]

@timruffing:

On the attack vector with the second and last positions occupied by the attacker. The fact that the initial node is only sending its own vins/vouts seems to create this attack, but of course this streamlining of data offers a lot of speedup.

Anyway, I have an idea to avoid this attack. Why couldnt the initiator of a shuffle occupy the first two spots? this would protect the first node from the 2+last attack wouldnt it? Granted if the attacker is in spot 3+last, it would still leak information, but at least there are two possible accounts and by making one of them like the change outputs and not expecting additional privacy, maybe this will reduce the attack?

Alternatively, what do you think about all (more?) nodes sending their vin/vout to the first node? That would seem to totally thwart the 2nd+last attack

James

[Jean-Luc]

But then you trust the initiator of the shuffle to not be an attacker himself. If he occupies the first k spots, it is as if the shuffle starts from k+1. At least in the Nxt core implementation, the shuffle creator is equal to all other participants, and will be penalized the same way if discovered to cheat.

I have all parts of the algorithm implemented and working now, including the blame phase of detecting and penalizing rogue participants who either submit invalid data or do not submit their transactions in time, with all integration tests passing. What remains is only to make the shuffle process user friendly, by automating the submission of process/verify/cancel transactions.

For the AES encryption, I now use GCMBlockCipher:

Code:

    public static byte[] aesGCMEncrypt(byte[] plaintext, byte[] key) {
        try {
            byte[] iv = new byte[16];
            secureRandom.get().nextBytes(iv);
            GCMBlockCipher aes = new GCMBlockCipher(new AESEngine());
            CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
            aes.init(true, ivAndKey);
            byte[] output = new byte[aes.getOutputSize(plaintext.length)];
            int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
            ciphertextLength += aes.doFinal(output, ciphertextLength);
            byte[] result = new byte[iv.length + ciphertextLength];
            System.arraycopy(iv, 0, result, 0, iv.length);
            System.arraycopy(output, 0, result, iv.length, ciphertextLength);
            return result;
        } catch (InvalidCipherTextException e) {
            throw new RuntimeException(e.getMessage(), e);
        }
    }

[jl777]

But then you trust the initiator of the shuffle to not be an attacker himself. If he occupies the first k spots, it is as if the shuffle starts from k+1. At least in the Nxt core implementation, the shuffle creator is equal to all other participants, and will be penalized the same way if discovered to cheat.

I think in all variants the assumption is that there are non-attacker nodes participating. if the attacker is a passive statistics gathering attacker, i dont see how anything can be done to prevent (or even detect) such info gathering attackers

But if you control, the first two slots and assume at least one other non-attacking node, at least the initiator will get some privacy.

It would be interesting to see the math on how many shuffle rounds are needed to obtain practical privacy. I am thinking at least 10. Assuming there are 100 nodes ready to shuffle, then by making 10 random groupings of ~10 nodes to shuffle with, unless the attacker controls the majority of nodes, it seems to gain privacy.

James

[.LooTz.]

https://soundcloud.com/coremediaradio/jumblr Here is the latest on Jumblr fellas