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

Only defence to premined blocks seems to be to ensure payout is never more that 50BTC then there is no point withholding the blocks when you do win.

How about the potential that there are multiple wagers with the same transaction hash?  That would appear in the results.

 - https://bitcointalksearch.org/topic/m.883119

sha256(secret) has been published for all the secrets that will be used in the next 10 years, and the full output of HMAC is shown.  See this 'recent bet':

In a perfect world, the methodology is secure, and this would be extremely difficult.   Even with millions of bets there should be no way to reverse-engineer the secret from the HMAC operation, especially knowing only the last two bytes.  (is the full output of HMAC(secret,TxID) shown?)

It's my understanding that there has not been a lot of confirmed double-spend [attempts].  I could be wrong though.

But the world isn't perfect.  The machine holding the secrets and doing the calculations must be connected to the internet.  Maybe someone found a way to get the server to leak information.  I'm sure interested peoples have isolated a "direct" connection to this node, and even if they don't "hack" it, may be able to get useful information out of communicating with it.

Not very.  More likely is that they could double-spend their losing bets using pre-mined blocks, and only let their winning bets confirm.

If I control a lot of hashpower, I make sure that every block I mine contains a spend to myself.  Each time I find a block, I double-spend that transaction in the form of a "less than 512" bet at SatoshiDice.  I wait a few seconds to see if I win.  99% of the time I'll lose, but if I win, I throw away the block I mined and let my winning bet confirm, otherwise I submit it to the network as normal, causing the lost bet to never be confirmed.  By waiting to see if I win the bet, I risk my block being orphaned, but my expected win is enough to cover that risk so long I can bet high enough at SatoshiDice.

Is there any flaw in that system?  Have any steps been taken to stop it happening today?

how likely is it someone could brute-force the daily secret hashed and published in advance?

Depends on what his goal is.

My guess is that someone found a vulnerability and exploited it for 1000 blocks, and is waiting for the site to "refill" before doing it again.  The sequence of losses is just way too extreme over that 182k-184k region to be luck, unless it's based mostly on long-shot bets.  But from the previous postings, there haven't been a ton of long-shot bets..

Or the vulnerability was found and fixed.  I'm not really sure.  But as an attacker, it might be more beneficial to let the site recover and skim money instead.  So you get the benefits of running a gambling website without actually having to run one!

Here's the same thing but with dates instead of block numbers on the X axis:

Here's a graph of how the profit for the site has been at the end of each block since it started.  I don't know if it's bad luck, or if someone is cheating.



There was a reasonably big loss overnight.  Someone bet 5 BTC twice in the same transaction: 5 BTC on "under 1500" and another 5 BTC on "under 6000".  Both bets won.  This seems like a good way of partially evading the low maximum bet limits, since the same random number will be chosen for all bets in a single transaction.

Or someone is managing to roll back zero-conf losing transactions!

This satoshidice guy is pretty unlucky.

Good catch!

I just noticed that the script that generates the statistics doesn't know that you can send 0.0054321 BTC to an address to set the payout address for your winnings.  Around 10,000 bets have used this feature.

Making the script aware of this rule changes the output as follows.  Note that the 'Unreturned' amount is now much smaller.  The script was previously considering all bets which had their payout address set manually to be "unreturned".

I would think the space required is pretty much in proportion to the number of transactions, but I could count that too.  Unfortunately running the analysis seems to have messed up by blkindex somehow, so I'm held up while that regenerates.

What I wanted to find out was whether the number of outstanding transaction outputs was still increasing rapidly. If you plot a rolling average of the  increase in the number of outstanding outputs per new transaction, it peaked at nearly 1 last September, dropped to 0.25 around January, grew to 0.4 in April and has slowly declined back to 0.25 again.

It's difficult to make sense of, but unless that ratio goes into a steady decline, it means that the number of outstanding balances to track is increasing rapidly along with the number of historical transactions.  As I say, the data doesn't really show yet whether that's the case or not.  We're adding 20,000 to the number of unspent transaction outputs each week lately, but a year ago, when transaction volume was much lower, we were adding 50,000 a week.  If by some mechanism a node is storing only the unspent outputs, figure 70-80 bytes each, that would need 120MB, growing at 1.5MB / week.  Meanwhile the blockchain is growing by 100MB / week (that's a rough estimate, I'll try to get real numbers tomorrow).

Yes it is. It would be more relevant if you added two more columns TxBytes and TxBytesLeft. Those fields shouldn't simply count the transactions but the space required to store them. This will more driectly relate to the discussion in other threads.

Don't know if this is of interest to anyone -- growth in the block chain from the beginning of the year:

Block#    Date        Tx          TxLeft      Outputs    OutputsLeft
160651    2012-01-05  2141909     537489      4958838        1265195
161701    2012-01-11  2184208     530150      5058211        1256418
162751    2012-01-18  2231239     535105      5167264        1265877
163801    2012-01-25  2277606     544932      5275969        1281789
164851    2012-02-01  2322666     551070      5383353        1296623
165901    2012-02-08  2370911     560104      5497425        1314422
166951    2012-02-15  2430945     570340      5638086        1335083
168001    2012-02-22  2479948     581100      5754867        1355583
169051    2012-02-29  2524194     589006      5866066        1375399
170101    2012-03-07  2573735     597328      5992463        1395833
171151    2012-03-14  2615923     603458      6103448        1410601
172201    2012-03-21  2661845     613033      6217395        1431445
173251    2012-03-28  2706242     624443      6328060        1452971
174301    2012-04-04  2756117     633395      6449913        1471912
175351    2012-04-12  2809748     642169      6579808        1487912
176401    2012-04-20  2872153     650236      6729451        1505063
177451    2012-04-27  2929045     658588      6866321        1521086
178501    2012-05-04  2991166     668820      7014679        1541885
179551    2012-05-10  3087103     676173      7233590        1559496
180601    2012-05-18  3239737     684265      7569078        1576859
181651    2012-05-26  3469896     698220      8067651        1606888
182701    2012-06-02  3654532     708385      8474595        1629500
183751    2012-06-09  3877115     718799      8956077        1648213
184801    2012-06-16  4179254     738515      9623716        1678629
185851    2012-06-23  4407499     758333     10153165        1714365

To clarify: the last four columns are the number of transactions, the number with still unspent outputs, the number of transaction outputs, and the number of transaction outputs still unspent.  I hope it's accurate, the numbers look sane to me, and the code was fairly simple, but I could quite possibly have made a stupid mistake.

It's relevant to the various threads on scaling & blockchain efficiency.

I've not checked, but maybe it's not that they're not processing them, but that miners can't/won't keep up?  Either way it would show up the same on the blockchain I think.

Thanks dooglus.  I've been super busy and I accidentally deleted my most-recent updates to that script, and didn't feel like reimplementing it.  I've been too busy trying to get out the next version of Armory.

You got the interpretation right:  looks like SD is taking a really long time to process bets so there's a lot of unreturned bets piling up.

It looks like the 'Unreturned' amount needs to come out of the profits, meaning the site is still 200 BTC down.  This explains the increase in the house edge, I guess.

Here's how I think the picture really looks: