[ANN] Bitprivacy - decentralized trustless privacy

[Tom Scholl]

Bitprivacy is a fully decentralized Bitcoin privacy solution that can be integrated into personal Bitcoin wallets.

Privacy is achieved by everyone writing their inputs to the network; when all are supplied they make a new connection & write their outputs. Blind signing prevents denial-of-service attacks.

Bitprivacy is for casual Bitcoin users who don't want people spying on them. It does not protect against government-level (global adversary) monitoring, and as such is not suitable for criminals looking for strong anonymity.

Latest release is Bitprivacy version 0.2:
- MIT licensed
- Bitcoinj-based, android-friendly
- 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 trade with everyone simultaneously

Some things not done yet:
- 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)

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. I have also put in a partial claim for the new CoinJoin bounty.

If you want to help this project, you could try it out and post here. You can also donate directly, address in my sig.

-----------------------------------------------------------------------
Original post:

I'm developing an MIT-licensed decentralized privacy solution in Java.

You can try the testnet prototype at https://github.com/dustyneuron/bitprivacy
A simple 3-party tx works ok right now.

Currently it is client/server rather than full peer-to-peer, but it is decentralized in that anyone can run a server, clients can pick and choose which server to tx on, and Bitcoins cannot be stolen by a malicious server.

People post 'schemas' of what kind of transactions they're willing to participate in.
E.g. I want to be in a transaction where
        * each party signs an input of 5btc
        * each party provides an output of 5btc
        * requires 5 parties
        
Once the requirements have been met, the transaction is handed round for partial signing. Each participent checks the transaction is what they expect before signing.

The schema/matching system could also be used for simple contracts like crowdfunding.

Comments welcome!

[bujiraso]

Here's a comment: if you're the first to allow clean, user-friendly crowd-sourcing via bitcoin -- I see bright days in your future.
Lemme know if you need an extra dev or whatever. I forked you.

[Tom Scholl]

Thanks!

In terms of GUI, I think a crowdfunding app should be packaged as an add-on/fork of an existing wallet app like Multibit, as otherwise the user process would involve having to make an extra transaction to send funds to the app. Would you be interested in hacking on that?

Right now I am working on making this thing fully p2p, using DHTs.

[bujiraso]

Yeah, I'll look into that.

[marcus_of_augustus]

Ok, this looks like a promising start ... opportunities for this are boundless. 

[Tom Scholl]

Version 0.2:

