While the described attack is relatively easy, there is still some effort involved and considering your game's current revenue it is probably not worth the time of anyone that has the knowledge necessary to carry it out. But if your game gains any traction and your system remains in this form it is virtually guaranteed that someone will attempt to take advantage of it, if only to prove a point.

Another point to consider is that cheating the system is not possible for an external attacker in the event that the house is already cheating by picking beneficial transactions.

The monetary value of the transaction need not be large. As long as Blockchain.info accepts the transaction the attack could be performed with just a few satoshi as well.

I care about Bitcoin gambling and its community and one could also argue that one has a moral obligation to expose potentially fraudulent deception. As a result I have no problem putting some effort into my posts. You on the other hand have ignored nearly all of the well-thought-out and detailed explanations of why your game is not provably fair, instead opting to stick your head in the sand and to resort to personal attacks.

Arguing with you is most likely futile, which I am well aware of, but I hope that potential players will be able to form an educated opinion on you and your site and avoid your game when they read this thread.



At the time of this writing it is Mon, 04 Jan 2016 06:27 GMT-0800 so your game could not have even occurred yet. I'll assume that is just a bug or a mistake and that the time you meant is 12:09:55 GMT instead.

Again, Bitcoin transactions do not have timestamps. It is impossible to determine when a received Bitcoin transaction was generated. What Blockchain.info is showing you is the time they received the transaction. This time can vary wildly from node to node. Take a look at the following table, which shows when different blockchain explorers received the transaction in question:


Notice that Biteasy received the transaction significantly earlier than Blockchain.info at 12:09:13, whereas BitPay and CoinPrism did not receive the transaction at all until it was included in the block at 12:21:14.

Even if you assume that Blockchain.info is an authoritative source of transaction timestamps (which they are not), there is no way for players to verify that you picked the last transaction before the end of the round or even that the transactions received were not generated by yourself in order to ensure a certain result.

The following three transactions were received by Blockchain.info at Mon, 04 Jan 2016 12:09:53 GMT:

• f52420afebdf771a39f8ee27b7600ed2217e0067842b1ead38b1e0b9ba8be77d
• 1cdcc435be42f8c1819d0ad344d79453770c68f7aab53f3fa8d1de2e63635022
• 880cf804f70a6a8064ba194dfc983fd733cd04a88727eec3ab3c148d8048da6e

What makes any of them more valid than the next? How are players to verify that the house did not pick the one which benefits it the most?

Also, if the game ended at 12:09:55, why did you use a transaction that was received at 12:09:53, rather than one of the two transactions (1, 2) that were received at precisely 12:09:55? And how can players verify that you did not broadcast the transaction you picked in order to ensure a win for a player you control?

The answer is that the deciding transaction and therefore the winning player may as well be chosen arbitrarily by the house. Your game is not provably fair. In fact it is worse than the previous one because now players have the opportunity to cheat other players if the house isn't already cheating.


You claim that it is not possible to generate transactions and calculate their ID without broadcasting them and that it is not possible to calculate a game's result using the last transaction's hash and the pot size, despite posting a code snippet that does just that yourself (granted, you seem to have only copied and adopted it from this thread rather than writing your own). It is safe to say that I have a better understanding of your "provably fair" system than you have yourself.

Feel free to address all of the points I have brought up this time. I doubt you will.

It is even worse than that: Since unconfirmed transactions are used to calculate each game's outcome, any valid transaction can be broadcast even if it has no chance of ever being confirmed. This effectively makes the attack free provided one has enough dust spread over a sufficient number of addresses.

Why do you believe this is not possible? How do you think cold wallets and offline signing work?

Here is a transaction that has not been broadcast in hex form:


In a real attack we would generate many more, for example 100, instead of just one.

---

The transaction ID of the above transaction is fa3c30c7821cdff2b191468bd5e9314f82d21d8dd27bc5e4548fcf4c512a2cb5. Note that it remains not broadcast yet we have just calculated its transaction ID. We can easily calculate the transaction ID for all of the unbroadcast transactions we generated in the previous step.

---

You do not know how to calculate the winning ticket on your own site? The necessary code was given by yourself in the first post in this thread and on your site's FAQ.

All we have to do is input the hash of the transaction we just generated—but still have not broadcast—and the total number of satoshi (let us assume 60.000 satoshi for example) in the pot into the LuckyNumberGenerator function:

---

Let's assume we want the player with the tickets from 6668 to 8334 to win. The previous code example can easily be expanded upon to find all the winning transactions among the one:


Because tickets 6668 through 8334 are 16.66 % of all tickets, we can expect approximately 16 of our 100 pregenerated transactions to cause us to win.

---

Transactions can absolutely propagate in less than a second, especially to a well-connected node like blockchain.info. Because cheating in the manner I am describing is possible even with longer propagation times as long as they are somewhat predictable I will not argue this point, however.

---

The order in which you saw the last transactions is completely meaningless as another node (one of your players trying to verify the fairness of your game, for example) might receive the same transactions in a completely different order than blockchain.info. As transactions do not have timestamps it is not possible to verify that the house did not pick a more favourable transaction that arrived at roughly the same time—although not last.

And even if transactions did have timestamps (again: they do not) it would be easy for an attacker to simply send several winning transactions to blockchain.info right before the winning ticket is chosen.

If you know the winner will be chosen in 10 seconds you can simply start broadcasting one of the 16 winning transactions we generated earlier every tenth of a second starting in 9 seconds. This virtually guarantees that the ticket you want is the winner.

---

Another player joining before the winner is chosen is not a problem as you now have an additional 10 seconds to start your calculations anew.


Neither luck nor magic have anything to do with this. Any run of the mill computer can make these calculations in the required time frame (10 seconds). In fact, I'm confident my mobile phone could do it.

If you cannot understand this simple concept you have no business running a Bitcoin gambling site.

The previous thread is to be locked, so I hope we can continue the discussion here.

Unfortunately the new system also does not offer provable fairness and potentially allows even players to cheat. This stems from the fact that the game result is generated from the number of satoshis in the pot and the hash of the last received transaction at the end of each round. Transactions can be generated in advance and later broadcast by anyone, which consequently allows the winner to be chosen at least for rounds with few players. A better explanation by another user can be found here:


I also urge you once again to start using SSL. Basic SSL certificates can be purchased for less than $5 per year or can even be obtained for free from Let's Encrypt, albeit with some effort. It is irresponsible to send your players' information in the clear, especially when money is on the line.

That being said, I do think it is laudable that you have recognised the that your previous system was not provably fair and are attempting to make improvements.

The site has switched to a new "provably fair" system, which the operator announced in a new thread. Of course they never acknowledged that their old system was not provably fair.

Unfortunately the new system is also flawed, perhaps even more so than the previous one, as dooglus explains in another thread:

This script has a negative expected value, as does any other script that disregards the bonus system. Running this script 24/7 will not "maximize your profits", instead it will ensure that you eventually lose your entire bank roll.

Programming and selling gambling bots is not reprehensible, but misrepresenting them as an "investment" is. And while you do not outright claim that your script is consistently profitable, you are certainly implying it. Potential buyers need to understand that this script is not a money machine.

Scripts in the strategy editor are executed on the side of the client. Consequently closing the browser will stop the script.

Any visitor to your site can clearly see that tickets are not randomly assigned, as I've already shown in this screencapture. The ranges in blue beside the players' names represent the tickets that a player holds. The n-th player to join will always hold tickets (n-1) * 10000/m +1 through n * 10000/m, where m is the total number of players. There is nothing random about it.

In addition, as I have also already explained, random ticket assignment would make it even easier and not harder to cheat with your current "provably fair" system:


Just to humour you I'll revise my explanation for that scenario:

The house generates the lucky number 6000 and an arbitrary number of legitimate players join the round. The house joins the round itself with a player they control and "randomly" assigns the winning ticket to that player, ensuring the win for the house.

If the ticket numbers were assigned to players randomly it would be easier—even trivial—for the house to cheat, not harder, because the house could simply "randomly" assign the winning ticket to a player it controls. There would be no way for players to verify that the tickets were indeed randomly allocated in your current system.

Instead, however, tickets appear to be split among players sequentially in the order in which they entered the game, as can be seen here.

This means it is not trivial for the house to cheat, but not terribly difficult either. Depending on the approximate number of players the house expects to join the round it will add its "puppets" at different points.

Let's assume that by counting how many players are currently online, how many participated in the last round and how many are able to participate in the next round, the house predicts that between three and seven players will join the round. Making accurate predictions within these bounds is fairly easy with the information the house has at its disposal.

