Bitcoin Forum

Hey, I've written on my idea how to make contracts with people who don't really know each other with low cost, no third party.

Ideas based on NashX.com service. Special thanks to Mike Hearn for "Contracts" page on the wiki.

http://blog.oleganza.com/post/58240549599/contracts-without-trust-and-without-a-third-party

TLDR:

1. Two parties independently lock some amount of money in a single Bitcoin transaction without meeting in person or trusting anyone.
2. This money can be unlocked only when both agree with that. If at least one party does not want to unlock the deposit, another party cannot do anything about it.
3. Both parties can unlock deposit only atomically, for both of them. No one can unlock just for himself.
4. No one else has access to the deposits and neither party can access other party’s money.

Output scripts:

txout1: AlicePubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY SHA256 HashB EQUALVERIFY

txout2: BobPubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY SHA256 HashB EQUALVERIFY

HashA, HashB are hashes of the secret numbers of each participant. Numbers are revealed when they want to unlock the money.

Amount of deposit should be 200-300% of the price. E.g. if the deal is about 1 BTC worth of merchandise, the deposit should be at least 2 BTC.

NashX ask seller for smaller deposit (100%) because he sends first, but this doesn't seem "fair" for many people. So lets have 300% each, so it does not really matter who sends first. Parties can negotiate how much they lock up, of course.

Ideas?

This is great! Oh and probably a floor or a cost to this transaction to prevent spam attacks.

I just got a feedback from a friend of mine. This is an attack that can be fixed.

When Bob sends his secret number to Alice, Alice now can use funds anytime. She can put this money into "long-term savings" because she is 100% sure she can refund them. And Bob would have to wait.

To avoid this problem, both parties can create a "destruction" transaction that spends all funds to 00000000000000000000000000000000000. This transaction would be signed by both of them, can be released by any of them any time (it may have a short lockTime to let people cool down) and will be invalid once any party spends their output.

The scripts will be like this:

txout1:
IF
  AlicePubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY HashB EQUALVERIFY
ELSE
  AlicePubkey CHECKSIGVERIFY BobPubkey CHECKSIGVERIFY
END

txout2:
IF
  BobPubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY HashB EQUALVERIFY
ELSE
  AlicePubkey CHECKSIGVERIFY BobPubkey CHECKSIGVERIFY
END

When this transaction is signed by both parties, Alice and Bob would construct and sign another transaction that spends these two outputs to a predefined invalid address. Once a person sees that deposit is in blockchain and he has a valid destruction tx, he begins executing his part of the deal. If any party decides to play bad, the other guy may threaten to destroy all funds. This solves the problem of non-releasing secret numbers for undefined period of time.

I'll update my blog post soon.

The Bitcoin scripts all require that you have your bitcoin client running.

And if person A is not satisfied and person B feels that they are in the right, person A has all of the power and can deny person B from ever getting the funds. Or person A could be person B's competitor and purposefully withhold funds.

It does help as far as a blanket send with no intermediary, but I believe a thriving Bitcoin escrow services industry will help things quite a bit.

As I mentioned in the article, escrows need to be experts. That's not very cheap or possible in many typical cases. And some things are not possible to prove to an escrow or anyone.

FYI, this was also discussed:
https://bitcointalk.org/index.php?topic=75481.msg835859#msg835859
https://bitcointalk.org/index.php?topic=98827.msg1081648#msg1081648
https://bitcointalk.org/index.php?topic=70074.msg811194#msg811194

one of my crazier notions:
https://bitcointalk.org/index.php?topic=99566.msg1088647#msg1088647
I'm working on something even more insane atm.

Thanks for the links.

I've replied to your post about statistical escrow. What's this "even more insane" something of yours? :-)

I'm experimenting on testnet with multisig transactions. I'm trying to nest them. Hopefully, I'll have a working example to show in Austin this weekend. When I try to explain it on IRC, I get blank stares and guffaws. I'll just muddle through the protocol. It works on paper, but until I can show it on the blockchain, it is just a crazy notion.

so... how did this go?

Escrow is really the only way currently

I'm relatively new to contracts but I want to make sure I understand the idea.

Will the spending inputs scriptSig contains <aliceNumber><bobNumber><signature> ?

Thank you,
-schone

I misunderstood how the keys are handled with multisig. The keys are hashed to create the inputs. I would need to re-use one key from a transaction to link to another. Essentially creating a logic path of outputs to be used as inputs for other multisig transactions. It could possibly still be done, but would require some extremely complex math to fit the nested transactions together as a multi-level multi-sig transaction. The idea would basically create a decentralized credit union where depositors would secure funds and allow loans as groups. But that is overthinking it a bit now.