All great changes, especially BIP 70 and the fixes on transaction malleability and relaying. I'm unconvinced the efforts to make bitcoind (now Bitcoin Core Server) a "border router" are well-spent however. Software that's optimized for server deployment and larger clusters is fundamentally different from what you would run on your desktop. I personally think that Bitcoin Core should focus on the protocol and extensions to be a good reference implementation, easy to deploy in all environments.
The router functionality is very important, because bitcoin-core is the only bitcoin implementation capable of verifying transactions & blocks. The reason for this is that the bitcoin protocol, in practice, is whatever bitcoin-core implements, including any and all bugs. All attempts to fully implement bitcoin-core have all had chain splitting bugs (btcd, bitcoinj experimental full verification mode) so they are not yet trusted in production.
Unfortunately the wallet handling capabilities of bitcoin-core don't scale to high numbers of wallets. Thus as an org running a service handling many wallets, it is useful to program against a lightweight client API such as bitcoinj, and then have your client peer with "trusted" bitcoin-core nodes.
I've heard that argument many times and all it does is reinforce the idea that no other implementation can work. And how you end-up with an implementation mono-culture. Forks of a single block happen regularly, it can be dealt with. A production system can detect a fork and check the reference implementation's behavior, preventing any longer fork.
The *coin ecosystem need more than one implementation, a single codebase can't cater to all uses. I should know, I'm an Apache member.
Forks of a single block ("orphans") are expected due to block propagation taking a nonzero amount of time.
That's very different than the case where say 50% of the network is running bitcoind, and the other 50% is running btcd, and some transaction triggers an edge case in either implementation that causes one implementation to accept the transaction and another to reject it.
I think multiple compatible implementations would be great to have, but we don't have them at the moment, and in the meantime companies handling huge numbers of bitcoin transactions need a solution that works today. So I applaud the bitcoin-core team for catering to the increasingly common use case of using bitcoind only for consensus.
And it happened even only with bitcoin-core. Anyhow the 50/50% scenario across implementations is unlikely to happen if everyone seeing a new one cries forking wolf.
I do empathize with the need of solutions for today though. I was just thinking about tomorrow.
alternative implementations would mean you need consensus between different groups of developers holding the keys to the software. unlikely to be a good idea.
Any luck on delivering a feature to prevent exchanges like Coinbase from stealing my money, or ability to retrieve my money once it's been stolen? There seems to be no way not to use exchanges when using Bitcoin, so this is a real problem.
Or I suppose it could be that Mt. Gox was the problem, and now the problem has gone away.
Still, I predict that when the economy crashes again as it did in 2008, we will see many more exchanges die off, and they'll take everyone's money with them. This may harm mass adoption of Bitcoin by reducing confidence.
A feature you're talking about already exists in Bitcoin, and it's called multisignature addresses. There are few wallets that implement them [1] [2], as well as one exchange [3] (full disclosure: I wrote it) where you can buy and sell besides just storing your Bitcoin.
On top of much better security, using multisignature addresses gives you answer to your second question: everyone using services like those below can check their wallet contents on the Blockchain at any given time. There's no need for the service to "prove" anything - everything is provable and exists on the Blockchain by design.
Bitalo is not an exchange, its an OTC marketplace. The tagline on the site - "NO FRAUD IS POSSIBLE IN A TRANSACTION" - is a flat-out lie. A fraudster can just reverse the bank payment (up to 6 months later in the US), long after the coins have been released from multi-sig escrow.
An exchange operates a limit order book, which matches and settles trades automatically. Otherwise you just have a forum where each user has to repeatedly, manually handle the logistics and security of a wide variety of payment systems. The exchange should do that, not the user.
I don't know much about US then. Is Europe as far as I know it's not possible to revert a bank transfer once it's processed. So there's no place for fraud.
But if that's the case for the US, what's stopping a thief to send money to an exchange like Bitstamp, buy BTC, withdraw it and then reverse the fiat payment in a similar matter?
And while it's true that on Bitalo you have to handle the fiat payments yourself, but it will be often faster to get BTC that way than to send it to an exchange, wait for them to process the deposit, and only then buy BTC.
> But if that's the case for the US, what's stopping a thief to send money to an exchange like Bitstamp, buy BTC, withdraw it and then reverse the fiat payment in a similar matter?
Sending money to bitstamp requires an international wire transfer (SWIFT), those (usually) can't be reversed.
Its ACH payments which get reversed so easily (ACH is a domestic network, all in-country). That's why TradeHill shut down after a fraudulent $20k Dwolla payment, all Dwolla deposits/withdrawals are through ACH. And that's why Coinbase has to be so careful with which customers they allow to purchase bitcoins, all Coinbase deposits/withdrawals are ACH.
> And while it's true that on Bitalo you have to handle the fiat payments yourself, but it will be often faster to get BTC that way than to send it to an exchange, wait for them to process the deposit, and only then buy BTC.
Speed of a first purchase is one thing. But I'd guess that the main reason people keep funds on an exchange is because they want to day-trade, pick up cheap coins with a lucky limit order during a flash crash, or have the option to panic sell in a split second (not even a one hour wait for 6 confirmations). That kind of trading is only possible on an exchange with a limit order book, not an OTC marketplace.
Then keep your BTC on an exchange for as little time as possible. Deposit right before selling, withdraw right after buying. In my experience, Coinbase credits the BTC within minutes of sending to a Coinbase address, so exchange rate fluctuations while waiting for confirmations shouldn't even be as big of a problem, as it may be for other exchanges. (If outside US or otherwise unable to use Coinbase, that may be a bigger problem.)
When you sell BTC on Coinbase, it takes anywhere from two days to two weeks for Coinbase to actually pay you. If they get into dire financial straits like Mt. Gox, then this period will gradually widen to become many months, and then some payments will stop going through altogether. So you'll have sold your N bitcoin and they'll have lost it.
I guess this problem is unavoidable short of using lots of different exchanges. Maybe there just needs to be more than one Coinbase.
You could try cash transactions on localbitcoins if you're worried about bank delays. You'll probably pay a premium for it though, and introduce new risks of being mugged or something.
The problem for exchanges especially (maybe to a lesser extent for "brokers" like Coinbase) is that they _need_ exclusive access to your bitcoins, to ensure there's no way for you to take them before they can give them to the other party in a trade. I don't see any way around this, short of exchanges trusting users to deliver bitcoins after the trade. Even with multisignature/escrow systems, there is the risk the user double-spends the coins at the same time they make a trade. (And if the exchange is able to take back the cash, or withhold it until the bitcoin transaction is confirmed, there's probably not a fair way in general to reverse the trade, is there?)
> The problem for exchanges especially (maybe to a lesser extent for "brokers" like Coinbase) is that they _need_ exclusive access to your bitcoins, to ensure there's no way for you to take them before they can give them to the other party in a trade.
The decentralized order books in Ripple show this is solved. We don't need a central authority to match trades, no more than we need a central authority to prevent double-spends. When you post an offer to trade XRP for snapswapUSD on ripple, the XRP remains 100% in your control (until someone takes your offer and a trade is matched). Ripple shows how trade matching can be implemented as a decentralized cryptographic "contract".
Of course, this won't work with bitcoin as the native currency until somebody implements trade matching as a bitcoin contract (and exchanges like bitstamp issue bitstampUSD as colored bitcoins). And even then, there's still the fact that bitstampUSD is centrally issued and could all turn worthless the moment Bitstamp stopped redeeming it. And that has another solution (coins which track fiat-price in a decentralized prediction market).
Are you talking about multisig? That doesn't have adequate properties for use in an exchange. I assume that you are requiring that the user sign off on any transfer of their coins, because otherwise the chance of theft would still exist. If so, then (1) you are requiring that all transfers hit the block chain (immediate non-starter simply due to scaling issues), (2) the exchange is not effective as people can DoS by dropping out and refusing to sign if the market moves or they otherwise have second thoughts, and (3) you're ignoring the fiat side of the exchange.
Trustless exchanges can work, but they generally need much more infrastructure and possible changes to bitcoin (or a side chain).
Points 2) and 3) can be solved, an exchange that accepts fiat and signs a transfer immediately after placing an offer is entirely possible. At Bitalo we chose not to accept fiat, but it's not a limitation of multisig scheme.
I'm not convinced no fractional reserve is the absolute answer. I am fine with exchanges making some money from what I keep there. In one way or another it will benefit me. What needs to be worked on is the actual fraction they can get insured for in the low-probability case everyone wants to run out with their coins.
> Any luck on delivering a feature to prevent exchanges like Coinbase from stealing my money, or ability to retrieve my money once it's been stolen? There seems to be no way not to use exchanges when using Bitcoin, so this is a real problem.
FYI, Coinbase isn't an exchange; they're an online wallet and Bitcoin broker. Exchanges are for trading, and have much much lower fees. Gox was an exchange, as is BTC-e and Bitstamp.
They create an individual wallet file for each user AES encrypted with your password. They also support 2-factor auth and auto-backups to 3rd party services like Dropbox.
How can they support 2-factor auth without also having the ability to spend the bitcoin in the wallets? What's needed is a way to keep bitcoin on remote servers without them having the ability to spend it, but to grant access with 2FA. This prevents password phishing attacks and keylogger attacks, without the user having to worry about their harddrive crashing and losing their wallet. But I'm not sure whether that's possible short of making them keep an encrypted wallet, which negates all of the user convenience of using an exchange.
Apparently blockchain.info only provides the encrypted wallet after the alternative authentication is succesful. They don't have the ability to spend your coins.
"It is highly recommended you enable two factor authentication on your My wallet account. Your wallet data is still only encrypted with your password however a second authentication step will need to be passed before your encrypted wallet data is output."
blockchain.info is great compared to some black box wallet but their model can't provide per transaction two factor, meaning once malware has your keys in memory you are good to go and you are going to have a real bad time.
That's possible with multisig and GreenAddress offers 4 different kind of 2FA: Google Auth, SMS, email and Phone (robot call)
If you trust every other aspect of their service (that they aren't capturing and storing your password, which of course they handle every time you use the service), then you can feel safe in knowing that you don't have to trust them not to spend your coins because they can't.
But only if you trust that every other part is honored.
That isn't a rational set of conditions. In the usage of Blockchain.info, they absolutely gain the capacity to capture your private keys. As does anyone who hacks the service.
The way it's supposed to work, and I guess does work today otherwise we'd have heard about it, is that your passphrase doesn't actually get sent anywhere. Instead, it all happens client-side.
So today they don't have your keys. Not to say they couldn't be malicious in the future, or get hacked, but that's not the case today. Again, as far as I know.
Apparently the password is never sent from the client-side, and I've read claims that the client-side JavaScript code is verified on this. You can install a plugin which notifies any changes to the JavaScript code.
Something like the 'Digital Oracle' project might help, by requiring an extra 3rd-party signature for fast/suspicious transactions, while still allowing you ultimate control:
But regardless, great job guys.