Bitcoin Forum

PROOF OF CONCEPT ONLY

http://sx.dyne.org/anontx/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My address: 1H1LP8UhGR5wK9WppBMwewCddwdebYqwwT

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJSHFzwAAoJELvkzMTyLzm16NIQAJZZoLdS1NNW8OfOzV4p9LAO
+u6pQzUm9KuxLuswGaAklrB4KExYmKSbd+kPVfkEsJb7Zu2Txi1ChUnY1xIV4t6/
GjuyM5qNuAD7NrLSJ3sCIKeQnWlwcj35Au9uxQzc7upry4wN9UCkBJjX0bbtDnkY
Yuj9eRNt8z2Mpr/0pyhuCoyoPRFxaPLwcWnkGkXbZzQ/1MsBh0x7s5vH5hs5LHLT
t9WPSE97erEVsnSFXMDhHxQKyNjo9Dm2TKAVFZUsXxnG7nua/c5sxVHxi1VRrvYn
eIWSiAfMk9TIQZZ/mzZrSVUiSfLhyIDbForeCDEmh0ctSITv9GA5Ob/tHF30PyQg
5Z5RCPX3oXFMpTsSwL4BwR9pIaf8rs2iV3YG8Rr3+DyrgMmjwjPnvyoUsw+8cHdC
lSQuPFAT9m7orBsUP7BSVuiuHAakKieg7nVUoswusvYENjVVjKw4mhflVCOkX3HS
ae+3kfGMrRcWEZXjI3K6NeJNt2MzMmc9xl1PTJo2XAr86pI0k7cAf5ke09SloYtm
y+l3ugv6Tl/Y2kWTF7n3N+QvDbg5rvAh7Yvtin84hb9vk4adxZggF1OUYqJDjI1s
Mhjbm9wFI2B+cxjcrWKyMoXK4Ia5wyRIreMFKmYQ18vQDpwncHSTdKI5uSUpEPgT
3UuPRMkRWEoMiqvNSMqh
=o2J/
-----END PGP SIGNATURE-----

https://unsystem.net/static/genjix.gpg.txt

