Bitcoin Forum
November 15, 2019, 07:35:39 AM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 »
  Print  
Author Topic: CoinJoin: Bitcoin privacy for the real world  (Read 291287 times)
laurentmt
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
June 06, 2014, 07:28:26 PM
 #541

The "entropy" will depend upon the model of attacker. Start by enumerating those.

My attempt to collect a few random thoughts on the subject (long post).

1/ First studies in this field have modeled the blockchain as transactions graph and/or addresses graph. In a generic way, the enlarged blockchain ecosystem can be modeled as a graph in which nodes are:
- Txo : associated to a given amount and controlled by a given script
- Entity (human / organizational / machine) : controls txos by controlling associated scripts (alone or with others entities)
- Tx : acts like "micro-mixers" of txos (amounts of input txos are mixed/splitted and forwarded to output txos)
Note: the description is purposefully simplified, but it should be enough for the discussion.

2/ An attacker has 2 objectives:
      - deanonymization of entities
      - determination of the links between input and output of transactions

These 2 objectives are not orthogonal. They're mutually reinforcing. Every information gained for one can be used for the other.


Deanonymization of entities

3/ It often starts with side-channel attacks:
- information gathering (bitcoin addresses, id, emails, ...) from various sources (forums, social networks, db managed by exchanges, merchants, ...). These information allow to associate deanonymized entities to a subset of the txos. Solutions like Stealth addresses help to address this issue.
- network eavesdropping (like the one described here). It's a 2-steps process (at least):
      a - association of an ip address to a tx
      b - association of an entity (person, ...) to the ip address
      c - for more complex scenarii (mixed or coinjoin txs) ip address has to be associated to a subset of the input txos of the tx.

4/ As stated by gmaxwell, starting from the txos associated to deanonymized entities, the attackers want to follow the deanonymized funds forwards or backwards and expand their knowledge recursively. It leads us to the second objective.


Determination of links between inputs and outputs of transactions

5/ I think the problem can (should ?) be addressed in a probabilistic way. An attacker doesn't need 100% certainty before deciding of an action. She just needs to be above a given threshold of confidence. If a bunch of the analysis can be automated, the attacker can study several alternative hypotheses and decide which one seems the best.

6/ Taint analysis is the first tool usable for this kind of analysis. The result has 100% certainty (it's just a basic "read" of the blockchain) but produces limited insights.

7/ You can use some heuristics to enrich information provided by taint analysis. First studies in the domain used very simple heuristics like multi-input transactions and shadow addresses (see the paper "Evaluating User Privacy in Bitcoin") but gave quite good results. This privacy issue was addressed by avoiding address reuse and some new proposal like mixers or coinjoin txs. You can also use some "best-guess" heuristics like the one used by blockchain.info to determine which output is payment and which one is change.

8/ The more you know about entities, the more you can use sophisticated heuristics. For example, an attacker can use a specific knowledge (2 persons live in the same city and are occasional users of localbitcoin) in order to infer that the input of a coinjoin tx is linked to a specific output (if she already knows which input/output is controlled by these 2 persons). The attacker has not 100% certainty about this inference but it could be a reasonable hypothesis.

9/ Coinjoin has been proposed as an additional solution to strengthen privacy. As already stated by gmaxwell, it does not provide 100% anonymity but can provide better privacy. With proper design it helps to increase the cost to retrieve a given quantity of information (links between input and output). But as stated above, coinjoin remains attackable if you have side-channel informations.

Here's a "dumb" example. The attacker is an intel. agency with access to a huge amount of side-channel infos. As an analyst of this agency, I investigate on a man (let's call him Charlie) suspected to finance a terrorist attack by repeated small bitcoin transactions. Our hypothesis is that funds are received by another person (Mr. X) suspected to sell the coins on localbitcoin to gather dollars which will be used to buy some materials for the attack (I told you, it's a dumb scenario). Today, I want to analyze a given coinjoin transaction because I know that Charlie controls one of its inputs. Let's say that this coinjoin tx has 3 inputs and 3 outputs, all with same amount. The agency has a program of massive surveillance which tells me that :
- input A is controlled by a woman suffering a cancer (information retrieved from her facebook account)
- input B is controlled by Charlie
- input C is controlled by a teenager (boy - information retrieved from snapchat)
- output D is controlled by a small e-commerce website running on tor and selling weed
- output E is controlled by a porn website
- output F is controlled by an unknown entity, for now.

According to additional information that I can access, I will be able to build different hypotheses with more or less confidence:
Hyp1) The woman has bought some weed to cure her pain and the teenager has watched some porn. Charlie may have send some coins to Mr. X and I should investigate deeper the output F
Hyp2) If I know that Charlie smokes weed may be this tx is just a false positive for my investigation => Charlie has bought some weed. The woman has nothing against a porn movie from time to time and the teenager...has bought a video game.
Hyp3) [use your own fantasy here]
...

