Potential solutions for Escrow/Fraud issues

[Matthew N. Wright]

I believe that modern escrow solutions are archaic at best and rely too much on the opinions of a possibly ignorant third party. I propose a feature to bitcoin that will remove the need for an external escrow solution, strengthening the economy and ridding our community of fraud once and for all.

I will call this proposition "coin fragmentation". To properly explain coin fragmentation, I must first briefly outline the process of a bitcoin transaction based on the current implementation:

• Jon sends 1BTC to Mary
• Jon loses access to that 1BTC
• Mary gains access to that 1BTC

As anyone can see, this requires that Jon trust Mary first to provide whatever services she has offered, and as such opens opportunity for fraud and confidence trickery.

As you can see from the following outline, by inserting just two programmatic steps, we can  remedy this once and for all:

• Jon sends 1BTC to Mary
  
  
• 1BTC is split and locked into two individually worthless fragments
  
  
• Jon loses access to that 1BTC
  
  
• Mary must now provide promised services before Jon will release his fragment.
  
  

From this point, we have several possible outcomes. For simplicity, let's separate them by an honest and dishonest transaction.

Honest

• Maria proceeds to provide services rendered, Jon releases his fragment. Maria now has 1BTC.
• Maria does not provide services rendered, Maria releases her fragment. Jon now has 1BTC.

As is clear above, no additional complications arose from implementing this feature given an honest transaction.

Dishonest

• Maria proceeds to provide services rendered, Jon does not release his fragment. Neither Jon nor Maria have the 1BTC until the other releases their locked fragment.
• Maria does not provide services rendered, Jon does not release his fragment. Neither Jon nor Maria have the 1BTC until the other releases their locked fragment.

In the above outline, all monetary incentives to defraud have been removed.

With implementation of this feature, bitcoiners would be able to:

• Trade safely and openly with complete strangers
• Return incorrect amounts back to sender
• Provide refunds
• Improve negotiation and problem solving techniques
• Enforce higher standards for service quality in the community

Thank you.


Matthew N. Wright

[1714107346]

1714107346

[1714107346]

1714107346

[1714107346]

1714107346

[1714107346]

1714107346

[DeathAndTaxes]

This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical applications require changes to the protocol hence the discussion on OP_EVAL & P2SH.

Don't feel bad once when I was young I thought I invented secure key exchange without realizing it had already existed for a couple decades.

[SomeoneWeird]

This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical application requires changes to the protocol hence the discussion on OP_EVAL & P2SH.

This.

[arsenische]

Good idea. I didn't look close at the bitcoin protocol, thus "OP_EVAL & P2SH" means almost nothing to me yet.. But it is nice to hear that somebody is working on it. Probably bitcoind's JSON API will need to have some way to identify the sender. Right now gettransaction call doesn't have any info about the sender (though probably it has been done intentionally to enforce the best practice of using each address only once).

[Matthew N. Wright]

This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical applications require changes to the protocol hence the discussion on OP_EVAL & P2SH.

Don't feel bad once when I was young I thought I invented secure key exchange without realizing it had already existed for a couple decades.

This has already been discussed and potential implementations already exists.  It just requires multi-sig transactions.  Practical application requires changes to the protocol hence the discussion on OP_EVAL & P2SH.

This.

For the record I've read https://en.bitcoin.it/wiki/Contracts and am also quite aware of what benefits multi-signature transactions will bring.

It is possible that through multi-signature transactions, a model that I am proposing could be more easily implemented, but I find no where in the discussions anything resembling what I am proposing.

All existing proposals as I know of require:

• third-parties
• agreement from both parties, even to return coins to sender

Please elaborate.

[osmosis]

There are a lot of details on how this would be implemented, and sounds like there may be some work done here already for split keys. What I am getting from your idea is that escrow could be done with no 3rd party whatsoever. Also, refunds could be back to the sender without any action on the senders part. This would be a great value adding functionality to the bitcoin client.

[Matthew N. Wright]

There are a lot of details on how this would be implemented, and sounds like there may be some work done here already for split keys. What I am getting from your idea is that escrow could be done with no 3rd party whatsoever. Also, refunds could be back to the sender without any action on the senders part. This would be a great value adding functionality to the bitcoin client.

That is correct. Perhaps my explanation was too difficult for the previous posters to understand. Should I simplify it?

[DeathAndTaxes]

There are a lot of details on how this would be implemented, and sounds like there may be some work done here already for split keys. What I am getting from your idea is that escrow could be done with no 3rd party whatsoever. Also, refunds could be back to the sender without any action on the senders part. This would be a great value adding functionality to the bitcoin client.

That is correct. Perhaps my explanation was too difficult for the previous posters to understand. Should I simplify it?

 I am not confused and there is no need to simplify anything.  Using mult-sig you can implement EXACTLY what you proposed.

You send coins to an address which requires two keys.  The seller & buyer both have one key.  Neither can access the coins without other's private key.  Seller ships goods to buyer, and buyer then send his key to seller.   Seller uses pair of keys to gain control of funds.  There is no need for third parties in multi-sig (they could be used in a 2 out of 3 setup but they aren't a requirement).  Nothing is required other than the blockchain, updated protocol (w/ miner support), and updated clients.

Just because you were unaware of all the discussions involving multi-sig for last year or so doesn't mean you came up with anything new or novel.

[Matthew N. Wright]

