Bitcoin Forum

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

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.

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

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.

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.

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


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.

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.

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.

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


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?

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.

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.

Didn't read most of the thread..sorry, but a problem I foresee.

Say I'm trading my 1000 bitcoins for something. The bitcoins are magically locked away, well..the guy tries to scam me, of course I don't release my half, but neither does he!

So, now I'm out of 1000 bitcoins, but he's not out of his object. What does this mean? Well, the scammer can use this against me and agree to unlock my half of coins for a small fee...

He could but his rep is ruined.  Now compare your same scenario without escrow.  You pay scammer 1000 BTC and he disappears.

Which is worse?  If mult-sig escrow a silver bullet that allows one to be careless with giants piles of coins?  No.  Is it better than the current 100% implicit trust required system?

Just was pointing out a small flaw in the protocol, I think after a set amount of time on the coins, they should be returned to the host if the deal doesn't go through [both parties would see the time before they agree on it]. Then again, this leads to more security issues of people paying for goods and then not confirming the arrival of goods.

Really hard to do a system like this without a 3rd party to inspect each of them. If one of the parties are corrupt, the deal falls through and 1 guy gets screwed over anyways.

You can't see the problem with that?

Method A: coins locked forever without consensus
False transaction by buyer - buyer loses/gains nothing, seller loses coins
False transaction by seller - buyer loses coins, seller loses/gains nothing

Method B: coins returned to sender without consensus
False transaction by buyer - buyer gains product & coins, seller loses coins
False transaction by seller - buyer loses coins, seller loses/gains nothing

In the current method neither party GAINS anything by faking the transaction.  Yes they can make someone else lose but they don't gain.  In a coins return to buyer method the fake buyer can always win.  You create a game theory scenario where the proper way to play the game is not complete transactions as a buyer.

So untrusted buyers won't be trusted to use the escrow and thus make the escrow worthless.

So not to fragment off but the reason why auto refunds can't be done is becuase the person that is supposed to recieve the refund has the other half of the "key" to commence an action(such as unlocking and sending back to wallet). Is this correct?

Correct.  It is the same reason the merchant won't "automatically get paid".  They need to sign off on the "forward" transaction also.

In a 2 party transaction both parties must sign the transaction even if it is obvious to the humans that they will want to sign it.  Granted some of this can be automated by the wallet.  You could get a popup "there is a half signed transaction to receive 50 BTC @ addresss xxx we control.  should we sign it to complete?  yes/no/more info".

Thanks DeathAndTaxes and everyone. I finally get that what I am proposing will require multisig adoption for it to work safely.

On that note, I hope that whichever implementation is adopted, that there is an escrow function also adopted that does not:

• require 3+ parties just to perform a single transaction
• there is no 'time limit' created on the transactions where all coins are returned (same thing as not having escrow at all)

Did anyone read my reply (https://bitcointalk.org/index.php?topic=60158.msg700632#msg700632)?

Example, I am the buyer and I have this transaction already signed by the seller:
If I want to release the escrow, I sign it and publish it. The seller automatically get paid.

This discussion (https://bitcointalk.org/index.php?topic=33615.0) is relevant.

A two party escrow would eliminate malicious fraud.  Surprised no one has mentioned it.

Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions.

I like the idea by CoinSpeculator very much!
Is it possible with P2SH multisig approach currently being implemented?

P2SH is discussed here:
https://bitcointalk.org/index.php?topic=56969.0
https://bitcointalk.org/index.php?topic=58579.0

Yes.  Essentially you just have a transaction w/ 2 inputs (100% from buyer and x% from seller) and those funds require both keys (signatures) to transfer.

So buyer gets the product he creates a transaction sending all of funds (his 100% & sellers 10%) to seller and sign it.  Then seller signs it and transaction is complete.

For a refund seller creates a transaction returning the 100% to buyer and 10% to himself and signs it.  The buyer then signs it and the transaction is complete.

I like it.  I actually like it a lot.  Even a small counterparty deposit increases the cost of being a jerk.
In a "normal" escrow the buyer only stands to lose reputation and honestly some people don't value that very highly.  A small counterparty deposit ensures they lose BOTH reputation and financial stake.

That's a very interesting direction. Other than the annoyance of requiring that someone have something in order to give something, it does seem to fit all the criteria for a social solution to fraud.

I believe I'll support this.

Also, thank you DeathAndTaxes for contributing to this thread and helping myself along with others to understand the finer details.

Well if you already have significant reputation & trust it is unlikely you will need to put up a counterparty deposit.  Obviously is someone asks you for more of a deposit you are comfortable with you can not trade.  If it becomes commonplace it will be just another negotiating tactic so that both parties feel their risk is hedged.

Interesting thing is that you can use blockchain to facilitate order updates too.

1) Mathew wants to buy a rig from me from me.  We agree on a price of 150BTC.
2) Mathew wants to use escrow (smart idea) but I have little rep so he demands a counterparty deposit of 30 BTC.
3) I negotiate it down to 10 BTC which he accepts.
4) We create the transaction with 160BTC which requires 2 signatures to release.
5) Once I ship the product I sign the first half of a "paid" transaction (all 160 BTC goes to me) I include in the transaction the tracking #.

