Topic: AWARDED [BOUNTY] split key wallet escrow - 1 BTC (Read 3911 times)

Thanks!

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

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

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.

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.

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.

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

But I'll definitely need an address from you

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

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.

Probably even better

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.

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.

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

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.

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'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?

lol  or so ...

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

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")

https://blockchain.info/wallet/escrow

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