gmaxwell: Yes, in the last part of that comment, that's what I suggested.

If a pseudonym is reused often, then correlation could be used to link all inputs with the pseudonym that provided them. This could the be further used to see if outputs from mixed transactions that the pseudonym in question has been part in often has some outputs in common, thus deanonymizing users who use this frequently for the same outputs (assuming the recipient has repeating or non-individual payment/donation addresses, which is common).

I've read that SMPC has been used IRL successfully for auctions for farms selling their goods. Can't remember the source. SMPC should be possible to run on most hardware. There's multiple implementations of it, some in Java and some in C.

How would a homomorphic mix work?

Two-round SMPC could certainly work, where the inputs simply are the individual signatures plus the previously unsigned transaction, creating a properly signed transaction.

Edit: SMPC implementations:
FairplayMP: http://www.cs.huji.ac.il/project/Fairplay/
Sepia: http://www.sepia.ee.ethz.ch/
Viff: http://viff.dk/
SIMAP (nothing available for download?): http://ny.alexandra.dk/uk/labs/Security-lab/Pages/Secure-Multiparty-Computation.aspx

I have one suggestion that among others uses Secure Multiparty Computation (SMPC). https://en.wikipedia.org/wiki/Secure_multi-party_computation

Step one: Peer finding is done using a DHT network. This can be done inside I2P or Tor if you want to for increased anonymity. You might want to do reputation tracking where nodes uses public-key based pseudonyms (if you reuse a pseudonym, you must make sure to not spend inputs that can be tied to you personally more than just once (or rather not more often than the average, some identifiable inputs might by chance be involved with the same 3rd party multiple times) with that pseudonym since it otherwise can be directly correlated with your pseudonym).

To make verification of inputs simple and quick, each client keeps an updated Merkle tree hash of all currently valid spendable outputs in the blockchain (basically those that not have been spent yet) in this form: [Address]-[Transaction ID]-[Amount of BTC].

The SMPC uses cryptography to emulate a trusted 3rd party computer, running code all participants have agreed on. Unless a majority of the participants collude (Sybil attacks are a potential issue, be careful about who you run this with), no participant can get any other information out of it than they are *supposed* to get out of it.

Now, everybody puts in their transactions and their private keys for them. The SMPC checks if all participants really have the correct private keys for the (valid) previous outputs they claim as inputs through checking what addresses they correspond to, what transaction ID was claimed and how many bitcoins are claimed, and checks this data against the Merkle hash tree.

It then checks that the outputs aren't larger than the inputs. A transaction is then generated with all the user provided inputs and outputs, and signs it with all the private keys.

The signed transaction is given as an output to all the participants, and any one of them can publish it (or all of them at once).

Nobody can know which transactions came from whom, other than that they know their own. Out comes a signed Bitcoin transaction that includes them all in one. Either everything gets signed properly or it exits with an error. The protocol doesn't allow the generated transaction to be created in any other way than the correct way. All user specified outputs will be included, all user specified inputs will be included, no user can specify larger outputs than inputs (unless everybody agrees), etc...

The only major risk here is that of a Sybil attack (a large number of colluding nodes), and the major risk in here is private-key disclosure, the second is identifying which pseudonym spent what input. I hope that we can get around that somehow. One possible way is to not have the private keys provided to the SMPC, but to use simply prove you have the private key through signing a challenge of some sort, where the challenge can be a random number that is a checksum of all random numbers provided as inputs by the participants, so you only need one signature per participant. The SMPC would then only output an unsigned transaction, where all participants needs to sign it. The question then is how they all share their signatures with the other participants, ideally they should be able to hide that it came from them. Chaumian blinding could maybe be used in this step.

If you decide to not use blinding (to just pass on your signature), and not use any permanent pseudonym of any kind, then you'll have a risk of DoS attempts through both doublespend attempts (making the generated transaction invalid) and through canceled SMPC runs at the last step (thus wasting CPU power).