I think you get the idea. This thought experiment illustrates a few interesting facts:
- to be effective, this kind of attack requires side-channels informations. The more information you have, the more effective you are.
- let's forget the "paranoïd" scenario that intel. agencies want to do massive surveillance just because they can do it or because they pursue some nasty goals. This experiment shows that to do their job (investigating potential serious threats) intel. agencies "have to" break privacy of all users (I don't argue it's good or bad, I just draw a logical conclusion. So please, do not yell at me)
- to strengthen his privacy Charlie could chain several coinjoin txs but this solution has a major drawback: if coinjoin txs are rare among "normal" users, chaining several txs becomes a real red flag telling "Hey ! I prepare (do) something illegal"
- as proposed by others persons, systematic coinjoin txs for all users would produce a combinatorial explosion. It's not perfect anonymity but it would raise very significantly the cost of this kind of attack. 


Automated analysis (machine learning algorithms, ...)

10/ To my knowledge, few studies have used this kind of tool until now but they could be very effective (see the paper "Unsupervised Approaches to Detecting Anomalous Behavior in the Bitcoin Transaction Network"). By trying to detect repeated patterns in the blockchain, this approach helps to infer additional information. The rationale is simple : some activities are associated to very specific patterns. For example, it's likely that transactions corresponding to mining pools paying the miners or gambling sites paying the players have very specific characteristics.

Another example is provided by the MTGox's source code which was leaked a few month ago. It was quickly identified that there was an automatic process in place to split/merge amounts in their hot wallet. This knowledge was later used to detect that some funds were transfered according to this pattern (a few days before MTGox officially states that some funds had been retrieved). In this case, the pattern has been provided by a leak but you get the idea on how this kind of information can be used to reach the 2 objectives of the attacker.

11/ Patterns corresponding to automated (and non-random) processes should be the easiest to detect but it does not seem impossible that human operations could also be processed by studying temporal or behavorial patterns. For example, if you live in Europe it's likely that you send your txs at very different GMT hours compared to american or asian users.


Conclusion

12/ The current model provided by bitcoin (or by bitcoin with occasional coinjoin txs) is ultimately very close to the current situation of the interweb. Thus, it's quite straightforward to deduce the different levels of attacks and attackers:
- Group A : Intel. agencies
They have access to a massive amount of side-channel information already gathered from various sources. They will get the best results. Since not all side-channels information are not obtained by legal (official) means, these information don't always allow an official (legal) reaction.
- Group B : Large corporations
They have access to some amounts of side-channel information by providing paying services requiring the user to provide some personal informations. They'll be able to extract additional information by merging these data with data from the blockchain but at a lower level than group A. They'll an incentive to monetize these information by selling them to others entities (marketing, ads, ...).
- Group C : Basically the rest of the world
We have occasional access to some side-channel information by our direct interaction with others bitcoiners. Individually, it'll be difficult to extract significant information by merging these data with data from the blockchain.

13/ A bitcoin bank located in an exotic island and providing offchain transactions could remain the best solution for those wanting to hide illegal activities like money laundering.

14/ In this matter, I would say that the current bitcoin model does not change a lot of things compared to the current statu quo (even if bitcoin remains a great technology and a great innovation)