Now the house waits for three legitimate players to join. If there are unexpectedly less players, the house simply passes and allows the round to end. If, on the other hand, three players A, B and C enter the round, the house will immediately also "purchase" tickets with three players D, E and F; which it controls, giving player D the winning ticket. Up to four additional legitimate players E, F, G and H can now join without the house losing the winning tickets.

Based on the houses earlier prediction, more players joining is unlikely. But even if an eighth legitimate player defies all odds and joins the round, causing the legitimate player E to now own the winning ticket, the house can simply add another eight puppets, giving the winning ticket back to the house and allowing more legitimate players to join without endangering the house's winning ticket. For all practical purposes this can be repeated as often as necessary. Alternatively, the house can simply prevent new players from joining the round past a certain point, for example by simply ignoring entries and blaming it on latency or bugs.

Such a winning strategy exists for every possible winning ticket.

TL;DR: The house can take advantage of information asymmetry by adding one or more fake players and thereby cheating the legitimate players of their winnings.

The lucky number is not picked (or at least the hash isn't displayed) until the first player purchases a ticket, but generally we are in agreement until here.



This is false. If the house knows the number is 10.000, for example, what stops it from waiting until new players are unlikely to join and then purchasing the winning ticket itself? The players would never know they've been cheated. This is the weakness I'm addressing in my previous post.



Again: I do not own bustabit, nor am I an administrator or a moderator for bustabit. My one post in bustabit's thread doesn't make me a bustabit admin any more than my four posts in this thread make me an administrator of your game.

I also don't believe that pointing out technical issues qualifies as "ruthless" in any way.

I am familiar with your "provably fair" system and I have considered it in the example given in my previous post. Hashing a few values doesn't magically make your game provably fair—there is a lot more to it. As I have demonstrated, players can still be cheated by the operator fairly easily.

Although I am not the owner or administrator of bustabit, I do not see how that would invalidate the evidence I have presented even if it were the case.

Please take the time to read and understand the example in my previous post. There is also the issue of not using transport layer encryption (SSL), which you have yet to respond to as well. Your refusal to address these problems is quite telling.

I am not here to "bash you", I'm here because someone—who turned out to be an owner of your site—kept and keeps spamming links to btc-raffle in bustabit's chat, so I decided to take a closer look. Was that not the intention? There's no such thing as bad publicity, right?

I did not say anything regarding your trustworthiness—although your behaviour does raise some red flags—, I said that your site is not provably fair despite claiming to be. The concerns I brought up are of technical nature and as such are not affected by whether you question my motives or trust me. In fact, anyone can easily verify my claims.

The correct response on your side would be to refute those claims with a technical argument (not attacks on my character) or make improvements to your game if necessary. Speaking of which, you should stop sending your users' login credentials in the clear and start using SSL, especially since you are handling customer funds. Transport encryption is a low-effort, high-value necessity that you owe your players.

This game is not provably fair and you are misleading your players by claiming it is.

Granted, by displaying the salted and hashed result before the game ends, you prove that the winning ticket (the "lucky number") was not changed based on subsequent wagers by players. However, there is no way for players to verify that the house isn't posing as other players. These fake players would have an obvious advantage since they know which games to enter and when to do so in order to win the pot with a high likelihood, thereby cheating the real players.

Consider this example:

• Player A purchases a ticket and the hash 5041f376ddcb15642ffecea159db207945c0dc0f8375fb9c4657b1b27b6b0e1eb4cd9a138939664 acd254839f15e70fd18e670ac814202aea4b860bd2aa56adb is shown.
• Players B, C, D and E also purchase a ticket.
• The game ends and the lucky number 9337 is revealed. Also, the salt 774eb411-8f95-4e65-b0cd-89c19d05f03b is now displayed.

Player D is having a bad run and he's getting suspicious, so he decides to verify the last game. He uses the formula in your FAQ and enters the lucky number and the salt. To his surprise, everything checks out. The hash is correct!

So, nothing to see here? Not quite. The house purposefully generated a lucky number near the end of the spectrum (from 1 to 10.000). After players B, C and D purchased their tickets the house decided that more players were unlikely to join, so it purchased the winning ticket itself, posing as player E, and thereby cheating player D of his winnings.

This is just one attack vector and I imagine a clever (malicious) site operator would be able to come up with more. In any case you cannot reasonably claim that the game is provably fair.

bustabit was written in JavaScript using Node.js. It's published under a permissive licence and you can view the source code here. The script engine that players use to write bots et cetera also uses JavaScript.