Server:
More technical info: http://sx.dyne.org/anontx
We've delivered usable software, simple for grandma (money goes in, money goes out), requires no blockchain or bitcoind, easy to install and trustless. We followed gmaxwell's instructions as our guidepoint and went further. And we delivered the product fast.
Right, the key is to make it a thing normal users do. Central services can be shutdown.
You have the code. Setup your own server. It's all opensource.
note: Our implementation of the server is in stages and does not know the mapping so it's better even.
...
As I said above, I generally think the non-decenteralized versions of these transactions will be implemented and commonly used first, simply because they're so much less work to do.
note: we do a 4 step process where the outputs and inputs are loaded separately, so the server doesn't know the mapping between them
I think adding a rendezvous mechanism to the P2P network makes sense. It's already a broadcast network after all. So perhaps the right design is not to try and do absolutely everything over the existing P2P network but rather allow people to announce rendezvous points (Tor hidden services?) over the broadcast channel and then allow nodes to set announcement filters like they set Bloom filters today. If you are an SPV/leaf node on the network you wouldn't hear announcements until you request them. Other nodes would relay them all.
- Powerless: has no real power. It's just a meeting point for participants to exchange data.
- Uninformed: has no special information except that which is public (and goes on the blockchain). There's no mapping between inputs and outputs because clients add their data in successive stages.
- Controls nothing: holds no funds. Funds and private keys are stored client side. Signing is done client side.
- Tor service. You can take down hidden services, but Silk Road and all the other services are still running around since 2+ years. Code is opensource so you can setup your own services. Users just paste the URL into the software. It's not really centralised. An analogy: BitcoinSpinner uses the BitcoinSpinner server, but in Electrum you choose your server and can setup your own.
- Extensible. Adding the p2p mechanism for exchanging data can easily be done. Replace the ServerInterface class methods in client.py with your own: https://github.com/calafou/coinjoin/blob/master/client.py Then the URL in the software becomes a shared secret. We designed the software with this in mind.
More technical info: http://sx.dyne.org/anontx
We've delivered usable software, simple for grandma (money goes in, money goes out), requires no blockchain or bitcoind, easy to install and trustless. We followed gmaxwell's instructions as our guidepoint and went further. And we delivered the product fast.
As far as I can tell, genjix's implementation is neither decentralized nor private, correct? The hard parts are still left to be done.
Right, the key is to make it a thing normal users do. Central services can be shutdown.
You have the code. Setup your own server. It's all opensource.
FAQ:
Don't the users learn which inputs match up to which outputs?
In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their inputs and outputs to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.
Don't the users learn which inputs match up to which outputs?
In the simplest possible implementation where users meet up on IRC over tor or the like, yes they do. The next simplest implementation is where the users send their inputs and outputs to some meeting point server, and the server creates the transaction and asks people to sign it. The server learns the mapping, but no one else does, and the server still can't steal the coins.
note: Our implementation of the server is in stages and does not know the mapping so it's better even.
This is an extremely interesting idea. Could you elaborate on how the Zerocoin transaction stages map to the stages of CoinJoin transaction creation?
For non-decenteralized coincoin, you simply pass around a transaction and sign it. It's a single sequence and an atomic transaction, you'd make two loops through the users, one to discover the inputs and outputs, and another to sign them. There really aren't stages to it....
As I said above, I generally think the non-decenteralized versions of these transactions will be implemented and commonly used first, simply because they're so much less work to do.
note: we do a 4 step process where the outputs and inputs are loaded separately, so the server doesn't know the mapping between them
I think adding a rendezvous mechanism to the P2P network makes sense. It's already a broadcast network after all. So perhaps the right design is not to try and do absolutely everything over the existing P2P network but rather allow people to announce rendezvous points (Tor hidden services?) over the broadcast channel and then allow nodes to set announcement filters like they set Bloom filters today. If you are an SPV/leaf node on the network you wouldn't hear announcements until you request them. Other nodes would relay them all.