A few months ago, I decided to dedicate a good portion of my free time to develop tools and services for the Bitcoin ecosystem.
I truly believe Satoshi created a liberating technology that has the potential to the empower millions around the world, and I want to contribute to that cause.
I have seen enough damage from governments to sit back and do nothing. It is time to take over and build solutions designed for individuals, valuing their privacy, security, freedom and sovereignty.
This is the start of my journey, I'm proud to announce BTRY.
BTRY
BTRY is an open-source accountless (daily) lottery that uses asymmetric cryptography to register bets/prizes, and the Lightning Network to send and receive payments.
Thanks to Bitcoin, cryptography and the Tor network, BTRY is:
- Globally available
- Permissionless
- Transparent and auditable
- Completely private
- Simple
On top of that, it offers instantly redeemable and hard money prizes!
Source code: https://github.com/aftermath2/btry
It requires a browser proxied through Tor to be accessed (like the Tor Browser). It can't be accessed through clearnet.
Getting started
All you need to participate is an ED25519 private key.
BTRY initially generates one randomly to ensure an uninterrupted experience, but is up to the user to keep it, enter a custom one or generate it using the UI.
The private key never leaves the client, its associated public key is used to identify your bets and prizes, and the signature is used to withdraw them.
The user should make sure to back it up, because it's the only way he can withdraw the funds. For greater privacy, it's suggested not to reuse keys on different lotteries.
Bets
Bets are submitted by paying invoices, the invoice amount is the number of tickets that the user gets assigned once paid (1 sat = 1 ticket).
A single ticket can win multiple prizes, all users participate for the 99.609375% of the prize pool. The bigger the bet, the higher the chances to win.
Any user can do any number of bets and they can be as little as 1 sat and as big as the capacity available.
In this lottery, ticket numbers are not chosen by the users but assigned sequentially. For example, if the prize pool is of 10,000 sats and the user submits a bet for 5,000 sats, he would get the tickets 10,001 to 15,000. If any of the winning numbers is between those two, the user is assigned a prize.
Prizes
Winners are announced daily at 00:00 UTC and the winning numbers are generated using cryptographically secure random numbers.
These are the prizes as a percentage of the prize pool:
| Place | Prize |
|---|---|
| 1st | 50 |
| 2nd | 25 |
| 3rd | 12.5 |
| 4th | 6.25 |
| 5th | 3.125 |
| 6th | 1.5625 |
| 7th | 0.78125 |
| 8th | 0.390625 |
| BTRY fee | 0.390625 |
All prizes expire after 5 days, this is to avoid having liquidity locked for long periods (automatic withdrawals may help overcome this).
Users can opt to receive notifications through Telegram in case of winning. Messaging service identifiers are stored for one week and permanently deleted after that.
Next steps
Although I present BTRY as a lottery, I would like it to become a platform that offers many services. Some of the features I'm looking to add in the next weeks/months are:
-
Battles (#9):Battles are a non-custodial PvP game based on HODL contracts where two players compete for a fixed amount of money.The funds are never in the hands of BTRY, it merely acts as a coordinator and decides which payment to settle (loser -> winner) and which one to cancel (winner -> loser).Initially, the idea is that both users choose one number between 0 and 1000, BTRY generates one randomly (using provably fair numbers) and the one that got it closer wins. In case of a tie, both invoices are canceled.However, the goal is to move towards other forms of deciding a winner, like real event outcomes. There has been demand for a sports betting platform based on Lightning and these technologies may be a great fit for that.
-
On-chain transactions support (#5): The ability to deposit and withdrawal using on-chain transactions could be really useful, especially because big prize pools may be cheaper to move on-chain than in lightning. The main issue is that without splices, it does require managing liquidity on both layers and paying the fees to move from one to the other.
-
Automatic withdrawals via lightning addresses (#11): To overcome the drawback of having a limited time to withdraw the prizes, a potential solution could be to let users specify a lightning address before the prizes are assigned so they are sent automatically if they win. On-chain addresses could be used as well if #5 is implemented.
And more... Feel free to leave comments on the existing issues and to open new ones if you would like to propose a feature request or report a bug.
Contact
I run the node aftermath, I'm looking for long-lived channels and actively managed nodes.
Minimum size: 2M. Private channels are rejected to avoid locked liquidity (this may change in the future).
I will be reading your feedback here and answering any questions. You can also contact me on Telegram at @aftermath02.
/dev/randomin linux).{url}/api/events?stream=eventsto the messages of type "payments" and receive updates every time a user makes a withdraw. All you will be able to see is the payment_id and status though.