If I'm understanding correctly, these scripts are very long lived in that days, weeks, or years may go by before segments of the contracts are resolved. This does seem like a powerful mechanism. Unanswered in the paper is a look at the wallet implementations; can I expect wallets to correctly report the balance in a payee's wallet, if they have outstanding contracts?
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.
Escrow contracts in Bitcoin are now more and more used because they add real security without taking much convenience. Shameless plug [0] - I work for a startup that does exactly that, utilizing multi signature Bitcoin addressed for added user security. But you could also build a service for a true escrow very easily and as you say, that wouldn't mean putting all the trust into the escrow party, which is great. These services, in fact, already do exist [1].
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.
What I wonder is what happens to the money locked up in these transactions. I understand that the money is effectively inaccessible to both the sender and the receiver until the transaction is resolved. Is that right ?
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 ?
The money is sitting on special multisignature address before transaction is resolved. It's a 2 out of 3 address, which means that two signatures are required to move the funds further. The good thing about it is that you can totally skip the escrow party here if buyer and seller agree - they both just sign the transaction and send it to the network. Escrow is needed only in case of a conflict - he would have then to investigate and sign a transaction with either buyer to refund the Bitcoins or to seller to forward them to him as contract described (in a case that buyer disappears for some reason).
This setup has one downside though - if one party sides with the escrow, they could agree to sign a transaction to scam the other party. That's why it is not 100% bulletproof and you have to carefully select your escrow partner so that both parties trust him to an extent.
As for your question - it really depends on the way the contract is structured. In theory you could have a 2 of 3 signature address and a timelocked/nLockTimed transaction sending money to an additional arbiter if the time passes without a resolution.
Bitrated [1] [2] is doing exactly that - arbitration using multi-signature transactions and a marketplace for arbitration services. A major new version is about to be released shortly, with an improved UI and many new features (disclosure: I'm the founder).
On a related note - all the blockchain contracts are limited by their inability to access real world data (e.g. stock prices, websites). For that you need distributed oracles:
https://github.com/orisi/wiki/wiki/Orisi-White-Paper
Exactly - scripts are pure functions. Reasoning behind this is explained by Satoshi himself at Bitcoin Talk [0]. Contracts page at Bitcoin wiki has an example of defining a will using Bitcoin and an oracle [1].
Yup. The concept of a blockchain is fundamentally incompatible with external inputs. That's because at any given moment you need two things:
- everyone to agree that the new block is valid (and you can't really do that if blocks contained functions that had to be verified with external/changeable outputs)
- everyone has to agree that all the past blocks were valid, which is even harder, because if blocks referenced external outputs, the sites/sources they relied on may have changed
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
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).
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.
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.
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. :)
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.
> 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.
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 :)
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.
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.
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.
> 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.
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.
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).
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.
The author does appear to be anonymous. By the systematic lack of articles (a lot of noun phrases seem to be missing "the"), I would guess a speaker of a Slavic language. Possibly Polish, given the DNS.
I am very curious about the same. I did a whois on the domain, and its information is protected, of course. The DNS is in Poland, and the site runs on Digital Ocean (Netherland IP). I am guessing he/she is European. But other than that...
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.