Please post details of your alleged 46 bitcoins, and I'll get it sorted for you. But frankly I think you are mistaken.
Yes i to would like to see the outcome of this 2nd claim. I have never heard of it previously and I try to monitor the gambling forums very closely (when time permits). I expect it's lies spread by an associate of a SatoshiDice clone to try to steal more of their business. There's no evidence of a 46 BTC bet being unprocessed. |
|
|
|
I would like to setup an account, here is my private withdrawal address so anyone can track how much I have taken out. Also I will post here every time I make a deposit so you guys know how much I have sent in too, the general time, and with some deductions can track every transaction.
Kthnx.
Just post the first deposit amount and date. We can take it from there.  |
|
|
|
[newb]
Re:the brain wallet tab:
Is there a minimum recommended passphrase ? Are 30 characters enough?
[/newb] thanks!
And further: is bitaddress.org the only way to recover the private key, or are there alternatives?
bitaddress is just doing an sha256 hash of the brain wallet passphrase to get the private key, and then encoding it into wallet import format in the standard way. So creating an alternative would be trivial. I don't know of existing software that will do the job, but it probably already exists. For the first step: $ echo -n 'abcdefghijklmnopqrstuvwxyz 123' | sha256sum
daa0f2bcf5f0ea99d3df46a07af6202f781ff46016ce14b94b66eee000b0056b - |
|
|
|
on the new brainwallet tab, i updated my local copy to say input type="password". perhaps you could think about this for the next revision.
people probably aren't using this in public, but might still feel better not having their phrase shown on the screen.
That's a good point. I think it's worthwhile to have the ability to toggle show/hide for passphrase text. I'll add that to the next version. Maybe also the option to have 2 boxes where I can type the passphrase twice, have it not show up, but have an indication of whether I typed it the same both times. I understand some people might want the passphrase displayed on-screen, so they can check whether they typed it right, but for those who don't want it displayed it's useful to have a "type it again to make sure" box. |
|
|
|
The missing payment is for 62.6235 BTC, not 50 BTC. He accidentally made a 50 BTC bet when trying to withdraw from MtGox to his own wallet due to a copy/paste error, but that is unrelated to this problem. |
|
|
|
There is an alternative to SatoshiDice, it's BTCDice(.com), which is a S.D. clone but seems to pay out much faster and as far as I know hasn't had any problems paying out bigger payments. I'm still waiting on 46 bitcoins from SD which was over a month ago, so I've given up on them and made the switch to BTCDice.
If SD wants to pay me back the 46 bitcoins they owe me, then I would think about switching back to SD. Probably never going to get those back. IMO, SD should be listed as (not always paying back), but that's just my personal opinion.
SatoshiDice has paid back every bet sent to it. The only exception is bets which come from addresses that the player cannot access (ie - they send from gox, and gox doesn't send the bet from their account address, so it gets lots in the void - thus the warning on the front page). Please post details of your alleged 46 bitcoins, and I'll get it sorted for you. But frankly I think you are mistaken. I check the blockchain every day to produce statistics on SD. I post them to the statistical analysis thread. As a by-product of this check, I get to see how many bets haven't been paid out. There is no 46 BTC bet outstanding, and never has been that I have seen. Here's a list of the unpaid bets from the last run I did, about 12 hours ago, showing the bet transaction ID, the date, and the amount bet: 968a692ab98b1f275c635c76be003ab1db9740d0b62f338b270115342ca42f5b 09:39:19 Apr-28-12 0.10000000
a96a3cc6284df89c4d670722e6c2705b7d3709673be8e7207c53e02f35220d45 15:13:48 May-24-12 0.50000000
a83faeb7a346cd205143fbf68b6d261925993a111d5719ec7430ed673346dd49 16:12:00 May-24-12 0.50000000
8cc820a32ac2446f4087c67f5af06b1ed32a38f1ea9cacc22f931c96cb1528cf 16:13:54 May-24-12 0.50000000
ad4866a91ce24c624f3582aa87b19cd8e55361c31315b9d79d80084730697c14 06:33:05 Jun-09-12 0.10000000
bea477ad898c961642876207e65c0f7700581e3c839987e5de151dd640a7eaa0 17:43:56 Jun-15-12 0.04000000
c9cca3a9e5a1494cee2c87c950c1283f83d091920cb6e6749b3e5930d8d69ac2 09:29:03 Jul-07-12 0.01000000
72b97a20c5cee0b9f05b5203d0361263edb41b752a15e2838ac2b3b6789f74c2 11:31:37 Jul-28-12 32.00000000
6071357b4e24964f398de274e55c85cadaf33e1f54acaa284a7dfc23933feff3 17:47:08 Jul-28-12 1.00000000
18455d8b2020cef49579fa2f024375a43e242f4bb0c303cba526327944c65e46 17:47:08 Jul-28-12 1.00000000
802455195c92092bf863c82f77baec33e6f21fd8de2aa604826918d56e76d205 07:15:28 Jul-29-12 0.05000000
555cc5382acc939178dcb81cd83172984eec99b767f78bf05389c94657d01020 07:21:21 Jul-29-12 1.00000000
bb8d9eca3e807622e92472c4043a3573d4521c02927e563b58b8ad4a3d9d9173 07:28:15 Jul-29-12 3.00000000
eb3ee5f086b285fa40208257b59091b065d4f1f76b240a15d965da3790baa062 23:01:51 Jul-29-12 0.80000000
434cb9541a56d496e2d0a240f7ee75b4119317a5e32f79a71e5c5511289f1ebc 23:01:51 Jul-29-12 0.20000000
c508831ed64c7f4ff0d261d2971e38dab61e550e445ee3eb8f476d47cea0c12c 04:29:24 Jul-30-12 2.00000000
e7fe8ae530f9beaee6c0d8b89fb5d5aeee0a1a49a03be743e1bf796d66306c82 04:29:24 Jul-30-12 0.20000000
7bac881cf5bd745b944f3d1bec3934df70ef5b29a991b3ad8f6772ab853aa42a 22:47:06 Jul-30-12 0.05000000
e838d3a4494e91c747a3704fd3ee0f05840c576e960bd97a5947b54a301e364a 22:47:06 Jul-30-12 0.05000000 The first 6 or 7 are due to a bug in the version of bitcoin that SD uses to process its bets and may have been put right manually. The 32.00000000 BTC bet is by far the largest outstanding bet, and is the one this thread is all about. Here's a screenshot of the transaction, showing that the 32 BTC bet is "unspent":  If the bet had been paid back, win or lose, that output wouldn't show up as "unspent". Edit: I just re-ran the stats and the same 19 bets are outstanding. This used to happen all the time, and fireduck would fix it manually. For the last month it's been a lot better until the rash of double-spends about a week ago.Edit2: When I re-ran the stats I hadn't run bitcoind since the last time, so of course I got the same results... Will edit again once everything is up-to-date. Edit3: All up-to-date now. Only one of the 19 listed bets was paid out, the 14th one, txid eb3ee5f086b285fa40208257b59091b065d4f1f76b240a15d965da3790baa062. |
|
|
|
rockxie, you need to quickly send 100 btc to that address and when it hits, you'll win back everything you lost. If it doesn't win, send 200. It's a sure thing!  It looks like he tried winning it back, won, and then wasn't paid out: https://bitcointalk.org/index.php?topic=96664 |
|
|
|
If the coin happened to be coming from a green address (such as those from Mt. Gox, Instawallet or wherever else they are offered) to return it without treating it as a wager.
Return it to what address? If they return it to the green address then the originating account won't get credit for it. |
|
|
|
Dooglus,
You are very resourceful, thanks for helping debug the code while I'm on vacation! I still don't fully understand the issue (and why that line of code fixed it), but it's not a bad thing to reopen the file just before scanning. As it was before, blk0002.dat was being opened before blk0001.dat was scanned. Your line reopens the file just before it is scanned (and I could see why that's a good thing). The first thing I do when I get back is I'll put that fix into 0.82.1 and commit it. And then I'll release 0.82.1 because it's about time...
Seriously, thanks for helping me with this! I've been stressed that issues like this are cropping up and I've had no time to deal with it!
You're welcome. Actually the change as you describe it is not what I intended. I meant to reopen each file after it was scanned, not before. Isn't that what my change does? All I'm aiming to do is to have the fileSizes_ array contain the sizes as they were actually read, not the sizes as they happened to be when the files were originally opened. Because when the stored filesizes value is smaller than the amount that was actually read, that's when the crash happens. |
|
|
|
I see your analysis, but its far from conclusive proof that its 1Dky is controlled by SR. But what about that cluster of 25k addresses, all since June 18? So my deposit sent to SR on June 9 probably went through a different cluster. Maybe the SR tumbler is periodically creating fresh address clusters.
There would have to more experiments to analyze SR's coin tumbler, like timed deposits and withdrawals.
I prove that the 25k address cluster is controlled by Silk Road. And that the fat address is funded directly by that cluster. That rules is out as being an MtGox deposit address, since the coins don't move once deposited to the fat address, except for a couple of large withdrawals. Coins deposited to MtGox deposit addresses are typically quickly moved to new addresses as they are withdrawn by other users. Do you know if your SilkRoad deposit address is part of the 25k cluster? If you tell me the address you used, I can check for you. |
|
|
|
More bad results for SatoshiDice. And they seem to have stopped responding to users with payment issues too ( https://bitcointalk.org/index.php?topic=96664.0, https://bitcointalk.org/index.php?topic=77870.0) Results: 2012-Aug-03 09:32am (up to block 192158)
Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP
--------------------------------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 12426 | 0 (0.00000) | 12141 | 285 | 78.33 | 0.01 | 18.39 | 78.31 | 0.025
1dice1Qf4 2 0.00003 | 1144 | 0 (0.00000) | 1074 | 70 | 17.19 | 0.00 | 5.58 | 17.19 | 0.010
1dice2pxm 4 0.00006 | 1691 | 0 (0.00000) | 1657 | 34 | 20.56 | 0.02 | 2.22 | 20.54 | 0.104
1dice2vQo 8 0.00012 | 1427 | 1 (0.00072) | 1385 | 41 | 33.70 | 8.05 | 4.15 | 25.65 | 23.894
1dice2WmR 16 0.00024 | 1697 | 1 (0.00060) | 1663 | 33 | 66.72 | 4.19 | 7.40 | 62.52 | 6.289
1dice2xkj 32 0.00049 | 4130 | 2 (0.00049) | 4117 | 11 | 298.93 | 103.16 | 1.29 | 195.76 | 34.512
1dice2zdo 64 0.00098 | 5931 | 8 (0.00135) | 5906 | 17 | 365.95 | 123.33 | 55.64 | 242.62 | 33.701
1dice37Ee 128 0.00195 | 6916 | 17 (0.00248) | 6850 | 49 | 1316.72 | 1174.03 | 44.25 | 142.69 | 89.163
1dice3jkp 256 0.00391 | 6083 | 30 (0.00494) | 6039 | 14 | 664.75 | 797.04 | 13.11 | -132.29 | 119.901
1dice4J1m 512 0.00781 | 9169 | 65 (0.00709) | 9099 | 5 | 1773.18 | 1184.87 | 9.35 | 588.31 | 66.822
1dice5wwE 1000 0.01526 | 17847 | 270 (0.01513) | 17573 | 4 | 5075.12 | 5329.51 | 1.80 | -254.39 | 105.013
1dice61SN 1500 0.02289 | 9031 | 212 (0.02349) | 8813 | 6 | 3258.33 | 3670.25 | 15.00 | -411.91 | 112.642
1dice6DPt 2000 0.03052 | 17435 | 552 (0.03167) | 16880 | 3 | 3899.21 | 3437.95 | 9.24 | 461.25 | 88.171
1dice6gJg 3000 0.04578 | 9127 | 436 (0.04781) | 8684 | 7 | 5313.00 | 6813.90 | 24.99 | -1500.90 | 128.250
1dice6GV5 4000 0.06104 | 10406 | 645 (0.06200) | 9758 | 3 | 3585.61 | 3179.24 | 31.20 | 406.36 | 88.667
1dice6wBx 6000 0.09155 | 17205 | 1631 (0.09485) | 15565 | 9 | 9102.68 | 9262.59 | 7.01 | -159.90 | 101.757
1dice6YgE 8000 0.12207 | 39347 | 4847 (0.12323) | 34485 | 15 | 7092.18 | 6283.95 | 0.00 | 808.23 | 88.604
1dice7EYz 12000 0.18311 | 17571 | 3337 (0.18998) | 14228 | 6 | 7149.07 | 7383.88 | 14.50 | -234.80 | 103.284
1dice7fUk 16000 0.24414 | 48514 | 11806 (0.24339) | 36700 | 8 | 18134.74 | 19337.33 | 347.79 | -1202.59 | 106.631
1dice7W2A 24000 0.36621 | 34886 | 12900 (0.37014) | 21952 | 34 | 15838.13 | 15832.20 | 212.63 | 5.93 | 99.963
1dice8EMZ 32000 0.48828 | 341907 | 166673 (0.48770) | 175081 | 153 | 134470.80 | 135865.93 | 2173.21 | -1395.12 | 101.037
1dice97EC 32768 0.50000 | 141492 | 70579 (0.49913) | 70825 | 88 | 60545.43 | 58873.73 | 789.20 | 1671.70 | 97.239
1dice9wcM 48000 0.73242 | 108148 | 79546 (0.73594) | 28542 | 60 | 98663.72 | 97111.92 | 467.98 | 1551.79 | 98.427
1dicec9k7 52000 0.79346 | 2514 | 2011 (0.80024) | 502 | 1 | 6939.36 | 7160.55 | 0.00 | -221.19 | 103.188
1dicegEAr 56000 0.85449 | 2175 | 1846 (0.84952) | 327 | 2 | 2961.91 | 2950.07 | 0.00 | 11.84 | 99.600
1diceDCd2 60000 0.91553 | 736 | 670 (0.91530) | 62 | 4 | 436.95 | 424.04 | 0.00 | 12.91 | 97.045
1dice9wVt 64000 0.97656 | 6117 | 5860 (0.97879) | 127 | 130 | 5188.65 | 4991.42 | 239.20 | 197.22 | 96.199
--------------------------------------------------------------------------------------------------------------------------------------------
| 875072 | 363945 | 510035 | 1092 | 392291.03 | 391303.27 | 4495.23 | 987.75 | 99.748
--------------------------------------------------------------------------------------------------------------------------------------------
SD Profit before fees: 987.75913595 BTC (0.252%)
Cumulative Fees Paid: 440.67125000 BTC
SD Profit after fees: 547.08788595 BTC (0.139%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 2702068 : SatoshiDice Tx: 1611343 (59.6%)
Blockchain MB: 1137.0 : SatoshiDice Tx: 662.5 (58.3%)  The follow 12 bets are pending still: 72b97a20c5cee0b9f05b5203d0361263edb41b752a15e2838ac2b3b6789f74c2 1 191241 11:31:37 Jul-28-12 32.00000000 1dice97E 1BCgHiW4jhUN1vggaeR3aSQpWhRxMLXjRg
18455d8b2020cef49579fa2f024375a43e242f4bb0c303cba526327944c65e46 0 191269 17:47:08 Jul-28-12 1.00000000 1dicegEA 14q94SKrm8W3yBzhi2BZ8xm8VJvPWcXAMG
6071357b4e24964f398de274e55c85cadaf33e1f54acaa284a7dfc23933feff3 0 191269 17:47:08 Jul-28-12 1.00000000 1dicegEA 14q94SKrm8W3yBzhi2BZ8xm8VJvPWcXAMG
802455195c92092bf863c82f77baec33e6f21fd8de2aa604826918d56e76d205 0 191343 07:15:28 Jul-29-12 0.05000000 1dice8EM 1GfDEVE4g5ghVp1e3v2Q1VqEMvG9FVVPio
555cc5382acc939178dcb81cd83172984eec99b767f78bf05389c94657d01020 1 191344 07:21:21 Jul-29-12 1.00000000 1dice8EM 1HcUSJNPJtP69ajpnUmFoU3WKDxssdNjMi
bb8d9eca3e807622e92472c4043a3573d4521c02927e563b58b8ad4a3d9d9173 1 191345 07:28:15 Jul-29-12 3.00000000 1dice8EM 1LQh4yvTW552ibohytuzLV9V8dbfieVdea
eb3ee5f086b285fa40208257b59091b065d4f1f76b240a15d965da3790baa062 1 191486 23:01:51 Jul-29-12 0.80000000 1dice97E 1FjvstaGAGyCXBMP8u2PkDk9tm1dkRhpm7
434cb9541a56d496e2d0a240f7ee75b4119317a5e32f79a71e5c5511289f1ebc 1 191486 23:01:51 Jul-29-12 0.20000000 1dice8EM 1LTMipT8ebJ1MNFRP9BdfkDYzW3RzLXoit
e7fe8ae530f9beaee6c0d8b89fb5d5aeee0a1a49a03be743e1bf796d66306c82 0 191521 04:29:24 Jul-30-12 0.20000000 1dice8EM 1ArM4VrvgiKExHYKFHwytjFusmr633ZjCU
c508831ed64c7f4ff0d261d2971e38dab61e550e445ee3eb8f476d47cea0c12c 0 191521 04:29:24 Jul-30-12 2.00000000 1dice9wc 17CzCQobrCofVnB8FYSn4suvYuT7g8Woxw
7bac881cf5bd745b944f3d1bec3934df70ef5b29a991b3ad8f6772ab853aa42a 1 191642 22:47:06 Jul-30-12 0.05000000 1dice6wB 19Jjrd4ue3uCcXYJrVwx7PhxTm4MZdC4YY
e838d3a4494e91c747a3704fd3ee0f05840c576e960bd97a5947b54a301e364a 1 191642 22:47:06 Jul-30-12 0.05000000 1dice6wB 1FoejzNLBRLQiewgyQmP3PJAipbmaScXii |
|
|
|
Did you try sending a PM to fireduck? He's been responsive in the past to 'stuck' transactions. |
|
|
|
and I am going to try getting a backup of the wallet to get the coins back but there is no guarantee I will be successful
For future reference is it best practice to make backups before disasters happen, not try to get them after the fact. It seems the Bitcoin community keeps making this mistake over and over again. I wonder why we can't learn from each other's mistakes. Whenever you're responsible for a wallet, make backups. Whether it's your coins or other people's. That's all... |
|
|
|
his Gigamining operation.
GPUMAX. Gigamining is something else. |
|
|
|
Sorry to interject in your conversation, but I have a question. The jackpot is "Less than 1 wins 64000" but I've not seen zero come up in the rolls. Are all the wins really less than or equal?
No, they're really "less than". The lucky number is effectively 16 random bits - the first 16 bits from the hmac_sha512() of your transaction id and their daily secret string. It will be between 0 and 65535 (0x0000 and 0xFFFF) inclusive. Nobody won the "lessthan 1" bet yet but it was only played 12000 times, so that's to be expected. I would be surprised if nobody had ever rolled a zero though, since over 860,000 games have been played in total. There are lots of statistics about SatoshiDice here: https://bitcointalk.org/?topic=80312 |
|
|
|
The only Casino game that I know of that this is possible to achieve (without cheating of course) is Black Jack (counting cards), but now days with continuous shuffle this is no longer possible.
Take a look at strikesapphire.com. Their blackjack was very beatable until recently (dealing 65% to 75% of the way through 6 decks before shuffling and allowing a spread from $0.10 to $5.00) and probably still is, but to a much lesser degree. |
|
|
|
These bets are still outstanding: |
|
|
|
Appears satoshidice has been unresponsive to several unpaid winning bets going on 4 days now. Is that suspicious?
It's worrying if nothing else. |
|
|
|
oh, by better inputs i mean it could have used a single input and given change, I didn't really think of it as the inputs fitting perfectly, I will have to get around to building the dust ignoring version for windows
Yeah, I think the only think the client tries to optimise is the 'fit' - ie. it tries to minimise the amount of change you get. Even if that ends up costing you 40 times your payment's value in fees... |
|
|
|
|
Show Posts
