In order for bitcoins to be useful for money, it must be possible to determine how many bitcoins I have, or, more exactly, how many I have available to spend. The fact that there is a language associated with bitcoin redemption, and the redemption happens at the time of the creation of the outbound transaction makes this very difficult to determine.
So, more clearly, if I want to spend some coins that have been nominally sent to me, at the time that I attempt to send them to another address, I have to have all the information necessary to redeem the coins that were sent to me, for each instance of an incoming transaction to my address.
If this sounds complicated, it is because it is. Ethereum, one of the many post-Bitcoin cryptocurrencies, does a much better job of this on the pure currency side -- spending coins at an address to which I have the private key is just a matter of saying how many coins I want to send and where. Ethereum, unfortunately (in my mind) complicates this with a much more sophisticated language that lives in a side-chain.
I think the ultimate Bitcoin successor (or modifications to the Bitcoin protocol itself) will have to prune down the scope of allowed transactions, rather than expanding it. This isn't just a question of the "my grandmother won't be able use it" -- although having an unspendable incoming transaction from the "publishers bitclearing house" for a million bitcoins will definitely be a bit offputting.
In the end, even for a sophisticated user, it will be nearly impossible to present a view of how many bitcoins you have available to spend. This is why the core devs have been very reluctant to allow different kinds of scripts; multisig is the first real expansion.
Colored coins, while kind of fun, live outside the blockchain, so don't really bother me. It's basically the equivalent of a (for example) car saying "anyone who holds a dollar bill with serial number xxxxxx from year yyyy can start the engine", in a world where it is impossible to forge dollar bills (as is the case with bitcoins).
Your Bitcoins just have two states: Spendable and not spendable. Spendable coins are ones that you can go ahead and make a transaction with right now. Unspendable coins are ones that are locked up until some event occurs—maybe they're part of a complicated Script, or maybe they're already part of an unconfirmed transaction.
It's not unlike how when you go buy something with your Visa credit card and the merchant places a soft hold on some value. That value becomes an unconfirmed transaction until days (weeks? months?) later. Bitcoins are similar except the inverse, you get a hard hold until the transaction is resolved.
Are credit card complicated? Very, especially when you realize how much of the arcane half-broken functionality is purely due to specific regulation thresholds. But we get by alright with burying our heads in the sand.
> Colored coins, while kind of fun, live outside the blockchain, so don't really bother me.
Depends on the colored coin, some live on the blockchain. http://coloredcoins.org/
It really is quite complicated. In the best case, in my view, there would be specialized clients that would interpret certain classes of transaction scripts, and the majority of wallet software would not care at all, and only acknowledge the basic transactions (pay to pubkey hash). But all miners have to be aware of the full scope, and all full nodes will need to have some extra complexity, in order to even validate the blockchain. That complexity leads to unpredictable behavior and bugs. My guess is that when Bitcoin really has to go head-to-head with another coin, this "feature" will have a dragging effect.
I glanced at the papers on http://coloredcoins.org, and they haven't changed. Though the colored coins are tracked through the blockchain, the fact that a coin is colored, and what that color means, lives entirely outside the blockchain. My analogy with "smart property" simply looking for a particular serial numbered bill is very apt, but of course you gain the cryptographic anti-counterfeiting guarantees of bitcoin. All the same risks apply as well; you can inadvertently spend a colored coin, and if the recipient is not looking out for it, they'll probably never know that they are in nominal possession of a colored coin, and possession of the "smart property" will simply float around between people, just like a similarly-marked dollar bill inserted into a vending machine would do.
More complex transactions would show up in more advanced wallets (possibly separately), and that is the way it happens in the real world now. Say you hold an options contract or a bond on some stock exchange - it's "spendable" but doesn't show up on your everyday bank account balance. This is useful money as we know it now. The allowance for such flexible transactions is a feature and not a weakness :)
It's really not that difficult.
A wallet isn't tasked with knowing about crazy things that it might be able to spend if you modified the code— what you're saying is completely isomorphic to saying that the US Dollar has a weakness because someone could put a $100 bill in a locked safe with your birthday as the combination and bury it in your back yard without your knoweldge, and you wouldn't know that you could spend it.
Any contract use with Bitcoin requires you to have software that understands the contracts— no wallet does or will ever show arbitrarily encoded contracts written by a third party. Otherwise, someone could start "paying" you using 1 of 2 payment with one of them being a private key your wallet knows— then claw the funds back after you thought the transaction was settled. Because a contract could do almost anything it would never be safe to just automatically accept them, in any system, and so nothing does or will.
This is not necessarily true. It is a UI challenge. You can imagine a UI that, for example, understand that you are participating in a crowd-funding contract, and denotes the bitcoins locked down in that contract in a special area. For the crowd-funding contract, you can exit at anytime before the contract closes, so the UI could present that option as well. This approach can be applied to other contracts as well.
Of course, with a finite number of transaction types, this is easy, right? Well, not even then. Because you don't redeem these things when you _receive_ them. You redeem them when you _spend_ them. There's no easy solution here; most likely the clients will have to do a one-time sweep of receptions that it knows how to complete to an unencumbered transaction input, so that they can be spent without having to gather a bunch of documents. But at the very minimum, a very challenging experience compared to cash, or even the "standard" transaction inputs.
Additionally, with BIP-16 (P2SH) and BIP-70 (payment protocol) it is up to the recipient to provide the spend script. Presumably my wallet won't generate a script it doesn't understand. If the wallet doesn't track the required information, whether that's your private key or something more complex, of course you're going to have problems.
[0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611
[1] https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_extern...
That's why not only Bitcoin, but also Ethereum and all the other blockchain-based currencies need oracles for passing external inputs in.
By the way, here's our repo, if anyone's interested in the whole concept: https://github.com/orisi/orisi -- there are tutorials there explaining how to set up an example oracle, and an example client sending stuff to oracles to sign.
There's also one of the core devs explaining this stuff: gavintech.blogspot.com/2014/06/bit-thereum.html
https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal...
The escrow mechanism strikes me as particularly powerful; it's like traditional escrow but even better because the buyer doesn't quite give up control, and the seller knows that the escrow company can't just disappear with their funds.
Activation of the escrow agreement can take minutes, rather than days or weeks for traditional escrow (usually involving wire transfers), once the escrow agreement is set up.
It doesn't solve the problem of the escrow company being in cahoots with one of the parties, but I believe the mechanism can be extended to N-way escrow where multiple escrow companies could be arbiters over the transaction. Then the buyer and seller can both have a trusted escrow company in the transaction and know that their interests are indeed being represented, and the escrow companies can determine if the other escrow company is one that they trust as well, before committing to fulfilling a transaction.
Also, at least for P2SH (multi signature/escrow addresses), getting their balance is no different than for normal addresses. Completed transactions to them are perfectly visible on the network so you can sum them up. Uncompleted (partially signed) transactions are not sent to the network though, so you cannot estimate how many "pending" Bitcoins are there for a given address.
I wonder about the implications of that, since it effectively takes money out of circulation, during whatever length of time it takes to finalize the transaction. That presumably includes any conflict resolution process that may exist ?
