-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathexample.html
83 lines (80 loc) · 8.38 KB
/
example.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<title>TC | Example</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css">
<link rel="stylesheet" href="css/common.css">
<!--<link rel="stylesheet" href="border.css">-->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.0/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<script src="script/loadNavbar.js"></script>
<script src="script/example.js"></script>
</head>
<div id="nav-placeholder"></div>
<div class="container">
<div class="well" style="font-size:1.8rem">
<div class="alert alert-info">
<p>Note: the images in this page are a bit out of date; they refer to Burnable Payments as "BOPs" and show a slightly different interface.</p>
<p>Aside from these superficial discrepancies, the information below remains accurate.</p>
</div>
<p>Programmers are invited to follow along in the <a href="https://github.com/coinop-logan/coinop-logan.github.io/blob/master/BOP.sol">full Burnable Payment source code</a>, but the leading comments in the source code sum up the basic rules:</p>
<pre>...
//In the Open state,
//Payer can logPayerStatement() to add additional details, clarifications, or corrections.
//Anyone can become the Worker by contributing the serviceDeposit with commit();
//this changes the state from Open to Committed. The BOP will never return to the Open state.
//After this state change, Worker will never be changed.
//In the Committed state,
//AutoreleaseTime is set to (now + autoreleaseInterval).
//Payer/Worker can logPayerStatement() or logWorkerStatement(), respectively.
//Payer can at any time choose to burn() or release() to Worker any amount of funds.
//Payer can delayAutorelease() setting the autoreleaseTime to (now + autoreleaseInterval), any number of times.
//If autoreleaseTime comes, Worker can triggerAutorelease() to claim all ether remaining in the payment.
//Once the balance of the payment is 0, the state changes to Closed.
//In the Closed state,
//Payer and Worker can still log statements.
//If addFunds() is called, the contract returns to the Committed state.
...</pre>
<h1>A Simple Example</h1>
<p>Let's imagine the payer needs a transcript written for an audio recording. He is willing to pay 0.5 ETH for the service, and sets a <i>service deposit</i> of 0.1 ETH. He also sets an <i>autorelease timer</i>, which is explained later.</p>
<center><img src="https://i.imgur.com/VWYSMav.png"></center>
<p>For more guidance on what values to choose, see <a href="http://toastycoin.com/creatingbops.html">Creating Effective BPs</a>. This page is more of an overview of the entire life cycle of a BP.</p>
<p>After clicking "Create BP," it will be created within the next few Ethereum blocks and will be publicly viewable via the interact page:</p>
<center><img class="img-responsive" src="https://i.imgur.com/YDtQSI5.png"></center>
<p>The above image shows the payer's view of the BP. Other users don't see the "recover" button or the payer statement input form at the bottom.</p>
<p>Until and unless a worker is found, the BP is in the "Open" state. In this state, the payer can cancel the payment and recover the entire payment. He can also add more funds or log additional Payer Statements if he likes.</p>
<p>Meanwhile, other users are browsing through Open BPs looking for jobs they can do with service deposits they can afford.</p>
<center><img class="img-responsive" src="https://i.imgur.com/9lRpeTu.png"></center>
<p>If one of these users is confident they can do the work, they can pay the service deposit to become the BP's worker. The BP will now show a "Committed" state with the worker locked in. Additionally, the worker will see a "Worker Statement" form to begin communicating with the payer.</p>
<center><img class="img-responsive" src="https://i.imgur.com/JQBQMRD.png"></center>
<p>The BP is now in the "Committed" state. In this state, the worker is locked into the contract, and the payer can no longer recover the payment. Note that the committed BP is holding not only the payer's original payment, but also the worker's service deposit (in this example, 0.6 ETH in total).</p>
<p>The fate of this 0.6 ETH is decided by the payer. Although he cannot directly recover it, he can still choose whether to release the payment to the worker or burn it (as in <a href="http://toastycoin.com/example.html" style="cursor:pointer" data-toggle="popover" data-placement="bottom" data-html="true" data-trigger="focus" data-content="When ether is <i>burned</i>, this means it's sent to the address 0x0. Since no one can access any funds from this address, the ether is effectively destroyed—removed permanently from circulation." data-original-title="" title="">destroy</a>). He can burn or release in parts or all at once.</p>
<p>As you can see, the auto-release timer has already started counting down. This is really just protection from a "lazy payer." The payer can reset this as many times as he wants, up to the amount he specified upon BP creation (5 days, in our example). If the timer reaches 0, the worker will see a "Trigger Auto-release" button. This will release all remaining ether to the worker.</p>
<center><img class="img-responsive" src="https://i.imgur.com/0BlMWtp.png"></center>
<p>While in the Committed state, the worker and payer begin communication using the Worker and Payer Statements respectively. Because these statements are stored on the Ethereum blockchain, they are reliable, signed, permanent and unhackable. They are also a little expensive and public, so payers and workers may negotiate a private place to chat instead. In either case, the event log below the BP information will show their public actions:</p><p>
<center><img class="img-responsive" src="https://i.imgur.com/28Fsf9H.png"></center>
<p>If the worker provides the transcription, the payer can release the payment. If not, the payer can burn it. Once the entire payment has been either burned or released, the BP moves to its final state, "Closed."</p>
<center><img class="img-responsive" src="https://i.imgur.com/s57yVSi.png"></center>
<hr>
<p>BPs utilize game theory to strongly guarantee the following, assuming <a href="http://toastycoin.com/creatingbops.html">an appropriate service deposit is set</a>:</p>
<ul>
<li>Payers unwilling to pay for the job will never open a BP in the first place; therefore, each Open BP represents a legitimate opportunity for some capable worker to earn the payment.</li>
<li>A payer will only release the payment if the worker completes the job, otherwise the payer will burn it.</li>
<li>Only capable, confident workers will risk investing the service deposit to commit to a BP. The higher the service deposit, the more confident the worker must be.</li>
</ul>
<p>If you're interested in the details, see our <a href="http://toastycoin.com/gametheory.html">more rigorous exploration of the game theory involved</a>.</p>
<p>Otherwise, feel free to check out the <a href="http://toastycoin.com/browse.html">list of BPs</a> or <a href="http://toastycoin.com/create.html">open up your own BP</a>!</p>
<hr>
<p>Finally, let me point out that because BPs are nothing more than a specific kind of smart contract, anyone else can create other kinds of interfaces or tools for BPs. As long as these other tools follow the same <a href="https://etherscan.io/address/0x38b394cd27c3b0d865f58a4512b65c7b0ab6db66">BP Factory contract</a>, the pool of BPs will be shared as well: a BP created by any one interface would be reflected on all of them.</p>
<p>For example, one could create:</p>
<ul>
<li>A server that monitors BPs and emails users when a BP's state changes (the server could charge X ETH per Y notifications)</li>
<li>A more advanced search/browse utility, to filter through the total pool of BPs</li>
<li>A bot that responds to BPs of a given format, to provide some automatic service</li>
<li>A specialized interface that creates BPs for some specific use-case</li>
<li>A tool that analyzes and aggregates data for specific Ethereum addresses, facilitating reputation research: how much has a given user released vs burned? How many BPs have they used?</li>
</ul>
</div>
</div>
</body>