Would you guys be interested in an open source automatic escrow ?

[gogodr]

I want an excuse to get on a node.js project with bitcoin core or bitcoinjs.
I'm thinking about making a multi sig system.

The system would be like this:
A wants to send bitcoin to B in exchange for something.
A sends the bitcoin to a generated address from my app along with the target address, then the app makes the transaction requiring A's signature before the bitcoin is sent to B.

Any inputs on the subject? hurdles, maybe you think it is a stupid idea or a brilliant one?

[1715313440]

1715313440

[1715313440]

1715313440

[albert11]

what if A never release funds? that's why i think 2 of 2 is useless, your idea is good though, a trustless escrow system is very much needed but needs to be 2 of 3 imo.

[Blazr]

How do you plan to handle disputes? what if the seller claims to have sent the goods and the buyer claims not to receive it? you will need someone to act as a mediator. It would be best to use a 2 of 3 with buyer, seller and escrow each holding one key. If the transaction is all good, both buyer and seller can move the funds on their own without the escrow needing to do anything or even know the transaction is taking place, they only need the escrows public key to set up the 2 of 3. When there is a dispute then the escrow can get involved and ultimately choose who gets the coins by signing their transaction. So long as the escrow does not collude with the buyer or seller this is safe.

We really need better support for M of N in wallets. Something like this would significantly reduce scams on Bitcointalk. All an escrow needs to do is post their public key in a thread and the buyer and seller can craft a 2 of 3 address with it and continue on their own without the escrow and only require the escrow to do anything when there is a problem.

Perhaps you could make a standalone application to do m of n escrow transactions. I think the best way to do it would be to make it in Javascript, you're most likely to see the most usage there.

[gogodr]

I thought that the fact that, if a scam were to occur in the platform,the bitcoin would disappear as nor A nor B would have access to that bitcoin.

Process:
- A sends bitcoin to b through the platform.
- A no longer haves that bitcoin, it is being held by the platform and just waiting for A to sign it.
- B can see that the transaction is on process and proceeds to send the goods to A
- Once A receives said goods, A signs the transaction
- B receives the bitcoin

Scenario 1
*If B never sends the goods, A never signs.
::Outcome::
A loses the bitcoin as it is being held by the platform.
B didn't send his goods.
B never receives the bitcoin.

Scenario 2
*If B sends the goods, but A never signs.
::Outcome::
A loses the bitcoin as it is being held by the platform
B sent the goods to A
B never receives the bitcoin.

-- Proposal to avoid the loss: Have someone mediate the transactions so that he/she can resolve a dispute.

**********

Scenario 2 is not likely to happen, as A would have no motive to not sign

Scenario 1 is the one that could happen, but if it were to happen B wouldn't benefit from it other than making A lose bitcoin.

------
I think this is one of those, why not both?

how about a platform that offers the both things.
- An easy and fast system without an external party in the transaction other than the application
- a medium for an easy escrow so that an external person can mediate the trade.

The second would have this process:

- C creates the transaction.
- A sends the bitcoin to the platform
- B sends the goods to A and registers it in the platform
- A confirms the reception of the goods
- C signs the transaction and the bitcoin is sent to B
- B receives the bitcoin

*If there is a dispute
- A makes the dispute
- B submits evidence
- A submits evidence
- C mediates and sends the bitcoin to the rightful party.

[dznuts85]

I thought that the fact that, if a scam were to occur in the platform,the bitcoin would disappear as nor A nor B would have access to that bitcoin.

Process:
- A sends bitcoin to b through the platform.
- A no longer haves that bitcoin, it is being held by the platform and just waiting for A to sign it.
- B can see that the transaction is on process and proceeds to send the goods to A
- Once A receives said goods, A signs the transaction
- B receives the bitcoin

Scenario 1
*If B never sends the goods, A never signs.
::Outcome::
A loses the bitcoin as it is being held by the platform.
B didn't send his goods.
B never receives the bitcoin.

Scenario 2
*If B sends the goods, but A never signs.
::Outcome::
A loses the bitcoin as it is being held by the platform
B sent the goods to A
B never receives the bitcoin.

-- Proposal to avoid the loss: Have someone mediate the transactions so that he/she can resolve a dispute.

**********

Scenario 2 is not likely to happen, as A would have no motive to not sign

Scenario 1 is the one that could happen, but if it were to happen B wouldn't benefit from it other than making A lose bitcoin.

------
I think this is one of those, why not both?

how about a platform that offers the both things.
- An easy and fast system without an external party in the transaction other than the application
- a medium for an easy escrow so that an external person can mediate the trade.

The second would have this process:

- C creates the transaction.
- A sends the bitcoin to the platform
- B sends the goods to A and registers it in the platform
- A confirms the reception of the goods
- C signs the transaction and the bitcoin is sent to B
- B receives the bitcoin

*If there is a dispute
- A makes the dispute
- B submits evidence
- A submits evidence
- C mediates and sends the bitcoin to the rightful party.

what if the case is, A sends the correct amount of coins in the transaction but B only sends half or not really the goods he is selling then the bitcoins of A will be lost even he is the one being honest in the transaction?

[Blazr]

How about this:

Buyer sends 2BTC to the escrow. Seller then informs buyer he has been scammed, and tells him that if he releases the 2BTC to him he will give him back 1BTC of it. Buyer decides to cut his losses and the seller successfully scams 1BTC.

Another scenario is that someone could buy goods off a competitor and not release the funds in order to put them out of business.

A better solution would be https://en.wikipedia.org/wiki/Nash_equilibrium however this has similar issues too.

[gogodr]

::EDIT:: Still working on this

[medUSA]

"Automatic" escrow has been thought about by many others for a long time. It is not a problem when both parties honour the deal. The tricky part is when a dispute happens and their is no automatic solution. There has to be a third party involved to settle the dispute.

Blazr outlined a 2 of 3 multisig method and it is kind of a defacto standard so far.

It would be best to use a 2 of 3 with buyer, seller and escrow each holding one key. If the transaction is all good, both buyer and seller can move the funds on their own without the escrow needing to do anything or even know the transaction is taking place, they only need the escrows public key to set up the 2 of 3. When there is a dispute then the escrow can get involved and ultimately choose who gets the coins by signing their transaction. So long as the escrow does not collude with the buyer or seller this is safe.

I believe automatic escrow is almost impossible to achieve without a real person in the equation. I can imagine people engaging in prank deals just to lock down some poor guy's money.

[freemind1]

I would not put my Bitcoins in an automatic escrow would not do unless there was a person behind, what if the server fails?. It may take a thousand things.

[jxm262]

@gogodr  PM me if you'd like to collaborate on something bitcoin related in Node.js.  Even if we don't pursue this idea, I have a few others. 
 
Also, I created a Node.js Slack community if you'd like to join.  Alot of folks from the /r/node subreddit and node.js google group have joined.  It gives a nice platform to talk with other node.js devs in real-time.  (I see a few bitcoin folks too). 

nodeslackers.io to register. 

Or PM me and I'll give you my personal email.  I've been looking to partner up and learn more about the bitcoin space

[gogodr]

@gogodr  PM me if you'd like to collaborate on something bitcoin related in Node.js.  Even if we don't pursue this idea, I have a few others. 
 
Also, I created a Node.js Slack community if you'd like to join.  Alot of folks from the /r/node subreddit and node.js google group have joined.  It gives a nice platform to talk with other node.js devs in real-time.  (I see a few bitcoin folks too). 

nodeslackers.io to register. 

Or PM me and I'll give you my personal email.  I've been looking to partner up and learn more about the bitcoin space

I just registered.

[Amph]

How do you plan to handle disputes? what if the seller claims to have sent the goods and the buyer claims not to receive it? you will need someone to act as a mediator. It would be best to use a 2 of 3 with buyer, seller and escrow each holding one key. If the transaction is all good, both buyer and seller can move the funds on their own without the escrow needing to do anything or even know the transaction is taking place, they only need the escrows public key to set up the 2 of 3. When there is a dispute then the escrow can get involved and ultimately choose who gets the coins by signing their transaction. So long as the escrow does not collude with the buyer or seller this is safe.

We really need better support for M of N in wallets. Something like this would significantly reduce scams on Bitcointalk. All an escrow needs to do is post their public key in a thread and the buyer and seller can craft a 2 of 3 address with it and continue on their own without the escrow and only require the escrow to do anything when there is a problem.

Perhaps you could make a standalone application to do m of n escrow transactions. I think the best way to do it would be to make it in Javascript, you're most likely to see the most usage there.

this is actually easy, because you must sign to take the package from a courrier(ups for example) if you do not sign, then i know you refused the package(i can check on the tracking), so this isn't a problem really

same thing if the buyer don't release the fund, but he say that he released them, just check blockchain transaction, if this is true or not

and btw i'm all for automatization, "machine" here are far better than human

[SebastianJu]

Scenario 1 is the one that could happen, but if it were to happen B wouldn't benefit from it other than making A lose bitcoin.

And there starts the problem. Lets assume your system is used because B has no trust, then B could extort A to not release the coins. Lets say he says that he only will release the coins until A sends him something. Of course the chance might be small that A is trustin him now but thats the benefit i see for B not releasing coins.

So a mediator would be needed.

It superiour to escrow trades as long as no dispute exists, which is the case 99% of the cases, but when one comes up you need another person. Though one might think that the scam probability might be higher without an intermediary.

[Snail2]

An escrow not going to work without a real third party mediator who can make decisions. An automated escrow can work well e.g in the case of exchanging BTC to an altcoin or even fiat where the system can handle both transaction but not for stuff where it needs a "honest" input from one or more participants.

[gogodr]

I understand that the hard part is going to be the disputes.
Still I believe that if it can't all can be automated, at least I can provide part of it automated.

How about a free system(free as in the fee is a miner's fee for the trades) That can handle disputes. Once a dispute is called, a trusted user can mediate the dispute requesting information to both parties.

The way to get a trusted user is to offer the service,I would have to get a couple of escrows interested in the platform and they could mediate the disputes for a fee.

Effectively, it would be paying extra to get most of your money back if you got scammed, so it reduces the loss up to a small fee.

:: that  being  said, if there is no  dispute, the system can  work as proposed and fully automatic.

The way to do it would be by having the platform also sign the transaction and give the trusted escrows power over the key that the platform holds for the assigned transactions.

-----------

The way it would work should be for both A and B to agree on a trusted member so that if a claim happens, the escrow will take in place in the transaction. If there is no dispute then the escrow never takes in place and the transaction is fully automatic.

Tho, if a dispute were to happen, the only one paying the fee would be the winner of the dispute.

----------

is that alright?

[SebastianJu]

I understand that the hard part is going to be the disputes.
Still I believe that if it can't all can be automated, at least I can provide part of it automated.

How about a free system(free as in the fee is a miner's fee for the trades) That can handle disputes. Once a dispute is called, a trusted user can mediate the dispute requesting information to both parties.

The way to get a trusted user is to offer the service,I would have to get a couple of escrows interested in the platform and they could mediate the disputes for a fee.

Effectively, it would be paying extra to get most of your money back if you got scammed, so it reduces the loss up to a small fee.

:: that  being  said, if there is no  dispute, the system can  work as proposed and fully automatic.

The way to do it would be by having the platform also sign the transaction and give the trusted escrows power over the key that the platform holds for the assigned transactions.

-----------

The way it would work should be for both A and B to agree on a trusted member so that if a claim happens, the escrow will take in place in the transaction. If there is no dispute then the escrow never takes in place and the transaction is fully automatic.

Tho, if a dispute were to happen, the only one paying the fee would be the winner of the dispute.

----------

is that alright?

That sounds fine though the problem might already start before the trade. If one of the parties dont know how to securely make this trade. I mean you mostly trade things that you send by mail. You can give tips for that. But if something happens because the type of deal was done insecure then the escrow doesnt have much where he can decide.

So you might make a plan for physical goods, crytocoins, accounts of some things and so on. So that a mediator at the end has something to decide.

Alternatively you can restrict the use of the system to only that type of trade where a decision could be made then.

[countryfree]

An automatic escrow may be nice, but what people want is an escrow they can trust.
How do you build trust on something automatic?

[Amph]

An automatic escrow may be nice, but what people want is an escrow they can trust.
How do you build trust on something automatic?

you do it in the way that it cannot require any further maintenance/modification in the future, this mean no human should be touch it again

and before this, source code should be release for obvious reasons

[LOBSTER]

An automatic escrow may be nice, but what people want is an escrow they can trust.
How do you build trust on something automatic?

A centralized system is also vulnerable.

A decentralized system (like Bitcoin) is the one and only secure way.

In my opinion it's hard to build up trust for something like this in the Bitcoin community.

[gogodr]

I'll submit this project to the coinbase hackaton thing.
Lets see how this works, thank you all for the input.

[SirLolicon]

This would be great. But what would happen if the system crashed?

[gogodr]

This would be great. But what would happen if the system crashed?

if Implemented correctly, it shouldn't.
As with any information solution. Depending on the sensitivity of the service you might need a high reliability platform.
This involves not only a robust fail safe software but also backup hardware.

----------
If an IT service fails and loses information. It is mostly negligence.

[coinpr0n]

You could make the generation of multisig addresses automatically but I'd think you would still need at least 3 parties involved.

[jxm262]

@gogodr (I'll ping you on slack about this) and all the rest who might still be reading this...

I understand that the hard part is going to be the disputes.
Still I believe that if it can't all can be automated, at least I can provide part of it automated.

How about a free system(free as in the fee is a miner's fee for the trades) That can handle disputes. Once a dispute is called, a trusted user can mediate the dispute requesting information to both parties.

The way to get a trusted user is to offer the service,I would have to get a couple of escrows interested in the platform and they could mediate the disputes for a fee.

 
  
I think this is the best and potentially only route we can take.  I'd be more than willing to help build an automated system which gives a super super simple platform for escrow parties to charge a fee for their services.  Something that can be standardized (same docs for all users, etc..), easily accessible, and easy to implement by the escrow individuals & exchanges  (perhaps we build out a large SaaS type service?).  
  
The 2 / 3 multisig seems to be the way to go, I think where us devs come in is facilitating this process to be as streamlined and "easy" as possible.  At the same time, there's nothing from stopping us on embarking on a commercial type side of it too.  Perhaps we could focus some efforts on reaching out to the different escrow servicers, exchanges, blogs, etc.. and let them know of our service.  A super easy product that we provide for a small (incredibly nominal i'm talking) fee.  
  
We could even open source the entire platform, and only charge (my entrepreneur side talking) for some easy to use web-portal or advertising.  I mean there's a million ways to go with this.   But yeah, I do think this fits the requirements for what the coinbase hackathon is looking for.  


-J  
https://github.com/jxm262  
nodeslackers.io

[jxm262]

Anyway, I think we need to research the old ClearCoin service (maybe reach out to the old dev once we collect our thoughts a bit more).  Basically , just restart his old service and see what we can do to keep it something sustainable. 
 
https://bitcointalk.org/index.php?topic=21659.40