AWARDED [BOUNTY] split key wallet escrow - 1 BTC

[knowitnothing]

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

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.

[1714837642]

1714837642

[1714837642]

1714837642

[qwk]

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

[qwk]

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.

[knowitnothing]

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.

[qwk]

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

[knowitnothing]

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.

[devthedev]

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.

[qwk]

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

But I'll definitely need an address from you

[knowitnothing]

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.

[Abdussamad]

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.

[knowitnothing]

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.

[qwk]

But I'll definitely need an address from you

Hi, 13aoLuhzgT18vCf8FQiUYhRgoWvgJMfxNa, thanks.

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

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

[knowitnothing]

But I'll definitely need an address from you

Hi, 13aoLuhzgT18vCf8FQiUYhRgoWvgJMfxNa, thanks.

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

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

Thanks!