• Chaumian blind signatures for outputs (https://bitcointalk.org/index.php?topic=150681.0)
• New trading strategy to cope with unresponsive parties
• Fully peer-to-peer
• Lots of unit tests

It's still testnet only as there are some timing attacks and traffic analysis attacks possible, it doesn't yet cope with misbehaving parties, doesn't save trades to disk, etc, etc.

Download ready-to-go: http://bitprivacy.org/files/bitprivacy-0.2-jar-with-dependencies.jar
Source & instructions: https://github.com/dustyneuron/bitprivacy
Donation address in my sig 

[domob]

That's great news, I'm looking forward to having this available!  Any idea when you want to release a first non-testnet version?

Is there a (high-level) description of how it works available?  I'm not interested in how exactly the communications protocol is built-up byte-for-byte or the like, but would be interested in seeing what information the peers communicate to each other and so on so that I can form my own opinion on how secure and anonymous this is.  (I trust you to do it "right", but am still interested in the details.)

[oakpacific]

I get an urge to get everyone to see it....

Thanks OP, I will definitely take a look when I am free, and will donate if it work as expected.

Thanks again.

[Tom Scholl]

It's great to see people are keen for this  

Any idea when you want to release a first non-testnet version?

I'd like to fix the privacy issues, and do a security review to check malicious peers couldn't exploit data parsing or validation issues to steal coins. It would be great if another pair of eyes could check the protocol for mistakes.

Is there a (high-level) description of how it works available?

I've just written https://github.com/dustyneuron/bitprivacy/blob/master/DETAILS.md. It may be a bit too in-depth about the data layout, but it's certainly easier than looking at the code, and I can use it as a reference when I need to change things.

[townf]

Is there a way for the mixer to issue a cryptographic, physical receipt to the inputter (like on a smartchip), good for crypto on redemption at a later date? That way we can have physical cash! This would aid in anonymity and help adoption of crypto as a medium of exchange in general.

[Tom Scholl]

That sounds a lot like Chaumian cash. Open-Transactions works like this. As far as I understand, you do have to trust the receipt issuers to redeem it back to bitcoins/gold/whatever, although the trust gets spread out between several issuers. See https://github.com/FellowTraveler/Open-Transactions/wiki/CENTRALIZED for how that works.

[domob]

Is there a (high-level) description of how it works available?

I've just written https://github.com/dustyneuron/bitprivacy/blob/master/DETAILS.md. It may be a bit too in-depth about the data layout, but it's certainly easier than looking at the code, and I can use it as a reference when I need to change things.

Thanks, that's basically what I wanted to look at.  I'm no crypto-expert, but to me it looks good.

However, one thing I wondered about: Why do you need blind signatures for this protocol in the first place?  Couldn't you just simply submit your output to a chosen peer (like the blinding server) with a new network connection without obtaining a signature from the server before?  After all, before each peer signs the transaction, he/she checks that his/her transaction is in there anyway, so there's no chance someone could run away with my coins.  What additional trust/verification purpose does the blind signature fulfill?

[Tom Scholl]

I am getting a maven error with your pom.xml

Hmm. What version of maven (mvn --version)? I used maven 2 rather than 3.
If you're on maven 3, you might have to pass the -U flag to mvn. Can you try that?

[Tom Scholl]

Code:

[ERROR] Failed to execute goal on project bitprivacy: Could not resolve dependencies for project com.dustyneuron.bitprivacy:bitprivacy:jar:0.3-SNAPSHOT: Could not find artifact com.google:bitcoinj:jar:0.8 in sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots) -> [Help 1]

I've just tried it with maven 3 myself, and it worked for me (no special flags required). Did you do every step of these instructions? You have to download and build bitcoinj seperately because it isn't hosted in a maven repository:

Code:

sudo apt-get install git maven2 protobuf-compiler libprotobuf-java
git clone https://code.google.com/p/bitcoinj/ bitcoinj
cd bitcoinj
git fetch --all
git checkout cbbb1a2bf4d189732efe273ebf65ab2da14eaaa5
mvn -DskipTests install
cd ..
git clone git://github.com/dustyneuron/bitprivacy.git
cd bitprivacy
mvn -DskipTests package

[Tom Scholl]

However, one thing I wondered about: Why do you need blind signatures for this protocol in the first place?  Couldn't you just simply submit your output to a chosen peer (like the blinding server) with a new network connection without obtaining a signature from the server before?  After all, before each peer signs the transaction, he/she checks that his/her transaction is in there anyway, so there's no chance someone could run away with my coins.  What additional trust/verification purpose does the blind signature fulfill?

Excellent question.

If you don't use blinding, any random person could submit an output, and DOS the trade. But with blinding, the blinding server can verify that the blinded outputs came from trade members -IF the members sign the message with their peerId. But I didn't mention that, because I haven't implemented it yet. I will update the notes.

[domob]

However, one thing I wondered about: Why do you need blind signatures for this protocol in the first place?  Couldn't you just simply submit your output to a chosen peer (like the blinding server) with a new network connection without obtaining a signature from the server before?  After all, before each peer signs the transaction, he/she checks that his/her transaction is in there anyway, so there's no chance someone could run away with my coins.  What additional trust/verification purpose does the blind signature fulfill?

Excellent question.

If you don't use blinding, any random person could submit an output, and DOS the trade. But with blinding, the blinding server can verify that the blinded outputs came from trade members -IF the members sign the message with their peerId. But I didn't mention that, because I haven't implemented it yet. I will update the notes.

Ah ok, I already presumed it would "just" be about DOS.  Thanks for clarifying this, makes sense of course!

[Tom Scholl]

I've been thinking a lot about what privacy features are missing, and it's a lot more than I thought before. There's several months of work here.

So, if any developers are interested in things like fidelity bonds, Tor integration, automatic wallet "coin-joining" strategies, or integration with MultiBit, then please get in touch.

I've written about the threat model & defences on github in THREATS.md.