Pages:
Author

Topic: Designing distributed contracts - page 3. (Read 9594 times)

legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
May 20, 2011, 12:28:28 AM
#9
just listening.
full member
Activity: 234
Merit: 100
AKA: Justmoon
May 19, 2011, 07:05:22 PM
#8
Awesome, I can't wait to have "native" escrow support without a third party.

One question regarding the trust example:

Imagine you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthyness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account you'd probably like that money back.

Hmm, but you would get your money back no matter what, so if you wanted you could thoroughly ruin an identity and just start over with a new one once your deposit expires and is returned, correct?

It's true that it would incur capital costs for scammers as their money is tied up in this kind of escrow, but the costs for a scammer would be the same as for a legitimate user, no?

How does this compare to the following system:

- Global trust rating based on total fees paid from an address, perhaps weighted by age as well.
- Trust rating can be raised by sending a high-fee zero output transaction - think of it as buying trust from miners.
- There would have to be some place to lodge complaints against an address. Could be a website or a custom blockchain (that shares work with Bitcoin of course).

The result should be that a legitimate user can spend say 10 BTC on his trust rating once and use it for decades (assuming he doesn't get negative reviews). Whereas a scammer can do the same, but negative reviews and complaints lodged against the address will quickly make his 10 BTC investment void, requiring him to get another identity and spend another 10 BTC.

(Sorry if this is off-topic, it's not an example for a Bitcoin contract strictly speaking.)
jr. member
Activity: 59
Merit: 10
May 19, 2011, 05:09:43 PM
#7
What you are describing is a multipay as above. Just with a string embedded in it.
legendary
Activity: 1260
Merit: 1031
Rational Exuberance
May 19, 2011, 01:04:32 PM
#6
This contract stuff could be incredibly important. What I don't see here is how to enforce the single most important kind of transaction bitcoin will be useful for: the bet.

Example: Person A wishes to bet Person B whether the price of bitcoins will rise or fall over the next 30 days.

Desired features:
 - If person A and person B agree on who won the bet, no third parties are needed
 - If they don't agree, a third party mediator settles the dispute and decides who gets the money
 - Both persons commit their bitcoins, and they are locked (can't be spent) until the bet is over
 - The terms of the bet (i.e. how to decide who won) are encoded in the contract and permanently embedded in the block-chain. The terms can be viewed by either party, and can be viewed by the mediator if they must be brought in to settle a dispute. In this case the terms might be: "If MtGox average of highest and lowest price on July 1st 2011 is lower than $10, person A gets all bitcoins, otherwise person B gets them. Disputes will be settled by person C." (bitcoin addresses and email addresses would be included for all parties)
 - The mediator should be able to take a fee if their services are needed

If someone is able to describe how the above contract system could be used for a bet like this one, I would be VERY interested. Extra points if the bet can pay out partially to both parties, i.e. "Person A pays 5 BTC now to get $50 USD worth of bitcoins from person B on July 1st 2011"
legendary
Activity: 1526
Merit: 1129
May 19, 2011, 05:01:12 AM
#5
Not really. It's about limiting peoples options at each stage to remove the chances of bad things happening, or set up incentives to ensure good things happen.

Without a third party dispute mediator, buyer or seller has an incentive to screw the other person, so it's hard to do trade.

With a third party, you no longer need as much trust in the counterparty, but now you need to trust the third party instead. They also have an incentive to screw with you, although presumably there are far fewer escrow services than traders, and the escrow people have more to lose. The bigger risks are that the escrow service gets hacked and all the coins currently waiting for transactions to complete are stolen, or that trust becomes so centralized that escrow becomes very expensive.

With multi-pay contracts, we can minimize the chances of bad things happening:

  • If a trade goes well the third party is never involved at all. So there's no need for us to pay any fees.
  • If a trade goes south, as a buyer my only option is to get a pre-agreed mediator involved. I can't screw the merchant by taking back the coins (not a chargeback).
  • If the mediator gets hacked, the hacker can't steal any of the clients coins. They could only steal the companies own profits derived from mediation fees. That means I don't have to trust the security of their setup nearly as much, which in turn means it's easier for new mediation services to get started, leading to a more competitive and healthier market.

The cryptography of contracts lets us entirely remove various ways of things going wrong. The only trust you need is in the quality of the dispute resolution process. Other problems disappear entirely.
kjj
legendary
Activity: 1302
Merit: 1025
May 19, 2011, 03:18:01 AM
#4
Still the minimization of trust strikes me as good practice

Mental note to read the first post again when I'm not so tired.  My initial impression was that trust was being pushed around to (allegedly) trusted third parties, like bubbles under wallpaper, not being minimized.

By the way, I highly advise anyone interested in third party services to read about the history of ISK banking (AKA scams) in EVE Online.  The odds that a third party will remain trustworthy once the incentive to cheat becomes high enough has been holding steady at zero percent there for like 8 years now.
legendary
Activity: 1526
Merit: 1129
May 19, 2011, 03:06:47 AM
#3
I call them contracts because that's what Satoshi called them. I guess it's a reasonable analogy though conditional payments might be more precise.

I haven't made up my mind about their value yet. Introducing new contract types means writing a patch for the Bitcoin software then waiting for miners to upgrade. It's probably not a big deal, but it's not free.

Still the minimization of trust strikes me as good practice. Bitcoin doesn't have chargebacks nor does it have any big, trusted names taking part so escrow is pretty essential. A trusted escrow service like ClearCoin might easily end up with really huge amounts of of money sitting in it, waiting for mediation. Whilst Gavin is a highly trustworthy fellow, what if the site gets hacked? There's tremendous incentive to break into servers which are acting as escrow agents.

If I send money to the merchant using a multi-pay contract, it's easier for us to do business. If the mediator, on receiving the funds, immediately ties them up in yet another multi-pay contract that sends the coins either to me or the merchant then I know even if the mediator/escrow service gets hacked my coins cannot be stolen. At worst the hacker might destroy the keys and get nothing. This chaining of multi-pay contracts can be done with a slightly different protocol/set of SIGHASH flags so at no point is the money ever "in the open".

Building up trust is difficult, slow and the fact that the Bitcoin economy is being bootstrapped from zero means that lack of trust is a drag on commerce. If contracts can help grease the wheels they seem like a useful feature to me.
unk
member
Activity: 84
Merit: 10
May 18, 2011, 05:02:08 PM
#2
thanks for writing this up. i'm going to think about this more, but in the meantime i wanted to give you some initial feedback.

i think it works, technically, though i'm going only on your description and a very cursory review of the code. when multiple non-atomic transactions are necessary, there's always a concern about at least mischief that could be caused if one of them is delayed or obstructed, but the motivation for such attacks is unclear out of the context of particular forms of transactions, and nothing particularly dangerous jumps out to me in general.

i suspect, practically, that there may be a dearth of enthusiasm for scripting, at least initially. i'm inclined to think it's one of the more powerful and interesting features of bitcoin, but in many cases the extra distribution of trust that you get from the system is, i hate to admit, quite small practically compared to out-of-band protocols. for example, does the 'escrow' example achieve much more than sending the funds initially to the escrow agent?

still, simply committing to tie up funds without a trusted third party has compelling potential uses, as does CHECKMULTISIGVERIFY, which enables many kinds of 'contracts' on its own (though i would prefer the term 'commitments' or 'conditional payments', myself).
legendary
Activity: 1526
Merit: 1129
May 18, 2011, 03:29:16 PM
#1
(edit) The article this thread discusses can now be found here:

   https://en.bitcoin.it/wiki/Contracts

Pages:
Jump to: