So, the basic escrow works by two people working through a third party to exchange (usually money) for some other form of goods or services.
In a transaction where both people are honest, the escrow business can essentially be automatic since the buyer gets his goods and approves release of funds, only when there is a dispute does human interaction become necessary. Therefore, I propose the following system:
1) you create an escrow transaction for the amount, authorised by your key and containing the recipient's key/data etc - this block cannot be claimed until a subsequent block is issued by the buyer to approve it, it's also impossible for the buyer to reclaim it without the seller approving it to be returned.
2) it enters the network, gets verified and the seller sends the goods, once the buyer gets them, he creates a release transaction and the seller gets his bitcoins.
3) if a dispute occurs and both parties are refusing to release the money one way or the other, clearly it's now necessary to get a third party to arbitrate - in this situation, a signature from both the buyer and seller authorising a third party is required which will give that third party ownership of the original escrow transaction and they can then arbitrate the matter
Re: A proposal for a semi-automated Escrow mechanism
Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special "all clear" message to that server that then knows to "release" what it has to whoever it's suppose to go to.
Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.
One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.
One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
Re: A proposal for a semi-automated Escrow mechanism
Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special "all clear" message to that server that then knows to "release" what it has to whoever it's suppose to go to.
Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.
One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
Programming wise, should be possible with direct IP payments for example, where the "From" and "Comment" fields can be used to "reserve" the BTC until later.
One could send a transaction and in the comment field put something like "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server "Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.
Re: A proposal for a semi-automated Escrow mechanism
kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.
I'd go too with websites offering escrow services. The network is quiet complex as it is, without having to add all the confirmation, delay and dispute stuff.Currently when a transaction is broadcast it'll sooner or later be added to the block chain, what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
Also who do you think will be the third party moderating the dispute? There is no real advantage in adding it to the protocol itself.
Re: A proposal for a semi-automated Escrow mechanism
what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.
Re: A proposal for a semi-automated Escrow mechanism
what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.
if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.
1) be spiteful and nobody will get anything
2) agree on a third party to send the money to. that third party will be an arbitrator who will weigh up both sides of the argument and come to a decision as to who should be returned the money, minus whatever fee they agreed with the two hurt parties.
Subsequent to this, I also realised that my suggestion is open to trolling whereby a seller makes someone do an escrow transaction and then refuses to ship anything or arbitrate, my solution to this issue gives the following modification of the system:
the buyer makes an escrow transaction which is then presented to the seller, if the seller wants to go ahead, they must agree to be debited a sum stipulated by the buyer, the seller agrees and the escrow transaction then goes into the network for inclusion into the block chain, both parties are now down on their money.
if everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his "trust deposit" returned.
if the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.
if nobody can agree on a release, both parties now have an incentive to go to an arbitrator, when the arbitrator is authorised to receive the transaction funds, the trust deposit gets immediately returned to the seller, the arbitrator doesn't get a say over those funds.
Re: A proposal for a semi-automated Escrow mechanism
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
Re: A proposal for a semi-automated Escrow mechanism
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
That is really quite clever!
Do you simply assign the transaction to two bitcoin addresses and transmit it to the network for inclusion in the block list?
Can you do more than two? Is it a one-or-more situation?
Is this feature in the GUI yet?
Re: A proposal for a semi-automated Escrow mechanism
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
Due to that recourse, it is unlikely to be used as an escrow mechanism
Re: A proposal for a semi-automated Escrow mechanism
Due to that recourse, it is unlikely to be used as an escrow mechanism
Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)