Bitcoin Forum
December 04, 2016, 06:30:56 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 254 »
  Print  
Author Topic: SatoshiDICE.com - The World's Most Popular Bitcoin Game  (Read 398489 times)
dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
September 13, 2012, 04:49:55 AM
 #701

its strange that it only seems to be my big winning bets that are blocking  Undecided 

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.

1480876256
Hero Member
*
Offline Offline

Posts: 1480876256

View Profile Personal Message (Offline)

Ignore
1480876256
Reply with quote  #2

1480876256
Report to moderator
1480876256
Hero Member
*
Offline Offline

Posts: 1480876256

View Profile Personal Message (Offline)

Ignore
1480876256
Reply with quote  #2

1480876256
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480876256
Hero Member
*
Offline Offline

Posts: 1480876256

View Profile Personal Message (Offline)

Ignore
1480876256
Reply with quote  #2

1480876256
Report to moderator
1480876256
Hero Member
*
Offline Offline

Posts: 1480876256

View Profile Personal Message (Offline)

Ignore
1480876256
Reply with quote  #2

1480876256
Report to moderator
1480876256
Hero Member
*
Offline Offline

Posts: 1480876256

View Profile Personal Message (Offline)

Ignore
1480876256
Reply with quote  #2

1480876256
Report to moderator
xblitz
Jr. Member
*
Offline Offline

Activity: 32


I see what you did there!


View Profile
September 13, 2012, 05:13:05 AM
 #702

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  Smiley
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 13, 2012, 05:40:11 AM
 #703

its strange that it only seems to be my big winning bets that are blocking  Undecided 

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.
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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
September 13, 2012, 05:51:51 AM
 #704

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.

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.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 13, 2012, 06:55:25 AM
 #705

...
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.
No - it's a design flaw to be paying transactions with transactions that will never commit ... if they are double spends.

As I said:
Quote
That's just a design flaw your talking about there which I doubt is part of SD ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
xblitz
Jr. Member
*
Offline Offline

Activity: 32


I see what you did there!


View Profile
September 13, 2012, 02:39:32 PM
 #706

I now have 3 transactions that are unknown!   I hope this will get solved soon...  its strange that it only seems to be my big winning bets that are blocking  Undecided 

http://www.satoshidice.com/full.php?tx=7a1b4e1101385046795ef4518e6f037a35fab939c102faf72e9461fa11df6385
http://www.satoshidice.com/full.php?tx=a4eb369ffde29a3cd83b94d52480876024f1da40ad0e4f1571e87f0bdfc76f0f
http://www.satoshidice.com/full.php?tx=4d773e005cb9f48336d02f7f81218044da3dace275b11a86e6e5767148114856

for a total of about 42 bitcoins!  thats alot of money that I currently cant use...  why does it take so long for him to fix those?

Update.. just got paid! Smiley
dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
September 13, 2012, 04:26:27 PM
 #707

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

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.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 13, 2012, 09:58:45 PM
 #708

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

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.
No but you expect what is likely and ignore what is EXTREMELY unlikely.
BTC was designed well ...

Quote
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.
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 ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
fireduck
Sr. Member
****
Offline Offline

Activity: 366



View Profile
September 14, 2012, 10:32:30 PM
 #709

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.
sgravina
Sr. Member
****
Offline Offline

Activity: 442



View Profile
September 14, 2012, 11:34:22 PM
 #710

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

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.
evoorhees
Legendary
*
Offline Offline

Activity: 994


Democracy is the original 51% attack


View Profile
September 15, 2012, 03:52:09 PM
 #711


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

evoorhees
Legendary
*
Offline Offline

Activity: 994


Democracy is the original 51% attack


View Profile
September 17, 2012, 02:30:13 PM
 #712

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/
Chimsley
Jr. Member
*
Offline Offline

Activity: 38



View Profile
September 17, 2012, 06:04:26 PM
 #713

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

This one is stuck as well.
dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
September 18, 2012, 07:46:15 AM
 #714


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

korila
Member
**
Offline Offline

Activity: 107


View Profile
September 22, 2012, 04:07:02 AM
 #715

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


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


evoorhees
Legendary
*
Offline Offline

Activity: 994


Democracy is the original 51% attack


View Profile
September 22, 2012, 05:46:36 AM
 #716


Looks confirmed to me?
TradeFortress
VIP
Legendary
*
Offline Offline

Activity: 910


View Profile
September 22, 2012, 06:17:03 AM
 #717

If you like Satoshidice, you should play Minefield!
evoorhees
Legendary
*
Offline Offline

Activity: 994


Democracy is the original 51% attack


View Profile
September 23, 2012, 11:37:12 PM
 #718

If you like Satoshidice, you should play Minefield!

If you're going to spam or hijack a thread, try to be more creative at least.
rynmln
Jr. Member
*
Offline Offline

Activity: 49


View Profile
September 24, 2012, 05:52:33 AM
 #719

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...

dooglus
Legendary
*
Offline Offline

Activity: 1988



View Profile
September 24, 2012, 06:41:51 PM
 #720

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...

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 254 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!