Satoshi Dice -- Statistical Analysis

[ingrownpocket]

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

Code:

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

15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo	590 BTC
17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y	4036 BTC
1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV	1475 BTC
1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk	0 BTC
1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK	1371 BTC
1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah	9768 BTC
1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ	5080 BTC
1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric	800 BTC

Total: 23120 BTC ($447,140)

[Kryptox]

I've been searching around and can't find an answer to this so I apologize if this has been covered (I'm sure it has) but earlier in this thread there was a discussion about how SD cannot be rigged and it's provable.

How exactly do you go about verifying that the lucky number is calculated correctly from the Transaction ID?  How does the secret compute against the Transaction ID to produce the lucky number?

[ingrownpocket]

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

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)".

[Kryptox]

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?

[kgo]

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]

I'm a noob when it comes to cryptography.

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. 

[StarenseN]

...
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)

[ThickAsThieves]

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?

[dooglus]

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?

$ 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:

$ 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):

[dooglus]

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]

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.

[Bugpowder]

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]

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.

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).

[etotheipi]

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]

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.

[Bugpowder]

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

[etotheipi]

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.

[MPOE-PR]

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.

[Kryptox]

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?

$ 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:

$ 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.

[dooglus]

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.