I think you missed the question I asked: When did you buy the license, and when did you become unhappy with it?

When did this happen? Did you buy a license from me, or from Daniel?

When you were given the code, you should've been given something in writing saying what you are allowed to do with it. For instance, when I sold a license, I told people they can do what ever they want as long as: * They do not distribute it. * They do not sell it  * They do not claim to be, or affiliated with bustabit

Once I sold that person permission in writing (aka a license), it's not like I can retract it. If you haven't been given such permission, I suggest you contact bustabit support and get it in an email as writing as irrefutable proof of what you're allowed to do with the source code.




When did you buy the license? And when did you first be unhappy about what you received?  I hope this isn't a  "I bought something in btc and now that the price of bitcoin went up through the roof .... so i'd like my bitcoin back"

Yeah, your recollection is right. There was a full postmortem somewhere in the bustabit thread, but I can't find it right now. But basically the guy found a (subtle!) bug in an unreleased feature (changing the auto-cashout mid bet) which allowed him to cashout just before the game busted.  I was extremely fortunate that the person who discovered this bug just wanted to claim a fair bounty and didn't try bankrupt me (which he easily could have).

Bustabit never had such a bug. In bustabit v1 there was a pvp bonus system which rewarded you for cashing out after other players, but before the crash. At certain times it was profitable to bet at 1.01x if the players you were playing against were going for high multipliers (i.e. not cashing out often). This strategy could be trivially be defeated by other players cashing out after you (e.g. 1.02x).

 However this was a very explicit part of the game, and there were never any bugs around it. 

Nice work! I'd suggest also offering something that people can run themselves, so they can verify the code is really telling the truth or not.


There's no need to upgrade the server to make it faster.  Jut track the latest game you've successfully verified, e.g.


So let's say you verify game 23:



Now if you want to verify game 25,  you only need to hash it 2 times and then check if matches `maxVerifiedGame`. If it does, then game 25 is verified. If it doesn't, then it's not.


Basically it's the same idea of a blockchain. When a new block(s) come in, you only verify the new block(s) there's no reason to verify the old ones all the way to the genesis block each time

Hm. So your original bitcointalk post is:  2023-10-26T02:26:40Z  but I believe bitcointalk gives you a grace window of 5 minutes to edit a post without showing it as edited? So that pushes us to potentially: 2023-10-26T02:31:40Z .


But the mined block time was 2023-10-26T02:26:57Z (which I realize is not necessarily exactly when it was mined).  And your archive of the seeding event is 2023-10-26T02:26:59Z which is actually 2 seconds after the mined bitcoin block time.


So while I'm sure you aren't cheating in your seeding event, it's also not obvious to me that you fairly picked a client seed either. I believe it might technically have been possible for you to post a seeding event, then once the next block was mined, edit your original post, then use archive.org to snapshot the post-edited page. Because this uncertainty exists, you've kind of defeated the purpose of the seeding event.  Had you picked a bitcoin block that was days (or at least, hours) ahead of time and widely dispersed details of your seeding event and methodology it could be obvious to see the client seed was fairly picked.
 

 

Sweet. A slight tangent, but it'd probably worth making an /invest-calculator that allows you to plug in a few variables:

* bankroll
* how much you are investing
* assume bankroll is static or not (i.e. if investors keep taking profits)
* average daily turn over
 (and more??)

And gives you the average outcomes of the investment. As it's basically a calculation that investors all repeatedly need to keep making to figure out if it's worth investing or not. And it'll probably make investors more responsive, as it's a lot easier to see expected outcomes.

Perplex0, never before have I seen someone with your persistence and your unwavering refusal to accept 'no'. You're wasting your talents here.  If only you could focus on something more productive, you could really one day become a premier stalker.

Fair enough. Although FWIW just because code is on github doesn't imply you can use it for what ever you want, you still need to follow the license

 The reality is you did pirate code without permission and outright plagiarized website copy even when it contained claims that were obviously not true. I only left my negative feedback, because instead of immediately apologizing you ignored the issue and acted like it wasn't real -- which is not exactly confidence inspiring behavior.

That said, I'm not trying to be a copyright police either, nor is it my intention to try punish you either. And not to drive too fine of a point on it, but the industry is now full of dozens of competitors who actually have an impeccable multi-year history.

The way I see it, plagiarizing website content looks a bit amateur but it's not really the end of the world. Copying pieces of available bustadice code obviously should have been something that shouldn't have been done, but I do get that it makes it a lot easier and would have given you a nice reference spec to test against.

However for me, the line is copying claims that aren't true:


 It diminishes the work that went into websites that actually put month of work into protecting players privacy. And honestly, I feel like it's harmful to be making claims like this.  One of the reasons bustadice doesn't just say "We do shit to protect your privacy" is because it's so easily confused with "marketing speech" and tries to go into how it works on a technical level. So it's a bit unfortunate you'd just copying language like that so unnecessarily.

