Pages:
Author

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

legendary
Activity: 2940
Merit: 1333
January 31, 2013, 06:18:48 PM
"if any": in the latest chart the black line hasn't caught up to the red line yet.

The red line is the expected profit, based on the bet volume so far.  The black line is the actual profit.  As you say, the black line didn't catch the red line yet, but that just means the overall profit isn't quite 1.9% of turnover (it's 1.86% of turnover).  So the site is performing a little worse than expected, but it's still doing amazingly well, and making huge profits.

(Note, the house edge hasn't always been 1.9%; it has changed a couple of times in the past.  And also note that the red line is the expected profit after transaction fees are taken into account, so a little less than 1.9% of turnover).
legendary
Activity: 2940
Merit: 1333
January 31, 2013, 06:07:12 PM
I prefer the old one. Not that there is much difference.

I was talking about the difference between these two:

Quote
New: asdsadasdad23101010 ... ?!"#%#$
Quote
Old: asdsadasdad23101010 ... ?!"#%#$

For me, the first one is much clearer.  The 2nd looks kind of grey, not black.  Here's a screenshot of how they look to me:

sr. member
Activity: 476
Merit: 250
January 31, 2013, 04:37:47 PM
can anyone make an educated guess about s.dice's profits this month (if any)?

About 20K BTC



legendary
Activity: 952
Merit: 1000
January 31, 2013, 04:06:15 PM
I always thought the 50.000 number is all-time profit not this month's profit.
You were right, the 'Final SD Profit' is the all-time profit.
member
Activity: 113
Merit: 10
January 31, 2013, 04:03:15 PM
"if any": in the latest chart the black line hasn't caught up to the red line yet.

I always thought the 50.000 number is all-time profit not this month's profit.

member
Activity: 98
Merit: 10
January 31, 2013, 04:02:35 PM
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.

Right, I realized this shortly after my response.  I don't actually play SD - I think I've maybe placed 2 or 3 minimum bets in the past but I'm finding the math behind it quite interesting, along with how they are relying on a hash to spit out a lucky number.  I suppose it's probably the best way to make the game provable for now.

I just happened to come across some of your posts on stackexchange.  Really enjoy reading your posts.

I read an interesting article regarding sha256 statistical patterns by Femtosecond, as well as a few other authors.  From what I gathered, SD could actually create an even larger edge for themselves by being selective in the hashes they decide to use.  Conversely, players could also be selective in choosing the transaction ID's they decide to actually submit to give themselves the edge, including possibly sending transactions ID's that hash out identically to previously calculated hashes.  That's my understanding anyway, and I'm not sure how that applies to hmac sha512 but I'd guess it would be similar.

I might just start playing SD! Wink
legendary
Activity: 952
Merit: 1000
January 31, 2013, 04:00:35 PM
can anyone make an educated guess about s.dice's profits this month (if any)?

December 31, 2012
Final SD Profit:            33274.25422617 BTC (1.879%)

January 01, 2013
Final SD Profit:            43115.08527065 BTC (2.342%)

Today
Final SD Profit:            53139.67029635 BTC (1.795%)
member
Activity: 113
Merit: 10
January 31, 2013, 03:57:53 PM
can anyone make an educated guess about s.dice's profits this month (if any)?
legendary
Activity: 952
Merit: 1000
January 31, 2013, 03:56:18 PM
Thanks for the graphs dooglus.

The guy really had a run of bad luck there  Lips sealed


BTW, both fonts:

Quote
New: asdsadasdad23101010 ... ?!"#%#$
Quote
Old: asdsadasdad23101010 ... ?!"#%#$

I prefer the old one. Not that there is much difference.
legendary
Activity: 2940
Merit: 1333
January 31, 2013, 03:37:38 PM
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?
legendary
Activity: 2940
Merit: 1333
January 31, 2013, 03:00:21 PM
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%)



legendary
Activity: 2940
Merit: 1333
January 31, 2013, 02:55:29 PM
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.
member
Activity: 98
Merit: 10
January 31, 2013, 04:36:25 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.
hero member
Activity: 756
Merit: 522
January 31, 2013, 04:31:10 AM
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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 30, 2013, 06:40:53 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.
sr. member
Activity: 394
Merit: 250
January 30, 2013, 05:27:44 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
legendary
Activity: 2940
Merit: 1333
January 30, 2013, 05:16:58 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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
January 30, 2013, 05:04:11 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.
legendary
Activity: 2940
Merit: 1333
January 30, 2013, 04:37:38 PM
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).
sr. member
Activity: 394
Merit: 250
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.
Pages:
Jump to: