It was the Bitcointalk forum that inspired us to create Bitcointalksearch.org - Bitcointalk is an excellent site that should be the default page for anybody dealing in cryptocurrency,
since it is a virtual gold-mine of data. However, our experience and user feedback led us create our site;
Bitcointalk's search is slow, and difficult to get the results you need, because you need to log in first to find anything useful - furthermore, there are rate limiters for their search functionality.
The aim of our project is to create a faster website that yields more results and faster without having to create an account and eliminate the need to log in -
your personal data, therefore, will never be in jeopardy since we are not asking for any of your data and you don't need to provide them to use our site with all of its capabilities.
We created this website with the sole purpose of users being able to search quickly and efficiently in the field of cryptocurrency
so they will have access to the latest and most accurate information and thereby assisting the crypto-community at large.
Just an idea - what if we moved the mixing service to miners as a part of the job they do?
- users would broadcast special half-baked transaction (just inputs) - miners would somehow form the queue of unsigned inputs into mixing "batches" and provide a way how to query current batches - users would broadcast their signatures of the batch - when the batch is signed by all parties, its moved by miner into the current block, if after some timeout it is not signed (few blocks?), its dumped
This would reuse existing Bitcoin p2p network and add new message type(s). The transaction will remain the same, no need for fork. It will allow easy integration into existing clients.
Thanks for copying my idea upthread, and you added an idea of how to integrate without a fork. I can't comment if that will work or not.
Just an idea - what if we moved the mixing service to miners as a part of the job they do?
- users would broadcast special half-baked transaction (just inputs) - miners would somehow form the queue of unsigned inputs into mixing "batches" and provide a way how to query current batches - users would broadcast their signatures of the batch - when the batch is signed by all parties, its moved by miner into the current block, if after some timeout it is not signed (few blocks?), its dumped
This would reuse existing Bitcoin p2p network and add new message type(s). The transaction will remain the same, no need for fork. It will allow easy integration into existing clients.
I guess one issue is that for example with ring (group) signatures, the identity of the signers of the outputs is not known, so if the sum of the outputs doesn't match the sum of the inputs, then it is not known whom to penalize for oversubscribing (DoS) the outputs. We don't want a bijective mapping between inputs and outputs.
The only solution to this I see is to use divide-and-conquer to find the adversary (identity tied to the public key committed to the input). By dividing the set size in half and repeat, eventually the adversaries are discovered or they relent and complete the transaction. This is why a mandatory tx fee is important, so as to deplete their capital if they send to themselves.
The output signatures come at step 2, before step 3 where all sign their inputs, thus recursively repeating this operation is less time costly than being able to DoS step 3.
lol just received this email about our coinjoin server. we are running nothing except tor and our own software (checked processes).
-----Original Message-----
From: [email protected] Sent: 30 August 2013 07:54 To: XXX Subject: Abuse Message [AbuseID:0D0482:15]: AbuseNormal: 22-102567054 Notice of Unauthorized Use of Paramount Pictures Corporation Property
Dear Mr XXX,
We received information about spam or abuse from [email protected]. Please take all necessary measures to avoid this in the future.
Furthermore we request that you send a short response within 24 hours to us and to the complainant. This response should contain information about how this could happen and what you intend to do about it.
Register Court: Registergericht Ansbach, HRB 3204 Management Board: Dipl. Ing. (FH) Martin Hetzner Chairwoman of the Supervisory Board: Diana Rothhan
----- attachment -----
Return-path: <[email protected]> Envelope-to: [email protected] Delivery-date: Thu, 29 Aug 2013 17:52:21 +0200 Received: from [67.128.96.38] (helo=newpop2.baytsp.com) by lms.your-server.de with esmtp (Exim 4.74) (envelope-from <[email protected]>) id 1VF4WC-0005Im-FE for [email protected]; Thu, 29 Aug 2013 17:52:21 +0200 Received: from portalmail2.baytsp.com ([10.243.1.48]) by newpop2.baytsp.com (8.14.4/8.14.4) with ESMTP id r7TFq9cU019137 for <[email protected]>; Thu, 29 Aug 2013 15:52:10 GMT Date: Thu, 29 Aug 2013 15:52:09 GMT From: "[email protected]" <[email protected]> To: [email protected] Message-ID: <12570450.32906.1377791529817.JavaMail.dc@portalmail2> Subject: 22-102567054 Notice of Unauthorized Use of Paramount Pictures Corporation Property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Clear (ClamAV 0.97.6/17768/Thu Aug 29 16:10:58 2013) X-Spam-Score: 1.5 (+) Delivered-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Notice ID: 22-102567054 Notice Date: 29 Aug 2013 15:52:08 GMT
Hetzner Online AG
Dear Sir or Madam:
Irdeto USA, Inc. (hereinafter referred to as "Irdeto") swears under penalty of perjury that Paramount Pictures Corporation ("Paramount") has authorized Irdeto to act as its non-exclusive agent for copyright infringement notification. Irdeto's search of the protocol listed below has detected infringements of Paramount's copyright interests on your IP addresses as detailed in the below report.
Irdeto has reasonable good faith belief that use of the material in the manner complained of in the below report is not authorized by Paramount, its agents, or the law. The information provided herein is accurate to the best of our knowledge. Therefore, this letter is an official notification to effect removal of the detected infringement listed in the below report. The Berne Convention for the Protection of Literary and Artistic Works, the Universal Copyright Convention, as well as bilateral treaties with other countries allow for protection of client's copyrighted work even beyond U.S. borders. The below documentation specifies the exact location of the infringement.
We hereby request that you immediately remove or block access to the infringing material, as specified in the copyright laws, and insure the user refrains from using or sharing with others unauthorized Paramount's materials in the future.
Further, we believe that the entire Internet community benefits when these matters are resolved cooperatively. We urge you to take immediate action to stop this infringing activity and inform us of the results of your actions. We appreciate your efforts toward this common goal.
Please send us a prompt response indicating the actions you have taken to resolve this matter, making sure to reference the Notice ID number above in your response.
Nothing in this letter shall serve as a waiver of any rights or remedies of Paramount with respect to the alleged infringement, all of which are expressly reserved. Should you need to contact me, I may be reached at the below address.
Regards,
Andrew Beck Irdeto USA, Inc. 3255-3 Scott Blvd. Suite 101 Santa Clara, CA 95054 Phone: 408-492-8500 fax: 408-727-6743 [email protected]
Note: The information transmitted in this Notice is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, reproduction, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.
This infringement notice contains an XML tag that can be used to automate the processing of this data. If you would like more information on how to use this tag please contact Irdeto.
Evidentiary Information:
Notice ID: 22-102567054 Initial Infringement Timestamp: 29 Aug 2013 15:39:19 GMT Recent Infringement Timestamp: 29 Aug 2013 15:39:19 GMT Infringers IP Address: 46.4.92.107 Protocol: BitTorrent Infringed Work: Jack Reacher Infringing File Name: Jack.Reacher.2012.FRENCH.BDRip.XviD-AYMO.avi Infringing File Size: 1464350720 Bay ID: 5166dd04b34ac587893959274914e9a782d8c375|1464350720 Port ID: 40670 Infringer's User Name:
Irdeto USA, Inc Andrew Beck 3255-3 Scott Blvd. Suite 101, Santa Clara, California 95054 United States of America 408-492-8500,408-727-6743 [email protected]
What about DOS attacks? Can't someone refuse to sign even if the transaction is valid?
Yes, this can be DOS attacked in two different ways: someone can refuse to sign a valid joint transaction, or someone can spend their input out from under the joint transaction before it completes.
However, if all the signatures don't come in within some time limit, or a conflicting transaction is created, you can simply leave the bad parties and try again. With an automated process any retries would be invisible to the user. So the only real risk is a persistent DOS attacker.
In the non-decentralized (or decentralized but non-private to participants) case, gaining some immunity to DOS attackers is easy: if someone fails to sign for an input, you blacklist that input from further rounds. They are then naturally rate-limited by their ability to create more confirmed Bitcoin transactions.
I don't see any way for the DoS adversary to spend the input before the joint transaction completes, if the joint transaction is atomic in the current block. If the joint transaction has been populated to all mining pools, then the input is disallowed by those pools to be double-spent in another transaction in the same block. If there is a competing PoW fork which didn't grab the joint transaction, then which ever fork wins will unwind the transactions of the losing fork(s). Am I missing something or was your point specific to limitations of Bitcoin (and not any altcoin in general)?
If those who want to participate in the joint transaction must sign with their private key to prove they have the funds available, before the set of payers (participant signers) is selected, then they can be fined for not signing the joint transaction. Am I missing something?
I do not know what Bitcoin miners do when they see double-spend attempts in the same atomic block. I am thinking they should submit these to the blockchain under some special transaction which fines the payer.
I guess one issue is that for example with ring (group) signatures, the identity of the signers of the outputs is not known, so if the sum of the outputs doesn't match the sum of the inputs, then it is not known whom to penalize for oversubscribing (DoS) the outputs. We don't want a bijective mapping between inputs and outputs.
This is not decentralized in the sense that the blockchain is a central ledger, but it is meta-decentralized in the sense that PoW input entropy is.
First of all it has to be recognized that in a truly decentralized environment that are almost no protections against sybil attackers; the best you can do is make a sybil attack expensive. Because of this a n-party-mix with fancy cryptography is equivalent to an iterated 2-party mix. (even in an n-party-mix n-1 of the parties might be a sybil attacker) This is not true for the non-decentralized case, such as a mix where access is controlled by possession of a bitcointalk account, or a good OTR reputation.
Secondly in a 2 party mix the other party automatically knows what txins and txouts you are contributing to the mix by process of elimination. There's nothing you can do about that. However you can ensure that only that party knows, provided your counter-party doesn't reveal the info.
Thirdly the anti-dos limited resource should be denominated in Bitcoins, not proof of work or some other similar scheme; you want a large-scale attacker to have costs as similar as possible to a small-scale attacker and PoW functions are very susceptible to large improvements due to optimization. For Bitcoin's that optimization has already happened.
So, building on my previous thoughts earlier in this thread, I'm proposing the following basic mix protocol, here between Alice and Bob:
1) Announce: Alice states that she wishes to create a transaction.
2) Reply: Bob replies with the txins and txout he wishes to add to the transaction.
3) Sign: Alice signs her txins and sends the signatures to Bob.
4) Broadcast: Bob signs his txins, and broadcasts the transaction.
Step 1 happens in the clear; steps 2 and 3 can be encrypted to the pubkeys of the respective receivers.
For anti-DoS the act of broadcasting these messages can be made expensive by requiring the senders to include a nLockTime'd transaction spending a txin to a scriptPubKey the sender controls. Usually this txin would be used in the mix, although technically it doesn't have to be. The key idea here is that by broadcasting such a tx the sender is guaranteed to spend some tx fees somehow, either in the nLockTime'd tx, or in a different tx with the same txin. The actual amount of fees required per KB of data broadcast can be adjusted automatically by supply and demand.
Note how since tx fees are what is being used you automatically have sybil resistance: an attacker trying to be the counter-party to a large % of total traffic will need to either spend, or have access to the privkeys of, a large % of all the transactions being done on Bitcoin itself. While any individual transaction may get unlucky and fall victim to an eavesdropper, overall there is a significant privacy benefit.
As for the broadcast medium, like I suggested above, putting this data on the Bitcoin P2P network itself makes the most sense to ensure the widest possible usage. Similarly re: usage, note how the only cryptographic primitive used in the above protocol that is not currently used by Bitcoin wallets is asymmetric encryption. Being only two parties transactions can go through quickly when counter-parties are available, and they can timeout and fallback to standard transactions otherwise. Bandwidth usage is a small multiple of the transactions themselves; potentially less if return-path routing of the replies can be made to work properly.
FWIW I'm planning on implementing this, either directly in the satoshi client, or as a prototype in python-bitcoinlib. It's a good complement to more complex schemes utilizing multi-party cryptography primitives for mixes among semi-centralized groups.
Don't you need tor or something to prevent everyone from learning everyone's IP?
Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)
As far as I know, Tor and I2P are low-latency mix-nets. Only a HIGH-latency (with random delays and orderings of relay) mix-net is robust against timing traffic analysis. I2P mentions possible high-latency support coming in version 3, but is that realistically coming very soon?
So really they don't necessarily insure anonymity against a formidable adversary such as intelligence agencies.
Also Tor limits hops to 3, and the security of mix-nets is related to the probability that at least one hop isn't compromised. Also all peers don't relay in Tor, thus Tor's servers are subsidized and some think they are already a tool of the intelligence agencies. Good performance, low-latency anonymity apparently isn't economic.
I have not studied BitMessage and Freenet. Do they offer the complete solution?
Is BitMessage using onion or garlic routing along with high-latency relaying?
That is if there is no cost to having multiplexed transactions, unlimited number of public keys, and the delays and limited time windows of CoinJoin or the blockchain + hash check bloat of Zerocoin. I am also thinking of a Visa-scalable block chain. Your naive users will never be using Bitcoin any way, because the blockchain can't scale. By making CoinJoin popular, you will have further cemented Bitcoin's inability to modify the block chain design in this respect (although there may be a way to scale the block chain with multiplexed transactions and unlimited public keys, I am still studying this).
If there is no cost, I am not against it. I am arguing it is lower priority, not that it isn't worth considering if it fits into the big picture goals.
Look at the above. I am happy to have the world know I am giving 5BTC to this effort, and I am happy for Gregory Maxwell to know that it is me where the money is coming from. But why should I give the whole world insight into my finances? With CoinJoin I won't have to use something as convoluted as encrypting an access key, and the proposals above share a common thread of being such that all the actual complexity can be hidden away in software with a sufficiently sophisticated implementation.
So why not have a separate individual BTC pool of capital for those purposes where you explicitly want to be public? Else send him a paypal to his email address. (Personally I wouldn't be announcing publicly my ownership of Bitcoin, because I think the governments are going to demand capital gains taxes in arrears, when they declare it isn't money rather a good like gold).
My upthread solution basically was to use high-latency mix-net (which doesn't exist!) and always be anonymous, else use the centralized banking system.
One problem with my proposed solution is the fungibility of taint. I had not read the linked thread prior to writing the above, thus didn't realize the gravity of the numerous mentions of "taint" in the OP.
I suppose there are rare cases where you want to give your identity to someone trusted but not the identity of the merchant to your bank. But that hardly seems like a compelling use case to justify such convoluted systems as proposed for CoinJoin.
Another problem with my proposed solution is although it does protect our privacy, but it doesn't protect our anonymity in an important use case, which I had mentioned as quoted above. Note some prior discussion that privacy and anonymity are related but not the same. The case is we want to be anonymous to the banks, i.e. we don't want all our payment history to be known to anyone (perhaps for legal, criminal, and free speech liability reasons), yet we have no choice but to reveal our identity to the merchant in order to use the service. An example is participating in a videochat forum (without a physical disguise) on some topic which is considered amoral, illegal, or threatening in some jurisdictions but not in others. For example paid sex videochat is illegal in some countries but not in others, but I am sure there are many other legitimate examples which are less offensive to readers here.
Without coin laundries, the only way to solve the above is to rely on the merchant to keep your public key secret. The merchant could even set up a server which receives the payment proof via BitMessage (and returns an access code which can be used on the merchant's website), so that the public key storage server's location can't be known by anyone other than the merchant. However the problem is that relying on the merchant is inherently insecure.
Also even if the payer doesn't care about his anonymity and privacy, the merchant might, so taint issue is also to a lesser degree about knowing who to pressure to reveal information about the merchant, i.e. the merchant might protect the identity of his customers well but the customers might not automatically protect their own identities well.
I am now looking at adam3us (Adam Back)'s ring signature suggestion. What are the tradeoffs of a ring signature approach?
I will re-read this thread and the other one to see if I find the answer. If there is anything to add to what has been already written in the two threads, please do. Especially to make the discussion more readily comprehensible for someone who is mathematical but not well studied in cryptography terminology ("oracles", etc.).
A couple minutes ago Phantomcircuit directed me to this writeup, which I'd not see before. It's a great proposal and does better from a privacy perspective of my earlier suggestions of ZC + TOR or Cham+Tor. And it's not especially new either! here we see the problem with just pumping out theory and not implementations: The activity in this thread is already more practically useful than that year old blog post.
In any case, they propose using multi-party computation to SORT a list of pubkeys provided by the participants. This accomplishes two things: Blinds the participants to whos keys is whos but makes sure that everyone knows that the pubkeys all came from the participants. Using chaum accomplishes only the latter but would depend on using tor (or the like) to prevent participants from learning the mapping. This is somewhat non-ideal if we want to be super paranoid about such things since tor is very vulnerable to timing analysis.
I'd looked into using MPC for this before but I was overthinking it and expecting the MPC to do too much and it didn't seem practical. It did not occur to me that we only needed a _sort_ to hide the correspondence.
So to make this real you need a multi-party computation system that can implement a sort: Here you go: http://viff.dk/ to use it build it then run
(It appears to be a bit python bitrotted and doesn't actually work for me ATM)
The sort.py script is setup for three players providing inputs, and they pick random values to sort (with an array of size .. all of this can easily be adjusted.
The protocol requires log2^2(N) communications between all the participants. You'd have every player provide a pubkey, at the end they all get a sorted list and learn nothing about who sent what.
Downsides:
* Thats a boatload of communication for a lot of participants, especially since you'd still run this over tor to hide the inputting parties IPs. This means that you probably have to have all parties online and communicating in realtime... if people are only logging on once per day, an 8 party operation would take 10 days I think. (log2^2(N))
* The MPC implementation in viff only has security against passive attackers e.g. they might snoop but they follow the protocol. VIFF has some code for a different kind of MPC which is secure against active attackers but I've never been able to get it to work before (in particular, it doesn't seem to have a comparison operator... which.. uh. sort really needs).
* Also, this is all expensive enough that it's probably not helpful for preventing DOS even if the activity model does let you detect which party is misbehaving.
Upside: no depending on TOR for hiding the mapping between parties, and stronger fundamental security than tor, to keep players identity secret from each other.
(Also downside— will take work to go implement this in an actual system )
I intended it as "make a proposal, do work, receive some baconreward". Obviously, if people want to appear with fully formed solutions they should get rewards too. My main criteria is that work done be actually usable by someone for something, we're awash with ideas around here (myself included): so show me the code. I am very much in support of the spirit here of just getting some stuff published and getting people trying it... this means both simple tools that don't implement a more complete vision, and more powerful ones too. The whole idea is to flow some funds from people who want to see this exist to people who are working on making it exist and everyone leaving happy, and so I think exposing a lot of really exacting procedural requirements isn't a grand idea. (Also, it's likely the case that I didn't foresee all the things that needed to be done in my post. Please: solve problems I didn't know existed too.)
(And yes, I need to pay out some bounties to the work done by people so far ... I'm afraid that it's probably going to wait until this weekend before I can try out the tools and talk to the other signers! (and feedback from donors and other people who've tried the stuff out!))
This just the right sentiment to get us moving forward .... without wanting to pee in the OS punchbowl (forewarned is forearmed), it is also probably worth keeping in mind that there is likely a rather large pot of funding waiting in the wings with an eye towards commercialisation of the CoinJoin tech (or similar), whether it be through proprietary s/ware packaging or fees for a pay-per-tx models or whatever.
I intended it as "make a proposal, do work, receive some baconreward". Obviously, if people want to appear with fully formed solutions they should get rewards too. My main criteria is that work done be actually usable by someone for something, we're awash with ideas around here (myself included): so show me the code. I am very much in support of the spirit here of just getting some stuff published and getting people trying it... this means both simple tools that don't implement a more complete vision, and more powerful ones too. The whole idea is to flow some funds from people who want to see this exist to people who are working on making it exist and everyone leaving happy, and so I think exposing a lot of really exacting procedural requirements isn't a grand idea. (Also, it's likely the case that I didn't foresee all the things that needed to be done in my post. Please: solve problems I didn't know existed too.)
(And yes, I need to pay out some bounties to the work done by people so far ... I'm afraid that it's probably going to wait until this weekend before I can try out the tools and talk to the other signers! (and feedback from donors and other people who've tried the stuff out!))
The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Emphasis mine.
Sounds like the intent was for people to make a proposal, do work, and potentially collect a reward. That means there aren't any requirements until a proposal is made.
I actually read that completely differently - that the bounty specifically requires support for the cryptographic anonymizing protocols that were proposed and discussed in the first few posts of this thread. Nevertheless, some clarity from he judges would be appreciated.
So far bitprivacy looks very interesting. I haven't reviewed the code at all, but the readme makes it sound like the kind of thing that's integratable directly into MultiBit or other wallets.
Support for Tor/fidelity bonds etc is all well and good but even a DoSable v1 would be a good upgrade for users today.
Ideally the implementation would be linkable into regular end user wallets so anyone can run a server, that's the more Bitcoinish way to doit, but the AGPL license prevents that as no existing wallet is licensed that way (and I doubt it will be changing).
Wallets aren't the only thing that matters: businesses will want to use this tech as well to keep their own finances private. The AGPL is IMO right out for that application - even the LGPL is problematic.
This is I think one of the problems with the bounty model. You have very loose requirements and a "we'll make it up as we go along" payout model, you're going to get disappointment and problems, it's just inevitable. Nobody specified the license so now we have one that practically guarantees that server operators and end users are different people, for no good technical reason (ignoring the choice of language and tools which make it hard to ship on things like phones).
Quote
The bounty fund will pay out as funds are available according to the signers best judgment for completed work proposed in this thread that furthers the goal of making improved transaction privacy a practical reality for Bitcoin users.
Emphasis mine.
Sounds like the intent was for people to make a proposal, do work, and potentially collect a reward. That means there aren't any requirements until a proposal is made. As for donators, they should recognize that they are putting their faith in gmaxwell, theymos and sipa's best judgement. (something I myself am quite confident in)
Now if it was going to be undefined, I'd suggest they say that in 9 months or something funds to to whomever has made the most actual impact to getting CoinJoin technology actually used in this space. As jdillon suggested proposals that integrate into existing wallet software are most important there.
Instead of people racing to hack out the *first* solution (typically badly written) you instead ask for people to bid (going to be renamed *dib* soon) as to when they will come up with a quality solution - if their bid/dib is accepted then they are not competing against anyone apart from themselves (to complete the task by the deadline they provided themselves).
The first 10 projects to be listed on CIYAM Open can be fee free for life so if you are serious in getting a project done *properly* I would be happy to help out.
CIYAM Open also allows people to donate at either the Project, Project Area or specific Project Task level.
It is MIT licensed, and furthers the goal of making improved transaction privacy a practical reality for Bitcoin users. It might help if you clarify whether funds can be paid for work done before the setting up of this bounty. I'm assuming solutions don't need to be called coinjoin, if this isn't the case you should say.
It's great to see so many people contribute to this bounty.
If you want to help bitprivacy directly, you could try it out and post in the thread.
Ideally the implementation would be linkable into regular end user wallets so anyone can run a server, that's the more Bitcoinish way to doit, but the AGPL license prevents that as no existing wallet is licensed that way (and I doubt it will be changing).
This is I think one of the problems with the bounty model. You have very loose requirements and a "we'll make it up as we go along" payout model, you're going to get disappointment and problems, it's just inevitable. Nobody specified the license so now we have one that practically guarantees that server operators and end users are different people, for no good technical reason (ignoring the choice of language and tools which make it hard to ship on things like phones).
.. all of this can easily be adjusted.
) 
