Potential solutions for Escrow/Fraud issues - page 2.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: bluefirecorp on January 18, 2012, 09:49:19 PM

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.

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.

bluefirecorp

legendary

Activity: 882

Merit: 1000

Quote from: DeathAndTaxes on January 18, 2012, 09:44:03 PM

Quote from: bluefirecorp on January 18, 2012, 09:41:20 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: bluefirecorp on January 18, 2012, 09:41:20 PM

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?

bluefirecorp

legendary

Activity: 882

Merit: 1000

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

Maged

legendary

Activity: 1204

Merit: 1015

Quote from: Matthew N. Wright on January 18, 2012, 05:45:35 PM

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.

DiThi

full member

Activity: 156

Merit: 100

Firstbits: 1dithi

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://bitcointalksearch.org/topic/escrow-750

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.

Matthew N. Wright

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 05:22:26 PM

Quote from: Matthew N. Wright on January 18, 2012, 05:20:43 PM

Quote from: DeathAndTaxes on January 18, 2012, 05:18:23 PM

Quote from: Matthew N. Wright on January 18, 2012, 05:12:15 PM

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?

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Matthew N. Wright on January 18, 2012, 05:20:43 PM

Quote from: DeathAndTaxes on January 18, 2012, 05:18:23 PM

Quote from: Matthew N. Wright on January 18, 2012, 05:12:15 PM

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 05:18:23 PM

Quote from: Matthew N. Wright on January 18, 2012, 05:12:15 PM

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

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Matthew N. Wright on January 18, 2012, 05:12:15 PM

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 05:09:01 PM

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.

Quote from: DeathAndTaxes on January 18, 2012, 05:09:01 PM

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

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Matthew N. Wright on January 18, 2012, 05:02:38 PM

Quote from: DeathAndTaxes on January 18, 2012, 04:59:48 PM

Quote from: Matthew N. Wright on January 18, 2012, 04:57:41 PM

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 04:59:48 PM

Quote from: Matthew N. Wright on January 18, 2012, 04:57:41 PM

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

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Matthew N. Wright on January 18, 2012, 04:57:41 PM

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: ?? on ??

Quote from: Matthew N. Wright on January 18, 2012, 04:52:59 PM

Quote from: DeathAndTaxes on January 18, 2012, 04:48:51 PM

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.

Matthew N. Wright

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 04:48:51 PM

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.

Quote from: DeathAndTaxes on January 18, 2012, 04:48:51 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Matthew N. Wright on January 18, 2012, 04:42:57 PM

Quote from: osmosis on January 18, 2012, 04:40:56 PM

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: osmosis on January 18, 2012, 04:40:56 PM

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?

osmosis

sr. member

Activity: 300

Merit: 250

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

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Quote from: DeathAndTaxes on January 18, 2012, 04:01:55 PM

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.

Quote from: SomeoneWeird on January 18, 2012, 04:06:39 PM

Quote from: DeathAndTaxes on January 18, 2012, 04:01:55 PM

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.

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