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

Actually, the fees are computed along with everything else, and included in that number.  As of my latest post:


The latest win/lost difference is 225.72 BTC, and then they've paid 25.06 BTC in fees to execute the payouts.   It appears they've paid slightly more than you would expect in fees... which with the above data would be 24.9305, but the script found 25.062 in fees paid.  Not a huge difference, but it means that some transactions must've had more than 0.005 fee.  Perhaps there were a couple winning payouts that required creating huge transactions and required larger fee.  I would have to assume the fee logic is included and automatically adjusted appropriately...

EDIT:  I see you figured it out before I finished posting   Oh well, I'll leave this post here...

And that's not including the fees it pays on each payout,right?
 46518 X 0.0005 = another 23.259 BTC

[Edit: I overlooked in the OP, fees were included in that 250 BTC total.]

It looks like whatever the problem was, it's fixed now.  Or very close to fixed.  I just re-ran my script, and there's 100% accounted-for on almost all rows.  Any remaining are probably live bets that naturally haven't had time to be paid out.

If I had anything to do with that getting fixed (like the script or tx list), I'd ask for a donation.  But it looks like SatoshiDice is now down 250 BTC with all the extra payouts    Not the best time to lobby for donations...

Two of my bets are listed on your list of unreturned bets. (5BTC and 1.9995BTC)

Hope I get a reply eventually

--TE

Erik,

Sorry for being out of the loop, but are you part of SatoshiDice.com?  I have no idea who's running it, I just know all the transactions are public and it's "easy" to collect the statistics.  And I like statistics

It looks like the site is down about 80 BTC total since it started.  Though, that number seems to fluctuate significantly -- statistically speaking it takes a long time for a 1% edge to prevail over the statistical variance of the game and 80 BTC is small compared to the 18,500 BTC wagered so far...

I am curious what happened to that 1% of unreturned transactions.  In case you want it, I posted the list of all unreturned transactions to my public dropbox folder.

I will tell you it's a negative number so far which has totally ruined my week

etotheipi - I'll have the developer check on your info, thank you for the analysis.

I dug a little deeper to find out if the unaccounted-for bets are a real issue with the SD service, or if it's a bug in my script.  I got my script to print out the list of unaccounted-for bets and then I randomly selected 4 of them.  Sure enough, block-explorer says those wagers have not been redeemed yet.  (I doubt anyone cares about the full-list, but I can give it if you're interested):

http://blockexplorer.com/tx/968a692ab98b1f275c635c76be003ab1db9740d0b62f338b270115342ca42f5b
http://blockexplorer.com/tx/931fbfc921291aaa8a4cd3d26e71f513143ddcd3ae97da37ed6db1266a9058fd
http://blockexplorer.com/tx/7719d3f8c1bacd64b8e38a76c6ab1d5f4071ecc06fce82f7409d6a4ec265504b
http://blockexplorer.com/tx/fbb636d434b556cb1c6ae80e0e5a76eec05fb7c85ab7fffcf90fdb5b40b56987


--The sum of all unaccounted-for wagers is 85 BTC.  I didn't do statistics on how that 85 BTC was distributed, so it's tough to tell how much they should've statistically paid out on these 85 BTC.  If they were all losing bets, SD would've paid out another 0.85 BTC.  Upper limit cannot be investigated without more work...

--I would hypothesize that for these 500 of 47,000 unrewarded bets, that they were paid out in another way.  But my previous scanning watched for return tx to the first sending address of the wager transaction, and I got the same results.  This means, that at least there was no automated payout.  Luckily the number of these is low, so probably don't skew the statistics too much, except for the 1dice3jkp which is missing 6% of the bets!

--I also rescanned just since block 179,000 to see if they have gone away (suggesting that it was an early bug in the service).  That's not the case.  There's still plenty of unaccounted-for bets in the last 800 blocks. 

--Therefore, it seems that SatoshiDice occasionally doesn't return bets!  I suppose it is possible that these bets are manually executed after a user does not get his payout and contacts the service.  However, there's no way to know for sure.

By the way, the cumulative wagers at the bottom do include these unrewarded wagers.    The "Cumulative Rewards" is probably artificially low.  SD is probably either slightly more red, or should be if they had to pay out on those unaccounted for bets.

Google docs have a quite nice API and you could use a spreadsheet there as input data for a graph/chart that would then get auto-updated every 15 minutes or so...

