Topic: SatoshiDICE.com - The World's Most Popular Bitcoin Game - page 237. (Read 495957 times)

Maybe you already know, but if you like you can split your bet in a single transaction.  Put half on <2000 and half on <3200, and you'll get the same lucky number for both bets.  It seems like quite a common thing for people to do; you can bet on all the bets at once if you like - there seems to be no limit.

Just want everyone to know that I won playing less than 3200 with a number of 1834... and to think I was so tempted to bet for below 2000...

If you're going to spam or hijack a thread, try to be more creative at least.

If you like Satoshidice, you should play Minefield!

Looks confirmed to me?

my last desperate 6BTC shove got stuck.. please help


http://www.satoshidice.com/full.php?tx=87c447d37647646dc5ba21b22775f94554dfe284975d1b9697238b1120106c6f

Looks like it has been paid out now.  Enjoy your 8 cents. 

http://satoshidice.com/full.php?tx=bab69ae0cf20c8818bcdababc013c351f995538a7cd916bd120f1b3821d1189a

This one is stuck as well.

Hey can I ask you guys to upvote this? Reddit's "day of" is focused on gambling today, so this is a good way to expose them to Bitcoin and SD.

http://www.reddit.com/r/RedditDayOf/comments/100red/heres_bitcoin_casino_satoshi_dice_named_after/

So far this month, players have won more than the house    

Well that was annoying.  But thanks for the payments.  I just got mine today, about 5 days late.  There were even two small payments in there that I didn't know were missing.

This whole wait was really to my benefit.  It kept me from betting for 5 days.  Not betting is the best way to not lose money.  I keep trying to win big but it's just not happening.  I've been up 40 BTC and have been down 120 BTC.  Right now I'm down 60 BTC which is quite a bit lower than my expected loss.  I am so close to not ever betting again.  Yet as soon as I got the money back today I placed another bet and won back 0.5 BTC.  I think my strategy for now will be to not bet more than 1 BTC a day.

I would like to explain a recent bug that has been plaguing our system and how it was corrected.

In our system we have a database of all transactions that relate to Satoshidice.   We also track their status (pending, confirmed, unknown).  We get a handful of transactions that were broadcast but never end up confirming.  After 24 to 48 hours we delete them from our system and move on.  There was an issue where the status of the transactions was not being recorded correctly.  So we would occasionally delete a transaction thinking it was hopeless when it actually confirmed some time ago.  Then the outputs spend for that transaction would be marked available and used to pay other transactions.  The more I ran the recovery process to clean things up, the more of these ended up getting created.

Now I have a separate safety check that checks an external repository of confirmed transactions before deleting anything.  This has been running for about 3 days and seems to work very well.

The other thing that happened that led to a large amount of unconfirming transactions was around Sept 8th we ran out of confirmed funds.  We try to always pay winners with confirmed outputs so there is no problem getting them confirmed and they are not dependent on anyone else's transactions.  Well, we ran out of confirmed and started paying with pending funds.  This of course didn't go well and a bunch of payment transactions had to be deleted and reprocessed.

We of course have alarms on confirmed funds and were notified as it was going down but Erik was traveling and I don't have access to the reserve funds so there was not much I could do, other than later run the recovery and cleanup tasks to get everyone paid.

No but you expect what is likely and ignore what is EXTREMELY unlikely.
BTC was designed well ...

Again, you've missed the point ...
I know how 0confirms work (and that SD uses 0confirms)

The point is "if" SD takes note of problems and stop propagating them or not?
The SD code is not based on the bitcoind code, so they may or may not have handled txn processing exactly the same and may have missed simple checks to avoid this?

Yes a double spend cannot be identified immediately, but it is certainly known VERY soon afterwards otherwise the double spend WONT work (I'm not referring to a "block withholding" double spend)
So SD should be keeping an eye out for such things since it does 0confirms - to stop going into a spiral of uncommitted transactions that will never commit.

Once a true double spend actually occurs, all the transactions based on the first failed txn of a double spend transaction, will NEVER commit. ever.

... and a double spend done by withholding a block is a very risky thing to try since you can lose 50BTC if you don't time it right ... and it is not something you can do often or easily and certainly wont make you lots of money with SD ...

All in all, double spends are extremely unlikely to cause anyone problems unless they don't keep track of transactions properly as is done in bitcoind ... and is also a good reason to write software that is a module added onto the standard bitcoind code ... it's very easy to add a module of code yourself ...

There's no good way to know if a transaction will ever make it onto the blockchain.  Even if you see it in a block it's possible that block will end up orphaned, and the transaction could end up being invalidated by the block which replaces it.

So if you want to be able to pay out winners without waiting for a bunch of confirmations, you're sometimes going to be at risk of paying out using transactions which will never confirm.  Unless you have a big enough hot wallet that you always have some old coins sitting in reserve to pay people out with.

When you have the kind of volume that SD has, I guess the coins in your hot wallet don't have a chance to get very old.

Update.. just got paid!

No - it's a design flaw to be paying transactions with transactions that will never commit ... if they are double spends.

As I said:

The payout transactions don't appear to exist anywhere.  For example, look at http://www.satoshidice.com/full.php?tx=7a1b4e1101385046795ef4518e6f037a35fab939c102faf72e9461fa11df6385 - it claims that the payout was made in tx http://blockchain.info/search?search=58cdc16b3e009203fd2da56c11490109be63e1aa5f27d94cee40304556dd29eb but blockchain.info says that transaction doesn't exist.

I don't know if it's a design flaw to use 0-conf inputs to pay out winners with.  It would certainly be preferable to use more confirmed inputs if possible, but maybe they do, and this problem we're currently seeing only happens when there aren't enough confirmed inputs available.

Hopefully - not the excuse.
That's just a design flaw your talking about there which I doubt is part of SD ...

If there is a double spend, for the 2nd transaction that doesn't get into a block, all the transactions based on it will NEVER get into a block.
You can't 'fix' a transaction, you can only create a different one that then new transactions can build upon.

If the design flaw is there in SD, then it will be identified by the transaction number of the winning payment changing to a new transaction (though it can change for other reasons)

You can, however, detect the cause of the problem - follow the transaction tree back and look for 2 that use the same source - one will be in a block and the other will be a pending/orphan transaction
or, follow the transaction tree back and look for transactions that don't exist any more.

yeah I guess that makes alot of sense! I guess im just eager to get my winnings! 

I don't know if I'm really lucky but all in all with SD and BTCDice I have won about 83btc 

I think there's a reason for that.  When you lose, the only input required to 'pay you out' is your own bet.  You know you didn't double-spend your bet, so the payout goes through quickly.

When you win, however, your payout is made up of your bet plus lots of bits of change that SD had in their wallet after paying out losing bets.  That change depends on the losing bets themselves not being double spent.  If any of the losing bets turns out not to be valid then the change from paying them out also won't be valid, and so your winning payout also won't be valid, since it depends indirectly on a double-spent losing bet.

The bigger your win, the more inputs it's likely to take to make the payout, and so the more chance you have of your payout depending on an invalid coin.

So SD's wallet will contain a bunch of transactions that they think are valid, but which will never confirm.  That's probably why it takes so long for these bets to get paid out - someone has to go in and manually tidy up the wallet.

I'm only guessing about all this, based on what I can see in the blockchain.  But I expect it's not too far from the truth.