So wheres the form?
Also these are all bounties?
Wheres the airdrop

i can  help you anytime if you hook it up. I will always help you if you help me

i am new to bitcoin and looking fowrd to go further. Bitcoin is very interesting hard pays

Honestly, the most painful thing is feeling lonely and rejection and wondering if I would always be alone in this world.
It's tough finding the right significant other and having someone by your side.
For me im just really independent and i gave up hopes of that happening

User name: Murphant

I want to add my master's thesis to the research page.

I am looking to compare different implementations of CoinJoin, but I don't feel like going through 20 pages. Would someone be considerate enough to list them here, or maybe in the original post?

I was imagining more of a decentralized CoinJoin where people got together to create the transaction instead of asking a service to do it, but both situations are similar. In the centralized case, maaku's solution does not seem to work as it requires communication between the participants. However, sellers not reusing addresses that receive payments does solve the problem even in the centralized case as Alice and Bob cannot simultaneously think that they are paying Steve.

The way I understand it, the problem can be phrased in the following way.

Suppose that both Alice (address A) and Mallory (address M) want to buy an item from seller Steve. Alice and Mallory create a CoinJoin transaction (A,M) -> (S,M') where M' is another address controlled by Mallory. Alice signs the transaction as she sees that the correct amount is sent to Steve and expects to receive her service. However, Mallory may also later claim that he sent the money to Steve and that he should receive the service. From Steve's point of view, both claims are equally valid.

I believe that maaku's solution would work as long as the join requests are signed and kept by each party. One downside of this is that it might reduce the anonymity of the system since each user can later prove the other user's intentions to a third party.


Another, simpler solution would be to make sure to never send funds to a public address in a CoinJoin transaction and for sellers to always use fresh receiving addresses.

gmaxwell's  "CoinSwap" introduces a framework that enables "secure" mixing in the sense that the mixer can't run with your coins. I believe CoinSwap is better for dedicated mixing than splitting funds into smaller quantities because it does not just spread the risk, it brings it down to just about zero. Additionally, the Tx fees are lower.


This is an interesting way to do so. However, it is vulnerable to having a mixing service that is not used very much, in which case only you and 3-letter organizations are trying to mix at any given time. In this case, you will probably have both your inputs included but are still being tracked. Of course, it would mean quite an expenditure for that organization, especially since they are only keeping track of you. In any case, I see CoinJoin as a casual solution that works to give low anonymity to the Bitcoin network as a whole rather than high anonymity to a limited group of people.

That will only happen if the mixer ends up proving that he sent the coins. With such a threat in mind, Alice would rather indeed sign whenever she has received the output coins (why wouldn't she anyways?), at which point the contract is never been made public as the mixer has no reason to do so and the association between Alice's old and new addresses is never included into the blockchain.  In other words, the "condition that stated x Bitcoins had to be sent to Alice" clause is never released in the blockchain if Alice signs.

However, as gmaxwell points out, it appears that this attaching of a contract and a proof to a transaction is not possible in Bitcoin at this point.

Can you please be more precise as to which parts could not be done? Not that I don't believe you, I just want to see if I can go around them.

We can simplify for now by supposing that Alice will only receive her funds at address B. I understand that the Mixer -> B tx and the header of the block that contains it will have to be referenced, but I didn't expect it to be very large. I understand that the proof verification will be more computationally intensive for verifying nodes. I'm not sure I understand that a "SPV fragment" is and google isn't helping me much.

I agree that might be necessary.

What I mean by "from address A" is "signed by A's private key" and what I mean by a "transaction to address B" is a "transaction that can only be spent by using B's private key". I understand that accounts are not unified and that the "balance" of an address rests in the number of txins it is able to spend. Am I missing or misrepresenting something? How would you rephrase these terms?

If the script ever gets extended in such a way, I believe that what you propose would be best indeed.

I have a proposal that might or might not be feasible in Bitcoin. I do not fully understand the capabilities of the Bitcoin script and would like to know if it supports such a functionality.

Say Alice wants to mix her coins with a mixing service but she does not trust that the mixer will not run off with her coins.

Alice produces an order that says the following:
    I will give you 10 btc from address A and you must send that amount minus the fees to addresses B and C in a specified time frame.
Alice signs this order and privately sends both the order and its signature to the mixer.
Alice sends 10 btc to the mixer in a special transaction T that locks her coins and is not accepted by the network until it fulfills one of these three properties
-Alice signs T, then the coins go to the mixer
-The mixer provides a proof that B and C have received the expected btc in the expected time frame and produces the signed order, then the coins go to the mixer
-A timeout (say 2 weeks) makes the coins go back to Alice

The result is the following
-If everything goes as planned, Alice signs T, T goes to the mixer, the mixer never publicizes the order and Alice has gained her anonymity
-If the mixer never pays B and C, Alice doesn't have to do anything and her coins are refunded as T refunds the coins to Alice after the expiration period.
-If the mixer pays as expected but Alice does not sign in a timely manner, the mixer can produce the signed order as well as the txs used to pay B and C and T pays the mixer. In this case, Alice loses her anonymity.

It seems to me that neither party can cheat the other out of its money, and both parties will want the transaction to go through. Does that seem right?


There are a few technical things that I am uncertain about
1. Can Alice lock the coins from A in such a manner?
2. Can a transaction be such that depending on how the are conditions met, the coins are output to different addresses?
3. Is is possible to make the script understand the contract and to "prove" that B and C were paid?

If we assume that laundries are easily identifiable on the network, I disagree that using one actually removes the taint. If tainted coins enter a laundry, then any coins exiting the laundry from that point on will share some of that taint, including the coins that the original owner of the tainted coins got back. Thus the result is the same as using CoinJoin, although the taint dissipation is executed faster in the laundry case.

I have done some work previously on the problem and came up with a (theoretical) solution that is quite analogous to CoinJoin but that uses a fixed network off 2-party txs instead of a potentially bigger one. You can see the video here
http://www.youtube.com/watch?v=6hc8qaR_Fok&list=PLUOP0P68GJ3BGjfqoLLnzAefk3ZzXQtJ7&index=35
but as there is a lot of what I am talking about that has already been discussed here, I would like to simply upload the pdf. Is there a website similar to pastebin where I can do that for pdfs? I also have a more detailed description of the network that might be of interest here that is also in pdf format.

Someone previously proposed using Secure Multiparty Computing before to implement CJ, but one must realise that SMC is only a set of tools. E.Z.Yang proposed one specific implementation using sorting, which is a cool idea, but according to Yang himself is currently not feasible in practice. In his own words, "The big obstacle is that secure multiparty sorting is somewhat difficult to implement with large keys (since integer comparison operations tend to only handle a few bits at a time)." The hunt is still on to find an efficient way to use SMC to solve the problem.

I am quite excited that people are working on making this work and will be trying the programs proposed here when I can.

Edit:
Link to the video's pdf: https://www.dropbox.com/s/nvkvo1dl3xif87v/PresentationBitcoin2013.pdf

You are quite right, A, B and D are associated at this point in your situation. Of course, with an M-to-N mixer, A and B could have been combined together into say E previously and then E could not have been linked quite as easily to C or D, as it would be unknown which of them is the payment and which is the change. The same result can be obtained however by mixing N-to-N twice, a first time with A and B to unlink them and a second time with D after the transaction you were proposing. In such a way, the outputs of A and B (which we can call F and G) are linked to spend C and change D as before, but since neither F, G, C or D are linked to anything else after the second mixing, who cares?

Now you are right that my approach takes two mixings while yours takes only one but it is actually more secure since D cannot be linked at all to any other of Alice's future transactions as it is mixed right after. In your approach, an adversary actually would have a 1 out of 2 chance of correctly guessing the change address anyways, whereas this probability of guessing is much smaller in the case of a secure mixing.


Yep, that's just the point of mixing these small outputs. After the mixing, you can just throw them all together in one large output if that is more intuitive, but you can actually go straight to spending them together in one or many larger transactions without caring if they are linked together, as they are linked to nothing else.

One important difference between the schemes you are considering and Yang's is that in your schemes, the people that do the mixing seem to know the link between the input and output addresses of the people that they are mixing with, while this is not the case in Yang's proposal. Another important difference is that you accept inputs of different sizes, while he doesn't. I understand the appeal of using inputs of different sizes but as Yang suggests, we can just transform these into standardized sizes using a greedy algorithm and mix them separately. This means that you don't have to fiddle the sizes as you have been doing.

As for M-to-N mixing with M>N as justusranvier suggested, I believe it is not really an improvement over N-to-N mixing. My reasoning is the following:
The idea of M-to-N mixing seems to be to reduce the number of change addresses each user has. This cannot be done before the mixing as this would link previous transactions. However, this can be done without a problem after the mixing since all that you can learn from the blockchain is that some of the addresses in the mixing belonged to the same person, and you would have learned that from any M-to-N mixing with M>N anyways. Of course, that means that the number of addresses in the mixing transaction is larger, but this has the upside of increasing the anonymity gained.

Thanks for the link, but that seems to have been an e-wallet and not a mixing service.

I was thinking some sketchy startup mixer might have tried doing that as a small scale scam, but I get your point.

I know that many exchanges/services have ran/gone out of business, taking the user's coins with them, but has this already happened with mixing/laundry services? I'd expect that to be the case, but I have found no reports of such events happening.

Do you have any examples of laundry services that burned their users? I am not surprised that there are some but was unable to find reports of such dishonest mixing services.


On another note, there's a presentation on Zerocoin at the Bitcoin 2013 conference this weekend, if anyone wants to go.