My intent is to make the system as automatable and fast as possible while maintaining full security.

Vissa klienter låter en redan välja om man vill visa det i BTC eller mBTC.

Lite udda med de som inte ens har reklam. Fast å andra sidan kör jag med Adblock, så det är väl mer än fråga om vilka som *kräver* att man har Adblock av.

It contains a bunch of bitcoin related keypairs, yes. But my suggestion involves a backup related keypair that is dedicated to backup, not part of the bitcoin protocol.

Here's my take on the idea:

1: Your wallet is encrypted. There are multiple options. The primary options are two, asymmetric or symmetric. More on this later.

2: Your ecrypted wallet is split into numbered pieces. Probably 64k per piece. A wallet of, let's say, 512 kb would be 8 pieces. Each piece are given a label consisting of one random string + piece number, the random number would preferably the public key of the wallet owner.
Example label: 1GJKkkdc6cnriW6CFsi2gxrTME1CJzcfpo-01
To prevent spammers from uploading a billion intentially wrong pieces with the same label as yours you would sign each piece cryptographically so that you can verify that they are yours at download. You would also include a date stamp.

3: The pieces are uploaded. Everybody would store such pieces. Since the labels include the public keys from the keypair that was used to generate the signatures, each node could discard pieces with labels that do not match the signature of the piece. This prevents spammers from flooding the network with bad pieces and thus makes it easier to get the right ones at download.

4: When you download your pieces you make a request for pieces labels with your public key. You check the date stamp and verify the signature. Then you decrypt it.

Regarding encryption:

Option 1 - asymmetric encryptions like RSA (PGP and GPG):
Advantages: You don't have to enter the password every time or store it in plaintext on the machine that encrypts the wallet and uploads them. All you need on the computer is the public key of the key pair to encrypt. You only need the private key and password when decrypting after fetching your pieces. The private key can be a 4096 bit RSA key that is stored in a safe box in a bank once while the wallet still is just as usable as before and you can make backups continously.
Disadvantages: You must back up your private key seperately. There is no point in doing this in the network too, then you'd lose most of the advantages compared it has over symmetric encryption. You could just as well use symmectric encryption if you have no good way to back up the private key.

Option 2 - symmetric encryption like AES:
Advantages: You don't need to keep track of any key files. All you need is the password that you remember in your head. The password would be used as a key by hashing it with SHA256 (which is considered very strong).
Disadvantages: You need to enter your pass every time you start your miner or it has to be stored in plaintext. If your password sucks then it WILL be broken quickly since all an attacker need is your public key (and since you put this as a label on your pieces it's easy to get) and then start to bruteforce the pass. If you use the same password for it as for your email/facebook/whatever and *ever* have mentioned your public key in email/facebook/whatever, then *THAT IS ALL* an attacker need to "e-swipe" your wallet! If any of those sites are hacked and your pass is leaked, YOU HAVE LOST YOUR BITCOINS IN SECONDS! Do NOT use the same password for this as for anything else!

Note that for symmetric encryption you should still have an asymmetric keypair to sign the pieces before uploading, but at the recovery stage only the public key is needed and only needed to identify and authenticate your own pieces.

Summary: Wallets are split in pieces, are encrypted, signed and uploaded. Nodes that store them check the signature aginst the uploaded encrypted piece so that bad (spammer) pieces can be discarded (this don't have to be done every time, maybe for every 3rd piece to save CPU?). To get them for recovery you send a request for pieces with your public key. You verify them, assemble them, and then decrypt them to get your wallet file. With RSA you need the private key and the pass, with AES you only need a pass (different advantages and disadvantages).

May I suggest making an Android app (or adapting an existing one) for the monitoring? A widget on your home screen that shows stats like average khash/sec last 10 minutes, temperature, uptime, uptime percentage, current system status, etc... That would be really useful. Too bad I can't afford setting up a rig!