Topic: CoinJoin: Bitcoin privacy for the real world - page 36. (Read 294672 times)

About calling external functionality through the shell, we're very aware this is a very dangerous practice, and are working towards more direct access to the libbitcoin functionality for all languages (https://gitorious.org/libbitcoin-bindings or new electrum like protocols implemented for all languages and easy to use) so these dangers won't exist. Just for the proof of concept this is the way that works now for us to keep testing and developing. We welcome all security auditing and will refactor the code to make security more explicit.

Please keep analizing the code and providing feedback, its really appreciated!.

Cheers!

You're right, added COPYRIGHT notice, made it AGPL for now, since this is proof of concept we will think about a more permissive license but we're comfortable with AGPL to encourage a more open ecosystem.

You need to add a statement as to what license the code is released under; without one the code is not open source as all creative works are copyrighted by default.

Hi ppl, this is Pablo, co-implementor of CoinJoin proof of concept with Amir (sorry don't have an account here so writing through Amir's account):

New "release" of CoinJoin, features:

 * Server now has a public "lobby" to serve as meeting point (front page announcing "open" coinjoins)
 * Creator of coinjoin can choose amount, so its no longer just 0.01, now you can join arbitrary amounts
 * The client can now resume the session in different runs, so you can actually run it in several times to finish the coinjoin and wait for other ppl joining (you had to keep it open before).


You can check the video at (shows using the tool and lobby):

 * http://www.youtube.com/watch?v=rr6DeziHdFs

Test server still at:

 * http://7vxb75tbnszhy2go.onion

We keep working on the implementation and more features so donations welcome at: 1H1LP8UhGR5wK9WppBMwewCddwdebYqwwT
(ideas are the ones from his thread including: serverless setup, casual use for joining tx and fees...).

Code at: https://github.com/calafou/coinjoin, free and open source ;-)

Cheers!

Oh come on, who does a live test anywhere near keys with 200 BTC on them? That's staggering confidence.

jdillon: I think all your points are reasonable ones.

I'd advise people doing work on this stuff to write robust mechanisms first, and only then follow up with GUI's and other gloss. The experts who should be playing with these tools initially don't need GUI's to do so.

I'd also advise people to release implementations that only work on testnet until enough time has passed to have some hope that the bugs have been shaken out - it's easy to lose money fast with wallet related code and we can't afford to get people burned initially.

I'd like the administrators of this bounty to make clear some conditions for a large portion of the reward to be given:

• Testing - It has been rumored that the recent 200BTC fee transaction was the result of a failed CoinJoin transaction. Regardless of whether or not that is true, unittests and good coding practices should be taken into account.
• # of users - Take into account the # of potential users. Solutions applicable for a larger % of the total Bitcoin userbase are much more important than solutions not so widely applicable. Solutions that can be used 'by default' are far more valuable than ones that can-not.
  
• Licensing - Part of being widely applicable is the license of the software. I am in RMS's camp here, and while normally it makes sense to use restrictive open-source licenses in a tit-for-tat scenario, like him I too believe that sometimes getting the idea as widely used as possible is the right approach. Note that RMS has specifically said this in relation to Bitcoin's MIT license. Implementations should use licenses no more restrictive than LGPL.
  

As the largest individual contributor to date I hope my words are taken seriously.

Yes, I am writing this in response to Amir's proof-of-concept, which is nice to see happen quickly for people to play with, but to see it reported in Bitcoin Magazine already as "and today, two Bitcoin developers in Spain have come up with a solution." very much bothers me given how far it is from a complete solution.

For one thing, the code has rather frightening constructs such as:

call("sx rawscript [ %s ] [ %s ] | sx set-input txfile.tx %s > signed-tx" % (signature, pubkey, input_index))

I would not in the least bit be surprised if there is either a shell exploit already present, or there will be one in the future. In addition there is no license for the code, and it depends on sx/libbitcoin with are AGPL licensed.

tl;dr: I would be happy to see Amir and co receive a token BTC for their efforts, but they have to put a lot more work in for what they have done to be worth more than that.

Thanks for the heads-up of this thread.

I spent a month working on a peer-to-peer Bitcoin privacy solution back in May, it's called BitPrivacy.

