Bitcoin Forum

One of the reasons why I don't like to do escrow has always been that I don't want to hold the funds of someone else.
So, I had the idea of making that unnecessary for an escrower.

I'd like to offer a bounty of 1 BTC for a developer who will make a nice, clean software that creates a split 2-of-3-wallet and directly emails each one of the three keys to the email-adresses of the buyer, seller and escrower.

In the end, no single one of the involved parties will have access to the funds in that wallet, but whenever two of the three parties agree, they will be able to sweep the contents. If it's extendable to, for example, 3-of-5, that could even make a "voting" escrow team possible.

That will greatly reduce the amount of trust needed in an escrower.

I would like to see a software that may be installed as some kind of web service, where you would (unfortunately) have to trust the web site's owner again, but for the moment, I just can't think of a better solution.
I'm also open to any suggestion for improving this idea.

My bounty will be awarded solely on my discretion, I will decide whether or not I like your software, and whether or not I want to award it.

Obviously, it has to be full open source under a free license.

As a starting point, you might want to take a look at:
https://bitcointalk.org/index.php?topic=149820.0 (https://bitcointalk.org/index.php?topic=149820.0)


Edit: this bounty has been claimed. Fulfillment on 2013-11-27 at 1 BTC = $1000 :)
https://blockchain.info/de/tx/5b445f6126be4e0aa4d284ee7f910ca9f46c2b3885b6e10553ba5971709d1371

https://github.com/knowitnothing/webescrow_nm

cool idea. bounty is too cheap

I can do it and I'm kinda interested in doing it

Nope, if I understand your proposal correctly it's not the same thing.

I think this can be avoided

I'm curious why you'd want that over casascius' utility. It's fairly easy to use, so long as all parties are willing to try it, and there's much less trust involved.

https://bitcointalk.org/index.php?topic=195168.0

Mainly for extendability, I'd like to go in the direction of 3-of-5 later on. Also, as far as I understand casascius' approach, it requires a lengthy process chain with sending invitations, accepting, sending on, etc. That's probably quite a hassle if all you want is a one-of-escrow for a smaller transaction.
Also, from a psychological point of view, a lengthy, complicated process does not inspire confidence.

Technically, though, the casascius tool is much more secure than what I'm looking for.

Aww, it's not that lengthy. Escrow generates two codes - one for buyer, one for seller. Seller uses code from escrow to generate another code ["SellerCode"] and the BTC address. SellerCode is sent to buyer, which he combines with his own escrow code to verify the BTC address. From there, it works like normal escrow, except buyer releases a code to seller instead of telling escrow to release funds (to redeem, seller combines the two escrow codes and the "SellerCode" in the utility for privkey).

Oh, well. I'm not very ambitious anymore, I guess. I hear you.  :)

I understand you very well  ;)

See, the above process even reads lengthy and tiresome. It also requires you to "install" extra software. Just imagine, you're a noob trying to buy something and the seller proposes to install software from some strange guy who calls himself casascius and you'll have to work some magic on some strange alphanumeric codes. Does that inspire confidence?

I've always said that the majority of people will use bitcoin over web services of some kind. That's just the way it is. They're used to entrusting google with their email, facebook with their family photo album, paypal with their money, why would they start using "real" software for something like bitcoin?  ;D

That covers multisig, not really what I have in mind.

I've chosen m-of-n-wallets for a reason. I think they are the easier concept to grasp for the majority of users, and that might just be most important for adoption.

Feel free to chip in  ;)
I'm not buying a software here, so 1 BTC is all it's worth to me.

I don't even usually do escrow, just get asked from time to time.

visit http://coinbit.tk and create a vanity address, or atleast read their explanation. sheds some light on how easy this could be made http://coinbit.tk/about.html. take note of their split key process where part of the key is given to you and the rest is sent to the server once the form is submitted. this might be something you are atleast partially interested in. a good starting point maybe. just my .02(thought i'm quiet out of depth here honestly. hope that helps)

just a little http://upload.wikimedia.org/wikipedia/commons/thumb/1/17/Belize_Speed_Bump_Sign.JPG/320px-Belize_Speed_Bump_Sign.JPG

Why split the wallet? Split just the private key used to generate the pay-to address.

edit: eeh i've just read the thread title :)

maybe oversimplifying things, but since you want just a moderate lvl of security, but ease off use just make a small app that generates the key on a trusted server, then encrypts it with symmetrical encryption, send the bitcoin address, secure delete it and then distribute the encrypted key along with a portion off the key so than whenever n out of m of the recipients join their parts there's at least one full copy off the symmetrical key.
and another app that receives such parts and outputs the bitcoin key.

that way you just have to trust the server in which the apps reside and generating the key is only a matter off imputing parameters of n, m, and delivery method for each member's parts and data.

and receiving the key will be a matter of imputing one copy of anyone encrypted data, the minimum amount off decryption fragments and where to deliver the key

and that way as long as the same code is running you don't even need to use the same server for getting the key back (although both will have to be trusted)

edit: after goggling i realized my solution was already posted somewhere else, along with another great one:
http://stackoverflow.com/questions/1719376/how-to-encrypt-something-so-that-can-be-decrypted-using-any-two-of-three-keys
the checksum one is great for your intention in my opinion, along with the best rated one (incredibly similar to mine)

sorry for the edit, but i rushed to post

https://blockchain.info/wallet/escrow

okay, first things first:

1. your idea look great

2. have an idea for a software and want someone to develope it for 130 €
3. you want that the software is free to use and open source
4. you decide which program is good to earn the bounty, but maybe using all of them.

but you don't want to buy a software. You want do donate for a developer 130 € who develops this program in days or weeks of work.

okay, my opinion:

If you want something for someone, who might work for this a couple of days or weeks of manpower, you ususally pay for it.
If you want, that the result is open source and free to use for everybody, than it's your decision, but you pay usually for the time of the developer, because you get all the right of the result, if you pay enough.

if you find someone, who do this, great. But you won't find any professional, who do it for living. (the focus is on "do it for living")

Well, actually, I'm looking for someone who is already working on something like this and maybe my bounty can give him a little push in the right direction.
I can imagine e.g. the developer of bitaddress to already have this on his future feature list, and this is no more than a little incentive to make it happen a little sooner and maybe a little more the way I like it.

If no one takes the challenge, well, I guess we'll just have to wait until 1 BTC is attractive enough to fund a months worth of software development, because I'll keep the bounty up, no matter how much that single bitcoin is worth ;)

lol  ;D or so ...

I'm actually concerned about the workflow, so maybe my request is a little unclear.
I might consider a solution that does not include a web server, I might even prefer it.
It may also be based on multisig.
But, and that's the important part, the workflow should be:

1. escrow sends a key to buyer & seller, as well as a payment address to the buyer
2. buyer sends money to that address
3. no one (not even escrow) is able to access funds on the payment address without one other person
4. a) ideally, buyer & seller agree and seller may claim the funds without needing escrow
4. b) escrow may take sides and help one of them to claim the funds

Also, a definitive requirement will be that at least the buyer (who might be a complete newb) does not need to understand anything like multisig, is not required to install software or do anything more complicated than sending payments to an address and keeping his part of the key (and possibly sending that by email to someone else when everything is settled).

The reason is just that right now a complete newb has no other chance than either
a) trust the seller
b) trust an escrow person
c) learn (and we all know that's what they fear most ;D )

Another problem with "traditional" escrow that shall be solved by this approach is unavailability of the escrow person (e.g. on vacation, dead, amnesic).


Does that software solve the problems above?

One of my friends had suggested an automated service.
It would send each of you a key and keep a key.
In case of dispute, it would ring the operator, if not , there is not human interaction needed.

I've just added a demo at https://dice.gg/webescrow_nm that does this task, full source code is available at https://github.com/knowitnothing/webescrow_nm. Let me know if that is close to what you had in mind.

Instead of the escrow sending the keys, the service does the task. All the other steps occurs as mentioned in your post.

The server is required for sending the emails, as well generating a private key that the escrow has no access to. Of course now you have to trust this server is not actually storing the private key. If you check the code you will see it is never stored (except in memory till the request completes), but then you have to trust that I'm not running a modified copy of the code that does more than that code.

Wow, that looks precisely like what I always had in mind, good job! :)

Gimme a little time to check the sources and stuff, but I'll definitely be awarding this thing with the bounty.
Unless I find a backdoor, that is ;D

Been looking over the code a little, I see no backdoors  ;)


How much work do you think it would be if you would add an optional field for a PGP public key for each address?

I.e., for each email-address you may define a public key.
If provided, the email will be sent encrypted?
If not, it will be plain-text.

What if instead of doing that, the person creating the escrow just ticks a checkbox next to the email "Encrypt using GPG" ? GPG will find the public key based on the recipient.

Probably even better :)

There is rough support for that now.

Unfortunately it cannot be that simple for a variety of reasons, instead I decided to go with a 2 step process. First the person submits his public key, then when creating the N-M escrow the guy selects whether he wants to encrypt a given email with GPG or not. If a key related to that email was uploaded earlier, it will succeed (or should succeed if there is some bug).

Testers are welcome.

Nice job! Pretty slick. Going to have to give it a try one of these days.

Not finished testing and stuff, got too much trouble with my other bounty ::)

But I'll definitely need an address from you ;)

Hi, 13aoLuhzgT18vCf8FQiUYhRgoWvgJMfxNa, thanks.

Just some reminders to anyone that considers using this: by using it you are trusting that the server running this code is not storing a copy of the private key and/or at least n shares. By using GPG encryption you remove the issue where the server could be, knowingly or not, storing emails in plain text, and also, of course, protects yourself when receiving the emails.

On the other hand there is a good amount of convenience here, the escrow is only required to engage in the process if there is some kind of dispute between the seller and the buyer (in the standard n = 2, m = 3). The buyer just needs to make a standard transaction to a newly generated bitcoin address. After confirming the seller has done his part, the buyer gives his share to the seller which allows him to obtain a private key for the address used. If the seller doesn't act, e.g. doesn't send a product, the escrow can just give his key share to the buyer, which will be able to regain access to the bitcoins sent. If the buyer pays but doesn't give his share (for whatever reason, like not knowing he has to do that), the escrow can just give his share to the seller instead. In all the cases, no single person has access to the funds.

This is close to what is mentioned in the emails sent, by the way.

Does it have "state"? I mean does it keep track of the progress behind an escrow deal and allow for recovery in case something goes wrong? For example one common scenario is that one or more of the parties did not receive the email or it ended up in their spam box and they can't find it.

The scenario you gave is fixed by the parties communicating: "I received the email", "me too", "good, me too".

Adding state implies in saving one or more parts of the shares, for an unknown amount of time. This is problematic for a server that don't want to store anything, it would need to involve other methods for storing the shares.

Furthermore, there is no need to keep track of the progress behind a given escrow deal, as anyone can verify if the address received funds. Allowing for recovery in any given case means the server can also steals the funds. If one of the parties did not receive the email then they can just setup another one, there is no penalty or fees involved.

https://blockchain.info/de/tx/5b445f6126be4e0aa4d284ee7f910ca9f46c2b3885b6e10553ba5971709d1371

I just had to wait for this bounty to be at $1000 ;D

Thanks!