Quote from: btc-raffle.com on January 04, 2016, 12:15:20 PM

I first want to say i am very impressed on how much time you just spent attempting to make our undeniable provable fair system look any different than it is.

You are a highly skilled troll but the end of the day you are still just a troll. People can see you are 100% lying.

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.

Quote from: btc-raffle.com on January 04, 2016, 12:15:20 PM

Lets take this last games hash

Mon Jan 04 2016 12:09:55 GMT-0800
has won with 0.00080000 btc, had a winning chance of 88.89% and made 0.00009899 btc of profit.
LUCKY NUMBER: 1747

HASH: 1cdcc435be42f8c1819d0ad344d79453770c68f7aab53f3fa8d1de2e63635022

TOTAL POT: 90000 satoshi

now lets take that hash over to blockchain

Do you see this?
https://blockchain.info/tx/1cdcc435be42f8c1819d0ad344d79453770c68f7aab53f3fa8d1de2e63635022

Can you see the time stamp?
2016-01-04 12:09:53

Can you see the time stamp of the game?
Mon Jan 04 2016 12:09:55 GMT-0800

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:

Blockchain Explorer	Received Time (UTC)
Biteasy.com	12:09:13
ChainFlyer	12:09:49
Blockchain.info	12:09:53
BlockCypher	12:09:54
BLOCKTRAIL	12:09:55
BitPay	12:21:14
CoinPrism	12:21:14

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:

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.

Quote from: btc-raffle.com on January 04, 2016, 12:15:20 PM

Now do you understand how the provably fair works?

Or are you going to continue to troll?

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.

jlfvr

Posts

Merits