Disclosure : english is not my mother tongue Roll Eyes
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
instagibbs
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
June 06, 2014, 08:10:46 PM
 #542


2/ An attacker has 2 objectives:
      - deanonymization of entities
      - determination of the links between input and output of transactions

These 2 objectives are not orthogonal. They're mutually reinforcing. Every information gained for one can be used for the other.


I think defining it as a submodular function of those two concerns is a great starting point. Not a lot to be done on #1, at least on-blockchain, is there?

If we are just comparing between what we have now and what we could have, I think it's vastly superior. For now, at least in the US, the feds snoop on all our credit card purchases, without a warrant. Probably enough evidence for a warrant, but not for conviction of any particular crime.

Getting beyond that with reasonably not too much effort will be the real challenge.

p.s. Anyone know of any good annotated datasets of transactions? Unsupervised learning is notoriously  Huh to interpret.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
June 07, 2014, 04:50:11 PM
Last edit: June 07, 2014, 11:16:09 PM by laurentmt
 #543

I think defining it as a submodular function of those two concerns is a great starting point. Not a lot to be done on #1, at least on-blockchain, is there?
Well, bitcoin can't prevent an attacker to gather side-channel information but it can try to obfuscate links between personal information (email, social network id, ...) and addresses in the blockchain. Stealth addresses seem a promising solution for this. Moreover, deanonymization of entities is a recursive process fed by all the results obtained while working on the 2nd objective. Thus, coinjoin seems a useful tool to raise the cost of deanonymization.

If we are just comparing between what we have now and what we could have, I think it's vastly superior. For now, at least in the US, the feds snoop on all our credit card purchases, without a warrant. Probably enough evidence for a warrant, but not for conviction of any particular crime.
I could be wrong but I think it's just a matter of time before the 2 situations converge. The current trend seems to be more and more SPV clients and web wallets operated by regulated corporate entities. I guess merchants will have some duties too. Thus, if US feds have access to credit card purchases, accessing raw deanonymized informations should not be a problem for them. Of course, it remains solutions like coinjoin but I think they'll be a niche if they're opt-in features.

Getting beyond that with reasonably not too much effort will be the real challenge.
It's a very interesting point. My take is that it has 2 parts :
  - what is technically doable
  - which level of privacy is desired (according to the 3 groups defined in previous post)

It's easy to feel the tensions created inside the community by the latter. But even if the community was able to reach a consensus (an utopia) it would have huge consequences. Imagine the reaction of governments, corporations, investors if the whole community states that it wants perfect privacy and be protected from all kind of attacks. Ultimately, having a blurred position on this subject is surely the "best" option to increase the acceptance of bitcoin and reach mass adoption. But the price to pay is that it introduces a ghost in the place which exacerbates tensions (a good example here https://bitcointalk.org/index.php?topic=635317.0).

p.s. Anyone know of any good annotated datasets of transactions? Unsupervised learning is notoriously  Huh to interpret.
Nope. Possible solutions to cope with this problem:
  - use an experimental approach (by injecting coins in the system as done by Moser for his paper "Anonymity of Bitcoin Transactions - An Analysis of Mixing Services")
  - rely on the community to get additional data (think to people who've shared their Gox addresses with the community to help investigate the bank run)

This point highlights the gap between the 3 groups of attackers (group A has an obvious advantage with its ability to gather side-channel information).
Summer,69
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
June 09, 2014, 10:00:26 AM
 #544

If all of the coins would be mixed, how can they be blacklisted and allowed by governments to intervene?
justusranvier
Legendary
*
Offline Offline

Activity: 1400
Merit: 1006



View Profile
June 10, 2014, 04:13:01 AM
 #545

In two weeks, this site is going to release an open source tool that purports to de-anonymize Shared Coin transactions.

http://www.coinjoinsudoku.com/advisory/

Coming from the perspective that it's impossible to improve that which is not measured, I'm glad to see tools like this appear. Hopefully in the future we'll be able to evaluate privacy claims in a more empirical and objective way and so be more likely to have tools that actually work.
laurentmt
Sr. Member
****
Offline Offline

Activity: 386
Merit: 250


View Profile
June 10, 2014, 03:48:25 PM
 #546

Peter Todd has made an interesting statement in the comments of this coindesk's article.

Quote
What Dark Wallet actually implements is to have two classes of users, those who need a transaction done immediately, and those who are mixing coins. The latter group simply copies the output amounts of the former group, providing a set of two outputs in every CoinJoin transaction whose ownership is unknown. SharedCoin does the same thing, but with blockchain.info acting as that coin mixing group.

I may be wrong but it seems likely that bc.i uses a same pool of coins over and over for the sharedcoin txs. It's not impossible that, with some efforts, someone could identify which txos in the transaction graph are concerned (i.e. belong to bc.i), decreasing a bit more the level of privacy offered. To be effective and avoid this kind of privacy leak, coinjoin should use a large pool of mixing coins (the 2nd group of users in Peter's comment) and avoid reusing the same mixing coins over and over (with a frequency which allows to identify them).

