Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin contracts

curiosity-driven.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Bitcoin contracts

#21

Post by nullc »

andrewla wrote: 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…

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.

Re: Bitcoin contracts

#22

Post by nullc »

kolinko wrote: post #10

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

Or reality keys, for example.

Re: Bitcoin contracts

#23

Post by nullc »

andrewla wrote: post #15
shazow wrote: post #14

Earlier quoted context omitted.

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…

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

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

Re: Bitcoin contracts

#25

Post by waps »

M4v3R wrote: post #7
bdamm wrote: 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…

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 ?

Re: Bitcoin contracts

#26

Post by nadaviv »

bdamm wrote: 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…

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

[1] https://www.bitrated.com/

[2] https://news.ycombinator.com/item?id=6842697

Re: Bitcoin contracts

#27

Post by M4v3R »

waps wrote: post #25
M4v3R wrote: post #7

Earlier quoted context omitted.

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…

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…

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.

Re: Bitcoin contracts

#28

Post by kolinko »

kolinko wrote: post #10

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

One more thing - here's our repo if anyone wants to play with contracts with external inputs: https://github.com/orisi/orisi

Re: Bitcoin contracts

#29

Post by kolinko »

Theyeard wrote: post #12
kolinko wrote: post #10

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]. [0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 [1] https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_extern...

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

Re: Bitcoin contracts

#30

Post by kolinko »

waps wrote: post #25
M4v3R wrote: post #7

Earlier quoted context omitted.

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…

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…

If you're curious about the subject, you might want to watch one of our (Orisi.org) tutorial videos: https://www.youtube.com/watch?v=boPW1FwNu4c . It's a part of a longer tutorial available here: https://github.com/orisi/orisi , and a part of the system described in this whitepaper: https://github.com/orisi/wiki/wiki/Orisi-White-Paper

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.

Post reply on HN