Satoshi Dice -- Statistical Analysis - page 41.

dooglus

legendary

Activity: 2940

Merit: 1333

Here's a summary of the recent big bets. I wanted to see how s.dice made its money back. The first line says "there were 17 winning bets of 10 BTC on lessthan 12000 and 125 losing bets with the same stake and target, making a net loss (for the player) for 506 BTC":

Quote

wins losses
------------------------------------------------- --------------------------------------------
count target stake profit total profit count target stake profit total profit net profit
------------------------------------------------- -------------------------------------------- --------------
17 <12000 10 43.35211333 736.98592661 125 <12000 10 -9.9505 -1243.8125 -506.82657339
2 <12000 20 86.70472666 173.40945332 8 <12000 20 -19.9005 -159.204 14.20545332

32 <16000 10 30.02646000 960.84672 77 <16000 10 -9.9505 -766.1885 194.65822
14 <16000 50 150.13430000 2101.8802 30 <16000 50 -49.7505 -1492.515 609.3652

18 <24000 100 167.01256666 3006.22619988 39 <24000 100 -99.5005 -3880.5195 -874.29330012
19 <24000 150 250.51910000 4759.8629 52 <24000 150 -149.2505 -7761.026 -3001.1631
2 <24000 200 334.02563333 668.05126666 6 <24000 200 -199.0005 -1194.003 -525.95173334
2 <24000 250 417.53216666 835.06433332 19 <24000 250 -248.7505 -4726.2595 -3891.19516668

84 <32000 100 100.38430000 8432.2812 72 <32000 100 -99.5005 -7164.036 1268.2452
74 <32768 100 95.69950000 7081.763 82 <32768 100 -99.5005 -8159.041 -1077.278
------------------------------------------------- -------------------------------------------- --------------
28756.37119979 -36546.605 -7790.23380021
------------------------------------------------- -------------------------------------------- --------------

The majority of the losses were on the lessthan 24000 bets. Here are graphs of the probabilities of the number of wins for 3 cases. In all 3 cases the actual number of wins is pretty far left on the graph:

stake 150 BTC, target <24000, 71 bets, 19 wins, 52 losses:

stake 250 BTC, target <24000, 21 bets, 2 wins, 19 losses:

stake (all 4 stakes), target <24000, 157 bets, 41 wins, 116 losses:

Incidentally, how's the font look in the table inside the 'quote' above? It's much easier to read than the one I usually use, but does it show up well for you too?

dooglus

legendary

Activity: 2940

Merit: 1333

Variance, eh?

Nice recovery just as the month's about to end...

Quote

Total of 16 bets unaccounted for.

Results: 2013-Jan-31 11:32am (up to block 218965)

   Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP
----------------------------------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 77415 | 0 (0.00000) | 76121 | 1294 | 797.55 | 0.01 | 104.64 | 797.53 | 0.002
1dice1Qf4 2 0.00003 | 3824 | 0 (0.00000) | 3325 | 499 | 62.95 | 0.01 | 17.04 | 62.94 | 0.020
1dice2pxm 4 0.00006 | 6062 | 1 (0.00018) | 5640 | 421 | 88.41 | 159.97 | 8.46 | -71.56 | 180.939
1dice2vQo 8 0.00012 | 8660 | 3 (0.00036) | 8231 | 426 | 131.05 | 176.01 | 10.03 | -44.95 | 134.301
1dice2WmR 16 0.00024 | 10544 | 1 (0.00010) | 10131 | 412 | 313.59 | 4.56 | 18.66 | 309.02 | 1.456
1dice2xkj 32 0.00049 | 11712 | 3 (0.00027) | 11315 | 394 | 626.52 | 303.62 | 1.36 | 322.89 | 48.463
1dice2zdo 64 0.00098 | 14508 | 14 (0.00099) | 14072 | 422 | 920.39 | 230.74 | 55.73 | 689.64 | 25.071
1dice37Ee 128 0.00195 | 16543 | 32 (0.00199) | 16079 | 432 | 1983.06 | 1416.66 | 48.32 | 566.39 | 71.438
1dice3jkp 256 0.00391 | 18259 | 83 (0.00464) | 17798 | 378 | 2275.21 | 3651.88 | 13.17 | -1376.67 | 160.507
1dice4J1m 512 0.00781 | 27139 | 204 (0.00771) | 26251 | 684 | 4465.82 | 4158.96 | 9.98 | 306.86 | 93.129
1dice5wwE 1000 0.01526 | 87191 | 1331 (0.01534) | 85411 | 449 | 23186.31 | 19657.87 | 1.95 | 3528.43 | 84.782
1dice61SN 1500 0.02289 | 20409 | 476 (0.02373) | 19582 | 351 | 6534.61 | 6608.00 | 15.07 | -73.39 | 101.123
1dice6DPt 2000 0.03052 | 51950 | 1595 (0.03093) | 49969 | 386 | 25838.70 | 23126.99 | 9.32 | 2711.71 | 89.505
1dice6gJg 3000 0.04578 | 23709 | 1080 (0.04637) | 22211 | 418 | 8622.55 | 9770.89 | 25.11 | -1148.34 | 113.318
1dice6GV5 4000 0.06104 | 29342 | 1778 (0.06137) | 27193 | 371 | 6679.21 | 6308.35 | 31.29 | 370.86 | 94.448
1dice6wBx 6000 0.09155 | 36526 | 3389 (0.09381) | 32738 | 399 | 14199.04 | 15917.82 | 7.15 | -1718.77 | 112.105
1dice6YgE 8000 0.12207 | 146457 | 17982 (0.12316) | 128021 | 454 | 72635.57 | 72942.95 | 100.24 | -307.37 | 100.423
1dice7EYz 12000 0.18311 | 60200 | 11009 (0.18424) | 48744 | 447 | 145406.48 | 148966.51 | 3314.67 | -3560.02 | 102.448
1dice7fUk 16000 0.24414 | 179703 | 43694 (0.24380) | 135529 | 480 | 332317.06 | 319177.29 | 2056.09 | 13139.76 | 96.046
1dice7W2A 24000 0.36621 | 176502 | 64752 (0.36795) | 111229 | 521 | 529202.23 | 525722.60 | 1012.97 | 3479.63 | 99.342
1dice8EMZ 32000 0.48828 | 929539 | 453083 (0.48817) | 475035 | 1421 | 752558.98 | 735657.23 | 2924.16 | 16901.75 | 97.754
1dice97EC 32768 0.50000 | 425912 | 212260 (0.49940) | 212771 | 881 | 573438.12 | 561459.76 | 5720.41 | 11978.35 | 97.911
1dice9wcM 48000 0.73242 | 271951 | 199617 (0.73547) | 71799 | 535 | 263250.74 | 257470.07 | 5454.88 | 5780.67 | 97.804
1dicec9k7 52000 0.79346 | 54270 | 42741 (0.79385) | 11099 | 430 | 55397.36 | 54229.66 | 1187.20 | 1167.70 | 97.892
1dicegEAr 56000 0.85449 | 40270 | 34073 (0.85619) | 5723 | 474 | 60871.21 | 60349.67 | 400.24 | 521.53 | 99.143
1diceDCd2 60000 0.91553 | 54469 | 49474 (0.91585) | 4546 | 449 | 56721.75 | 56317.52 | 0.22 | 404.22 | 99.287
1dice9wVt 64000 0.97656 | 13169 | 12152 (0.98063) | 240 | 777 | 22471.60 | 22076.80 | 239.70 | 394.79 | 98.243
----------------------------------------------------------------------------------------------------------------------------------------------
   small (bets < 4 BTC) | 2698994 | 1104976 | 1579702 | 14316 | 617222.65 | 604210.49 | 225.48 | 13012.15 | 97.892
   big (bets >= 4 BTC) | 97241 | 45851 | 51101 | 289 | 2343773.53 | 2301652.04 | 22562.70 | 42121.49 | 98.203
----------------------------------------------------------------------------------------------------------------------------------------------
   | 2796235 | 1150827 | 1630803 | 14605 | 2960996.19 | 2905862.54 | 22788.19 | 55133.64 | 98.138
----------------------------------------------------------------------------------------------------------------------------------------------