I'd do a few bitcoin, but 50 BTC is pushing my comfort level a bit too much. But I'd try get Daniel (the owner) on the bustabit chat. He might do it, I got him to play me rock-paper-scissors for 10 BTC not that long ago.


One player picks a move (e.g.  rock) adds a salt  (e.g.    rock|ohpleasegodletmewinthisisretarded ) then hash it (e.g. 877d3360cad6c7308f6a1bd8ce670d4b0e873f673f19da6cb89ac6bb4065214c ).

They then share the hash with the other player (e.g. in the chat). The other player makes a guess (e.g. scissors).


Then the first player can prove he won by revealing the salted move (rock|ohpleasegodletmewinthisisretarded) otherwise it's assumed the second player wins.  Ties are redraws.

I think this thread should make it:

https://bitcointalk.org/index.php?topic=922898.0


It was the first time a multiplayer game was made properly provably fair, and introduced the idea of committing to a  hashchain which will get seeded by a (bitcoin) blockhash that has no yet been mined.

And since that time, it's now become somewhat of a standard being used dozens of times -- frequently on bitcointalk.

You're thinking about it backwards. Getting investors is super easy, make the perceived reward greater than the perceived risk. That's really all investors care about.

Most people don't know this, but before bustabit was the giant it is now -- there was a time the max bet was like $30 USD. It's better to start small, build up an audience and then if you want to start supporting whales -- it will be extremely easy to find investors after you're proven yourself and the need for more money.


If you want to succeed, you should be instead laser focused on players. What can you offer that the other big reputable sites don't, so that people want to switch to you?

Unfortunately your seeding event is missing one critical component: You didn't explain how you "interpret" a game hash. You should publish a function and game rules before the seed is picked. That way we know you can't tailor your interpret (i.e. hashToGameResult) function based on the future results

I have started and run a few successful bitcoin casinos, and offered consulting services for a couple other (e.g. first csgo casino I helped made >1M USD profit in the first month after launch). (Go through my profile for more information).

I offer consulting services starting from 1 BTC. That would be something like ~5 hours of my time, going over pretty high level stuff. I am happy stubbing out some prototype code (e.g. game concept maths, risk management) but I would not be writing any production code (i.e. you need your own dev team).

You mean: https://bustadice.com/bankroll_stats.csv ?

@Daniel on a side note, it'd be kinda nice to have a .html version (e.g. a formatted table) of those stats, right now the .csv is hard to read unless you import it into a spreadsheet

Oh man, there's been a *lot*. And so many different classes of bugs. I think all the big casinos have at one time or another had at least one serious incident.

iirc, the primedice issue was they initialized the server-seed (i.e. for provably fairness) using a hash (?) function with the-current-time as (the only?) input. This meant that if two users created a server-seed at the exact same time, they would have the exact same server seed. Then one of the accounts just needs to reveal the server seed, and the other can continue using it for betting.  [Don't quote me on that, that's just my recollection of a many-years-old incident]


I used to run a major bitcoin casino (bustabit) and under my watch there was a pretty serious exploit:

https://bitcointalk.org/index.php?topic=709185.msg9679169#msg9679169

In that thread there's a pretty detailed technical postmortem of the issue. And kindly enough, the hacker even shared the code he used for the exploit -- which was pretty cool.

It's been a few years since I've been involved in this sort of stuff, but to me it looks like a high-volume service that is sending out bitcoin (e.g. an exchange or casino). If I wasn't so lazy, I'd try analyze the time-of-propagation for the transactions and see if it matches my hunch.

Most coinselection algorithms (including bitcoin cores) are kind of designed for user-level wallets, so they are massively consolidatory in regards to wallet utxos. This naturally means when you start sending out a lot of transactions, you're going to often generate huge unconfirmed transaction chains. This easily results in problems because of the mempool limitations (e.g maxdepth type thing).

With bustabit, I spent a few months and wrote my own purpose-built coinselection system to avoid these problems, but for most people that's a lot too much work and it's easier to just do a hack like make transactions occasionally include multiple-change outputs. That would likely explain some of the of the DAG like graphs you see?

---

Edit: Looks like your website is one of the few that actually calculate cpfp fee rate correctly I'm curious if you have the code you use for that calculation available? I (personally) really struggled with this calculation, and the solution I have feels like it's 10x as complicated as what someone smarter than me would come up with.

This is almost a parody of a casino.

a) "bustabitwin" is quite literally the worst name you could have picked. It's so blatantly abusing the "bustabit" trademark, that it's virtually impossible for anyone to ever take you seriously. Yet it looks different enough that it's not even good for phishing

b) You've plagiarized large portions of bustabit, and then taken something you should have copied, the provably fair, and fucked it up with md5 and shit. (Note: MD5 has been considered cryptographically broken since 2008)

c) Your footer says "BRAND - ALL RIGHTS RESERVED"

d) I only read the first sentence of your "User Agreement" and it refers to yourselves as "www.our site"

I'd dig a bit deeper, but I'm just starting to feel like I'm kicking a dead puppy