Pages:
Author

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

hero member
Activity: 836
Merit: 1007
"How do you eat an elephant? One bit at a time..."
FYI, Mycelium's development roadmap is

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)
2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)
3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.

Fantastic!
hero member
Activity: 836
Merit: 1007
"How do you eat an elephant? One bit at a time..."

I cannot code but I would love to see this project develop. If anybody wants to develop a wallet I'm sure there are many people like myself that would donate to help make it happen.
hero member
Activity: 994
Merit: 507
September 07, 2014, 05:20:52 PM
Cross posting a coinjoin conversation:

As part of ongoing efforts of the Monero Project, a small program has been generated that allows you to do 1-of-N ring signatures using a secp256k1 keypair and a keyring of public keys. The program signs both binaries and text files.

https://github.com/monero-project/urs

To build and install, use this command after installation of Go:
Code:
go get -u -v github.com/monero-project/urs/...

According to the paper, unique ring signatures are anonymous except in the case of signing the same message multiple times (in which case X and Y in the signature appear to be the same).

http://csiflabs.cs.ucdavis.edu/~hbzhang/romring.pdf

A potential usage might be to sign gitian asserts from a trusted keyring anonymously that contains well known members of the Bitcoin project. Another usage would be for members of a trusted community of Bitcoin users to anonymously vote for some proposal by signing it separately and publishing their signatures.

Thanks to Hein Meling for the initial URS implementation, Conformal Systems for their immensely useful libraries, and gmaxwell for inspiration.

Another interesting use could be a type of ring signature coinjoin? A group gets together and determines the inputs. The ring signatures are used for each person to pick their outputs and can even have multiple outputs of different values. Once the group has enough messages specifying the output addresses the coinjoin transaction is created and signed. If any party of the group cheats the output values will total to be too high and the transaction is discarded.

This is a good idea. In the original coinjoin thread gmaxwell described a blinding scheme wherein users would initially provide their outputs in blinded form, have them blindsigned by the central server (or the "leader" node in a p2p setup) (or all participating parties, which is bandwidth-heavy), then reconnect anonymously to unblind them. For a p2p setup this means that somebody has to produce the blind signatures: either a leader must be selected, which adds complexity to the protocol, or every party signs every output, which leads to O(n^2) scaling.

With a ring signature on the other hand, each party would anonymously sign only their own outputs -- all nodes participate equally, with O(n) signatures. (Of course, the ring signatures are O(n) in size, so you might say this is still O(n^2) scaling. But since every signature uses the same keyring, this doesn't need to be passed around. Just the signature itself plus a blinding factor Q (one per signature, no need to use different ones per key in this case) as described in an earlier post.)
legendary
Activity: 1680
Merit: 1035
This is cool to know, but I speculate that the average user wouldn't want this functionality. Of course those with security concerns or those trying to hide coins would absolutely love this service.

That's why some wallet makers will be implementing this as the default transaction method. Average users won't even know they are doing it.
member
Activity: 83
Merit: 10
Your average Bitcoin/Ethereum enthusiast
This is cool to know, but I speculate that the average user wouldn't want this functionality. Of course those with security concerns or those trying to hide coins would absolutely love this service.
hero member
Activity: 994
Merit: 507
3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.
The larger the pool the better and it might make it easier for ad hoc transactions if everyone cooperated on using popular servers.
legendary
Activity: 1680
Merit: 1035
FYI, Mycelium's development roadmap is

1) Implement HD wallets (about 95%+ done, and works fine in testnet Dev build, but still need to update LocalTrader and other minor things to work with it)
2) Move the entire infrastructure to Tor, meaning our nodes will be run as hidden servers, only accessible through Tor, and Mycelium Wallet will have Tor built in (hopefully this won't cause problems in blocked countries, like China or Iran)
3) Implement CoinJoin, using our nodes that are used for address lookup and broadcasts, to collect and broadcast mixing requests. Likely enable this as a default feature. We'll have to figure out if we'll need to follow the DarkWallet model of letting some users leave their coins to mix, or if we have enough transaction volume to do it on the fly. Maybe we'll even link with DarkWallet servers, and use the people looking to mix there.
newbie
Activity: 4
Merit: 0
1. Each participant starts a Tor Hidden Service.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.

There is little benefit to negotiation over the Bitcoin network protocol for traditional CoinJoin's besides eliminating the need for an additional networking layer.

On the downside, adding additional messages to the network protocol is likely an irksome process, and is not very flexible. A separate network may be rapidly iterated upon, and other shared transactions other that traditional CoinJoins may be added.