It's aim is a fully decentralized solution providing strong privacy, and as such it is more ambitious and complicated than genjix's CoinJoin.

A decentralized solution spreads the legal risk over everyone running nodes - I'd rather be a developer of privacy software than someone running a privacy service. I spent a couple of days reading the laws of my country (UK), and they are surprisingly broad.

Technically the plan is to have a peer-to-peer network over Tor. Privacy is achieved by everyone writing their inputs to the network; when all are supplied they make a new Tor connection & write their outputs.  

BitPrivacy version 0.2 featured:
- Bitcoinj-based
- Arbitrary N-party transaction schemes
- Blind signatures via the Bouncy Castle library
- All communication over a DHT, via the mature TomP2P library
- Aggressive trading strategy - it tries to transact with everyone simultaneously

Some things I didn't get round to:
- Peer discovery & running a well-known node - you have to enter an IP to connect to
- Adding a command-line switch for ProdNet (an easy code change)
- Tor

You can download the jar file right now, and join some testnet coins between N wallets. There is a thorough description of the protocol at DETAILS.md, and the threat model and defenses are in THREATS.md. The code quality is rough, but it does have some test cases. Forks, code-plundering, etc all welcome!

I actually put in a grant request to the Foundation for this. I don't think I'll ever get it, at least it gave me an incentive to document everything.

Interesting...  would like to hear an opinion, too. (PMed Tom)

Shit - I thought I had the record for paying the most fees ever (due to creating a raw tx when way too tired).

I hope they can get that back (in my case I got most of it back).

Good start ... even the most massive of constructions begin with a single stake in the ground.

Hmm. Novel idea to mix coins into mining pool fee. Untraceable.

Seriously, there is a chance ASICMINER will help the poor soul(s).

Uh. Does someone have a bug to report for a tool from this thread?  (If you want you can report to me in pgp email anonymously.)

This seemingly got lost.  Can anyone explain what the difference of the proposed scheme here is to what seems to be already implemented?

Why have servers at all? With I2P it would also be really easy to use DHT to set things up. Instead of a unique URL you could have a unique random string of any kind. Or even fully random peer selection.

Server:

• Powerless: has no real power. It's just a meeting point for participants to exchange data.
• Uninformed: has no special information except that which is public (and goes on the blockchain). There's no mapping between inputs and outputs because clients add their data in successive stages.
• Controls nothing: holds no funds. Funds and private keys are stored client side. Signing is done client side.
• Tor service. You can take down hidden services, but Silk Road and all the other services are still running around since 2+ years. Code is opensource so you can setup your own services. Users just paste the URL into the software. It's not really centralised. An analogy: BitcoinSpinner uses the BitcoinSpinner server, but in Electrum you choose your server and can setup your own.
• Extensible. Adding the p2p mechanism for exchanging data can easily be done. Replace the ServerInterface class methods in client.py with your own: https://github.com/calafou/coinjoin/blob/master/client.py Then the URL in the software becomes a shared secret. We designed the software with this in mind.

More technical info: http://sx.dyne.org/anontx

We've delivered usable software, simple for grandma (money goes in, money goes out), requires no blockchain or bitcoind, easy to install and trustless. We followed gmaxwell's instructions as our guidepoint and went further. And we delivered the product fast.




You have the code. Setup your own server. It's all opensource.


note: Our implementation of the server is in stages and does not know the mapping so it's better even.


note: we do a 4 step process where the outputs and inputs are loaded separately, so the server doesn't know the mapping between them

A simple scheme to enhance privacy without modifying the protocol.
I like it a lot.

By the way, there's a lot of confusion around zerocoin: http://themisescircle.org/blog/2013/08/22/the-problem-with-altcoins/
Is it a bitcoin upgrade? I doubt the overhead deserves it.
Is it a merged mined altchain with a coin fungible with btc? No way.
Will it become an altcoin? Probably.
Sorry, I don't want to move the thread to another direction, just wanted to note how less problematic this solution is.

Also genjix should keep in mind this isn't a "one-time" bounty:

Right, the key is to make it a thing normal users do.  Central services can be shutdown.

As far as I can tell, genjix's implementation is neither decentralized nor private, correct? The hard parts are still left to be done.