Topic: Jumblr - decentralized bitcoin mixer with 0.1% fee - page 2. (Read 4112 times)

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.

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.

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?

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

@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

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

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.

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

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

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

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

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?

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

...

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

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