Could i vibe code this into existence, or would it need a ground up personal build
There's a few components to this that will creep the scope, but if you re-use stuff it should be manageable. Lighting.Pub could obviously provide the Lightning interface and is already nostr-native.
Some of the ideation may be ambitious, creates a lot of conditional logic, pare down to base functionally than expand later as needed.
Long lived nostr services are a bit tricky as nostr-tools really sucks at that, but its doable. Making it reliable is an order of magnitude harder than making it demo.
Depending on your architectural knowledge it may be fairly difficult, but if you have some good foundations or some help it should be doable in a few days.
Would highly recommend iterating in a coding tool with a planning mode. Cursor is good at this, use planning mode iteratively to really nail down an implementation plan with all the minutia before running code gen. Do this over days so you can look at it with fresh eyes a few mornings in a row.
What language would be best for the code
You'll need nostr-tools in some form so just stick with nodejs / typescript
If the bitbetbot source is FOSS i can fork it I assume?
sqlite should be adequate, use the better-sqlite node module.
Planning mode may ask if you want to use an ORM or query builder... in my experience the llms are better off raw-dogging SQL than using them.
If it really takes off and has growing pains with sqlite then upgrading to postgres will be trivial.
Gaming the System
Lightning.Pub accounts use atomic transactions and locks to prevent drainage attacks, but the application itself could still be gamed. You'll need to think carefully about house edge and ensuring the house can't lose if the game is sybil attacked.
You also may want to dynamically hedge your exposure with an external exchange if the market gets one-sided, that introduces an exchange API to market-make into your back-end.
Liquidity
Not a problem for me since users are just using their own sats, and Pub will programatically lease channels... though this is still in early stages and may require some touch with high volume.
The liquidity issue the game bot will face is what I mentioned above, one-sided markets, where for example you may be net short Bitcoin if a lot more users are betting HIGHER and few bet LOWER
a hard cap on a single winning bet
You may want safety conditions to freeze new bets altogether, or only allow one-side of the market if its out of balance. This may be wiser than jumping into exchange integration initially.
Regulatory/Legal
Not legal advise, but I'd view it as a prediction market, and would cap bet sizes so you've made a demonstrable effort to prevent abuse by people using it to mix or transmit to others
There's a few components to this that will creep the scope, but if you re-use stuff it should be manageable. Lighting.Pub could obviously provide the Lightning interface and is already nostr-native.
Some of the ideation may be ambitious, creates a lot of conditional logic, pare down to base functionally than expand later as needed.
Long lived nostr services are a bit tricky as nostr-tools really sucks at that, but its doable. Making it reliable is an order of magnitude harder than making it demo.
Depending on your architectural knowledge it may be fairly difficult, but if you have some good foundations or some help it should be doable in a few days.
Would highly recommend iterating in a coding tool with a planning mode. Cursor is good at this, use planning mode iteratively to really nail down an implementation plan with all the minutia before running code gen. Do this over days so you can look at it with fresh eyes a few mornings in a row.
You'll need nostr-tools in some form so just stick with nodejs / typescript
Quick search and I can't find the source
curl -s https://rates.shockwallet.app/v2/prices/BTC-USD/spot {"data":{"amount":"96187.195","base":"BTC","currency":"USD"}}(coinbase mirror)
sqlite should be adequate, use the
better-sqlitenode module.Planning mode may ask if you want to use an ORM or query builder... in my experience the llms are better off raw-dogging SQL than using them.
If it really takes off and has growing pains with sqlite then upgrading to postgres will be trivial.
Lightning.Pub accounts use atomic transactions and locks to prevent drainage attacks, but the application itself could still be gamed. You'll need to think carefully about house edge and ensuring the house can't lose if the game is sybil attacked.
You also may want to dynamically hedge your exposure with an external exchange if the market gets one-sided, that introduces an exchange API to market-make into your back-end.
Not a problem for me since users are just using their own sats, and Pub will programatically lease channels... though this is still in early stages and may require some touch with high volume.
The liquidity issue the game bot will face is what I mentioned above, one-sided markets, where for example you may be net short Bitcoin if a lot more users are betting HIGHER and few bet LOWER
You may want safety conditions to freeze new bets altogether, or only allow one-side of the market if its out of balance. This may be wiser than jumping into exchange integration initially.
Not legal advise, but I'd view it as a prediction market, and would cap bet sizes so you've made a demonstrable effort to prevent abuse by people using it to mix or transmit to others