Do-it-yourself Escrow with two-factor address utility

[casascius]

It looks like somebody has figured out a way to use the two-factor feature of my Bitcoin Address Utility to do an escrow transaction.

https://bitcointalk.org/index.php?topic=129399.msg1383296#msg1383296

The way it works, is the person who is paying uses my utility to turn their Passphrase into an Intermediate Code.  They give it to the payee.

The Payee uses the Intermediate Code to generate an encrypted Bitcoin address.  The Payee also gives the "confirmation code" (appears on the printed Coin Inserts report) back to the payer.  The payer should be able to reproduce the same bitcoin address via the confirmation code and his passphrase.  The confirmation code also ensures that the payer will be paying an address that must have come from the passphrase, rather than one the payee got from his own wallet.

The payer pays.  Nobody can access the funds.

When the payer wants to release the funds, he gives the payee the passphrase.  If the payee wants to send the funds back, he gives the payer his private key.  If nobody gives the other their part, the funds are permanently locked up.

The concept is nothing new, but now that it's wrapped into a point-and-click utility, it's suddenly more reachable.

What do you think?  

Point-and-click two-factor escrow is also a plausible way to do collateral.  Imagine someone set up a trading platform or exchange where settling trades was done primarily on the honor system and the exchange held one factor of a two-factor collateral arrangement as a backstop.

[1714937617]

1714937617

[luv2drnkbr]

[HostFat]

Good!
I'll check later and I'll make an easy guide for my italian colleagues

Are you going to add some features on this topic in the near future?

[Rudd-O]

tutorial please.

[Fjordbit]

This essentially requires some kind of resolution between the two partners. However

- a seller could be a scammer just looking to grief "buyers".
- a buyer, once receiving the item, could random the locked up coins for a discount. The seller has no leverage here.

I'm not too keen on this and doubt I would agree to it. 2-of-3 transactions are where it's at.

[Spaceman_Spiff]

This essentially requires some kind of resolution between the two partners. However

- a seller could be a scammer just looking to grief "buyers".
- a buyer, once receiving the item, could random the locked up coins for a discount. The seller has no leverage here.

I'm not too keen on this and doubt I would agree to it. 2-of-3 transactions are where it's at.

What are 2-of-3 transactions?  
Is it a system in which the buyer and/or seller have to deposit some money that will be transferred back to them upon completion of a mutually satisfied transaction?  Because such a system would make sense to me.

I have seen the term "m-of-n transactions" before on this forum, is this a more generalised term?

Although I am not yet technically literate enough, do-it-yourself escrow seems like an awesome idea.  Thanks Casascius!

[chriswilmer]

tutorial please.

+1

[Fjordbit]

What are 2-of-3 transactions?  
Is it a system in which the buyer and/or seller have to deposit some money that will be transferred back to them upon completion of a mutually satisfied transaction?  Because such a system would make sense to me.

I have seen the term "m-of-n transactions" before on this forum, is this a more generalised term?

Although I am not yet technically literate enough, do-it-yourself escrow seems like an awesome idea.  Thanks Casascius!

Yeah, m-of-n is the generic term, meaning you need m parties of the original n parties to be able to spend the coins. In a 2-of-3, you could have the buyer, the seller, and an arbiter as the 3 people who participate in the transaction. They sign it in such a way that two of those are needed to spend the coin to the final destination (the sellers wallet). In most cases, if the buyer an seller agree, then they would just sign it and the arbiter would never even be involved. If there was a problem, however, the arbiter would make a ruling and with the buyer spend it back to the buyer, or with the seller spend it to the seller. This would require trust in the judgement and integrity of the arbiter, but is does allow two people with relatively low reputation to leverage the reputation of a well known third party.

[Rudd-O]

What are 2-of-3 transactions?  
Is it a system in which the buyer and/or seller have to deposit some money that will be transferred back to them upon completion of a mutually satisfied transaction?  Because such a system would make sense to me.

I have seen the term "m-of-n transactions" before on this forum, is this a more generalised term?

Although I am not yet technically literate enough, do-it-yourself escrow seems like an awesome idea.  Thanks Casascius!

Yeah, m-of-n is the generic term, meaning you need m parties of the original n parties to be able to spend the coins. In a 2-of-3, you could have the buyer, the seller, and an arbiter as the 3 people who participate in the transaction. They sign it in such a way that two of those are needed to spend the coin to the final destination (the sellers wallet). In most cases, if the buyer an seller agree, then they would just sign it and the arbiter would never even be involved. If there was a problem, however, the arbiter would make a ruling and with the buyer spend it back to the buyer, or with the seller spend it to the seller. This would require trust in the judgement and integrity of the arbiter, but is does allow two people with relatively low reputation to leverage the reputation of a well known third party.

Whoa.  Gamechanger right there.

[casascius]

Yeah, m-of-n is the generic term, meaning you need m parties of the original n parties to be able to spend the coins. In a 2-of-3, you could have the buyer, the seller, and an arbiter as the 3 people who participate in the transaction. They sign it in such a way that two of those are needed to spend the coin to the final destination (the sellers wallet). In most cases, if the buyer an seller agree, then they would just sign it and the arbiter would never even be involved. If there was a problem, however, the arbiter would make a ruling and with the buyer spend it back to the buyer, or with the seller spend it to the seller. This would require trust in the judgement and integrity of the arbiter, but is does allow two people with relatively low reputation to leverage the reputation of a well known third party.

My utility indeed has an m-of-n screen, but it was written for one person to create redundant access to their bitcoins without putting them in any single place.  I never wrote it with the intention for it to be used as an escrow tool, and the person who generates the m-of-n ends up with the private key.

