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

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:

I don't know if that means they're up 2091 BTC but owe 2038 BTC in unreturned bets, or whether the 2091 BTC is profit.

Here's the latest output:

Emails are also always just emails, regardless of content. Still I consider some as spam and some not.

Ya, ... consider it progress though.   The old ways that were not future-proofed go by the wayside and new ways emerge.

You can run BitcoinSpinner instead, right?

This is just sick - I'm currently on very slow mobile internet and downloading hundreds of MB of SD spam TXs is leading up to a point where I'm currently considering very much not running a full bitcoind at all any more.

Just imagine having your internet line clogged for 1 hour or more EVERY DAY when booting up the PC and loading the latest blocks.

Just read this, very informative and interesting thread. Thanks for the statistics.

Sorry, I've been slacking.  I just updated it now.

SD went through a rather dramatic swing the past few days:  jumping above 1,500 BTC profit, and dropping back down to around 500.  A spurt of large bets (50-100 BTC each) may be responsible...

Also, I added a field "Profit only completed bets":  it's because there seem to be some freezing issues with the service, such that hundreds of BTC in bets are getting backlogged, and the previous "Profit/Loss" fields were including those as profit.

The third entry is now the important one:  of all the bets that have been fully processed, SD has made about 650 BTC profit so far.

Update OP?

I have always believed that this should be a priority, but many devs I've talked to insist that it's not.  I wouldn't mind pioneering this in Armory if I can ever get networking-independence...

I believe I came up with a solid way to not only prune, but also allow lightweight nodes to verify balances without downloading the entire chain!  Don't want to derail this thread, but I appended it to the Scalable blockchain thread.  I wouldn't mind seeing some more discussion about it (mine, as well as other proposals).