Btw, it's likely that decentralized solutions like darkwallet are the easiest way to achieve this goal if they have enough traction and can maintain a large mixing pool.
sile16
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
June 24, 2014, 05:31:24 AM
 #547

There should be an open protocol that can help coordinate people who want to coinjoin.  Is there already something else out there that can automate that?
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
June 24, 2014, 05:52:49 AM
 #548

I'm implementing distributed coinjoin to a couple of alt coins. I guess it can be applied to bitcoin also.

Shortly the algo:
Coinjoin offers are broadcasted as normal transactions, but on other channel, using message "ctx".
These offers are collected to a complete coinjoin transaction by first sorting the offers, then all participants sign it in turns based on sorting order and transmits them on the ctx channel. When the last finds it is complete, it transmits the complete transaction using normal tx message.

https://bitcointalk.org/index.php?topic=607919.7860

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1001


View Profile
June 24, 2014, 05:31:29 PM
 #549

So it's trivially identifiable whose outputs are whose based on the observed offers?

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
June 24, 2014, 08:10:21 PM
Last edit: June 24, 2014, 08:35:39 PM by Nite69
 #550

So it's trivially identifiable whose outputs are whose based on the observed offers?

I have been wondering that too.
Coinjoin itself protects transactions on blockchain only. However it requires someone to log all transactions 24 hours / day.

It is one improvement which should be done some day. The offers should be encrypted, so only the participants can decrypt all inputs. Then it would reveal only one address, and that might be generated to be used only once, maybe with 0 output. Other possibility would be to share the offers throught encrypted channel.

Any other ideas to improve it?

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
maaku
Legendary
*
expert
Offline Offline

Activity: 905
Merit: 1001


View Profile
June 24, 2014, 10:41:11 PM
 #551

Read the first page of this thread. There's a solution involving blinded outputs.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
ShakyhandsBTCer
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


It's Money 2.0| It’s gold for nerds | It's Bitcoin


View Profile
June 24, 2014, 11:25:36 PM
 #552

Peter Todd has made an interesting statement in the comments of this coindesk's article.

Quote
What Dark Wallet actually implements is to have two classes of users, those who need a transaction done immediately, and those who are mixing coins. The latter group simply copies the output amounts of the former group, providing a set of two outputs in every CoinJoin transaction whose ownership is unknown. SharedCoin does the same thing, but with blockchain.info acting as that coin mixing group.

I may be wrong but it seems likely that bc.i uses a same pool of coins over and over for the sharedcoin txs. It's not impossible that, with some efforts, someone could identify which txos in the transaction graph are concerned (i.e. belong to bc.i), decreasing a bit more the level of privacy offered. To be effective and avoid this kind of privacy leak, coinjoin should use a large pool of mixing coins (the 2nd group of users in Peter's comment) and avoid reusing the same mixing coins over and over (with a frequency which allows to identify them).

Btw, it's likely that decentralized solutions like darkwallet are the easiest way to achieve this goal if they have enough traction and can maintain a large mixing pool.
The more times your output is the same address the easier it would become to trace your coins.
mitchellmint
Legendary
*
Offline Offline

