Bitcoin Forum
December 04, 2016, 02:01:31 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Potential solutions for Escrow/Fraud issues  (Read 3105 times)
Matthew N. Wright
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 08:59:36 PM
 #1

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

Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 09:01:55 PM
 #2

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
Hero Member
*****
Offline Offline

Activity: 700


View Profile
January 18, 2012, 09:06:39 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1116


View Profile
January 18, 2012, 09:18:45 PM
 #4

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 09:25:36 PM
 #5

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
Sr. Member
****
Offline Offline

Activity: 301



View Profile
January 18, 2012, 09:40:56 PM
 #6


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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 09:42:57 PM
 #7


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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 09:48:51 PM
 #8


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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 09:52:59 PM
 #9

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 09:57:41 PM
 #10

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 09:59:48 PM
 #11

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 10:02:38 PM
 #12

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 10:09:01 PM
 #13

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 10:12:15 PM
 #14

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 10:18:23 PM
 #15

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 10:20:43 PM
 #16

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
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 18, 2012, 10:22:26 PM
 #17

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
Untrustworthy
Hero Member
*****
Offline Offline

Activity: 588


Hero VIP ultra official trusted super staff puppet


View Profile
January 18, 2012, 10:45:35 PM
 #18

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
Full Member
***
Offline Offline

Activity: 157

Firstbits: 1dithi


View Profile
January 18, 2012, 11:21:21 PM
 #19

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.

1DiThiTXZpNmmoGF2dTfSku3EWGsWHCjwt
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 19, 2012, 01:32:39 AM
 #20

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.

Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!