Hey everyone!
I'm working on php/sql code to display the results, but I also don't want to leave anyone hanging.
There were no winners in any of the games today! This means that now I will return all incorrect bets (wrong amount, there was one this week in the Match1 / .1 btc game), and also late bets (no late bets this week). All games will continue onto Round 2. All bets will remain in place, and all Game Addresses will stay the same. I will also put up new Target Blocks soon. When you see the text at the top of the page change to "Week 2" you'll know I made the updates. For the time being, if you would like to continue betting, please feel free, as bets are still going to the same addresses.
One thing I need to mention though.
I really really don't want to piss anyone off by changing things up a little bit, but I found a snag in the game methodology and I have to change something to make the system work. Let me explain.
- Players tickets are their bet's transaction numbers.
- Each game's winning number comes from the games target block, the transaction number of the transaction where the block's solver is paid the 50 btc.
To keep odds relatively low, I decided to use a base10 number instead of base16. The transaction numbers are all base16 (hexadecimal). So my idea was to convert the entire transaction number to a decimal number.
The snag I ran into today: The number resulting from that conversion is astronomical and beyond the bounds of the integer variable. And thus, I don't have a reliable method of getting a true decimal number from converting the entire hexadecimal transaction number.
SO, my implementation is changing to this: Instead of using the entire transaction number for the players ticket numbers and winning number, I am using JUST the last 10 digits (to keep with the theme of 10).
So, as an example, lets use this week's MATCH2 game for 1 btc bets (there was only one ticket sold):
----- PLAYER 1 bets 1 btc in the Match2 game
- The Player's transaction number (hex): 4baa76c33ca7f98753f276b32be735ccc1f5c8cc59dbc6f3f196ecd448a3c18d
- The Player's transaction number to use: d448a3c18d (just the last 10 digits from above number)
- The Player's number converted to decimal: 911751758221
- The Player's ticket number: 2-1 (last two digits of the above number)
----- The WINNING TICKET NUMBER for this game:
- Target Block: 125002
- Transaction number of the 50btc solve payout: 8549e135fc5b68d9a55456cdc5c7704a3bc0b0bff5b198e44e619e01632bf3b5
- Transaction number to use (last 10 digits): 01632bf3b5
- 10-digit hex converted to decimal: 5958792117
- WINNING NUMBER (last two digits for Match2): 1-7
Player1 had "2-1" and the winning number was "1-7". No match, so the game moves on to round two.
The player's ticket numbers will stay the same, but a new target block will be chosen (typically will be one week in the future).
When the new target block is solved, we will get a new winning number to compare to all previous and new bets.
Long explanation, but again, I'm being careful not to upset anyone. I know changing things after the bets are made is not a good thing to do so early on, but like I said, I found the snag only today, so it was clear I needed to do something.
I think this is fair, and, nobody matched this week, so it's not like anyone's getting paid out by this change.
What do you guys think, does this sound fair?
Will check back later for feedback. Gotta go bury my head back into the code
Results display links coming soon.
