The Ethbet whitepaper provides a large amount of background information and some specific architectural details of Ethbet. This purpose of this post is to further elaborate on the Ethbet platform, its protocol, and its architectural details, including discussing the extensions of the protocol.
If you’re interested in gaining a lot of in-depth knowledge in this area, consider reading not only the Ethbet whitepaper, but also the 0x Whitepaper at https://0xproject.com/pdfs/0x_white_paper.pdf as well as the Etheroll whitepaper at http://crowdfund.etheroll.com/etheroll-whitepaper.pdf. Both of these projects have a lot of similarities with Ethbet. The following section has been added to our whitepaper as well.
The Ethbet Protocol
The Ethbet protocol is a description of what information users need to relay to each other in order to signal their intent to bet assets. This protocol is open, meaning that it can be implemented and executed by any actor. There is no need to use a specific website, browser, or even medium of communication, as the information can be exchanged via any method including email, a forum post, or a physical message. In addition to this, the protocol is extendable in that it can be modified for use with not just Ether, but also with any ERC20 token on the Ethereum blockchain. This would allow users not only to bet with each other using Ether, but also any other Ethereum-based token. The original version and deployment of the Ethbet protocol will focus on Ether, leaving the option of arbitrary ERC20 token support for a later period.
The Ethbet protocol closely mirrors the protocol outlined in the 0x whitepaper, as the Ethbet protocol has almost the same goal’s as 0x’s: 0x intends to allow users to exchange tokens with each other, while Ethbet intends to allow users to bet tokens with each other. The following example demonstrates a scenario of two users using the Ethbet protocol to make a bet with each other. In this example ‘Maker’ is the user that offers a bet and ‘Caller’ is the user that accepts that offer:
1. Maker approves the Ethbet contract to access their balance that they intend to wager
2. Maker creates an offer to bet their balance, specifying their desired amount, edge and bet expiration time, then signs this offer with their private key, proving both their their ownership and intent
3. Maker broadcasts their bet via any medium. Theoretically the best place to broadcast a bet will be an Ethbet relay, but there is no reason why it cannot be posted on a forum or sent via an email, as it is only a string (text)
4. Caller reads the bet offer from Maker and decides they would like to call it
5. Caller approves the Ethbet contract to access their balance as well
6. Caller submits the Maker’s signed order to the contract
7. The Ethbet contract authenticates Maker’s signature, verifies that the bet has not expired and that the bet has not already been called
8. The Ethbet contract executes the bet and transfers the bet amount between the two parties based off of the outcome.
The primary method of communication with the Ethbet protocol is intended to be via relays, as outlined in the previous section. The full protocol description of Ethbet is not yet finalized, but the information and format of it will be relatively standard, containing the parameters of a bet (amount, edge, expiration, and later on, asset type), as well as the necessary information to secure it, such as a cryptographic hash function like SHA3 and an ECDSA signature from the private key of the participants.
Future Protocol Extensions
As decentralized applications are complex and more prone to critical security issues than conventional applications, the original scope of the Ethbet project is relatively minor compared to what it is capable of. The following is a list of additional features that are feasible to add to the Ethbet protocol:
- Allow bets to not only have an edge, but also a win chance (‘roll under/above’ values), with the won amount adjusting accordingly
- Allow not only Ether to be used for bets, but also any ERC20 token
- Allow different types of games to be played, potentially using state channels for games that are more complex and need to save a larger state (such as Poker), according to market demand
- Modify token incentives to encourage protocol adoption and use by third parties, for example by providing useful infrastructure for third parties that is mutually beneficial between to use them and Ethbet
There are a few other potential ideas that can be elaborated on at a later time. Ethbet has to start somewhere, and instead of trying to start as a jack of all trades, we have decided it is better to start with one thing, and expand our domain only after we acquire mastery of our original scope.