Live data from Hacker News

Bitcoin contracts

curiosity-driven.org

1–10 of 32 posts

Re: Bitcoin contracts

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

Re: Bitcoin contracts

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

Re: Bitcoin contracts

#4
post #2

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 bitcoi…

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

Re: Bitcoin contracts

#5
post #4
post #2

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 bitcoi…

> 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 a…

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

Re: Bitcoin contracts

#7
post #3

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 po…

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.

[0] https://bitalo.com

[1] http://cosign.co.in

Re: Bitcoin contracts

#8
post #4
post #2

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 bitcoi…

> 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 a…

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.

Re: Bitcoin contracts

#9
post #2

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 bitcoi…

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

Post reply on HN