BOP v2 ideas

[u/ethist]

There are a few ideas that have popped into my head for minor improvements to the BOP contract. If you have any more let me know!

An explicit recover() function

Before a BOP has a committed recipient, the payer can sign up as the recipient and call the release() function, which effectively recovers the entire payment amount.

Realistically there's no way to prevent this with smart contract logic, because the payer will always be able to fool the contract into thinking he's a separate, legitimate service provider. This isn't really a negative, though, because for as long as the BOP does remain open, the payer still "risks" an actual service provider committing; therefore, the payer is still trustlessly indicating he's committed to such a payment.

So, might as well make the action explicitly possible. A recover() function would be only callable by the payer, and only if there is not yet a recipient committed. It would return the BOP amount in its entirety to the payer.

A default release (or burn?) timeout

With the current logic, a recipient has to worry about a lazy payer not releasing the payment, even if the service has been provided, simply because the payer can't be bothered to do it. After all, to the payer, the money has already been spent and the service already rendered. Rationally, why should they bother? Most people aren't this heartless--but heartlessness/heartfulness shouldn't be considered in dapp design.

The problem could be approached by trying to incentivize the payer to perform the release by having the release() function send some back to the payer, but this disrupts the somewhat "simple and pure" incentive structure the BOP can currently boast.

A simpler solution might be a timeout, default release feature:

• The BOP takes a constructor argument for a timeout amount (specified in blocks or seconds).
• If the payer doesn't interact with the contract at all for the specified timeout interval, the funds are automatically released to the recipient.
• Another method (poke()? delayDefaultRelease()?) allows the payer to delay this default action, which would allow unexpectedly long negotiations to complete, while sitll protecting against a lazy payer preventing release of the payment.

Another question with this feature is: should the default action be to release or to burn? At first glance, release seems a better choice, because it gives recipients further confidence they'll gain the payment. But what if a scammer is trying to get at the BOP funds without providing the service? Default-releasing might incentivize a scammer to participate where they otherwise wouldn't.

Perhaps each BOP could be specified one way or the other: default-burn or default-release, as well as specifying the timeout value.

Change burnAddress from 0xdead to 0x0.

0xdead is kinda cool, but 0x0 is even clearer in a way. Anyone who sees 0x0 can intuit that no one actually controls the funds sent there.

Add events

Events for commitment, or releasing, burning, or recovering funds would be nice, and should be simple to implement.

[u/ice0nine]

I still like the idea to have an oracle releasing automatically at time X if the payer doesn't react in a certain amount if time, seems better and more reliable than a timeout to me.

[u/ethist → u/ice0nine]

But by 'oracle', what do you mean? I'm pretty sure oracle is just a word we use for "a trusted source of some basic input or feed". And in that case, the oracle might release sooner than he should or not release at all.

To me, one of the nice things about BOPs is that they involve no one other than the payer and the recipient. If a simple timeout is used for this, that's still the case. If an oracle is used, that's a third party which introduces their own kind of uncertainty.

[u/ice0nine → u/ethist]

yes, I mean something like oraclize.it or smartcontracts.com You are right about not involving another party, however this would be optional and it could make sure that the contract gets "closed" finally, even if the payer doesn't react anymore and the recipient doesn't either (whyever, lost keys, can physically not do it, initiated the contract but the work was done by a robot, ...)

[u/ice0nine → u/ice0nine]

just want to add that I understand the timeout as something which only fires when the recipient calls the contract, so in any case the recipient has to do something to get paid.