

Bitcoin contracts - Theyeard
https://curiosity-driven.org/bitcoin-contracts?utm_source=hn

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

~~~
M4v3R
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](https://bitalo.com)

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

~~~
waps
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 ?

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

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

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

------
kolinko
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](https://github.com/orisi/wiki/wiki/Orisi-White-Paper)

~~~
Theyeard
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].

[0]
[https://bitcointalk.org/index.php?topic=195.msg1611#msg1611](https://bitcointalk.org/index.php?topic=195.msg1611#msg1611)

[1]
[https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_extern...](https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state)

~~~
kolinko
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](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

------
kylebrown
Wow, this is superb educational content.[1] Is the author anonymous?

1\. also [https://curiosity-driven.org/low-level-bitcoin](https://curiosity-
driven.org/low-level-bitcoin)

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

------
a-b
[http://trustatom.com/](http://trustatom.com/)