Check out my video about Bitcoin (http://www.youtube.com/watch?v=lzgY8taGyB0)

http://sx.dyne.org/anontx/3.png

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
(some ideas: serverless setup, casual use for joining tx and fees...).

Once this is tested a bit, will it be easy to eventually integrate into the main Bitcoin clients?

We can develop several protocols for finding peers and jointly creating multisig transactions for different goals.

The protocols can then easily integrated into mainline clients (the one we implemented can easily be included in other clients, just uses POST, GET and some json to pass around the input, outputs, tx and signatures).

Cheers!

Thanks. Would it be similar to zerocoin in that it's ideal to stick to certain "denominations" like 0.1, 0.01, 1, etc?

Yes we should develop some naming and versioning of different protocols that emerge so different clients and tools can all communicate.

Will coinjoin eventually offer the same anonymity benefits Zerocoin promised?

See the thread on the general idea (https://bitcointalk.org/index.php?topic=279249.0) for my thoughts on the general question.

Far out, I had no idea you could have other inputs from other people into transactions and do it in a trustless way.

This is amazing, and it just uses normal transactions.

So essentially this is coin mixing using the inputs of a transaction from lots of people. Of course you like you have said in that thread all the inputs must be the same denomination right?

Question: Is it possible to trace one input to a output?

So inputs 1a,2a,3a,4a in and outputs 1b,2b,3b,4b out. Is it possible to trace 2a ending up as 4b? (Assuming that is the path the transactions took)

I wonder if this could be added to regular Electrum client as an optional extra module (with extra dependencies libbitcoin, sx) ? Python, client/server ... seems closely aligned.

It is absolutely not possible to trace one input to an output in complex transactions. The reason is that, by the protocol, we only check that it all adds up (inputs, outputs, and fees). If it ads up, the transaction is valid. We don't, because we can't, keep track of a bitcoin, much like you cannot keep track of a number when adding numbers: If 3+5=8, you cannot tell which of those eight come from those three. With physical objects you could, but bitcoins are pure abstraction, like numbers in the above example.
You could maybe argue that one of the outputs is, for example, 12.5% related to one of the inputs (previous outputs, that is), but this is far from "tracing" one-on-one.

Is it possible to unravel the signed transaction to see where 1a wanted their money to end up?

The network must know the path otherwise how would they get from A to B.

The intention for the money to end up in a certain place is the weak link right?

No. The whole transaction  ("this group of things to that group of things") is the intention the transaction coveys, and it cannot be separated when using sighash all (the default sighash type).  Thats the point. :) There are possible side channels— how different clients encode signatures, for example, but the transaction style itself doesn't leak any information about the mapping when used correctly.

There is no fundamental requirement in the Bitcoin protocol for them to be the same, but if they are different sizes you likely leak some information about the input to output mapping: If I put in 5 and you put in 50... and addr X gets out 50 and Y gets out 5 ... how do you think they map?

How about the people partaking in the transaction, is it possible to watch as more and more people add onto the transaction who intended what btc to go where?

Or is the transaction made all at once with many people involved but no one seeing where the people want the coins to go. (I'm talking about watching the process of this coinjoin tx being built)

Wow. This is way above my head! I didn't even realise this was possible! I hope this project continues to grow and that anonymous peer networks can be found easily and quickly in the future.

It depends on how it is implemented. The simplest ways of implementing it make either a meeting point "server" learn the correspondence, or all the participating users.  More complicated ways result in no one knowing. (I sketched out at a very high level in the other thread two distinct ways on the more complicated ends of the spectrum, but there are many possible ways with distinct trade-offs in security, implementation complexity, resistance to denial of service attack, etc)

This is not good.

If Bitcoin is further anonymized, Dictator Barack Obama will ban it soon.

In this implementation the outputs and inputs are collected in two separate stages to avoid easy correlation because the user sent both input and output at the same time. During inputs and outputs stage it's possible to watch a counter of how many participants sent their data, but we don't show the details till everything is collected (we do this to further avoid correlation, but probably wouldn't matter or might even help to show them as it goes).

So will combining multiple transactions also help with blockchain bloat / sustainablity? Or would the size of the coinjoined transactions be much the same as the separate ones?

Good work. Something innovative again, and so interesting.

This probably increases both traffic and the size of the unspent transaction output set.

No not really, because if it was not for the intention of making this transaction to mix the coins then this transaction would not happen. So its not really cutting down on bloat.

On the plus side, this would be a normal sized transaction so its not going to do any harm.

CoinJoin does increase network traffic a bit, but it can be implemented in a way that decreases UTXO and blockchain size.

For instance in addition to everything proposed already, you can make CoinJoin automatically join together requests multiple requests to pay the same address. For instance if Alice, Bob, and Charlie all want to donate 1BTC to Wikileaks's public address their CoinJoin implementation can take note of that and generate a single 3BTC txout with that address. You could even extend the payment protocol with support so that, for instance, BitPay could have all customers in a given 10 second interval join their payments together for totally unrelated items into a single txout.

impressive!

Would it be possible for each party to a coinjoin transaction to give multiple output addresses so that if arbitrary input amounts are used, the output amounts can be randomly split across several outputs to prevent inferring an input to output relationship by amount?

idk ... what if I to payed you 45 BTC? Using this scheme for ordinary payment transactions would add a great deal of uncertainty to the whole blockchain.

I'd love to see this added to standard clients as standard payment mechanism if anyone can work out a reasonable protocol to automate collecting the sigs. Maybe with a payment request already including the merchant's input to the tx.

Could payment processors, web shops etc. use this to combine payments (within a few minute window or so) to the same or small number of addresses?
Guess that'd have to be done carefully to maintain anonymity.