Activity: 1129
Merit: 1000


TRUSTplus Dev


View Profile WWW
July 03, 2014, 03:45:47 AM
 #553

I havent read the whole thread so this might not be a new idea but... it was something I accidentally discovered sending coins to a different coin with the same digit.

This concept is not promised to be implemented by VVV but was kicked around.

https://docs.google.com/a/mitchellmint.com/presentation/d/1X0QHjzkVtGJf5sf1vtiIjGQ_AvPg2GdPSYrc5vb9NIo/edit#slide=id.g35a51815e_040

Buy TRUSTplus.  We are building a Financial Platform.
AdNarim
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
July 18, 2014, 03:23:39 AM
Last edit: July 19, 2014, 03:39:00 AM by AdNarim
 #554

I have an idea about a way to perform a decentralized Coinjoin so that individual participants are unable to map inputs to outputs - without the need for an anonymity network or blinded signatures.

As a disclaimer, although I have experience programming I am not well-practiced in cryptography, so forgive me if I make any egregious mistakes and waste everyone’s time.

Given the IP addresses and public keys for all N Coinjoin participant nodes, I envision the following onion routing protocol (inspired by what is used in Tor):

1.   Decide upon a random path which visits every node once and ends up back at our node.

2.   Using Onion Routing, send a multi-level encrypted message along this path. Each node by using its private key to decrypt the message will be able to see where the message was supposed to originate from, the bitcoin addresses to be used as inputs, and where to send the message to next. The rest of the message will only be able to be further decrypted by the next destination. When the message gets back to us, it should have visited every node in the path.
See: http://en.wikipedia.org/wiki/Onion_routing

3.   Same protocol, but with output addresses (can be done in parallel with the input addresses).

4.   Same protocol, but with our signature of the completed transaction.

5.   Broadcast transaction.


In theory, each node will be unable to tell from what node the input and output addresses originated. However, I see several serious issues with this proposal, and would welcome even more critique:

  • Timing Attacks: If a node receives the message early in the process, it is more likely that that the sender owns the associated addresses. This may be mitigated through random delays or other, more clever schemes.
  • Message Size: A node may be able to analyze the size of the message to determine how far along it is. To counter this, a randomly-sized allotment of junk data should be included in the inner-most message.
  • Slow: this protocol takes N time, as the message must be forwarded to each node.
  • DDOS: What is to stop some other node from screwing everyone over? It is possible to see if our message was tampered with (using random numbers, accumulating counters, etc.), but it would still be difficult to make the protocol resistant to malicious nodes mucking everything up and wasting everyone’s time.
  • Sybil Attacks: You’re pretty much screwed. Tor has similar issues, this is one thing you really can’t do anything about (other than favoring IP addresses that are likely to be in physically separate locations)
  • Other stuff: It’s probably out there, I just can't think of it at the moment.

Well, what about the positives? Assuming all the negative obstacles are surmountable:

  • Inputs are not linked to IP addresses.
  • Outputs are not linked to IP addresses.
  • Inputs are not linked to outputs any more than can be determined from looking at the finalized transaction.
  • No anonymity network required. This is important as P2P over, say, Tor is a pain.
  • No reconnecting required. You are not required to meet up with the same nodes again.
  • If you are behind a NAT router or firewall blocking inbound connections, you can hire an open node as a proxy. As only you have access to your private key, you can have this node forward/receive your messages without worrying about it snooping (granted, it can still cause as much trouble as the other nodes, and you probably have to compensate the proxy owner by including a small transfer in your transaction).
dillpicklechips
Hero Member
*****
Offline Offline

Activity: 938
Merit: 502

CryptoTalk.Org - Get Paid for every Post!


View Profile
July 26, 2014, 02:13:55 AM
 #555

Would using ring signatures work as a method of mixing without having to trust a server even though they are using one? Provably fair mixing?