It would be interesting to come up with a shared m-of-n scheme where nobody knows the private key but everyone can confirm they control part of a bitcoin address.  That might prevent a situation where somebody denies their counterparty a legitimate payment just to be a jerk, forcing their coins to be unusable.

[casascius]

Random idea:

What if I ran a dispute mediation service where I as a third party always maintained the ability to release the funds, so I could settle a dispute, but where the parties wouldn't need my help unless there was one?  For example, if I had a website where I gave out keyparts that let me join the dispute, but which wouldn't get in the way of the parties doing business.  The parties wouldn't rely on my continued existence unless they were in a stalemate and needed dispute settlement.

Imagine:  Alice wants to send an escrow transaction to Bob.  I'm Eddie the hands-off escrow agent.

Alice makes up a private key a.  Bob makes up a private key b.  I the escrow agent make two private keys, x and y.

Alice and Bob ask for my services.  I give Alice x and Gy.  I give Bob y and Gx.  So they both can calculate Gxy.

For those not familiar with the EC math, let me simplify it: pretend it's algebra, and G is a pre-defined constant with one special property: it's impossible to divide by G.  The rest are just regular numbers.  Gxy just means G times x times y.  Someone who knows Gx can't get x from it.  Further, G times anything can be made into a bitcoin address, and the "anything" becomes the private key.  If G itself were made into a bitcoin address, its private key would be the number 1.

Anyway, Alice and Bob's private keys a and b are for Alice and Bob's safety from me.  They exchange them with one another.  Alice stays safe from Bob by him not knowing x, and Bob stays safe from Alice by her not knowing y.

Alice and Bob both calculate the bitcoin address for (Gxy)ab.  Nobody has access to the funds.  The private key is xyab.  Alice knows abx and needs y, Bob knows aby and needs x, and I only know x and y.

Alice can give the funds to Bob by giving him x.

Bob can give the funds to Alice by giving her y.

If Alice and Bob refuse to cooperate and ask me to settle their dispute, I know both x and y, and can settle it in Alice's favor by giving her y, or in Bob's favor by telling him x.

[SlaveInDebt]

Good work, I fell better about paying 0.15btc for your coins  they will make a great holiday gift. Plus I can't wait to try and pay my tab with them.

[mrvision]

Whoa.  Gamechanger right there.

Hello my old friend.
Here you are:
https://raw.github.com/gist/3966071/1f6cfa4208bc82ee5039876b4f065a705ce64df7/TwoOfThree.sh

[luv2drnkbr]

Whoa.  Gamechanger right there.

Hello my old friend.
Here you are:
https://raw.github.com/gist/3966071/1f6cfa4208bc82ee5039876b4f065a705ce64df7/TwoOfThree.sh

I'm not proficient enough to read that, but it has me very excited because I at least think I know sort of what I'm looking at.  Oh boy oh boy oh boy.

In the mean time, it occurs to me 3rd party escrow can be done in this manner:  Alice has password used to create intermediate passphrase.  Bob uses phrase to make encrypted private key.  Bob then uses secret sharing to split the encrypted key up into 3 parts and gives Alice one part, Charlie (3rd party escrow) one part, and then Bob throws out the 3rd part since he already has the encrypted private key.  Alice also gives Charlie the password.

Now Alice has the password and 1 of 2 shares necessary to get the encrypted private key.  As does Charlie.  Bob has the entire encrypted private key but no password.  Any two out of the three of them can now work together to unlock the unencrypted private key.

The only problem I have with that is that Alice and Charlie can't verify that the shares they have will actually reveal the encrypted private key until it's too late (i.e. Bob screws Alice and so Alice and Charlie attempt to get the key, but Bob has simply spited them and the funds are now lost).

Also, Mike's utility does not split up encrypted private keys into m-of-n shares.

[justusranvier]

I thought the inclusion of multisig feature already implemented everything necessary to do escrow.

[casascius]

I thought the inclusion of multisig feature already implemented everything necessary to do escrow.

Other than the point and click UI for someone to actually do it (afaik)

[luv2drnkbr]

I thought the inclusion of multisig feature already implemented everything necessary to do escrow.

Other than the point and click UI for someone to actually do it (afaik)

Yup.  It's not point and click in the main client, and I don't know enough to do it any other way.  So for me, Mike's utility is what I'm using.

[justusranvier]

I thought the inclusion of multisig feature already implemented everything necessary to do escrow.

Other than the point and click UI for someone to actually do it (afaik)

Yup.  It's not point and click in the main client, and I don't know enough to do it any other way.  So for me, Mike's utility is what I'm using.

I should have been more clear.

In the mean time, it occurs to me 3rd party escrow can be done in this manner:  Alice has password used to create intermediate passphrase.  Bob uses phrase to make encrypted private key.  Bob then uses secret sharing to split the encrypted key up into 3 parts and gives Alice one part, Charlie (3rd party escrow) one part, and then Bob throws out the 3rd part since he already has the encrypted private key.  Alice also gives Charlie the password.

Now Alice has the password and 1 of 2 shares necessary to get the encrypted private key.  As does Charlie.  Bob has the entire encrypted private key but no password.  Any two out of the three of them can now work together to unlock the unencrypted private key.

The only problem I have with that is that Alice and Charlie can't verify that the shares they have will actually reveal the encrypted private key until it's too late (i.e. Bob screws Alice and so Alice and Charlie attempt to get the key, but Bob has simply spited them and the funds are now lost).

Does the procedure you described represent what needs to be done to generate a 2 of 3 multisig key, or is it something that users only need to do until good UI tools for using multisig keys exist in the clients?

[cbeast]

Casascius "accidentally" makes a two party escrow utility that will change the nature of commerce. Incredible! Now we need it gussied-up a bit and we have us a killer app.

[lebing]

Interesting - looking forward to seeing where this develops