Now depending on how sophisticated Mathews's client is (and this doesn't exist yet) the block chain could notify him not just of the half signed transaction but decode the text message inside showing him "Hey mathew I shipped the rig.  Here is tracking #.  Be sure to sign your half once you get it".

The half signed transaction sits on his wallet until he either signs it or rejects it (the blockchain has no concept of reject, reject would simply hide that transaction).

Now this is one example but when people like me says Bitcoin NEEDS mult-sig to expand beyond uber-nerds this is why.  multi-sig allows users to replace implicit trust with stronger methods.

Issue: wallet can be stolen
Solution:  multi-factor wallets are much harder to compromise
How: multi-sig allows 2 factor signing (wallet + secondary key on smartphone for example)

Issue: seller can be scammer (trading requires implicit trust)
Solution: escrow
How: multi-sig allows a transaction to be "half completed" and frozen until consensus between buyer & seller is acheived.

Issue: online wallets can be scammers (mybitcoin)
Solution: variant on multi-factor wallet
How:  multi-sig allows wallet provider to retain 1 of the two private keys and the user passphrase is in realtime converted into the 2nd private key

Issue:  double spends can be dangerous but merchants want realtime processing
Solution: multi-factor wallet provides some double spend protection
How:  Since a spend requires wallet provider key (not just user key) a double spend would require both wallet & user.  If merchant doesn't trust user but trusts wallet provider (because say they are multi-million dollar company w/ real assets) then double spend by user alone isn't possible.

And the list goes on and on.

After talking to a friend IRL about the two party escrow thing I realized there is nothing to stop the buyer from not releasing the money after the items arrive.

EX: I get items from seller, I'm already out my 100 bitcoins, and he's out 10 more, LOL!  I'm going to change my name and no one will never know that I'm a dick!

I think both sides would need a ~10% additional escrow to prevent all malicious fraud.  I think this is important especially for buyers as they will have far less reputation to verify and depend on compared to centralized merchants.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this (https://bitcointalk.org/index.php?topic=33615.msg421527#msg421527) for example. Some more discussion occurred here (http://bitcoin.stackexchange.com/questions/557/decentralized-escrow-functionality-built-into-bitcoin).

Thank you for sharing Meni. Many of us are very new to these issues, and some of us (like myself) have already followed them but were not quite clear on some of the finer points.

I am glad to see everyone discussing this issue just the same.

It appears you overly complicated the idea and no one in that thread had a clue what you were talking about.

This is ridiculous. Of the 3 people who posted after me in that thread:
remmy (the op) understood what I said, up to some technical details.
iamzill probably didn't understand. His loss, my suggestion solves his suggested failure mode and I explicitly addressed it.
BitOffer presumably understood what I suggested, as he referenced it.

My "overly complicating the idea" was written in a way that makes it precise who gets what in which conditions. It was designed to solve the problems raised earlier in that thread - some of which you will probably only realize after some more chats with your IRL friend.

Might wanna relook who the OP is.

I meant the OP of that thread, who is of course distinct from the OP of this thread.

I am distinct from the op of any thread. Indubitably (http://www.youtube.com/watch?v=7bmIKrU2jQU).

I like the CoinSpeculator's idea.
It can be % that can be set from the client before the transaction.
There should be a trackbar that goes from 0.00% to 100%, or even it can be set manually ( ex: 120% )
So, it will be even possible that both buyers and sellers will need to put the same amount of Bitcoin to make the exchange.
If everything will go well, the seller will get back his own money and buyers money too.

I don't know if this kind of transaction ( with such a high % ) will ever happen/needed, but I think that the should be available on the client(s)