Escrow without third parties

[etotheipi]

That conversation should address exactly that question.

Without buyer committing a risk deposit,  they have no reason to finish the transaction after receiving the goods.   They might have received a low-quality product and decided to spite the seller by leaving the coins locked.

Without the seller putting in a risk deposit, he can make bogus postings for merchandise for stuff he doesn't have and get victims to lock money into a 2-of-2 tx that he can then hold for ransom without any risk to himself "you're not getting any money back unless you sign this tx giving me half of it. "

Your proposal IS a three-party arrangement.  There's absolutely nothing wrong with it...  In fact I had a very similar idea a while back,  and I think it makes for a good third-party business model.  L

But there will always be demand for a true two-party solution.   That's where risk deposits are critical if they are going to happen at all.   

[cbeast]

That conversation should address exactly that question.

Without buyer committing a risk deposit,  they have no reason to finish the transaction after receiving the goods.   They might have received a low-quality product and decided to spite the seller by leaving the coins locked.

Without the seller putting in a risk deposit, he can make bogus postings for merchandise for stuff he doesn't have and get victims to lock money into a 2-of-2 tx that he can then hold for ransom without any risk to himself "you're not getting any money back unless you sign this tx giving me half of it. "

Your proposal IS a three-party arrangement.  There's absolutely nothing wrong with it...  In fact I had a very similar idea a while back,  and I think it makes for a good third-party business model.  L

But there will always be demand for a true two-party solution.   That's where risk deposits are critical if they are going to happen at all.   

This is why most larger sales contracts require at least a down payment. The seller already sent the goods, so already has enough comitted to the contract. As far as bogus sellers, caveat emptor. That's why vendors should have a public rating system or better yet, a good relationship between the vendor and buyer. If the customer decided to stiff an honest merchant, then that merchant would lose more than the customer with the merchandise and the escrow. I can see what you are trying to do, I just don't have an analogy in normal business transactions to relate this too.

I'm looking for anyone that is working on a decentralized gambling system to provide "Provably Fair" random number generation for an automated 3rd party private key provider.

[etotheipi]

This is why most larger sales contracts require at least a down payment. The seller already sent the goods, so already has enough comitted to the contract. As far as bogus sellers, caveat emptor. That's why vendors should have a public rating system or better yet, a good relationship between the vendor and buyer. If the customer decided to stiff an honest merchant, then that merchant would lose more than the customer with the merchandise and the escrow. I can see what you are trying to do, I just don't have an analogy in normal business transactions to relate this too.

I'm looking for anyone that is working on a decentralized gambling system to provide "Provably Fair" random number generation for an automated 3rd party private key provider.

"Caveat Emptor" is exactly what Bitcoin is trying to avoid.  There's no reason for that when Bitcoin offers a very good solution that dramatically reduces the risk and splits the rest of it across both parties.  It's not perfect, but I'm also not talking about large transactions.

Hypothetical:  I want to buy a WoW sword from you for 1 BTC.  We've never met in real life.  In fact, I think you're kind of a creep, so there's no reason I want you to know any more information about me than you already do.  The problem is there are no third-parties that want to even touch this.  Many of them don't want to deal with digital goods, and even if they did, there's no way for them to verify that the exchange of the sword actually ever happened.  Not only that, but taking 0.2 BTC fee for arbitrating this transaction is a waste of time for them.  (and some transactions, one or both parties may not even want a third-party, for privacy reasons).

Does that mean this transaction shouldn't happen?  We could go back to the original way where one party (buyer or seller) assumes all the risk by sending their half first, and hope the second party follows through.  I think you're a creep (not really, though ), so I'm not going to trust you.  There's no way I'd do this "the traditional way."   The risk-deposit idea offers a solution. 

[cbeast]

This is why most larger sales contracts require at least a down payment. The seller already sent the goods, so already has enough comitted to the contract. As far as bogus sellers, caveat emptor. That's why vendors should have a public rating system or better yet, a good relationship between the vendor and buyer. If the customer decided to stiff an honest merchant, then that merchant would lose more than the customer with the merchandise and the escrow. I can see what you are trying to do, I just don't have an analogy in normal business transactions to relate this too.

I'm looking for anyone that is working on a decentralized gambling system to provide "Provably Fair" random number generation for an automated 3rd party private key provider.

"Caveat Emptor" is exactly what Bitcoin is trying to avoid.  There's no reason for that when Bitcoin offers a very good solution that dramatically reduces the risk and splits the rest of it across both parties.  It's not perfect, but I'm also not talking about large transactions.

Hypothetical:  I want to buy a WoW sword from you for 1 BTC.  We've never met in real life.  In fact, I think you're kind of a creep, so there's no reason I want you to know any more information about me than you already do.  The problem is there are no third-parties that want to even touch this.  Many of them don't want to deal with digital goods, and even if they did, there's no way for them to verify that the exchange of the sword actually ever happened.  Not only that, but taking 0.2 BTC fee for arbitrating this transaction is a waste of time for them.  (and some transactions, one or both parties may not even want a third-party, for privacy reasons).

Does that mean this transaction shouldn't happen?  We could go back to the original way where one party (buyer or seller) assumes all the risk by sending their half first, and hope the second party follows through.  I think you're a creep (not really, though ), so I'm not going to trust you.  There's no way I'd do this "the traditional way."   The risk-deposit idea offers a solution. 

I think the problem with this type of transaction is "who goes first?" How would you even layer this transaction? Who puts up the money first without someone getting suckered by someone backing out? If they can be done simultaneously, then fine, but how do you verify it? It just seems to be a very complicated process to design. Maybe this is a function of the NTimeLock?

I've been thinking that these escrows are not unique to Bitcoin and perhaps should be done by payment processors like PayPal, Dwolla and even MtGox first, just to see if people would use them.

[etotheipi]

I think the problem with this type of transaction is "who goes first?" How would you even layer this transaction? Who puts up the money first without someone getting suckered by someone backing out? If they can be done simultaneously, then fine, but how do you verify it? It just seems to be a very complicated process to design. Maybe this is a function of the NTimeLock?

I've been thinking that these escrows are not unique to Bitcoin and perhaps should be done by payment processors like PayPal, Dwolla and even MtGox first, just to see if people would use them.

Yes, it's possible to guarantee that all parties' money gets committed at exactly the same time.  All purchase money and risk deposits get broadcast in the exact same transaction.  That transaction is not valid until all relevant inputs are included and signed.

It's not trivial to implement, but once it's done, it can be fairly transparent to the user.  Gavin and I were discussing in that thread how it might be done under-the-hood.

[teste]

See how I will use escrow without third parties (With NO fear)

1- The buyer and seller will commit risk deposit.
2- The risk deposit will have more value than the product being traded. Why?
Because the buyer could receive the product and not release the bitcoins. (The world has a lot of bad people)
3- All parts will have incentive to act honestly. Otherwise the two parts will lose money.

[gmaxwell]

First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.

You can do more impressive things with ZNPs, https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked

But it's all just armwaving unless someone bothers writing code to actually do something useful that way.

[Sergio_Demian_Lerner]

You can do more impressive things with ZNPs, https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked

But it's all just armwaving unless someone bothers writing code to actually do something useful that way.

In your proposal you say: " The reason this isn't something people are using yet is because while the academics have proven it to be possible actually converting complicated programs like compositions of ciphers and hash-functions into zero-knowledge proofs is apparently not something anyone has figured out how to do practically.".

Your proposal is, as you say, completely impractical. What you are saying in why_hash_locked (if possible) requires a huge amount of computation and probably 100 Megabytes message as proof.

A zero knowledge proof of knowledge of k in k*GPub is only a hundred bytes long, and takes only three EC multiplications to achieve. What more practical than that!!
You can do it either by Chaum-Pedersen protocol , Schnorr’s Id Protocol or even naive cut-and-choose.
(edit: The first two protocols were designed for the Poligh-Helman cipher, and must be adapted to ECC)

Please Max !!!

[gmaxwell]

A zero knowledge proof of knowledge of k in k*GPub is only a hundred bytes long, and takes only three EC multiplications to achieve. What more practical than that!!
You can do it either by Chaum-Pedersen protocol , Schnorr’s Id Protocol or even naive cut-and-choose.

And also doesn't give you any assurance that the delivered good is as described, except via witholding— which can still be done if the good is as described: holdup / extortion: "Thanks for the car, if you want me to release the payment you'll need to prepare a transaction returning half of it, cheers!".  If you just want to have sender locked transactions you simply use a two of two output, or a plain hash locked transaction, absolutely no need for ZKP or anything fancy.

[Sergio_Demian_Lerner]

I completely agree with you about holdup / extortion.

But don't say that ZNPs are "impractical" . There are plenty of practical protocols that rely on ZNPs.