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


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

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

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. 

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.

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)

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

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

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 )

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?