Using mult-sig you can implement EXACTLY what you proposed.  I am not confused.  There is no need to simplify anything. You send coins to an address locked by two private keys. The seller & buyer both have one key. Neither can access the coins without other private key.   Seller ships goods to buyer, and buyer then send his key to seller.   Seller uses pair of keys to gain control of funds.  There is no need for third parties in multi-sig (they could be used in a 2 out of 3 setup but they aren't a requirement).  Nothing is required other than the blockchain, updated protocol (w/ miner support), and updated clients.

Please take the time to read proposals before you shoot them down. It is quite clear you are not reading it.

Just because you were unaware of all the discussions involving multi-sig for last year or so doesn't mean you came up with anything new or novel.

I don't think what I am talking about is even related to the current discussions of multiple signatures. If you'd like to provide evidence of similarities, I will be more than happy to listen, but at the moment it seems you're just discounting something out of pure laziness.

[Matthew N. Wright]

Using mult-sig you can implement EXACTLY what you proposed.  I am not confused.  There is no need to simplify anything. You send coins to an address locked by two private keys. The seller & buyer both have one key. Neither can access the coins without other private key.   Seller ships goods to buyer, and buyer then send his key to seller.   Seller uses pair of keys to gain control of funds.  There is no need for third parties in multi-sig (they could be used in a 2 out of 3 setup but they aren't a requirement).  Nothing is required other than the blockchain, updated protocol (w/ miner support), and updated clients.

Please take the time to read proposals before you shoot them down. It is quite clear you are not reading it.

I don't get it, isn't this the exact same as "neither can access the coins without the other fragment"?

Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

As you can see, this is fundamentally different as it allows a more streamlined transactions interface for the client as well and does not require any communication between the two parties whatsoever.

[DeathAndTaxes]

Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

A refund can be done via multi-sig also.

[Matthew N. Wright]

Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

A refund can be done via multi-sig also.

Even with only one party's consent?

[DeathAndTaxes]

Not at all. In my proposal, the crucial difference (a matter of convenience if nothing else) is that the receiver can send the fragment back without the participation of the sender.

A refund can be done via multi-sig also.

Even with only one party's consent?

No.  However that is hardly your claim which was "I have the solution for the trust/escrow issue in bitcoin".

Had you said "I know multi-sig solves the trust/escrow issue in Bitcoin" but I have a method to make it even more user friendly we wouldn't be having this issue.

With mult-sig the receiver would issue an updated transaction (increment sequence number) and sign it.   To get the funds the sender would sign it.  This would invalidate the prior transaction and funds would return to sender.  A future client could simply advise the user of this half signed transaction, which he would click [accept] and the funds would return.  So yes multi-sig would require user to click "accept" unless there was some auto-accept refunds option built into the client.

[Matthew N. Wright]

Had you said "I know multi-sig solves the trust/escrow issue in Bitcoin" but I have a method to make it more user friendly we wouldn't be having this issue.

Good point. I'll update my original post and thread title to clarify this.

With mult-sig the receiver would issue an updated transaction (increment sequence number) and sign it.   To get the funds the sender would sign it.  This would invalidate the prior transaction and funds would return to sender.

My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

[DeathAndTaxes]

My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

[Matthew N. Wright]

My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

So there is no way currently to inject strings into the blockchain inside of valid transactions?

[DeathAndTaxes]

My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

So there is no way currently to inject strings into the blockchain inside of valid transactions?

Sure but I don't see how that does what you think it will do.
How about explain it is nuts and bolt at the code level.

[Matthew N. Wright]

My proposal would be for allowing this to happen automatically. So long as you can write your own data to the blockchain, this client feature could be implemented without altering the fundamental protocol, correct?

No because the protocol has no understanding of your Bitcoin fragments.  It would consider them invalid transaction and reject them (and any block which included them).

So there is no way currently to inject strings into the blockchain inside of valid transactions?

Sure but I don't see how that does what you think it will do.
How about explain it is nuts and bolt at the code level.

I'm re-discussing this with my group to make sure I understand the fundamentals before I argue anymore. I think I am more focused on the user experience more than the protocol itself and that is blinding me to the similarities of what I am proposing and the existing multisig proposals.

My idea would require that a key be split in half in a safe way, which is impossible without a third party, and that alone would make it unsafe, and it would also be simplified by current multisig initiatives. The thing I can't wrap my head around is why would someone need to 'confirm' a refund? Is this just inherent to the multisig functionality and unavoidable?

[DiThi]

It IS possible with just multisig:

You have 2 transactions, one that we'll call XtoA that sends the coins to A, the other, XtoB sends the coins to B. X is a script that require the transaction to be signed by both parties to be valid. A signs XtoA and B signs XtoB. In the moment A signs XtoB, it becomes valid without B interaction; and viceversa.

No need to do use sequences or anything. Am I wrong?

P.S: As others said, the idea is anything but new. Satoshi himself proposed this: https://bitcointalk.org/index.php?topic=750.0

I would prefer a 3-way escrow where a third party will be contacted (and payed for the service) automatically when there's a dispute and it has the final word. Either thing is possible with P2SH I think.

[Maged]

The thing I can't wrap my head around is why would someone need to 'confirm' a refund? Is this just inherent to the multisig functionality and unavoidable?

Yes. The problem is that a transaction's inputs have no way to conditionally restrict (or even restrict at all) the outputs of the transaction. Thus, you can't construct a transaction that only requires the one key if the multisig transaction is being sent to a certain address and both keys if it's being sent anywhere else.

This could potentially be added to Bitcoin, but the bloat, potential security issues, and the additional code to do it is hardly worth allowing the receiver of a transaction to return the funds without requiring the sender to do anything, especially since this is the least likely case to happen out of all of the escrow resolutions. When you consider that 2-of-3 escrows that use a third party to arbitrate disputes is likely the preferred method of escrow for people, and that the third party would be happy to sign a refund transaction, this becomes much less useful.