...but you should really rather work on Armory!

Finally!  Computed total profit/loss for SatoshiDice.  Looks like luck is not really working in their favor at the moment...




I forgot that all SatoshiDice bets are returned by spending the wager transaction, which is what I should've been searching for when scanning the blockchain.  So I modified the script to search for wagers and then subsequent spends of those wagers...and I got the same results.  Still a few that aren't accounted for, but those shouldn't substantially skew the results...  I suppose it's possible that they were transactions lost during debugging before SD was officially released...? 

For now, I need to get back to Armory development.  But I will keep this table/data updated daily, and eventually add confidence intervals and possibly localized statistics (last week, last 24H, etc).  Possibly figure out how to start auto-updating...

Good question!  I'll add that to my script... as soon as I finish releasing Armory 0.76 (which will hopefully be tonight!)

I will have to expand the script a little bit, to be able to determine transaction fees.  But it can be done...

So how much profit has satoshidice made so far?

It seems I'm a little late to that conversation.  But it seems to me that the most basic attack for an arbitrary individual is simply trying to broadcast competing transactions at the same time.  But if there's any chance for it to succeed, it has to be done right away before you know if you've won.  Thus, you'd invalidate half of your losers and winners.  Other attacks, while possible, are generally reserved to a select few people who have > 1% of mining power, and to bets that are significantly over the maximum bet rate right now and would not be worth it.

On the other hand, I could see that the time delay could allow SatoshiDice to queue up a few transactions, and rearrange their ordering to try to maximize the number of losing bets made.  They have pre-scripted, verifiable secrets, but there's no way to prove the order in which they received certain transactions.  If this were the case, it would be reflected in the stats...

Btw, I love the SatoshiDice concept.  I really like the transparency of it, too.  It's a very elegant, open setup that gives me confidence they are legit.  But you don't know for sure until you do some hard number crunching

P.S. -- I just updated the table.  About 35k bets total as of midday May 10.  And the stats looks fairly consistent with expectations...

But if I can double spend (e.g., Finney attack) to invalidate only my losing wagers, did I really lose?

See:
 - https://bitcointalksearch.org/topic/m.882919

My script uses the list of 24 addresses from satoshidice.com.  I do not track all addresses that start with "1dice", only the ones from that site.  So that's not an issue.

I thought all reward transactions included the wager transaction as an input.  Thus, if someone invalidated the wager by double-spending, they'd also invalidate the reward transaction.  And thus it would be pointless.

There are 24 specific 1diceXXX vanity addresses that SatoshiDice generated for their service.

Anyone can create their own 1diceXXX address as well, but that doesn't have any impact on the statistics for those 24.

There is one attack method I'm aware off ... send wagers that are too low (below the minimum) or too high (exceed the maximum) and thus the site sends a refund by returning the payment (and pays the transaction fee, mind you).  The service has ways to deal with that if it becomes a problem (deduct the fee before sending the refund, for example).

The other problem is the dust-like wagers.  The minimums are small enough that the site loses money on the smallest wagers due to transaction fees for the return payment.  That too can be adjusted should it become a problem.

But any transfer within the accepted range is a wager, and thus gets played and the return transaction created.   I can''t think of anything further that this third party could do (or why) to mess with the site.   (well, the Satoshi Dice site does describe other attack vectors, but they are precise and require double spending using Finney attack or other methods.)

Do you already have an account at Seals? The only thing easier for me to donate than bitcons is Seals chips!

a quick basic question: would it be possible for any third party to alter these statistics if he was generating 1diceXXX vanity addresses and sending random transactions around?

So how many bets a day are they running at?

I thought they started around the 27th April, so based on the 30k you found that is 18 bets (so 36 transactions) a block!

So this one site is responsible for the jump in transactions:
http://blockchain.info/charts/n-transactions-per-block

And I guess the jump in fees:
http://blockchain.info/charts/transaction-fees?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

Once I fill it up a little more (with localized statistics and confidence bounds), I might modify the version of Armory I'm running to leverage the already-loaded blockchain.  That way, I can recalculate all the stats every 5 min and update a plot somewhere...

Why?  I don't know...  because I'm a statistician and I can.  

I guess I spent of lot of months online playing poker, and spent time on the 2+2 forums doing similar analysis to try to identify players or phenomenon that were suspicious.  I guess it's one way to keep the gambling sites honest...