Pages:
Author

Topic: Potential solutions for Escrow/Fraud issues - page 3. (Read 3744 times)

legendary
Activity: 1199
Merit: 1012
January 18, 2012, 04: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).
hero member
Activity: 700
Merit: 500
January 18, 2012, 04: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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
January 18, 2012, 04: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.
hero member
Activity: 588
Merit: 500
Hero VIP ultra official trusted super staff puppet
January 18, 2012, 03: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
Pages:
Jump to: