Bitcoin Forum
February 03, 2023, 12:59:28 AM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Other / Beginners & Help / Re: Who can help a newbie? on: October 12, 2017, 02:53:55 AM
i can  help you anytime if you hook it up. I will always help you if you help me
2  Other / Beginners & Help / Re: Bitcoin for Beginners on: October 12, 2017, 02:52:28 AM
i am new to bitcoin and looking fowrd to go further. Bitcoin is very interesting hard pays
3  Other / Off-topic / Re: The most painful thing in your life on: October 11, 2017, 05:46:29 AM
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
4  Other / Bitcoin Wiki / Re: Request edit privileges here on: December 07, 2015, 03:41:58 AM
User name: Murphant

I want to add my master's thesis to the research page.
5  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: January 30, 2014, 10:35:31 PM
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?
6  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: January 18, 2014, 10:05:53 PM
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.

This is not exactly what I meant.

Alice uses input A and sends 1 btc to address S. Bob uses input B and sends 1 btc to address S. Correct coinjoin transaction would look like [A, B] -> [(S,1), (S,1)], but here service could change it to  [A, B] -> [(S,1), (X,1)], where X is services' address. Since Alice isn't aware of Bob's transaction and vice versa none would suspect the (S,1) output is not theirs, thus signing the transaction. As I said I don't really understand how maaku solves this problem. As I see it the only way to solve it is for users to provide some kind of a nonce with the outputs that can later be checked.

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.
7  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: January 18, 2014, 09:39:36 PM
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.

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

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.
8  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: November 18, 2013, 05:41:14 PM
For disadvantage (2):
Apparently the only way around is to split-up the amount to be cleaned into smaller quantities and serialize the procedure. E.g. if I want to clean 100 BTC, I serialize it into 100 times 1 BTC, i.e. I will not send out the (n+1)th BTC to the mixer before I have received the nth BTC back. So my risk of fraud gets reduced to 1 BTC. The price I pay is the increased Tx fees, so I can half these fees by accepting twice the risk by selecting 2 BTC increments for the mixing procedure instead of 1 BTC.
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.

2nd topic:
Idea how to minimize the likelihood of a CoinJoin sybil attack (i.e. that the N-1 co-participants of my CoinJoin transaction are "3-letter-hostile-organization spies"):
  • I initiate TWO CoinJoin transactions instead of just one, of equal output size, and at about the same time, but I inject them at different points of the network if possible (so that an observer does not know they both origin from me).
  • When all co-participants have completed their inputs to reach the number N (here I assume N=10 or so at least), I check if BOTH of my inputs show up amongst these N.
    • If yes, I can fairly assume that the CoinJoin server did not get flooded with 3-letter-hostile spying-transactions and also the other N-2 inputs are probably legit, and I will sign my two transactions.
    • If no, I must assume that the other N-1 transactions are hostile and my second input has been "squeezed-out" and pushed to the next CoinJoin transactions, and I better refrain from signing and try again later. Or I sign anyway (because my non-signing might get interpreted as a DOS attack) but then initiate another CoinJoin transaction were hopefully both of my inputs will show up then...

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.
9  Bitcoin / Development & Technical Discussion / Re: Idea for a mixer that can't run with your coins on: October 29, 2013, 01:03:47 AM
People can search the blockchain to see if there was ever a condition that stated x Bitcoin had to be sent to Alice's address in order to unlock Bitcoins. Leaving Alices new 'mixed' bitcoin forever linked to her old ones.

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.
10  Bitcoin / Development & Technical Discussion / Re: Idea for a mixer that can't run with your coins on: October 26, 2013, 05:33:40 PM
This cannot be implemented in the script today due to disabled op_codes.
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.

Even if it could be, the resulting transactions for the proof of payment redemption would be prohibitively large: They'd have to contain a SPV fragment for the mixer->b,c transaction plus some block headers, and the complete mixer->b,c transaction, and the script search for the right outputs and then check the fragments.
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.

[...] constrain your protocol that Alice must know the exact transaction the mixer intends to make [...]
I agree that might be necessary.

As an aside, your notation of "from address", "to address" suggest a pretty substantial misunderstanding of the Bitcoin system, likely inspired by block explorer sites that present things in terms of "address = account", this isn't how the protocol actually works.. but what you're describing could be restated in terms that do make sense in the Bitcoin protocol
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 script is ever extended to allow compact proofs of computation (https://bitcointalk.org/index.php?topic=277389.0) then what you're describing could work without huge transactions.  If the proof of computation is zero-knowledge then your protocol could be simplified further: instead of Alice releasing the coins in the faithful execution case the your second party could redeem them using a zero-knowledge proof that Alice's rules were followed, without actually revealing what those rules were.
If the script ever gets extended in such a way, I believe that what you propose would be best indeed.
11  Bitcoin / Development & Technical Discussion / Idea for a mixer that can't run with your coins on: October 25, 2013, 09:24:08 PM
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?
12  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: October 15, 2013, 05:57:45 PM

If we want to specifically and completely remove a certain colored taint from some coins, the use of a traditional "laundry" may be more adequate.


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.
13  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world on: September 01, 2013, 04:09:29 PM
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
14  Bitcoin / Development & Technical Discussion / Re: P2P coin mixing on: June 01, 2013, 07:24:49 PM
Suppose I have two outputs A and B, each with a value of 0.5 BTC. Presently there is no information in the blockchain that indicates A and B are owned by the same person. If I want to send 0.75 BTC to a third party, I must create a transaction  that takes A and B as inputs and creates a 0.75 output C and a 0.25 change output D.

An attacker looking at this transaction can conclude that the same person owns A, B and, D because it would not have been necessary to combine A and B if the real spend was only 0.25. It would not matter at all if A and B had been mixed prior to this operation or not.

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.

you have to combine smaller outputs from time to time in transactions

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.
15  Bitcoin / Development & Technical Discussion / Re: P2P coin mixing on: May 25, 2013, 04:29:58 PM
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.
16  Economy / Service Discussion / Re: Existence of mixers that ran with user's coins? on: May 19, 2013, 03:48:58 PM
Thanks for the link, but that seems to have been an e-wallet and not a mixing service.
17  Economy / Service Discussion / Re: Existence of mixers that ran with user's coins? on: May 19, 2013, 06:29:13 AM
I was thinking some sketchy startup mixer might have tried doing that as a small scale scam, but I get your point.
18  Economy / Service Discussion / Existence of mixers that ran with user's coins? on: May 18, 2013, 05:12:13 PM
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.
19  Other / Beginners & Help / Re: ZeroCoin on: May 13, 2013, 04:38:31 AM
Interesting... a lot of people have been burned by some scrupulous laundry services. This will be really useful.

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.
20  Bitcoin / Development & Technical Discussion / Re: Decentralised crime fighting using private set intersection protocols on: March 28, 2013, 04:26:37 PM
the tainted coins can be thrown away by spending them to transactions

While this is true, it would be hard to launder large amounts of money in that way due to the rather small tx fees at the moment. I understand the analogy with a Casino's profits, but it seems to me that the creation of a block is a rather hefty price to pay for laundering such a sum. Take into account that a miner who is able to mine a bloc and "clean" such shady transactions could instead have cashed in on regular tx fees for other transactions. These regular tx fees not received represent a loss for the miner. Thus, it seems to me that the coins should become clean once they are included in a tx fee simply because it is not efficient for a miner to participate in such a cleaning scheme.
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!