The winning bid must be the lowest unique bid up to the 199,000th block.
You should clarify whether bids in block 199k itself are counted. i.e. is it "up to" or "up to and including" block 199k? Also, is it allowed to send multiple bets in a single transaction? If I make a transaction with 2 outputs, one of 0.1 and one of 0.2, both to the bet address, does that count as two entries (0.1 and 0.2) or one entry of 0.3? It would be better (from a spam reduction point of view) if you treated it as 2 bets. Then I can make 2 bets with one transaction and not pollute the blockchain quite so much. |
|
|
|
The winning bid must be the lowest unique bid up to the 199,000th block.
You should clarify whether bids in block 199k itself are counted. i.e. is it "up to" or "up to and including" block 199k? |
|
|
|
If there are two bids of the same amount, both bids can not win.
I think a less ambiguous way of saying what you mean is: "If there are two bids of the same amount, neither bids can win." It might help to give an example: "If we receive bids of 0.1 0.2 0.5 0.1 0.7 0.2 and 1.2 then the bid of 0.5 wins. 0.1 and 0.2 are lower, but both occur multiple times. 0.5 is the lowest *unique* bid". |
|
|
|
No, definitely not ianbakewell. Has to be a lie.
The funny thing is that transaction d23b8ec28b10902d5882acc6e2a96418698fa571032bfa459ba417f9929a4e04 paid out 4 BTC before any 2 BTC deposit to the game address ever happened. So he's not even doubling a pretend deposit to himself - he's doubling nothing. Here's a summary of the 2 bets of 2 BTC and the 2 doubles to 4 BTC in the order they happened: doubled nothing to 4 BTC: 2012-09-11 22:54:00 block 198361 d23b8ec28b10902d5882acc6e2a96418698fa571032bfa459ba417f9929a4e04
inputs outputs
127dNjGRVqzW8tcpTjitmF3GqtXHoiodLc (6 BTC) 1HJDteSfRWud1hiWR75iDNYbQUffmo5Lm 2 BTC
1CyKTdcEHjWtD9FuamThfQA2cjbHvYQnzy 4 BTC bet of 2 BTC 2012-09-12 08:57:46 block 198415 083bc9301876e4340abb9ae8af5c49c1a084995a110d671431c7c5484287af72
inputs outputs
17hvZSX8rxn4oqWHvsWNd6BNq8jTftTvMj (5.5 BTC) *13pLHUm8gPEN5H4xvTg8pqFHcr24ywzY1Z* 2 BTC
17hvZSX8rxn4oqWHvsWNd6BNq8jTftTvMj 3.5 BTC ian's bet of 2 BTC 2012-09-12 19:09:52 block 198486 5ebbb89198062454c20bb24fefca4bfd2b1bcf142b67fa0f2689af832280717b
inputs outputs
1KvByyfswhphncQ2uDo29WjX82DrdW2zU9 (0.007 BTC) 15BASR3sz4N6aTrTTaNKrZd5Po9eWmrjCr 0.01 BTC
114kWBPqiboAKcb4Ms65ZrVHcP1s1jFEXG (0.004 BTC) *13pLHUm8gPEN5H4xvTg8pqFHcr24ywzY1Z* 2 BTC
12ytu2WEiB9kxbSQLQzq1fhJFDRwGVp82J (0.012 BTC)
1QCPDfLPK95saavsZokCAuzMiCriNrmfpV (1.9565 BTC)
1Kia3NFWjyJNW4kFXtRHQpBRM2jDxyfmk (0.0095 BTC)
1F6DJCG6SGvhsh72Ca1y448wEkPsRpTa4U (0.0095 BTC)
13JXvcqXXsFJmUJHaoBZJLQKCVxG9Pffmz (0.0055 BTC)
1FrcytRVednQsBLqno7WaGxJFMfQ91NENx (0.007 BTC) doubled ian's bet to 4 BTC: 2012-09-12 22:34:52 block 198520 062a48f0baff05c3ed09fbb0f7637f1d17619f21e7c9a366c5f2dcd8c5014839
inputs outputs
1CyKTdcEHjWtD9FuamThfQA2cjbHvYQnzy (4 BTC) 114kWBPqiboAKcb4Ms65ZrVHcP1s1jFEXG 4 BTC |
|
|
|
Another doubled:
Status: 0/unconfirmed, broadcast through 37 nodes
Date: 11/09/2012 23:53
To: 1CyKTdcEHjWtD9FuamThfQA2cjbHvYQnzy
Debit: -4.00 BTC
Net amount: -4.00 BTC
Transaction ID: d23b8ec28b10902d5882acc6e2a96418698fa571032bfa459ba417f9929a4e04
Over 6 BTC doubled so far! Any more players?
Did you mean this instead? Transaction ID: 062a48f0baff05c3ed09fbb0f7637f1d17619f21e7c9a366c5f2dcd8c5014839 That looks to me like a payment from you to Ian. The one you wrote doesn't. Edit: Oh, but the payment to Ian was after your post about having paid Ian. So that's confusing. |
|
|
|
It's ultimately just a matter of preference since everyone has equal opportunity to draw the bye, so if it seems like your way is popular we may tweak the software to run the tournaments that way (or offer both formats). But hopefully that explanation makes sense for the meantime.
That makes sense, sure. I was just surprised, being used to how Stars does its heads-up tournaments. * I signed up for the site yesterday. When I came back today it was asking for my password again. I thought I told it "remember password". Maybe I'm mistaken. It's working fine for us, test it deliberately next time you log in and let us know. * Yesterday I definitely told it to "auto muck" and use "4 color deck". Both these settings were forgotten when I logged in today. Same computer and browser? Mavens does remember these settings. Can you login again and see if it's a one time issue or if it's still forgetting? Thanks. Both these problems seem fixed now. I'm wondering if perhaps Chrome crashed or my laptop ran out of power before it got to save the settings. Actually, I think I remember the OS locking up hard shortly after I first played, and having to do a cold reboot. Thanks for the 100 chip comp.  |
|
|
|
I updated help page to reflect order of operation. The multiplier on the page is what the actual multiplier is.
I give up. |
|
|
|
|
Would people have played this differently if OP had written "I'm going to double everything sent to me - as soon as I can afford to do so using new payments"? i.e. if he proclaimed up-front that it was a kind of a ponzi.
|
|
|
|
Results: 2012-Sep-13 09:40am (up to block 198607)
Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP
--------------------------------------------------------------------------------------------------------------------------------------------
1dice1e6p 1 0.00002 | 19242 | 0 (0.00000) | 18888 | 354 | 139.78 | 0.01 | 25.28 | 139.76 | 0.014
1dice1Qf4 2 0.00003 | 1714 | 0 (0.00000) | 1642 | 72 | 24.09 | 0.00 | 6.68 | 24.09 | 0.007
1dice2pxm 4 0.00006 | 2303 | 0 (0.00000) | 2268 | 35 | 27.81 | 0.02 | 3.22 | 27.79 | 0.095
1dice2vQo 8 0.00012 | 2402 | 1 (0.00042) | 2358 | 43 | 50.97 | 8.06 | 5.15 | 42.91 | 15.818
1dice2WmR 16 0.00024 | 2498 | 1 (0.00041) | 2461 | 36 | 89.68 | 4.24 | 7.40 | 85.43 | 4.735
1dice2xkj 32 0.00049 | 5378 | 3 (0.00056) | 5364 | 11 | 378.91 | 303.32 | 1.29 | 75.59 | 80.051
1dice2zdo 64 0.00098 | 7741 | 8 (0.00104) | 7711 | 22 | 643.96 | 124.38 | 55.64 | 519.58 | 19.316
1dice37Ee 128 0.00195 | 9703 | 19 (0.00197) | 9629 | 55 | 1592.77 | 1274.64 | 44.25 | 318.12 | 80.027
1dice3jkp 256 0.00391 | 9825 | 43 (0.00438) | 9768 | 14 | 1283.94 | 1302.33 | 13.11 | -18.38 | 101.432
1dice4J1m 512 0.00781 | 14654 | 114 (0.00778) | 14531 | 9 | 2627.90 | 2003.43 | 9.35 | 624.47 | 76.237
1dice5wwE 1000 0.01526 | 28195 | 417 (0.01479) | 27769 | 9 | 8252.58 | 7606.47 | 1.80 | 646.10 | 92.171
1dice61SN 1500 0.02289 | 14776 | 335 (0.02268) | 14435 | 6 | 4693.11 | 4851.33 | 15.00 | -158.21 | 103.371
1dice6DPt 2000 0.03052 | 22404 | 696 (0.03107) | 21704 | 4 | 5476.87 | 4643.51 | 9.24 | 833.36 | 84.784
1dice6gJg 3000 0.04578 | 14902 | 688 (0.04619) | 14206 | 8 | 6769.48 | 8053.37 | 24.99 | -1283.89 | 118.966
1dice6GV5 4000 0.06104 | 15457 | 956 (0.06187) | 14497 | 4 | 4631.51 | 4111.60 | 31.20 | 519.90 | 88.775
1dice6wBx 6000 0.09155 | 20508 | 1918 (0.09360) | 18573 | 17 | 9897.72 | 9766.89 | 7.01 | 130.82 | 98.678
1dice6YgE 8000 0.12207 | 80580 | 9905 (0.12295) | 70654 | 21 | 10012.70 | 8604.04 | 0.00 | 1408.66 | 85.931
1dice7EYz 12000 0.18311 | 20463 | 3847 (0.18812) | 16603 | 13 | 8120.01 | 8323.94 | 14.50 | -203.93 | 102.511
1dice7fUk 16000 0.24414 | 74590 | 18144 (0.24332) | 56425 | 21 | 43977.32 | 43488.70 | 347.79 | 488.62 | 98.889
1dice7W2A 24000 0.36621 | 57312 | 21063 (0.36778) | 36207 | 42 | 28369.27 | 27604.82 | 212.64 | 764.44 | 97.305
1dice8EMZ 32000 0.48828 | 487227 | 237396 (0.48766) | 249411 | 420 | 295121.59 | 293785.51 | 2173.40 | 1336.07 | 99.547
1dice97EC 32768 0.50000 | 182463 | 90906 (0.49866) | 91394 | 163 | 178153.54 | 176972.92 | 1295.21 | 1180.61 | 99.337
1dice9wcM 48000 0.73242 | 145053 | 106687 (0.73588) | 38292 | 74 | 138932.38 | 136687.12 | 467.98 | 2245.25 | 98.384
1dicec9k7 52000 0.79346 | 10846 | 8623 (0.79541) | 2218 | 5 | 19867.58 | 19804.73 | 400.00 | 62.85 | 99.684
1dicegEAr 56000 0.85449 | 9565 | 8192 (0.85735) | 1363 | 10 | 9511.90 | 9334.48 | 400.00 | 177.42 | 98.135
1diceDCd2 60000 0.91553 | 4916 | 4492 (0.91487) | 418 | 6 | 8192.16 | 8104.56 | 0.00 | 87.60 | 98.931
1dice9wVt 64000 0.97656 | 7416 | 7134 (0.97981) | 147 | 135 | 16175.93 | 15898.34 | 239.21 | 277.59 | 98.284
--------------------------------------------------------------------------------------------------------------------------------------------
small (bets < 4 BTC) | 1228832 | 499781 | 727650 | 1401 | 307660.66 | 299269.74 | 143.10 | 8390.92 | 97.273
big (bets >= 4 BTC) | 43301 | 21807 | 21286 | 208 | 495354.94 | 493393.16 | 5668.35 | 1961.77 | 99.604
--------------------------------------------------------------------------------------------------------------------------------------------
| 1272133 | 521588 | 748936 | 1609 | 803015.61 | 792662.90 | 5811.46 | 10352.70 | 98.711
--------------------------------------------------------------------------------------------------------------------------------------------
SD Profit before fees: 10352.70465926 BTC (1.289%)
Cumulative Fees Paid: 640.86987500 BTC
SD Profit after fees: 9711.83478426 BTC (1.209%)
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 4166083 : SatoshiDice Tx: 2354671 (56.5%)
Blockchain MB: 1724.4 : SatoshiDice Tx: 961.6 (55.8%)  |
|
|
|
He has never behaved less than impeccably in his business here yet since Pirate's gone he's the next easy target.
Has he yet disclosed to his investors what obligations he has, what assets he will use to cover those obligations, and what losses are being passed on to them? If not, I'd say he's behaving at least a bit less than impeccably. Shouldn't this be something very easy to put together? Would be a quick way to make the trolls go away. If the list is going to be itemized, that's a privacy concern. If it isn't, then haven't we been shown those numbers already? I'm not sure the lack of such information impacts Patrick's peccability at all. |
|
|
|
I will update help page, but not going to change math to something inconsistent.
The payout multipliers you're quoting aren't the payout multipliers you offer. What you're doing would be like a casino saying "we pay out 38x on a single roulette number" (because that's what they would pay out if the house edge was 0%, but it isn't). Then someone hits a single number and the casino pays out only 36x. The player complains "you said 38x but I only got 36x", and you reply "you forgot the house edge!" What really happens is the casino tells the player "we pay out 36x on single numbers". That way it's clear what you're getting. |
|
|
|
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. |
|
|
|
|
Do I need to post each transaction here before you double them?
I have a transaction with over 100 confirmations that didn't get doubled yet. It's over 15 hours old.
|
|
|
|
It happened again. The 'edit watchlist' shows there are lots of threads updated since I last caught up - only the last 2 on this list don't have new posts for me:  but the watchlist itself only shows a few threads, all of them posted to in the last half hour since I last logged on:  It seems like sometimes something gets reset on the forum server which makes the watchlist think I'm up-to-date when I'm not really. |
|
|
|
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. |
|
|
|
What's going on here? The newest block is shown as being over an hour ago (there wasn't such a gap between these blocks) and has a size of 0. I probably suspended my laptop between visiting this page and taking the screenshot, but why would that cause the data to be incorrect?  |
|
|
|
Satoshidice shows multiplier less the house percent. I show multiplier prior to house percent.
Your help page at http://btcdice.com/howitworks.html says: If you win, your bet is multiplied by the prize multiplier and that amount is sent back. But that's not correct. If you win, your bet is multiplied by the prize multiplier, then the house edge is subtracted, and that amount is sent back. It would be best if you showed the actual multiplier the user gets. i.e. take the house edge off the prize multiplier before stating it. That way people can compare your odds with SD's to easily see which is better odds. For example, on "lessthan 16000", instead of saying the payout is "4.096x", calculate 4.096*(1-edge/100): >>> 4.096 * (1-1.650/100)
4.028416 and state that the payout is 4.028x. That way people can make a direct comparison with SD's quoted multiplier of 4.003x. |
|
|
|
its strange that it only seems to be my big winning bets that are blocking  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. |
|
|
|
|
I don't know if anyone asked already, but why are you doing this?
Do you plan to stop doubling at some point and keep all the coins you're sent from then on?
|
|
|
|
|
Also didn't you say they can easily play 8 tables at a time? That's a lot of running around between tables!
|
|
|
|
|
Show Posts
