[andrewla]

For many, the flexibility of Bitcoin in terms of what sorts of scripts can be executed with transactions is much of the appeal. I'm of the opinion, however, that it represents Bitcoin's greatest weakness.

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).

[shazow]

It's really not as complicated as you could make it seem.

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/

[andrewla]

It's not an insurmountable problem, but the design of the protocol, as I mention below, makes the transition from "unspendable" to "spendable" difficult, because you can't even try to satisfy the conditions until you try to spend the coins -- the only thing that would make sense would be to do this with another transaction that does nothing but transfer the unspendable coins to another address.

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.

[shazow]

I read you saying it's quite complicated, but everything you said feels reasonably simple to me. Maybe I've been staring at these challenges for too long? Maybe in a few years everyone will feel it's reasonably simple? Or maybe not.

When you get a charge hold on your credit card, there is nothing you can do to satisfy it either aside from waiting for the charge to resolve. I'd like to think we're used to this reality.

Regarding needing to keep track of all unspent/spendable outputs, the Bitcoin client has been doing this since the beginning. If you go into your Bitcoin data directory, there are two sets of databases—the blockchain and all of the unspent outputs in the blockchain. These get updated with every mined block. Querying it is easy.

Regarding coloredcoins, the annotations live on the blockchain but the protocol (ie. how they're interpreted) lives in the client.

Part of the reason why multiple accounts are popular in crypto wallets is precisely for this scenario. You can keep your car-owning colored coins in one account, your spending change in another, your life's savings in more, etc. It's kind-of like having a Checking, Savings, Retirement, Investment, Mutual Fund, etc accounts in your bank.

You're absolutely right these all come with new challenges for us to work through, but I'm not having trouble imagining a rosy future where people aren't accidentally giving away rights to their cars and failing to meet rent because their savings are tied up in a complicated Script that is refusing to get resolved. We're not there today, but it's still early and many folks are working on all kinds of innovative wallets. :)

[xorcist]

It may be complex but it's built from simple parts. You can check out the mini-language transactions are expressed in on the Bitcoin wiki. It's really quite simple.

Of course, ordinary users needn't care, since this is exactly what the Bitcoin software does for you: It tracks your money and how much of it is spendable.

[nullc]

> But all miners have to be aware of the full scope

Yes, miners execute a simple virtual machine that determines if the signatures in transactions are the satisfaction of the pubkeys.

Ignoring some cryptographic not ready for prime-time stuff, any other consensus system will operate the same way. In Bitcoin's case the script virtual machine is very carefully constrained to minimize the risk.

It's odd that you seem to speak highly of proposed work that would have a more complicated and less constrained execution execution environment in one breath but then claim that bitcoin's very simple system is a liability in your next message.

[bencxr]

Even in it's current form, your grandma's wallet balance would resemble that of her BoA checking account, where the spendable amount would be a total of the easily-redeemable (Pay to pubkey hash) transactions.

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 :)

[icebraining]

In fact, banks here in Portugal already show you two balances, an "accounting" balance which shows you the sum of all transactions, including ones that haven gone through yet (e.g. deposited checks) and an "available" balance which is what you can actually use right now.

It's really not that difficult.

[nullc]

This isn't a weakness at all. Your wallet knows what it can spend, and you only consider payments paid when they are paid according to your terms.

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.

[woah]

This is a really bizarre comment. None of this is any sort of obstacle. Any unspent, in-limbo coins are easily conceived of as being "refundable". Someone who would get confused by the things you mention would also get confused by the concept of a rent deposit, a money-back guarantee, or a corporate stock.

[marcell]

> 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 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.

[andrewla]

I'm going to stick with nearly impossible. Yes, it is theoretically possible to have a fixed number of built-in contract types that follow a certain schema, and to make a UX corresponding to each one. But in the full generality -- you get one of these crowd-funding contracts, and the client has to figure out what kind of counterparty signing has to happen in order to spend these damn things. Without prior knowledge of the structure, I'm guessing that this verges on intractable.

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.

[M4v3R]

It's not "nearly impossible", but it's not _easy_ either. You really need to store all inputs for a given address since the genesis block to obtain the balance of this address. You cannot get that information from elsewhere (apart from 3rd party APIs but then you have to trust the 3rd party, kind of defeating the purpose of Bitcoin).

[tlrobinson]

IMHO this is the least of Bitcoin's problems. My grandmother doesn't understand the internals of the internet, just like she won't understand the internals of Bitcoin.

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.

[DennisP]

Ethereum scripting isn't in a side chain, it's an integral part of the main chain. In fact, you have to pay ether to run the script.