Jumblr - decentralized bitcoin mixer with 0.1% fee

[jl777]

I am not sure if this is the right place to post about this, but this weekend I wrote a SuperNET agent which implements the coinshuffle (http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf) using realtime offchain broadcast packets.

Once there are enough participants, the privacy achieved will be close to using bitmessage for mixing, eg very, very good.

You need to have a bitcoin RPC available locally and at no time do you lose control of your funds. I searched, but I could not find any other decentralized bitcoin mixer, so maybe mine is the first?

Since there are no servers to manage, the costs are low, but it does use the network and so I set the fee at 0.1%. This allows many rounds of shuffling for the same cost as the centralized mixers without any third party risk.

This all came together so fast (https://github.com/jl777/btcd/blob/master/libjl777/plugins/agents/shuffle777.c) it doesnt even have a name yet!

I am looking for people to help test this and also to market this service. It is implemented as a meta-exchange called "shuffle" within InstantDEX, but it really is a totally different type of function and it works with bitcoins or any bitcoin fork without any changes needed.

To go from the low level API to a usable service, I think the following things are needed:

1. Name
2. GUI
3. Testing
4. Marketing

I hope to find people that can help as the only thing I can do well is write C code.

James

[1714123598]

1714123598

[1714123598]

1714123598

[1714123598]

1714123598

[1714123598]

1714123598

[OROBTC]

...

jl777

Please post some more details of your project.  There are many of us interested in the topic of how to better to hide BTC transactions (to improve financial privacy).

I am not expert by any means.  But, I have found both bitmixer.io and SharedCoin (blockchain.info's mixing service) to be pretty good services, both charge under 1%.  And, importantly, are not scams.


[Unfortunately, I do not code, I cannot read C.  But, that is why we are a community here.  Good luck, keep us posted.]

[jl777]

...

jl777

Please post some more details of your project.  There are many of us interested in the topic of how to better to hide BTC transactions (to improve financial privacy).

I am not expert by any means.  But, I have found both bitmixer.io and SharedCoin (blockchain.info's mixing service) to be pretty good services, both charge under 1%.  And, importantly, are not scams.


[Unfortunately, I do not code, I cannot read C.  But, that is why we are a community here.  Good luck, keep us posted.]

https://blockchain.info/search?search=18144ad2e7c4f6ab8cd5b85fb794d943099085d50e4fcc1de6de3d11fc597531

the above is the first jumblr shuffle

when the shuffle starts, all participants create a brand new keypair
they also know all the participants NXT addresses
let us say A, B and C are shuffling
A would then encrypt his data using layered encryption
so vin and vout in 2 separate blobs of data
first it is encrypted to C, then that data is encrypted to B
this is sent to B, who peels off one layer
notice that now what B got from A is encrypted to C, but B cant see what the data is
B encrypts his data to C and then shuffles his data and the received data and sends it to C
C now receives and decrypts it and has the real data, but other than his own data he doesnt know if it was from A or B
now he broadcasts the full transaction to everyone
everybody verifies his data wasnt changed and signs it and broadcasts the signature
everybody constructs the full transaction from all the incoming signatures and they all submit to the network

The above process is fully automated, so you just need to issue an API call to allow the coinshuffle. there is also an API call that lets you initiate a shuffle round.

James

[TimRuffing]

I'm one of the authors of the CoinShuffle paper. Really fantastic to see that people are interested in the protocol!

I had a brief look at the code and I think there are several severe problems:

• You use authenticated public-key encryption (from the NaCl library). It has the property that a recipient can be sure who created a given ciphertext. This is exactly the opposite of what we need in CoinShuffle. In fact, the whole point of shuffling is to hide that information from the recipient.
  We need normal IND-CCA encryption, e.g., or DHIES.
  So your implementation does not provide anonymity (or unlinkability as dubbed in the paper).
  
• Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.
• The whole blame phase is missing, so there is no robustness against DoS attacks as described in the paper. This is actually not a huge problem for a first implementation for a first implementation but should be noted because you implemented currently only a subset of the full CoinShuffle protocol.

(The list is not necessarily complete; these are just the problems that I've seen immediately.)

The problem is that the paper as-is is written for crypto researchers and is quite high-level. I think the protocol is not overly complex but the devil is in the details as with all crypto.

I've just started a collaboration with Kristov Atlas. We will write a BIP draft including a more detailed, development-oriented specification of the protocol including all the nitty-gritty details. We also plan talk to wallet developers and I will definitively write some code as soon as a reasonable version of the BIP is there. Contributions and collaborations are welcome in all stages, of course.

There are also some open questions, e.g., how to find participants for the shuffling, and what to use for communication (on a network level). How is that done in your implementation?

[jl777]

I'm one of the authors of the CoinShuffle paper. Really fantastic to see that people are interested in the protocol!

I had a brief look at the code and I think there are several severe problems:

• You use authenticated public-key encryption (from the NaCl library). It has the property that a recipient can be sure who created a given ciphertext. This is exactly the opposite of what we need in CoinShuffle. In fact, the whole point of shuffling is to hide that information from the recipient.
  We need normal IND-CCA encryption, e.g., or DHIES.
  So your implementation does not provide anonymity (or unlinkability as dubbed in the paper).
  
• Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.
• The whole blame phase is missing, so there is no robustness against DoS attacks as described in the paper. This is actually not a huge problem for a first implementation for a first implementation but should be noted because you implemented currently only a subset of the full CoinShuffle protocol.

(The list is not necessarily complete; these are just the problems that I've seen immediately.)

The problem is that the paper as-is is written for crypto researchers and is quite high-level. I think the protocol is not overly complex but the devil is in the details as with all crypto.

I've just started a collaboration with Kristov Atlas. We will write a BIP draft including a more detailed, development-oriented specification of the protocol including all the nitty-gritty details. We also plan talk to wallet developers and I will definitively write some code as soon as a reasonable version of the BIP is there. Contributions and collaborations are welcome in all stages, of course.

There are also some open questions, e.g., how to find participants for the shuffling, and what to use for communication (on a network level). How is that done in your implementation?

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.

As far as conflict resolution, I use the ethernet method, ie. if something goes wrong, try again with a different set of participants. Since I am using a realtime network to do the comms, a full round will finish in less than a minute. i use InstantDEX orderbook to establish the list of participants.

James

P.S. I will add check for no duplicates

[jl777]

pushed a fix so that if any vout or vin is duplicated, it is rejected

Let me know if there are any other issues.

I use a broadcast protocol for all the comms, so correlating IP addresses will require packet level analysis, but even this will be close to noise level once there is significant network activity as the response time for all broadcast packets is randomized via the anti-Ddos mechanism built into SuperNET

What is known about the participants are their NXT addresses, but these are likely to be a onetime or temporary address. Using this, we get the curve25519 pubkey to do the encryption with. Only the destination's pubkey is known, the sender uses a randomly generated onetime (per packet) keypair. So no way to link the data to the published address.

The destination addresses are also fresh never before used addresses.

I am seeing a small round of 3 nodes complete in ~5 seconds. With 13 participants, I hope to achieve ~30 seconds per shuffle. So if one is messed up, it is no disaster.

James

[jl777]

its a good thing I added duplicate checking!
found a bug with 4 participants with a duplicated input. considering I started coding this last Friday, I am pleased at how fast it has come together. 3-way shuffles seem to work for both BTC and BTCD and should work for any bitcoin fork as I only use standard pay to pubkeyhash

./BitcoinDarkd SuperNET '{"plugin":"InstantDEX","method":"placebid","base":"BTCD","exchange":"jumblr","volume":0.01}'

using the github.com/jl777/btcd , the above will add an entry to the InstantDEX orderbook for "BTCD" in the meta-exchange "jumblr"
this propagates to all the SuperNET nodes with InstantDEX active.

./BitcoinDarkd SuperNET '{"plugin":"InstantDEX","method":"orderbook","base":"BTCD","exchange":"jumblr","allfields":1}'
the above is a way to see how many different nodes are ready to shuffle

./BitcoinDarkd SuperNET '{"plugin":"jumblr","method":"start","dotrade":1,"volume":0.01,"base":"BTCD","timeout":20000}'
the above starts a shuffle round.

For now, only up to 3 has been verified and 4 had a bug. by changing "base" to "BTC" or any other coin, it will shuffle that coin. For coins I dont have the address type and script type for, just get me that info and I will add it to the list of supported coins

James

[jl777]

turned out it wasnt a bug, just make sure when testing that you dont use a copy of the same wallet on two nodes!

I hope that others can test as I can only test with 5 nodes and it is better to be doing 13 nodes at once and I want to make sure that works

If anybody can work as a tester, I will be able to pay for time.

James

[Jean-Luc]

Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.

Is that the same as checking that no two recipient addresses are the same, once the shuffle reaches the last participant, or is there more to it?

Multiple participants submitting the same recipient account would be a trivial attack to counteract, however there is no way to protect against a real sybil attack in which multiple participants, each submitting a different recipient address, are actually controlled by the same entity.

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.

[jl777]

I just verified a 5 node shuffle. start to finish was about 12 seconds

http://explorebtcd.info/tx/8cfcfba6ef25443c5e9b9c0de5706f0809e9bd559dfbe072ef31d1239b2af41e

The most time is due to the serial nature of getting the full transaction to the final node. However, once the unsigned rawtx is broadcast, all nodes calculate their sigs and broadcast them, so the phase of collecting the sigs and constructing the fully signed tx will take about the same time, regardless of 3 or 13 nodes.

All these comms are happening offchain without any financial cost, so even if it is disrupted, then it is not a big loss. Of course, if somebody is actively sabotaging things, there would need to be a layer to blacklist the bad actors. But that sort of thing i will save for another weekend. Once there are significantly more than 13 nodes available to shuffle with, then it will be possible to generate historical statistics on the effect a specific node has on the success rate. Granted it isnt as elegant as the conflict resolution with fancy math, but with extra rounds it would be possible to statistically identify the bad actors. newbie accts would then be added to the shuffle group at the lowest priority.

For now, it would be nice to get some people testing this a bit more.

James

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

I also think that to be using specific shuffled change outputs in future shuffles will contaminate things, so while it is a bit better than the transparent unspents, it is nowhere near as private as the shuffled amounts (assuming all the shuffled outputs in a round are the same value)

By allowing shuffle rounds to happen every minute, it will be possible to reshuffle already shuffled outputs and the wallet can track how many shuffles (and participants) each unspent has gone through to create a privacy metric.

James

[jl777]

I made an improvement to the sending privacy. Instead of using a onetime keypair, I will just use a commonly known account (NXT genesis acct). that way all senders will look like the same sender and thus reveals no information

the old way of onetime keypair was good, but against an attacker that is monitoring and logging packet level data, some information would leak. not sure they can construct any meaningful statistical correlations from that, but by using the same fixed account for all senders, this is removed

In the same vein, the final step of broadcasting the sigs would be vulnerable to the attacker to allow IP correlation. it is not on the blockchain, so not as bad as it sounds, but still might as well protect this also. It will double the time to do a round as I will have to do the layered encryption, but since the code for this is already done, it wont take much more work to do.

The following is a simplified three node shuffle between A, B and C

All encryptions are done using the same sender, the genesis account, which has a known privkey and pubkey.

A encrypts his vin and vout and change from genesis to C, then encrypts the output of that from genesis to B and sends this to B. The sending to B is done via a global broadcast of an encrypted packet, so all nodes will receive it. Again the encryption of this packet is done as the genesis account sending to B.

The network layer decrypts the packet and if it is not garbage, it calls the jumblr incoming packet processing. Only node B will be able to decrypt this and it will look like it came from the genesis account, but B will know the NXT address that sent the packet as this was agreed to from the orderbook. However, this NXT address is just an abstract address not connected to anything else.

B now peels off the layer of encryption for the vin, vout and change. He also creates his own set of vin, vout, change and encrypts it as the genesis account to C. Then he scrambles the vins, vouts (change is treated as normal vout) and the shuffled set of encrypted vins, vouts are broadcast to the network, pretending to be the genesis account.

All nodes receive the packet, but only C can decrypt it and he also decrypts all the vins and vouts and is able to construct a raw transactions without any signatures. He then broadcasts this without encrypting. Since it is known C is participating in the shuffle, I dont think an non-encrypted broadcast of the unsigned rawtx is leaking any important information.

All nodes receive the packet, the ones participating in this shuffle, then validate the raw transaction to make sure their vin, vout and change are there and also that there are no duplicates. If all is good, they create a signature for their vin and broadcast it. (this is the weakest link right now as the first node in the broadcast packet will know their vin, but not their vout)

All the participating nodes assembled a signed transaction out of the incoming sigs and when all signatures have arrived, they check their mempool to see if the transaction has already arrived from another participant. If not, they sendrawtransaction.

I hope the above clarifies my implementation. Any flaws found will be fixed and the leakage of IP address to vin in the sig broadcast seems to be the biggest leak, so I will fix that next

James

[box0214]

let me get this straight. this requires use of 3 block chains? btcd, btc, and nxt? so do we have to download all 3 blockchains on our local to utilize this decentralized coinshuffling?

[iCEBREAKER]

let me get this straight. this requires use of 3 block chains? btcd, btc, and nxt? so do we have to download all 3 blockchains on our local to utilize this decentralized coinshuffling?

BTCD and NXT are very low volume, so they are worse than useless for obfuscating BTC tx.

Any significant amount of BTC volume sticks out like a sore thumb on the other two (silent abandoned ghost town) chains.

Use Monero and XMR.to if you want real (ie on-chain zero-knowledge) unlinkablity for your BTC.

[_mr_e]

let me get this straight. this requires use of 3 block chains? btcd, btc, and nxt? so do we have to download all 3 blockchains on our local to utilize this decentralized coinshuffling?

BTCD and NXT are very low volume, so they are worse than useless for obfuscating BTC tx.

Any significant amount of BTC volume sticks out like a sore thumb on the other two (silent abandoned ghost town) chains.

Use Monero and XMR.to if you want real (ie on-chain zero-knowledge) unlinkablity for your BTC.

Doesn't seem like you have any clue how this actually works. The volume on those two coins has absolutely no importance on the api's he is using here.



without massive spreads, costs, volatility and other risks.

[jl777]

let me get this straight. this requires use of 3 block chains? btcd, btc, and nxt? so do we have to download all 3 blockchains on our local to utilize this decentralized coinshuffling?

for now it is the quickest way to get it working as I built it on top of InstantDEX

But the BTCD blockchain is not needed even now for this to work for BTC. It is using the NXT address just for a directory. So it would be possible to make it just require the BTC blockchain

[jl777]

let me get this straight. this requires use of 3 block chains? btcd, btc, and nxt? so do we have to download all 3 blockchains on our local to utilize this decentralized coinshuffling?

BTCD and NXT are very low volume, so they are worse than useless for obfuscating BTC tx.

Any significant amount of BTC volume sticks out like a sore thumb on the other two (silent abandoned ghost town) chains.

Use Monero and XMR.to if you want real (ie on-chain zero-knowledge) unlinkablity for your BTC.

There is no converting of BTC to anything. The coinshuffle creates a BTC transaction which uses the BTC blockchain, which is far more volumes than the monero blockchain

the shuffle tx never hits either the NXT or BTCD blockchain. so their volumes are irrelevant

So if you are saying that there is a problem with the coinshuffle algo, I am eager to hear how it is inferior as I am implementing the coinshuffle (without the conflict resolution for now)

As amazingly good that xmr is, I think BTC -> BTC is a much easier path as it doesnt have to go through a market trading. unless you are saying that xmr is better than btc?

[iCEBREAKER]

As amazingly good that xmr is, I think BTC -> BTC is a much easier path as it doesnt have to go through a market trading. unless you are saying that xmr is better than btc?

XMR isn't "better than" BTC for all purposes, but on-chain mixing (via ring signature+steal addresses) is infinitely superior to off-chain obfuscation.

[TimRuffing]

@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?

Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.

Is that the same as checking that no two recipient addresses are the same, once the shuffle reaches the last participant, or is there more to it?

Multiple participants submitting the same recipient account would be a trivial attack to counteract, however there is no way to protect against a real sybil attack in which multiple participants, each submitting a different recipient address, are actually controlled by the same entity.

Right, this cannot be prevented. The reason checking for checking for duplicates is indeed different and there's more to it than just checking at the end.

Consider a shuffle of 50 participants with peers P1, ..., P50 (in that order). The attacker controls the two peers P2 and P50. Without the duplicate check, the attacker can break the unlinkability of P1 entirely.

The attack is as follows:
P2 (attacker) receives a single ciphertext from P1 (technically, it's a list of ciphertexts with one entry so far) and removes one layer of encryption, resulting in another ciphertext C1. C1 has still 49 layers of encryption and the inner plaintext is the output address OUT1 of P1.

P2 is now supposed to add his own ciphertext C2 (again 49 layers of encryption, inner plaintext his output address OUT2).
However P2 just duplicates the ciphertext C1, i.e., sets C2 = C1. So P2 sends in fact [C1, C1] to P3.

Then the protocol continues normally but P1's output address OUT1 is now the only one that is there twice. Now assume that the honest participants P3, ..., P49 do not check for duplicates after decryption. The last participant P50 (attacker), who removes the innermost layer of encryption, will obtain a list of 50 output addresses. All of these addresses will be different except for P1's output address OUT1, which is the only address that appears twice in the list! So P50 just knows P1's output address, i.e., unlinkability is totally broken for P1.

To ensure that the attack remains undetected, P50 corrects the list of output addresses before publishing it, i.e., P50 replaces one of the OUT1 entries by an address under the control of the attacker. Note that P2 will not complain that his output address is not there in the final list, because P2 is controlled by attacker, too.

So the attacker can fully deanonymize P1 with only two peers in the right positions. In contrast, if the protocol is implemented correctly, the attacker needs 49 peers to fully deanonymize P1, i.e., everybody expect P1 need to be malicious.

This example where the attacker is in the second and the last position is the worst case for P1 and easy to explain, but the attack works also if the attacker is in other positions and wants to decrease the size of the anonymity set for other peers.

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.

[Jean-Luc]

Thanks for the explanation, now I added a check for duplicate data at each processing step.

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. If you take a look at the current way public keys are generated based on secret phrase: https://bitbucket.org/JeanLucPicard/nxt/src/369546f91ba32142562c18d224369ea64a3f0720/src/java/nxt/crypto/Crypto.java?at=master#Crypto.java-63 , for shuffling I have added generation of one-time keys based on secretPhrase plus known nonces:

Code:

    public static byte[] getKeySeed(String secretPhrase, byte[]... nonces) {
        MessageDigest digest = Crypto.sha256();
        digest.update(Convert.toBytes(secretPhrase));
        for (byte[] nonce : nonces) {
            digest.update(nonce);
        }
        return digest.digest();
    }

    public static byte[] getPublicKey(byte[] keySeed) {
        byte[] publicKey = new byte[32];
        Curve25519.keygen(publicKey, null, Arrays.copyOf(keySeed, keySeed.length));
        return publicKey;
    }

    public static byte[] getPublicKey(String secretPhrase) {
        byte[] publicKey = new byte[32];
        Curve25519.keygen(publicKey, null, Crypto.sha256().digest(Convert.toBytes(secretPhrase)));
        return publicKey;
    }

    public static byte[] getPrivateKey(byte[] keySeed) {
        byte[] s = Arrays.copyOf(keySeed, keySeed.length);
        Curve25519.clamp(s);
        return s;
    }

    public static byte[] getPrivateKey(String secretPhrase) {
        byte[] s = Crypto.sha256().digest(Convert.toBytes(secretPhrase));
        Curve25519.clamp(s);
        return s;
    }

and for the one-time keys used in the shuffle, shuffleId and recipientId are used as nonces. Then the one-time sender public key is added to the encrypted data, to allow its decryption by the recipient, yet it is not possible for the recipient (or anyone else) to tell who the sender of each encrypted data is.

If the blame phase needs to be entered, each participant discloses the array of sha256 digests ("keySeeds") used to generate each public/private key pair he used to encrypt to each of the next participants, which allows anyone to decrypt the content ot the data.