SD Profit before fees: 55133.64999467 BTC (1.862%)
Cumulative Fees Paid: 1994.43637500 BTC
SD Profit after fees: 53139.21361967 BTC (1.795%)
Pending Liabilities: -0.45667668 BTC
Final SD Profit: 53139.67029635 BTC (1.795%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 9101422 : SatoshiDice Tx: 5147181 (56.6%)
Blockchain MB: 3885.0 : SatoshiDice MB: 2113.9 (54.4%)

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: Kryptox on January 31, 2013, 04:36:25 AM

Thank you dooglus for explaining this so clearly! I didn't realize SD allows you to split a single transaction into multiple bets now. From what I understand, there was an update to the Bitcoin network not too long ago that doesn't actually allow you to use the exact same transaction ID twice.

It's not splitting a transaction into multiple transactions. It's putting multiple bets into a single transaction. If you're using the reference (satoshi) client, go to the 'send coins' tab and then click 'add recipient' a few times. That way you can send bets to many different satoshidice addresses in a single transaction. You can't send multiple bets to the same address using the standard client, but apparently can with some of the other clients.

Kryptox

member

Activity: 98

Merit: 10

Quote from: dooglus on January 30, 2013, 03:57:34 PM

Quote from: Kryptox on January 30, 2013, 10:25:26 AM

Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this?

EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice.

http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

003e -> 62

So that's lucky number was 62. How do you get from:

This
nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX

And this
38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

To this
003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

Do we just take it for granted that this is somehow correct?

Download and install Python. It's free, and comes with all the crypto libraries you need.

Then you can calculate lucky numbers for yourself, as follows.

Your example is from before the rule-change of Jan 3rd. Before then, all the bets in a transaction got the same lucky number. Here's how you would calculate it for your example (the bold parts are the parts you type). See how it spits out '62' at the end?

Quote

$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> txid = '38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8'
>>> secret = 'nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz'
>>> int(hmac.new(secret, txid, hashlib.sha512).hexdigest()[:4], 16)
62
>>>

For bets made after Jan 2nd 2013, the lucky number is different for each bet in the transaction, so you need to specify the output number (nout), as follows. Let's use a bet I made as an example, and calculate all 10 lucky numbers:

Quote

$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> txid = 'df7a5cb1ed439f1e0f314cfed88f77ab0f0fdf4a4d2e4714a8287834791fbd95'
>>> secret = 'DIGtgGbebAIjJeuh1tlzMW5Xzs8ds0V9azgs40JvWOd24NpFEttZEFM32OHgEqFd'
>>> for nout in range(10): print nout, int(hmac.new(secret, "%s:%d" % (txid, nout), hashlib.sha512).hexdigest()[:4], 16)
0 10351
1 37909
2 63099
3 19569
4 13550
5 36796
6 28032
7 53908
8 64653
9 36560
>>>

See how they match up with the numbers shown on the SD page (although the SD page shows them in the wrong order, it does now show the 'Idx' column so you can match them up):

Thank you dooglus for explaining this so clearly! I didn't realize SD allows you to split a single transaction into multiple bets now. From what I understand, there was an update to the Bitcoin network not too long ago that doesn't actually allow you to use the exact same transaction ID twice.

MPOE-PR

hero member

Activity: 756

Merit: 522

Quote from: Bugpowder on January 30, 2013, 04:32:44 PM

Amazing!

Over 1,100,000 BTC bet this month?!?

That is over TWICE last month's volume, which I thought was insane and unsustainable.

So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.

As long as we're sure there isn't a hole, yeah.

It's funny to me, because balance has been finally fully realized. Up until this point the only "s.dice is evil" theory was the "it's being fluffed" conspiracy. This would realize a net loss for the 90% shareholder, but arguably that is lower than whatever benefits incurred (publicity, whatever). Now we can have the corresponding "it's being skimmed" conspiracy. This would realize a net gain for the attacker, and a net loss for everyone invested in S.DICE (so both large and small investors are on the same side here). I imagine as the publicly held % varies over time the prevalence of (blind) conviction behind either of these will follow roughly.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: dooglus on January 30, 2013, 05:16:58 PM

There have been both types of double-spend in the last day or two. I've seen one instance of a zero byte (OP_FALSE) being prepended to the input script, but 3 instances of the signature itself being padded.

Both of these ways of changing a transaction's hash can be done by a 3rd party with no knowledge of the sender's private keys.

Agreed. My only point was that the one that involves non-standard transactions requires a much more resourceful attacker, since you can't just broadcast it. You have to know a miner who's willing to accept your non-standard transaction. However, padding the signature does not require anything special -- if you have a good connection to the person broadcasting, you can receive the tx, padd the signature with a zero byte, and forward the result to the rest of the network that hasn't seen it yet.

It will be "fixed" by the core devs trying to make such transactions non-standard: any signatures with excess zero-byte padding will be non-standard.

Bugpowder

sr. member

Activity: 394

Merit: 250

Quote from: dooglus on January 29, 2013, 04:42:58 PM

The high roller uses the following 8 addresses, by the way:

Code:

15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo
17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y
1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk
1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK
1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric

The 1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk address topped up the 1Di6ux address with a 4104 BTC deposit after it ran dry...

http://blockchain.info/tx/4fbce1a17a74947e8714fc43e2d17af36b243ab860ca94eb65f37da0f8de03a1

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: etotheipi on January 30, 2013, 05:04:11 PM

Bear in mind that it looks like (to me) that the tx was modified to only add an OP_FALSE to the input script. While this doesn't affect the validity of the transaction, it does make it non-standard, meaning that it's not as trivial as just (receive-modify-broadcast). In fact, for this to work, you'd probably need a miner to explicitly help mine it. That's one reason this is suspicious -- it's not just a conflicting transaction: it's a conflicting non-standard transaction that was mined anyway...

On the other hand, if I misread where that extra 0x00 byte was going and it was actually padding on the signature itself ... well that's exactly why sipa and gmaxwell have been trying to do: nail down unique representations for every serialized type in the transactions, and making anything that deviates from that non-standard. Then it would have the difficulties of the OP_FALSE description above: the conflicting tx would still be valid, but it would be difficult to propagate since no one would accept it by default.

There have been both types of double-spend in the last day or two. I've seen one instance of a zero byte (OP_FALSE) being prepended to the input script, but 3 instances of the signature itself being padded.

Both of these ways of changing a transaction's hash can be done by a 3rd party with no knowledge of the sender's private keys.

This old thread shows that the issue has been known about for a long time, but apparently isn't fixed yet.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: dooglus on January 30, 2013, 04:30:56 PM

Quote from: m0mchil on January 30, 2013, 04:08:03 AM

Quote from: dooglus on January 29, 2013, 04:42:58 PM

I don't really understand that double-spends page - I would expect it to show pairs of conflicting transactions, but it doesn't as far as I can see.

Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge.

I found that if I click on any of the transactions on the double-spends page it shows me a link to the corresponding double-spend transaction. I posted about 3 such transactions here, and retep replied, pointing out that these double-spends could have been made by anyone, not necessarily the big spender. I hadn't thought of that before, but it's quite interesting. Anyone can double-spend any transaction they see on the network by rewriting the transaction without needing access to the sender's private keys. It doesn't change any of the inputs or outputs, but it does change the transaction hash, and so changes the SD lucky number.

Bear in mind that it looks like (to me) that the tx was modified to only add an OP_FALSE to the input script. While this doesn't affect the validity of the transaction, it does make it non-standard, meaning that it's not as trivial as just (receive-modify-broadcast). In fact, for this to work, you'd probably need a miner to explicitly help mine it. That's one reason this is suspicious -- it's not just a conflicting transaction: it's a conflicting non-standard transaction that was mined anyway...

On the other hand, if I misread where that extra 0x00 byte was going and it was actually padding on the signature itself ... well that's exactly why sipa and gmaxwell have been trying to do: nail down unique representations for every serialized type in the transactions, and making anything that deviates from that non-standard. Then it would have the difficulties of the OP_FALSE description above: the conflicting tx would still be valid, but it would be difficult to propagate since no one would accept it by default.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: EskimoBob on January 30, 2013, 09:12:40 AM

Can you figure out, how and where did the coin get to those accounts?

I've looked in the past but got lost in the blockchain. There was no obvious source of the coins, just a bunch of addresses I didn't recognise.

Quote from: Bugpowder on January 30, 2013, 04:32:44 PM

So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.

The big loss wouldn't be such a concern if it wasn't paired with a bunch of double-spends on transactions from the whale's addresses. As I pointed out in the previous post, anyone can transmit double-spent bets by padding the signature of an input with an extra zero byte. They can do this only for bets that have won (or lost, depending on which way they want the graph to move).

Bugpowder

sr. member

Activity: 394

Merit: 250

Amazing!

Over 1,100,000 BTC bet this month?!?

That is over TWICE last month's volume, which I thought was insane and unsustainable.

So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: m0mchil on January 30, 2013, 04:08:03 AM

Quote from: dooglus on January 29, 2013, 04:42:58 PM

I don't really understand that double-spends page - I would expect it to show pairs of conflicting transactions, but it doesn't as far as I can see.

Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge.

I found that if I click on any of the transactions on the double-spends page it shows me a link to the corresponding double-spend transaction. I posted about 3 such transactions here, and retep replied, pointing out that these double-spends could have been made by anyone, not necessarily the big spender. I hadn't thought of that before, but it's quite interesting. Anyone can double-spend any transaction they see on the network by rewriting the transaction without needing access to the sender's private keys. It doesn't change any of the inputs or outputs, but it does change the transaction hash, and so changes the SD lucky number.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote

Total of 92 bets unaccounted for.

Results: 2013-Jan-30 12:51pm (up to block 218786)

Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP
----------------------------------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 77190 | 0 (0.00000) | 75898 | 1292 | 794.57 | 0.01 | 104.64 | 794.55 | 0.003
1dice1Qf4 2 0.00003 | 3819 | 0 (0.00000) | 3322 | 497 | 62.90 | 0.01 | 17.03 | 62.89 | 0.020
1dice2pxm 4 0.00006 | 6030 | 1 (0.00018) | 5608 | 421 | 87.96 | 159.97 | 8.46 | -72.01 | 181.860
1dice2vQo 8 0.00012 | 8656 | 3 (0.00036) | 8227 | 426 | 131.00 | 176.01 | 10.03 | -45.00 | 134.353
1dice2WmR 16 0.00024 | 10494 | 1 (0.00010) | 10081 | 412 | 311.63 | 4.56 | 18.66 | 307.07 | 1.465
1dice2xkj 32 0.00049 | 11583 | 3 (0.00027) | 11187 | 393 | 619.83 | 303.62 | 1.36 | 316.20 | 48.985
1dice2zdo 64 0.00098 | 13889 | 14 (0.00104) | 13455 | 420 | 887.34 | 230.74 | 55.72 | 656.59 | 26.004
1dice37Ee 128 0.00195 | 16175 | 31 (0.00197) | 15712 | 432 | 1954.53 | 1379.19 | 48.32 | 575.34 | 70.564
1dice3jkp 256 0.00391 | 17970 | 78 (0.00443) | 17514 | 378 | 2249.15 | 3542.76 | 13.17 | -1293.60 | 157.515
1dice4J1m 512 0.00781 | 26955 | 201 (0.00765) | 26071 | 683 | 4447.35 | 4122.08 | 9.98 | 325.26 | 92.686
1dice5wwE 1000 0.01526 | 86267 | 1318 (0.01536) | 84500 | 449 | 22933.29 | 19402.30 | 1.95 | 3530.99 | 84.603
1dice61SN 1500 0.02289 | 20369 | 476 (0.02378) | 19543 | 350 | 6530.84 | 6608.00 | 15.07 | -77.15 | 101.181
1dice6DPt 2000 0.03052 | 51463 | 1582 (0.03097) | 49495 | 386 | 25602.82 | 22872.34 | 9.32 | 2730.47 | 89.335
1dice6gJg 3000 0.04578 | 23694 | 1080 (0.04640) | 22196 | 418 | 8622.25 | 9770.89 | 25.11 | -1148.64 | 113.322
1dice6GV5 4000 0.06104 | 29297 | 1774 (0.06133) | 27153 | 370 | 6673.05 | 6287.39 | 31.28 | 385.66 | 94.221
1dice6wBx 6000 0.09155 | 36314 | 3376 (0.09400) | 32540 | 398 | 14193.64 | 15913.14 | 7.14 | -1719.50 | 112.115
1dice6YgE 8000 0.12207 | 145727 | 17882 (0.12309) | 127393 | 452 | 71680.20 | 71740.95 | 100.23 | -60.75 | 100.085
1dice7EYz 12000 0.18311 | 59724 | 10936 (0.18447) | 48347 | 441 | 143370.18 | 147417.44 | 3314.66 | -4047.26 | 102.823
1dice7fUk 16000 0.24414 | 178918 | 43498 (0.24377) | 134941 | 479 | 328033.09 | 314390.96 | 2056.09 | 13642.12 | 95.841
1dice7W2A 24000 0.36621 | 174521 | 64038 (0.36803) | 109963 | 520 | 503330.95 | 509788.75 | 1012.97 | -6457.79 | 101.283
1dice8EMZ 32000 0.48828 | 926538 | 451613 (0.48817) | 473506 | 1419 | 734450.90 | 716571.23 | 2924.16 | 17879.67 | 97.566
1dice97EC 32768 0.50000 | 422891 | 210756 (0.49941) | 211258 | 877 | 555106.22 | 543980.04 | 5720.40 | 11126.18 | 97.996
1dice9wcM 48000 0.73242 | 271032 | 198946 (0.73548) | 71551 | 535 | 262910.68 | 257133.39 | 5454.88 | 5777.28 | 97.803
1dicec9k7 52000 0.79346 | 53579 | 42195 (0.79387) | 10956 | 428 | 54896.71 | 53754.86 | 1187.20 | 1141.84 | 97.920
1dicegEAr 56000 0.85449 | 39908 | 33766 (0.85627) | 5668 | 474 | 58548.72 | 58077.37 | 400.24 | 471.35 | 99.195
1diceDCd2 60000 0.91553 | 54119 | 49144 (0.91567) | 4526 | 449 | 56642.49 | 56234.29 | 0.22 | 408.20 | 99.279
1dice9wVt 64000 0.97656 | 13137 | 12126 (0.98067) | 239 | 772 | 22469.29 | 22074.52 | 239.70 | 394.77 | 98.243
----------------------------------------------------------------------------------------------------------------------------------------------
small (bets < 4 BTC) | 2684278 | 1099463 | 1570533 | 14282 | 614337.60 | 601241.32 | 225.42 | 13096.28 | 97.868
big (bets >= 4 BTC) | 95981 | 45375 | 50317 | 289 | 2273204.12 | 2240695.62 | 22562.70 | 32508.50 | 98.570
----------------------------------------------------------------------------------------------------------------------------------------------
| 2780259 | 1144838 | 1620850 | 14571 | 2887541.72 | 2841936.94 | 22788.12 | 45604.78 | 98.421
----------------------------------------------------------------------------------------------------------------------------------------------

SD Profit before fees: 45604.78423613 BTC (1.579%)
Cumulative Fees Paid: 1978.33107500 BTC
SD Profit after fees: 43626.45316113 BTC (1.511%)
Pending Liabilities: 12.49110279 BTC
Final SD Profit: 43613.96205834 BTC (1.510%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 9057473 : SatoshiDice Tx: 5119162 (56.5%)
Blockchain MB: 3865.4 : SatoshiDice MB: 2102.1 (54.4%)

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: Kryptox on January 30, 2013, 10:25:26 AM

Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this?

EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice.

http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

003e -> 62

So that's lucky number was 62. How do you get from:

This
nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX

And this
38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

To this
003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

Do we just take it for granted that this is somehow correct?

Download and install Python. It's free, and comes with all the crypto libraries you need.

Then you can calculate lucky numbers for yourself, as follows.

Your example is from before the rule-change of Jan 3rd. Before then, all the bets in a transaction got the same lucky number. Here's how you would calculate it for your example (the bold parts are the parts you type). See how it spits out '62' at the end?

Quote

$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> txid = '38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8'
>>> secret = 'nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz'
>>> int(hmac.new(secret, txid, hashlib.sha512).hexdigest()[:4], 16)
62
>>>

For bets made after Jan 2nd 2013, the lucky number is different for each bet in the transaction, so you need to specify the output number (nout), as follows. Let's use a bet I made as an example, and calculate all 10 lucky numbers:

Quote

$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, hmac
>>> txid = 'df7a5cb1ed439f1e0f314cfed88f77ab0f0fdf4a4d2e4714a8287834791fbd95'
>>> secret = 'DIGtgGbebAIjJeuh1tlzMW5Xzs8ds0V9azgs40JvWOd24NpFEttZEFM32OHgEqFd'
>>> for nout in range(10): print nout, int(hmac.new(secret, "%s:%d" % (txid, nout), hashlib.sha512).hexdigest()[:4], 16)
0 10351
1 37909
2 63099
3 19569
4 13550
5 36796
6 28032
7 53908
8 64653
9 36560
>>>

See how they match up with the numbers shown on the SD page (although the SD page shows them in the wrong order, it does now show the 'Idx' column so you can match them up):

ThickAsThieves

hero member

Activity: 518

Merit: 500

I asked the owner about this topic a few days ago actually, and he convinced me that all that would happen if there were inside betting like this, would be that shareholders would eventually get all the money.

But, to run with this theory, this is only "harmless" fluffing of numbers if the whale loses. But, if the whale has a winning record, does that simply snake dividends from the 10% stakeholders?

I'm probably missing something here that makes this impossible, but if it's possible, there's essentially very little reason for the 90% stakeholder(s) not to constantly bet big on themselves, no?

StarenseN

legendary

Activity: 2478

Merit: 1362

Quote from: ThickAsThieves on January 30, 2013, 09:28:27 AM

Quote from: EskimoBob on January 30, 2013, 09:12:40 AM

Quote from: dooglus on January 29, 2013, 04:42:58 PM

...
The high roller uses the following 8 addresses, by the way:

Code:

15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo
17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y
1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk
1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK
1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric

You obviously know what you are doing

Can you figure out, how and where did the coin get to those accounts?
I still like my "idea" (more like a speculation) that this mysterious whale is sdice guy(s) himself and he is only trying to make sdice looks stronger and more profitable to possible future investors.
Only problem is, he "fucked up" and sdice "lost" a boat load of coin

Even if S.DICE was being fluffed, it would come at 10% expense to the "whale" while losing, because 10% of the dividends are public.

Anyone can bet what they want on the site, even majority shareholders with less to lose (because they'll see some of their losses come back thru dividends). This is only a problem if the odds are in the whale's favor, I think...

Actualy long term it's 10% of the house edge (=0.19%) given to stakeholders. So less tah 200$ lost for the whale every 100,000$ bet. That's cheap for a good advertising (even if i don't trust the conspiracy)

Kryptox

member

Activity: 98

Merit: 10

Quote from: Kryptox on January 30, 2013, 10:25:26 AM

I'm a noob when it comes to cryptography.

Quote from: kgo on January 30, 2013, 11:40:17 AM

You run the function yourself with the same inputs with a crypto library that you trust.

Thanks kgo. Do these crypto libraries exist somewhere on the net? I did a google search and yielded nothing.

kgo

hero member

Activity: 548

Merit: 500

Quote from: Kryptox on January 30, 2013, 10:25:26 AM

Do we just take it for granted that this is somehow correct?

You run the function yourself with the same inputs with a crypto library that you trust.

Kryptox

member

Activity: 98

Merit: 10

Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this?

EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice.

http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

003e -> 62

So that's lucky number was 62. How do you get from:

This
nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX

And this
38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8

To this
003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190

Do we just take it for granted that this is somehow correct?

ingrownpocket

legendary

Activity: 952

Merit: 1000

Quote from: Kryptox on January 30, 2013, 10:18:27 AM

How does the secret compute against the Transaction ID to produce the lucky number?

Quote

The lucky number used to determine the winner of games is simple. It is simply the first bytes of hmac_sha512(secret,txid:out_idx). That would be the secret string as the key and the transaction ID of your bet transaction as the data.

BTW, there's a error in SD site: "hmac_sha512(secert,txid:out_idx)".

Topic: Satoshi Dice -- Statistical Analysis - page 41. (Read 192914 times)