In regards to Tor, for Java there exists the Orchid library, which allows Tor to be easily integrated within Java applications. The main benefit of using Tor Hidden Services (to me at least, if I am understanding things correctly) is not really anonymity, but rather NAT traversal. Without Tor, you have to keep a port open to allow users to connect to you node and perform a decentralized CoinJoin. Tor hidden services connect to Tor Relays, and therefore do not require any ports to be open. As long as the NAT/firewall allows outgoing Tor connections, everything works out.

EDIT:
I forgot to mention, a downside of using Tor is that TomP2P and all other Java DHT libraries that I know of require ports to be open to ensure the integrity of DHT (if no nodes are hosting the DHT information, what's the point?). As such, in order to make the DHT robust the code would have to be extended to facilitate Tor Hidden services. This doesn't even address the fact that using a DHT to facilitate CoinJoining between number of users n>2 is a real pain.

Hence, decentralizing peer discovery is a job for another day week month.
full member
Activity: 170
Merit: 100
1. Each participant starts a Tor Hidden Service.

This would require all nodes to run Tor! Why not do the CoinJoin negotiation over BTC's network protocol, which the nodes participate in anyway? This way, those who use BTC through Tor also do the negotiation through Tor, but no one has to.
legendary
Activity: 1400
Merit: 1009
I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.
You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not Wink


/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.
I'm going to explain how Bitcoin can be used as a defencive weapon that allows the younger generation to avoid paying the debts bestowed upon them by the older generation, and how if they wield it correctly they'll collapse the fiat debt ponzi scheme, the tax base, and the US Dollar itself, with specific instructions for how to get started.

It's going to do great things for the public perception of Bitcoin.
newbie
Activity: 29
Merit: 0
... like cash enables thieves "even more" ...  Roll Eyes

money needs to be functional as an economic unit ... rather than fulfill every utopian fantasy bestowed upon it

Well that's always been my defense when explaining Bitcoin to people and they point out the issues with recent happening with mt gox and money laundering. Bitcoin does nothing less than cash does related to the legal side of things.

But, I'm just saying this sort of thing is adding fuel to the engine and could potentially make things a lot worse.


legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
... like cash enables thieves "even more" ...  Roll Eyes

money needs to be functional as an economic unit ... rather than fulfill every utopian fantasy bestowed upon it
newbie
Activity: 29
Merit: 0
I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.
You're gonna *love* my next blog post...

Link it to me and I'll tell you if I "love" it or not Wink


/ot

I'm really trying to figure this out and try to address some of my concerns and I believe this would result in a lot of accusations flying out.
legendary
Activity: 1400
Merit: 1009
I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.
You're gonna *love* my next blog post...
newbie
Activity: 29
Merit: 0
So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.

I was talking about how people compare Bitcoin users to criminals we all know it happens because of laundry for one example. Then this would just give those accusers more leverage because with this enabled technically everyone would be breaking the law.


Making Bitcoin illegal in every country if this is enabled. Unless I'm not fully grasping something I think that's what this is all about and could cause a few problems.

I can see why this would be beneficial to the network and the general user of Bitcoin but I can also see it enabling thieves even more.
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.

It also has technical benefits for the network in terms of reduced overheads.

btw, bitcoin is legal, it has no "legal problems". You are probably confused by the enormous legal complexities of handling government fiat.
newbie
Activity: 29
Merit: 0
So let me try and figure this out this is a little out of my league but here it goes:

Effectively you are creating a mixing service within the Bitcoin network itself? Making privacy better because no one can track where you sent your Bitcoin because it is split up and combined with other peoples transactions. Surely this has already been done by several mixing services?

Wouldn't this create more legal problems for Bitcoin? If this is what you want to achieve surely it's illegal because this can be abused very easily.
member
Activity: 63
Merit: 10
This is amazing, i will definitly keep an eye on this.
newbie
Activity: 56
Merit: 0
Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.

The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:

1. Each participant starts a Tor Hidden Service.
2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.
3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.

+ No traffic ever leaves the Tor network
+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous

It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.

P.S.
Here is an example of a 10-way CoinJoin I generated using my library:
http://tbtc.blockr.io/tx/info/894d10fea8e017789e80e2965d3421572e42e19ba8c6f51ce4a22b3c40b0f831

This is similar to what a CoinJoin transaction would look like in practice, except a more secure implementation would mix the outputs around better.

If you are writing a Java library and are planning on using a DHT, have a look at TomP2P.  Its what i used in http://coinmux.com.
Pages:
Jump to: