Note: the images in this page are a bit out of date; they refer to Burnable Payments as "BPs" and don't necessarily resemble the latest version of the Toastycoin interface.
Aside from these superficial discrepancies, the information below remains accurate.
First, let's go over some relevant rules of the Burnable Payment "game".
There are a few more aspects we will ignore for now and return to further below:
(We encourage Solidity developers to follow along in the source code.)
(Disclaimer: Below we will use the words "never" and "always". We use these terms when the reality is "close enough to count", like how one might say "the bathroom on the 4th floor is always crowded" or "you'll never hit a car at a traffic light if you only go when it's green." While not technically true, these statements are reliable enough to influence you to avoid the 4th floor bathroom or drive through a green light. Similarly, the below text will make "never" and "always" claims that are accurate enough for BPs to be useful.)
In this discussion we'll make use of a couple tools from game theory: game trees and backward induction. If these concepts are new to you, I suggest taking a look at this introduction to game trees, which uses backward induction (but doesn't explicitly say so), as well as the wiki on backward induction.
First, we'll build our game tree. The first node is the beginning of our "game"&emdash;the creation of the BP by the payer. Each subsequent level represents a choice one of the players can make.
Each node with no children represents an end state to the game. Here we can see there are 5 end states:
Using backward induction, we will begin at the bottom row of the game tree: row C. This row represents the payer's choice in each case, so we'll view things from his perspective.
First, a couple notes:
In this outcome, the payer will establish a reputation for releasing a payment even if the worker does not complete the task. With such a reputation, lazy, incapable, or dishonest workers will be more likely to commit to the payer's future BPs. "After all," they might think, "he's released the payment for no work before; perhaps he'll do it again." Such a reputation would thereby decrease the future utility of BPs&emdash;we could say that the payer has been marked as an "easy target".
This is a negative outcome, to the extent that the payer expects to try to use the service again, because he will face a greater risk of attracting scammers or lazy/incompetent workers.C2: No work delivered; payer burns payment
Here, the payer establishes a reputation for burning the payment in response to a worker who does not complete the work. This will have an opposite effect of outcome 1: lazy, incapable, or dishonest workers will be less likely to commit to the payer's future BPs. "It didn't work the first time; it's unlikely to work next time." This would increase the future utility of BPs by dissuading such attempts.C3: Work delivered; payer releases payment
Here the payer establishes a reputation for releasing the payment in response to completed work. Like choice C1, this makes it more likely that a worker will commit, but unlike C1, it's only confident, honest workers that will be thus attracted. "He released for good work last time; therefore, it's likely he'll release again if I can do the work."
This increases the future utility of the BP mechanism for the payer.C4: Work delivered; payer burns payment
Like outcome 2, this makes others less likely to commit, but this time it's dissuading even honest, capable workers. This decreases the utility of future BPs.
A rational payer will never choose options C1 or C4. With the payment already spent, and the work already either delivered or not delivered, the payer will choose to build a reputation that makes any of his future BPs more successful.
In short, he will always choose to release for completed work, and burn otherwise.
This might seem like an underwhelming conclusion for so much work, but we now know what a rational payer will do in every single case, and can cross off certain outcomes as game theoretically impossible.
We can now move up a level, to row B.
At row B, the worker is looking at an Open BP and deciding whether to commit and, if so, whether to attempt to do the work. It's convenient at this point to define some variables:
We will assume the worker has modeled the payer as a rational actor. Let's see how each choice works out.B1: Worker commits but does not do the work
The worker must pay D to make this choice, and we know that the payer will respond by burning the entire payment, arriving at outcome C2.
Endgame worker payout: (-D)B2: Worker commits and does the work
Here the worker still must pay D in addition to paying the "cost of effort" E for actually doing the service. But in the next turn, the payer will release the payment, which includes both the original payment P and the service deposit D. Since D is returned by endgame, we can ignore it:
Endgame worker payout: P - EB3: Worker does not commit
This one's pretty simple: the worker pays no service deposit, doesn't make any effort, and doesn't receive a payment.
Endgame worker payout: 0
We can make a couple conclusions from this.
In no case is node B1 chosen, so we can cross it off, as well as its remaining child node.
With that, we can finally make an interesting statement about BPs.
When a payer creates a BP, anyone else considering committing will almost definitely make one of two choices:
So, why would a payer open a BP? Because if no one commits, he can recover the payment, and if someone does commit, there is a strong game-theoretical guarantee that the worker will complete the work. The higher the service deposit, the stronger the guarantee.
When analyzing row C of our game tree, we took into account the effect a choice would have on the payer's reputation. But if the payer is sure he'll never use BPs again, he won't care about his reputation. Indeed, he may not even bother to return to release or burn the payment, after the service is rendered. Why should he (other than to be nice)?
This is an issue because we can no longer logically assume the payer's final choice, row C, in our game tree, which means we can't analyze rows B or A either. To help alleviate this, BPs have an "auto-release" feature.
Auto-release is essentially protection for the worker against lazy payers, and has the following rules:
With these rules, if a payer never returns to the payment after a worker has committed, the payment will eventually release. A "lazy payer" would make our game tree look like this:
Of course, now we have another issue: a dishonest or incapable worker might now commit, counting on outcome C1. But this assumes that the worker somehow knows to model the payer as a "lazy payer." More likely, the worker will only suspect the payer might be lazy.
Even if a payer does not plan to use BPs again, he doesn't need to broadcast this information. Users looking at the open BP won't know whether to model the payer as a lazy payer who will never use BPs again, or a payer who is interested in building a good reputation. From the perspective of these users, we might draw our game tree like so:
Here, we've combined the analysis of row C from our first assumption (the payer will make a choice with a mind to his reputation) with the lazy payment assumption (the payer will not return to the payment at all). In both scenarios, outcome C4 will never be chosen, so it's crossed out and outcome C3 is not. But whether outcome C1 or C2 is chosen depends on whether the payer is lazy.
Now honest workers still have a clear route to payment: whether the payer is lazy or not, they can guarantee a positive outcome by doing the work.
Dishonest workers hoping for outcome C1 must decide if the risk is worth it. A payer can dissuade this by increasing the service deposit and forcing the scammer to risk more, and in general convincing users that they will indeed be back to cast a final burn/release judgement.
Finally, this is really only an issue for a payer's very first BP. As soon as they have a reputation showing the right burn/release behavior, users viewing their BPs can count on this behavior continuing with a very high likelihood.
We won't go into such rigorous analysis here, but we can still make some useful conclusions. What should a payer do, to maximize the utility of future BPs? Fortunately, a payer can choose to burn or release any part of the payment, giving him a more nuanced response than a binary punish/reward option.
For simplicity's sake, let's imagine the BP contains a request to mow the payer's lawn, and the worker does a bad job, leaving patches of tall grass.
Burning the whole payment would likely make future honest workers more reluctant to commit because they worry the payment might be burned if they're not "perfect". Releasing the whole payment isn't ideal either: this might be too much of a comfort, attracting workers who are not skilled and won't do a good job. A better response would be to burn part of it and release the rest, as well as log a payer statement explaining his reasoning (possibly including pictures of the issues). This way, future workers will know that mistakes will be punished, but not without mercy. Confident workers would still commit, but less confident workers will hesitate.
See the "No extortion attempts" section of this Medium article.
The concern here is that when a payer opens a BP, let's say with 3 ETH and a service deposit of 1 ETH, someone will spend 1 ETH to commit just to force the payer to burn the payment. As stated in this reddit comment, "So for 3 ETH I can force you to burn 15 ETH? Sounds like a good deal for me."
This only makes sense if someone both has money to spend, and has a really great time seeing a stranger's money go to waste on the Internet. Of course trolls abound on the Internet, but it's hard to imagine they'll be regularly shelling out real money just to confound someone's effort to spend money (although that might depend on what the payer is trying to buy).
In any case, to the extent that this is an issue, payers can just increase the service deposit amounts.