We are getting closer and closer to what I believe to be the most important Bitcoin conference of 2014. We are really excited to be part of it and can’t wait to meet everyone, especially the devs but also startups and ultimately what makes Bitcoin really great and
unique – the community and the people!
At this point it looks like most of the schedule is final and we are definitely looking forward to hear the keynote speech and all the feature presentations. These presentations now have a title, but are not ultra detailed yet: we are guessing to hear all sorts of things, ranging from legacy-banking bridges, insurance, regulation but also more robust storage and payment solutions with ease of use, security and privacy in mind as one main focus.
Especially regarding the security and privacy we hope to hear talks about the payment protocol (for which we just finished the implementation of the client component, currently in a test-phase on our testnet environment) but also stealth addresses, coinjoin and merge avoidance.
We would also like to congratulate with the DarkWallet team for pulling off the first wallet that implements innovative privacy features such as coinjoin and stealth addresses. There has been a lot of discussion about all these features in the recent past, especially stealth addresses and the so called waste of disk/memory capacity due to blockchain overbloat.
BIP32 allows for the creation of a Master key pair. Using the master public key you can derive an unlimited number of child public keys, the private keys for which can be derived from the master private key.
You could theoretically put your master public key on a server and dynamically generate a new address for each new payee. This way you don’t have to keep your private keys on the server.
The problem is that doesn’t work in some use cases. For example, I have a basic WordPress blog with a static tip address. I cant dynamically generate a new address for each tipper because I don’t control wordpress’s server.
I could put my master public key on my blog, but then anyone can use that to derive all my addresses and see the balance of my wallet.
The reason stealth was created was to allow me to put up a single address and receive payments to a new address each time without other people seeing my balance.
Now, you can still have stealth addresses without using the blockchain as a mean to store the secret. But it requires communication with the party you intend to transact with, which as Mike suggests, could be easily
done with the payment protocol.
It’s really hard to say, yet, what is waste and what isn’t, especially thinking about multisig addresses. In fact, they take additional space too – as Peter Todd said in the bitcoin-dev mailing list – and we certainly don’t consider that a waste so it will be interesting to see what happens. It seems clear the community wants and needs an offline way to generate addresses for third parties and using the blockchain means you don’t need to backup additional data each time (which would be required if the system used was exclusively the payment protocol without a fall back measure on the blockchain).
On the other hand, using stealth addresses this way has privacy and scalability consequences, especially for light clients. This can be, in theory, at least partially tackled with SPV improvements or trusted third parties. The discussion about boom filters changes and SPV seems a compromise between how many clients will know about your transactions and how much. Additionally, I’m not too convinced on adding Tor to SPV to improve the privacy of thin clients. As according to the wiki it would make wallets more vulnerable to the sybil attack:
Low-latency encryption/anonymization of Bitcoin’s transmissions (With Tor, JAP, etc.) can be defeated relatively easy with a timing attack if you’re connected to several of the attacker’s nodes and the attacker is watching your transmissions at your ISP.
Regarding online creation of new addresses, there can also be third parties providing new addresses as needed. This has obviously its weaknesses as you rely on this third party being available which is certainly not always a given but also it could provide non-user addresses if malicious. We have this feature but we also have stealth
addresses in the road map, especially as the original specification supported multisignature (although it is my understanding that Darkwallet doesn’t current implement it).
To see in action our dynamic address click the green link donate button on the left hand side
or see it in action on ZealDocs.
What about coinjoin? People have been speaking about improving the current interoperability between wallets, as
all coinjoin implementation currently rely on a single centralized server, correction, the guys at Darkwallet already have gateway channels available. One such improvement is creating a ‘federation’ of coinjoin servers but it won’t mean that the system will be really decentralized. At least in a federation system it should be easier to increase the number of parties and, because of how coinjoin works, I presume this should mean improved privacy.
What I’m actually looking forward for is a system that is fully decentralized. I am not yet entirely sure how a system like this would work, but
I wouldn’t be surprised if someone is not far from envisioning one or if one is already available and I did not have a chance to find it yet. It was pointed out to me that something is in the works. At GreenAddress we have coinjoin or something similar in our roadmap although – obviously – if something betters becomes available we’d skip directly to that 🙂
Last but not least, a word on merge avoidance. Generally, I think it is a great idea and a great way of improving privacy. I think wallets could be smart enough to have the right mix of efficiency and privacy
with regards to how they would split amounts by knowing what amounts you spend most often and optimize for that, so that you can have your privacy and avoid splitting bitcoin to too many (or too few) addresses.