Toasted Money
Conclusions from my Burnable Open Payments stunt
Burning Money
A couple weeks ago, I pulled a stunt on the Ethereum subreddit. Here’s the post:
I ran the stunt under an alt, u/ethist, a brand new account with no history. I did this to demonstrate that the success of the experiment doesn’t rely on any reputation or social context. So to clarify now, I am both u/ethist and u/coinop-logan.
I opened by burning 1 ETH — sending it to the unspendable ethereum address 0xdead. This did a two things:
First, like walking into a room with a business suit, it was an immediately obvious sign that I was serious. It elevated me above a simple troll in terms of credibility, just like the suit would elevate me above a surfer with shorts and flip-flops. It’s a sort of proof of expense, and gives the reader a reason to pay attention. Without this kind of credibility, I believe readers wouldn’t have cared enough to try to understand the counterintuitive, unconventional concepts laid forth in the post, possibly ruining my chances of front-page visibility.
Second, the burn simply opened the reader’s mind to the possibility that a deliberate and public destruction of money can, in some cases, serve the burner.
Then I introduced the concept and code for Burnable Open Payments (BOPs):
The code of this contract is extremely simple. There are certain incentives and guarantees the BOP can boast: a scammer can’t profit, and a recipient is incentivized to deliver a satisfying product.
The Stunt
I opened three BOPs, each with a different service requested and different payments and commitTheshold values:
- Spraypaint some grafitti
- Develop a simple android app
- Create infographics about these BOPs
- Solve some technical difficulties involved in verifying the BOP contract source on etherscan.io (I opened this one shortly after the post was written)
In total, these four BOPs held a total of 15.5 ETH.
Two of the BOPs were filled successfully, and two had no action. Here are the BOPs on etherscan.io.
The first one to be filled was the source verifying one, and one could say it was the most “real”. The others were somewhat artificial examples, constructed primarily as demonstrations. But this last BOP was created because I’d run into technical issues linking the source code of the contract on etherscan.io. It was an unexpected problem I was desperate to fix quickly but couldn’t figure out, so I put 0.5 ETH into a new BOP with a commitThreshold of 0.1 ETH, explained my request and linked to the contract, and went to sleep. The next afternoon, I logged on to find that u/veoxxoev had committed the 0.1 ETH to become the recipient, and verified the source code for me. I released the total 0.6 ETH held in the payment. I had the problem solved, and u/veoxxoev had 0.6 ETH back after depositing 0.1 ETH initially.
The second one to be filled was the infographic request, and the images above are the fruits of the payment. The recipient committed the 1 ETH but didn’t contact me at all until he had completed the infographics. What an odd feeling to have done business with a person I’d never met.
After he produced the first version, I released most of the payment. We then began communicating through the payerString and recipientString variables in the BOP, and later used temporary chat rooms. I requested some revisions for spelling, grammar, and rewording, then released more when he delivered a revised version. I burned 1 ETH, as he did not complete all of the requested service. But he was professional and pleasant to work with, as well as up-front about not having time to complete the last bit of work. I ended up releasing 5 ETH. I had my infographics, and the recipient gained 4 ETH and got back his initially deposited 1 ETH.
For the BOPs with no action, I signed up as my own recipient and called the release() function, thereby recovering the 10 ETH in those payments. Note that this recovery was only possible because no recipient had yet committed.
After this fund recovery on the no-action BOPs, I spent a total of 6.5 ETH, including the initial burn in the beginning of the post. This gained me the infographics above and the service of solving the technical difficulties involved in linking the BOP sources.
Immediate Findings
I consider this a success, both in terms of services rendered for ether spent and in terms of experimental results of the stunt. Here are the immediate findings:
No “troll burns”
A commonly raised point was the possibility that someone might commit to be the recipient without intending to deliver the service, just to force me to burn the money. The somewhat dubious reasoning was “So for 3 ETH I can force you to burn 15 ETH? Sounds like a good deal to me”. This didn’t happen.
No extortion attempts
Nick Johnson raised the more valid point of possible extortion attempts. An attacker could commit to be the recipient, then refuse to do the service but offer back some of the payment if it’s released to him (a smart contract could even be used to ensure the extortioner delivers). From a purely game-theoretical point of view, in a single iteration of this game, it would then be rational for me to agree to release the payment and receive part of it back, since the attacker has blocked any other recipient from committing and providing me the service.
My response was that in multiple iterations of the game, it becomes rational for me to refuse extortion attempts and burn the money, because this action disincentivizes further extortion attempts.
In any case, no extortion attempts were made. For each of the two committed recipients, the service was rendered satisfactorily in a timely manner.
No incapable recipients (mostly)
Another concern was the possibility of a recipient committing to the BOP, but being unable to deliver on the request satisfactorily.
For the source-verifying BOP, this didn’t happen — the recipient committed and delivered the service before I even noticed anything had happened with the contract at all.
For the infographic BOP, the recipient delivered graphics I’m happy with, but only completed two of three points I wanted him to illustrate. In this case, I wouldn’t exactly call the recipient incapable, but at the same time, I didn’t get all the value I asked for in my initial service request. Still, I consider the 2 infographics a good value for the 6 ETH I spent on the BOP.
BOPs Feel Magical
Using these BOPs, I contracted two services, and there are a number of things I didn’t need to do:
- I didn’t need to generate a good reputation or spend any effort trying to convince anyone I was honest. As shown in the second infographic, the fact that my ether was placed in the BOP proved my commitment to paying for the service. The fact that I was effectively anonymous was not a barrier to business.
- I didn’t need to painstakingly specify in legalese or smart contract code the exact requirements of the services. I only needed to describe my request in human-readable language, and be clear as to my burn/release policies. This completely skips the often-encountered problem of getting a smart contract to judge real-world results, or the alternative problems of legal loopholes or poorly worded contracts.
- I didn’t need to understand the steps required in solving the problem, and I didn’t need to know what skills the service provider needed. I only needed to be able to judge the degree of completion of the task.
- I didn’t need to find a service marketplace that suited my needs, and didn’t need to worry about whether the requested service passed any third party’s judgement of what is or isn’t allowed.
- I didn’t need to search through candidates, judging the ability and trustworthiness of each. In fact, in the case of the infographic BOP, the first version was delivered without any communication at all.
- I didn’t need to involve any arbitrator role, such as an escrow third party, a judge, or lawyer — any of which would have their own subjective judgments and introduce their own kind of uncertainty into the transaction for both me and the recipient.
Any other method of paying for a service would require some or all of the above steps. With a known associate, 1 applies at the very least. With Fiver, Elance, and similar sites, 4, 5, and 6 apply, as well as 3 to some degree. 2 applies to any situation in which a contract is used to specify or judge the completion of the service itself (whether legal or “smart”).
All I had to do with these BOPs was specify the service in plain English, instantiate the contract with funds and an appropriate commitThreshold, and wait. Later I decided how much to burn and how much to release. That’s it.
A BOP is a kind of receptacle you can throw your money in, write up a service request, and sit back and wait. Later, if you’ve put enough money in, you’ll find that a recipient has committed and is already at work convincing you to release the payment — theoretically by providing the service.
If the payment is too low to incentivize any committed recipients, you can just recover the payment — your burnable money isn’t really “spent” until a recipient has claimed it by committing. So at any given moment, either you have someone directly incentivized to serve the request who is likely able to do it, or you can recover the payment.
Conclusion
There are two points worth making.
First, burn-capable smart contracts deserve further research and experimentation. These BOPs were able to ensure incentives and suggest motivations with extremely simple smart contract logic, and this is a consequence of the fact that some logic paths in the contract led to complete or partial burning of the funds. It’s impossible to directly profit from a burn, and because the payer always has this option, a scammer is unlikely to enter into the contract.
Second, and more importantly, this 100-line smart contract and a Reddit post were the only tools I needed to conduct real business, over the Internet and with no trust or reputation at all. I might have asked for a research project or study to be done, a product to be fabricated in a machine shop, or even for a direct deposit of fiat currency into my bank account for the amount held in the BOP. With enough ether in the BOP and an appropriate commitThreshold, is there any reason to suspect these services and many others certainly wouldn’t be filled?
My point is not that BOPs are the killer app, or that they’d work every time and for every circumstance. Instead, my point is that a contract as simple as a BOP was the only interface I needed to spend my ether in a new way, with less hassle than any other method, and with satisfying results.
If these BOPs worked once, what other simple contracts might we construct to begin spending and earning ether in new ways, immediately? Maybe constructing a decentralized marketplace is the wrong way to approach the problem — maybe we don’t need a marketplace at all, so much as we need new kinds of payments and a way to publicize them.
I’ve started a subreddit to do some more research and experimentation along these lines: /r/dapplab. Come join in! See what your ether can do — or see what you might do to earn ether.
