Why does this address: 12BdKh5HHUyGFduGm6y8nY4KS1LxzsduXo
Link to this address: 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
Closure reports it has no outputs then returns that one.
I see the same. It tells me: error: specified key was never used in a TX output but this transaction has 12BdKh5HHUyGFduGm6y8nY4KS1LxzsduXo as an output, so the message is a little confusing. And then the address isn't in its own reported cluster - that's got to be a bug. |
|
|
|
Also, can somebody tell me why Intersango is a wise choice to store/invest hard-earned bitcoins. And before you go there, I feel that Intersango and Bitcoinica are not mutually exclusive.
They're currently having trouble with their bank account, leading to delayed deposits: Metro Bank (UK) 2012-07-24 18:51 BST
While we were previously under the impression that the problems we were having with Metro bank were due to a technical issue on their end (as this has happened before), we have been told that our account activity is being reviewed and that we must be patient during this process. We have faith that our contact at Metro bank will properly investigate the matter. They have indicated that they do not require information from us at this time. The resolution time we were given was around 1 week, however this is just an approximation.
We apologise for the inconvenience this has caused our userbase. We are doing everything we can to resolve the problem as fast as possible. In the future, we may not be able to accept payments quite as fast anymore to prevent fraud however we will work hard to decrease our resolution times for issues and make the experience of purchasing and selling bitcoins as easy for the UK as possible.
We understand that many people have called Metro bank and Metro has told them that there is no issue. This is entirely incorrect. We believe it in not intentional it is simply that their support staff assumes that if there is not an issue affecting all accounts or a huge number of accounts at the bank that there is not an issue with our account.
|
|
|
|
Mostly always true, but not 100% always true: not all transactions
work the way you describe.
For example, block reward TX have the full public key specified, not
just the 160 bit hash.
It's 100% true for payments to bitcoin addresses, and 0% true for payments to public keys... Block rewards are no different than regular payments in this respect - both block rewards and regular payments can be made to bitcoin addresses or public keys. In practice nobody much sends payments to public keys, whereas it's common for block rewards to go to public keys, but there's no technical reason for that to be the case. In the thread about quantum computers it was mentioned that the use of 160 bit addresses quite possibly strengthens the network, since the advent of quantum computers would make cracking a 256 bit public key a 2^128 step operation, whereas reversing a 160 bit hash would still be a 2^160 step operation. i.e. finding the public key from an address would be the hard bit, and finding the private key for the public key would be relatively easy. That implies that you should only spend from each address once, since in order to spend from an address you have to publicly declare its public key. |
|
|
|
Dooglus is saying there's 2^160 public keys for the 2^256 private keys. In other words the mapping is not injective, meaning that more than one private key can map to the same public key.
No, there are 2^256 public keys but only 2^160 bitcoin addresses. i.e. there are around 2^96 public/private keypairs for each bitcoin address, and any of those 2^96 can spend the coins at an address. More than one private key can map to the same *address*. |
|
|
|
Any private key with the same bitcoin address will let you spend its money.
Is this true though? I thought the public key was present in the blockchain, and having 2 public keys that resolved to the same bitcoin address would probably cause the quintessential swirling vortex of doom, but shouldn't allow the coins to be spent. This assumes that there are 2^256 public keys that go with those 2^256 private keys. Yes, it's true. Look at the scripts on blockexplorer. They say "to spend this, you must provide a public key with the following 160 bit hash, and a signature made with the corresponding private key". It doesn't specify which public key must be used. Any one with the correct 160 bit hash will work. Here's an example script: OP_DUP OP_HASH160 5b62be019b9c39991daed3c3d0e2186986476c11 OP_EQUALVERIFY OP_CHECKSIG |
|
|
|
Don’t concede the wager and chance the outcome of Aug 14th. What's the significance of that date? The bet is until October 2013 or so isn't it? |
|
|
|
See how the blue line goes vertical at the end? It actually goes up 400 BTC then back down 400 BTC. I looked at the big bets that caused this and it appears to be a single player: 2012-07-24 05:50:58 lessthan 32000 Bet Amount: 21.50 Outcome: LOSE Payment: 0.10700000 Profit: -21.393 Cumulative Profit: -21.393
2012-07-24 05:51:51 lessthan 32000 Bet Amount: 43.00 Outcome: LOSE Payment: 0.21450000 Profit: -42.7855 Cumulative Profit: -64.1785
2012-07-24 05:52:27 lessthan 32000 Bet Amount: 86.00 Outcome: LOSE Payment: 0.42950000 Profit: -85.5705 Cumulative Profit: -149.749
2012-07-24 05:56:39 lessthan 16000 Bet Amount: 86.00 Outcome: LOSE Payment: 0.42950000 Profit: -85.5705 Cumulative Profit: -235.3195
2012-07-24 05:54:07 lessthan 32000 Bet Amount: 172.00 Outcome: LOSE Payment: 0.85950000 Profit: -171.1405 Cumulative Profit: -406.46
2012-07-24 05:58:02 lessthan 16000 Bet Amount: 107.50 Outcome: WIN Payment: 430.28932000 Profit: 322.78932 Cumulative Profit: -83.67068
2012-07-24 06:04:53 lessthan 48000 Bet Amount: 250.00 Outcome: WIN Payment: 334.39083333 Profit: 84.39083333 Cumulative Profit: 0.72015333He bets thousands of dollars and ends up less than $10 up. Notice how after losing the 86 BTC bet he bets the same amount at double the odds rather than doubling the bet. Martingale gets scary quick! |
|
|
|
Results: 2012-Jul-24 01:47am (up to block 190505)
Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP
--------------------------------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 10762 | 0 (0.00000) | 10482 | 280 | 57.71 | 0.01 | 17.88 | 57.69 | 0.033
1dice1Qf4 2 0.00003 | 999 | 0 (0.00000) | 929 | 70 | 8.54 | 0.00 | 5.58 | 8.54 | 0.021
1dice2pxm 4 0.00006 | 1506 | 0 (0.00000) | 1474 | 32 | 13.88 | 0.00 | 1.22 | 13.87 | 0.051
1dice2vQo 8 0.00012 | 1289 | 0 (0.00000) | 1249 | 40 | 18.64 | 0.00 | 4.15 | 18.64 | 0.042
1dice2WmR 16 0.00024 | 1514 | 0 (0.00000) | 1484 | 30 | 25.62 | 0.02 | 6.60 | 25.59 | 0.103
1dice2xkj 32 0.00049 | 3455 | 1 (0.00029) | 3443 | 11 | 111.43 | 100.41 | 1.29 | 11.02 | 90.111
1dice2zdo 64 0.00098 | 5210 | 7 (0.00135) | 5186 | 17 | 212.08 | 121.70 | 55.64 | 90.37 | 57.385
1dice37Ee 128 0.00195 | 6325 | 15 (0.00239) | 6262 | 48 | 1234.78 | 1148.24 | 40.25 | 86.53 | 92.992
1dice3jkp 256 0.00391 | 4874 | 22 (0.00453) | 4838 | 14 | 516.89 | 334.58 | 13.11 | 182.30 | 64.730
1dice4J1m 512 0.00781 | 7647 | 49 (0.00641) | 7593 | 5 | 1560.53 | 746.69 | 9.35 | 813.84 | 47.848
1dice5wwE 1000 0.01526 | 14013 | 205 (0.01463) | 13806 | 2 | 2299.43 | 1970.99 | 1.80 | 328.44 | 85.716
1dice61SN 1500 0.02289 | 7801 | 183 (0.02348) | 7612 | 6 | 3073.99 | 3498.29 | 15.00 | -424.30 | 113.803
1dice6DPt 2000 0.03052 | 9469 | 298 (0.03148) | 9168 | 3 | 3437.89 | 3149.86 | 9.24 | 288.03 | 91.622
1dice6gJg 3000 0.04578 | 7691 | 378 (0.04919) | 7306 | 7 | 4950.12 | 6483.39 | 24.99 | -1533.26 | 130.974
1dice6GV5 4000 0.06104 | 8533 | 543 (0.06366) | 7987 | 3 | 3045.70 | 2822.91 | 31.20 | 222.78 | 92.685
1dice6wBx 6000 0.09155 | 15779 | 1491 (0.09453) | 14282 | 6 | 8760.70 | 8957.31 | 7.01 | -196.61 | 102.244
1dice6YgE 8000 0.12207 | 31680 | 3944 (0.12452) | 27729 | 7 | 6387.25 | 5654.73 | 0.00 | 732.51 | 88.532
1dice7EYz 12000 0.18311 | 16580 | 3146 (0.18980) | 13429 | 5 | 6845.20 | 6994.97 | 14.50 | -149.76 | 102.188
1dice7fUk 16000 0.24414 | 44182 | 10721 (0.24269) | 33454 | 7 | 13861.13 | 13682.86 | 97.79 | 178.27 | 98.714
1dice7W2A 24000 0.36621 | 32836 | 12157 (0.37060) | 20647 | 32 | 13747.50 | 13676.13 | 212.63 | 71.36 | 99.481
1dice8EMZ 32000 0.48828 | 315841 | 153941 (0.48760) | 161769 | 131 | 98000.04 | 98557.45 | 2173.21 | -557.40 | 100.569
1dice97EC 32768 0.50000 | 130873 | 65255 (0.49891) | 65539 | 79 | 48823.95 | 47197.33 | 789.20 | 1626.61 | 96.668
1dice9wcM 48000 0.73242 | 93996 | 69156 (0.73613) | 24790 | 50 | 76324.51 | 74924.62 | 467.98 | 1399.89 | 98.166
1dicec9k7 52000 0.79346 | 875 | 700 (0.80000) | 175 | 0 | 1335.75 | 1344.51 | 0.00 | -8.76 | 100.656
1dicegEAr 56000 0.85449 | 689 | 569 (0.82583) | 120 | 0 | 407.99 | 343.46 | 0.00 | 64.52 | 84.184
1diceDCd2 60000 0.91553 | 140 | 125 (0.91241) | 12 | 3 | 48.09 | 48.61 | 0.00 | -0.52 | 101.093
1dice9wVt 64000 0.97656 | 5906 | 5653 (0.97854) | 124 | 129 | 5025.32 | 4832.49 | 239.20 | 192.83 | 96.163
--------------------------------------------------------------------------------------------------------------------------------------------
| 780465 | 328559 | 450889 | 1017 | 300134.79 | 296591.69 | 4238.91 | 3543.10 | 98.819
--------------------------------------------------------------------------------------------------------------------------------------------
SD Profit before fees: 3543.10320692 BTC (1.181%)
Cumulative Fees Paid: 392.85462500 BTC
SD Profit after fees: 3150.24858192 BTC (1.050%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 2373598 : SatoshiDice Tx: 1441132 (60.7%)
Blockchain MB: 1002.6 : SatoshiDice Tx: 592.4 (59.1%)  |
|
|
|
The conjectured security level of ECDSA 256 bit keys is 128bit (source: http://www.nsa.gov/business/programs/elliptic_curve.shtml). It's in fact likely to be closer to 2^256, the size of the space of all possible secp256k1 keys. That means : breaking an ECDSA 256 bit key would take, using the best known algorithms today, on the order of 2^128 attempts. That's 340282366920938463463374607431768211456 attempts. Don't forget that there are only 2^160 different addresses, due to the hash160 step in making an address from a private key. You don't need to find the rich account's private key. Any private key with the same bitcoin address will let you spend its money. I don't know how you got from 2^256 to 2^128 in your analysis, but can you use the same magic to get from 2^160 to 2^80? |
|
|
|
Just a small niggle, but when playing blackjack I can't immediately tell whether I've hit 21 or bust since my total disappears from the screen. In either situation the dealer turns over his card, and my total vanishes until the dealer has finished his taking his turn, which may involve quite a few cards.
Would it be possible to have my total displayed while the dealer is acting? Also, the dealer's total isn't displayed while he's acting, only when he finishes. I'd like to see the dealer's total change as the he plays.
Good suggestion! We'll have to change how we do our dealing logic somewhat - the difficulty is that the javascript in the browser doesn't really have any knowledge of the blackjack game itself, all the game logic is on the server, the javascript is dumb and just handles dealing the cards. We'll figure out a way to do this though, cause, I agree, it will be much better. Maybe related to this: If I play a play money blackjack game and put all my chips on a single hand and lose, the "you're out of play money" alert pops up as soon as I bust or stand, and before the dealer even starts playing. It's odd to stand on 20, then see that I've lost, and only then have the dealer hit a 6 card 21 to beat me. It feels "cheaty", like the 6 card 21 was pre-determined. It was, of course, but it would look better if the "out of money" alert only showed up after I had seen the hand play out. See these screenshots of it happening. In each case I had stood at 16 or 18. The dealer has 13, 15, and 10, but has already been declared the winner:  |
|
|
|
It looks to me like if I have 7 or more cards, the cards will overlap with the result of the hand. I had 6 cards in this hand, and it almost overlaps:  Wish I could multiply my bankroll by 85 when I play for bitcoins... |
|
|
|
|
Interesting.
How are you calculating the CDF?
|
|
|
|
|
Last I heard it was with RyNinDaCleM, step 36.
|
|
|
|
|
Suggestion:
Offer a 4-colour deck option for the video poker, to make it easier to distinguish the suits. Typically sites will draw diamonds in blue and clubs in green when this feature is enabled. See pokerstars and sealswithclubs for sites that do this well.
|
|
|
|
I'll spend some time rejiggering the strategy to take account of fees and the house edge. But you agree in principle that the strategy would minimise losses - on average - if used?
My initial reaction to this is that it shouldn't be possible to change your rate of loss at this game. Every bet has the same (negative) expectation. So no matter how you size your bets, don't you expect to lose at the same rate? If the odds change over time, like in blackjack where you can use the cards you've already seen to deduce the composition of the remaining cards, you can raise your stake when the odds are in your favour and end up with a positive overall expectation. But with SatoshiDice, like roulette, there's a constant negative expectation. In short, you can expect to lose 1.8% (or whatever the house edge currently is) of everything you bet, no matter how you size your bets. How does that fit in with your idea that you are minimising your losses on average? My argument above would suggest that the way to minimise your expected losses is to minimise your stake. i.e. don't play at all. |
|
|
|
I had the same problem with gox, but I was using the android wallet app and copied the wrong address.
lost 2btc
If you lost the 2 btc because you won the bet but Gox didn't credit it to your account, you'll probably find that they'll credit it back to you eventually. If you lost it because your SatoshiDice bet lost, then I would guess you're out of luck. |
|
|
|
|
Just a small niggle, but when playing blackjack I can't immediately tell whether I've hit 21 or bust since my total disappears from the screen. In either situation the dealer turns over his card, and my total vanishes until the dealer has finished his taking his turn, which may involve quite a few cards.
Would it be possible to have my total displayed while the dealer is acting? Also, the dealer's total isn't displayed while he's acting, only when he finishes. I'd like to see the dealer's total change as the he plays.
|
|
|
|
|
If you look in the history on the browser you used, you should be able to see where you were immediately before you visited the scam site.
|
|
|
|
now that there have been three quarter million bets, i would be curious to see the a chart of the results of the distribution of lucky numbers,
are there any ranges that have been beating the odds?
https://bitcointalk.org/index.php?topic=80312.msg1047173#msg1047173 has a table of the results so far. If you compare the 'should win' column with the number in brackets in the 'win' column you'll see that lots of the bets have been beating the odds. For example, you would only expect "lessthan 64" bets to win 1 in 1024 bets, but of 5178 bets so far, 7 have won. We would expect only 5 to have won so far. Despite this, "lessthan 64" is currently the most profitable bet for the house, relative to the amount bet on it (other than the ones which nobody has won yet, i.e. lessthan 16, 8, 4, 2, and 1). It has only paid back 58.146% of payments received. It must be that the losing bets were on average bigger than the winning ones. The 3 new bets are performing badly for players, all giving back less that expected. Particularly the "lessthan 56000" bet, which should pay out 85.449% of the time, but so far in 99 bets has only paid out 76.768% of the time, resulting in an effective 25 house edge! "lessthan 52000" has actually paid out more often than lessthan 56000", despite being easier to win. But I don't have a distribution chart. I'd have to make a web query for every bet to get that since the lucky number doesn't get into the blockchain. |
|
|
|
|
Show Posts