Have the clients connect and have all the inputs define the initial state of the cryptonote type ring signatures. Each person then shuffles the ring and they are only able to follow their own coins. They then specify the outputs in the ring whatever they are. Once everyone is happy they are getting paid they all sign. No one, not even server would be able to follow who is getting what. And even if the person had one input they could have multiple outputs depending on what they specify in the ring.

Kind of like my idea here: https://bitcointalk.org/index.php?topic=706000.0

 
                                . ██████████.
                              .████████████████.
                           .██████████████████████.
                        -█████████████████████████████
                     .██████████████████████████████████.
                  -█████████████████████████████████████████
               -███████████████████████████████████████████████
           .-█████████████████████████████████████████████████████.
        .████████████████████████████████████████████████████████████
       .██████████████████████████████████████████████████████████████.
       .██████████████████████████████████████████████████████████████.
       ..████████████████████████████████████████████████████████████..
       .   .██████████████████████████████████████████████████████.
       .      .████████████████████████████████████████████████.

       .       .██████████████████████████████████████████████
       .    ██████████████████████████████████████████████████████
       .█████████████████████████████████████████████████████████████.
        .███████████████████████████████████████████████████████████
           .█████████████████████████████████████████████████████
              .████████████████████████████████████████████████
                   ████████████████████████████████████████
                      ██████████████████████████████████
                          ██████████████████████████
                             ████████████████████
                               ████████████████
                                   █████████
.CryptoTalk.org.|.MAKE POSTS AND EARN BTC!.🏆
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2870
Merit: 2606



View Profile
July 26, 2014, 02:19:00 AM
 #556

Would using ring signatures work as a method of mixing without having to trust a server even though they are using one? Provably fair mixing?
Please see the fifth post in the thread. Smiley
AdNarim
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
August 01, 2014, 05:23:04 PM
Last edit: August 09, 2014, 03:41:15 PM by AdNarim
 #557

I am currently working on a Java library which facilitates decentralized CoinJoin-ing using a BitcoinJ backend.

As of this moment the library only works with fixed CoinJoin participants, I have yet to implement participant discovery (that's next on the list).
It also is very insecure at the moment, as I hacked together some sections in order to test general principles. It will be some time before the code is solid enough to not be embarrassing :\

Current plan:
1. Implement peer discovery (perhaps using a DHT)
2. Fix error handling and enhance verification of transaction components
3. simplify, refactor, rename
4. post source code (under a permissive OSS license)
5. Make CoinJoin process more anonymous.
6. ALPHA release?

example:
http://tbtc.blockr.io/tx/info/c4d86d7a054e5979172b223a15d5d9594f703d6376ab294ee4b2da45ff77b0eb

This is a test CoinJoin transaction between only 2 users. In this example I set the change and output address to be the same. The general caveats of a CoinJoin transaction still apply: each change address is clearly linked with an output address, and therefore by using blockchain analysis it may still be possible to link addresses. True anonymity requires minimal address reuse and tools for managing taint.

For now, though, I just send an unconfirmed transaction to a new address of fixed size, then use that unconfirmed transaction as part of the CoinJoin. Needless to say, for this scheme 0 confirmation coinjoins should not be accepted! Regardless, I am trying to write the library to be adaptable as possible to different types of CoinJoins, including coinjoins where each user has multiple inputs, casual coinjoins, and coinjoins without any change address.
AdNarim
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
August 05, 2014, 10:16:29 PM
Last edit: August 06, 2014, 12:51:24 AM by AdNarim
 #558

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.
BTCfan668
Member
**
Offline Offline

Activity: 88
Merit: 10


View Profile
August 06, 2014, 03:52:26 AM
 #559

How safe is doing this bitcoin transaction?
This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2870
Merit: 2606



View Profile
August 06, 2014, 09:01:03 AM
 #560

This is very safe, however it is not very private. It is essentially not possible to "lose" your coins doing this, however it has been proven that these types of transactions can be traced by inspecting the blockchain.
Don't confuse blockchain.info's completely broken "Shared Send"— they provide no privacy at all for reasons unrelated with this thread. The privacy implications of well constructed CoinJoins are discussed in some depth in the initial post and some other posts in this thread.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!