ingrownpocket
Legendary
Offline
Activity: 952
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 03:14:59 PM |
|
... The high roller uses the following 8 addresses, by the way: 15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo 17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y 1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV 1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk 1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Total: 23120 BTC ($447,140)
|
|
|
|
Kryptox
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 03:18:27 PM |
|
I've been searching around and can't find an answer to this so I apologize if this has been covered (I'm sure it has) but earlier in this thread there was a discussion about how SD cannot be rigged and it's provable.
How exactly do you go about verifying that the lucky number is calculated correctly from the Transaction ID? How does the secret compute against the Transaction ID to produce the lucky number?
|
|
|
|
ingrownpocket
Legendary
Offline
Activity: 952
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 03:22:37 PM |
|
How does the secret compute against the Transaction ID to produce the lucky number?
The lucky number used to determine the winner of games is simple. It is simply the first bytes of hmac_sha512(secret,txid:out_idx). That would be the secret string as the key and the transaction ID of your bet transaction as the data. BTW, there's a error in SD site: "hmac_sha512(sec ert,txid:out_idx)".
|
|
|
|
Kryptox
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 03:25:26 PM Last edit: January 30, 2013, 04:34:01 PM by Kryptox |
|
Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this? EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice. http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 003e -> 62 So that's lucky number was 62. How do you get from: ThisnJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX And this38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8 To this003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 Do we just take it for granted that this is somehow correct?
|
|
|
|
kgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 04:40:17 PM |
|
Do we just take it for granted that this is somehow correct?
You run the function yourself with the same inputs with a crypto library that you trust.
|
|
|
|
Kryptox
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 05:09:05 PM |
|
I'm a noob when it comes to cryptography.
You run the function yourself with the same inputs with a crypto library that you trust.
Thanks kgo. Do these crypto libraries exist somewhere on the net? I did a google search and yielded nothing.
|
|
|
|
StarenseN
Legendary
Offline
Activity: 2478
Merit: 1362
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 05:55:38 PM |
|
... The high roller uses the following 8 addresses, by the way: 15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo 17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y 1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV 1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk 1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
You obviously know what you are doing ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Can you figure out, how and where did the coin get to those accounts? I still like my "idea" (more like a speculation) that this mysterious whale is sdice guy(s) himself and he is only trying to make sdice looks stronger and more profitable to possible future investors. Only problem is, he "fucked up" and sdice "lost" a boat load of coin ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Even if S.DICE was being fluffed, it would come at 10% expense to the "whale" while losing, because 10% of the dividends are public. Anyone can bet what they want on the site, even majority shareholders with less to lose (because they'll see some of their losses come back thru dividends). This is only a problem if the odds are in the whale's favor, I think... Actualy long term it's 10% of the house edge (=0.19%) given to stakeholders. So less tah 200$ lost for the whale every 100,000$ bet. That's cheap for a good advertising (even if i don't trust the conspiracy)
|
|
|
|
ThickAsThieves
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 06:07:13 PM |
|
I asked the owner about this topic a few days ago actually, and he convinced me that all that would happen if there were inside betting like this, would be that shareholders would eventually get all the money.
But, to run with this theory, this is only "harmless" fluffing of numbers if the whale loses. But, if the whale has a winning record, does that simply snake dividends from the 10% stakeholders?
I'm probably missing something here that makes this impossible, but if it's possible, there's essentially very little reason for the 90% stakeholder(s) not to constantly bet big on themselves, no?
|
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 08:57:34 PM |
|
Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this? EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice. http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 003e -> 62 So that's lucky number was 62. How do you get from: ThisnJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX And this38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8 To this003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 Do we just take it for granted that this is somehow correct? Download and install Python. It's free, and comes with all the crypto libraries you need. Then you can calculate lucky numbers for yourself, as follows. Your example is from before the rule-change of Jan 3rd. Before then, all the bets in a transaction got the same lucky number. Here's how you would calculate it for your example (the bold parts are the parts you type). See how it spits out '62' at the end? $ python Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib, hmac >>> txid = '38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8' >>> secret = 'nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz' >>> int(hmac.new(secret, txid, hashlib.sha512).hexdigest()[:4], 16) 62 >>> For bets made after Jan 2nd 2013, the lucky number is different for each bet in the transaction, so you need to specify the output number (nout), as follows. Let's use a bet I made as an example, and calculate all 10 lucky numbers: $ python Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib, hmac >>> txid = 'df7a5cb1ed439f1e0f314cfed88f77ab0f0fdf4a4d2e4714a8287834791fbd95' >>> secret = 'DIGtgGbebAIjJeuh1tlzMW5Xzs8ds0V9azgs40JvWOd24NpFEttZEFM32OHgEqFd' >>> for nout in range(10): print nout, int(hmac.new(secret, "%s:%d" % (txid, nout), hashlib.sha512).hexdigest()[:4], 16) 0 10351 1 37909 2 63099 3 19569 4 13550 5 36796 6 28032 7 53908 8 64653 9 36560 >>> See how they match up with the numbers shown on the SD page (although the SD page shows them in the wrong order, it does now show the 'Idx' column so you can match them up): ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FyrSGfMQ.png&t=665&c=NzAZL2pmeZ9tPw)
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 09:25:54 PM |
|
Total of 92 bets unaccounted for.
Results: 2013-Jan-30 12:51pm (up to block 218786)
Address Target Should Win | #Bets | Win | Lose | Refunds | BTC In | BTC Out | Refund | Profit | RTP ---------------------------------------------------------------------------------------------------------------------------------------------- 1dice1e6p 1 0.00002 | 77190 | 0 (0.00000) | 75898 | 1292 | 794.57 | 0.01 | 104.64 | 794.55 | 0.003 1dice1Qf4 2 0.00003 | 3819 | 0 (0.00000) | 3322 | 497 | 62.90 | 0.01 | 17.03 | 62.89 | 0.020 1dice2pxm 4 0.00006 | 6030 | 1 (0.00018) | 5608 | 421 | 87.96 | 159.97 | 8.46 | -72.01 | 181.860 1dice2vQo 8 0.00012 | 8656 | 3 (0.00036) | 8227 | 426 | 131.00 | 176.01 | 10.03 | -45.00 | 134.353 1dice2WmR 16 0.00024 | 10494 | 1 (0.00010) | 10081 | 412 | 311.63 | 4.56 | 18.66 | 307.07 | 1.465 1dice2xkj 32 0.00049 | 11583 | 3 (0.00027) | 11187 | 393 | 619.83 | 303.62 | 1.36 | 316.20 | 48.985 1dice2zdo 64 0.00098 | 13889 | 14 (0.00104) | 13455 | 420 | 887.34 | 230.74 | 55.72 | 656.59 | 26.004 1dice37Ee 128 0.00195 | 16175 | 31 (0.00197) | 15712 | 432 | 1954.53 | 1379.19 | 48.32 | 575.34 | 70.564 1dice3jkp 256 0.00391 | 17970 | 78 (0.00443) | 17514 | 378 | 2249.15 | 3542.76 | 13.17 | -1293.60 | 157.515 1dice4J1m 512 0.00781 | 26955 | 201 (0.00765) | 26071 | 683 | 4447.35 | 4122.08 | 9.98 | 325.26 | 92.686 1dice5wwE 1000 0.01526 | 86267 | 1318 (0.01536) | 84500 | 449 | 22933.29 | 19402.30 | 1.95 | 3530.99 | 84.603 1dice61SN 1500 0.02289 | 20369 | 476 (0.02378) | 19543 | 350 | 6530.84 | 6608.00 | 15.07 | -77.15 | 101.181 1dice6DPt 2000 0.03052 | 51463 | 1582 (0.03097) | 49495 | 386 | 25602.82 | 22872.34 | 9.32 | 2730.47 | 89.335 1dice6gJg 3000 0.04578 | 23694 | 1080 (0.04640) | 22196 | 418 | 8622.25 | 9770.89 | 25.11 | -1148.64 | 113.322 1dice6GV5 4000 0.06104 | 29297 | 1774 (0.06133) | 27153 | 370 | 6673.05 | 6287.39 | 31.28 | 385.66 | 94.221 1dice6wBx 6000 0.09155 | 36314 | 3376 (0.09400) | 32540 | 398 | 14193.64 | 15913.14 | 7.14 | -1719.50 | 112.115 1dice6YgE 8000 0.12207 | 145727 | 17882 (0.12309) | 127393 | 452 | 71680.20 | 71740.95 | 100.23 | -60.75 | 100.085 1dice7EYz 12000 0.18311 | 59724 | 10936 (0.18447) | 48347 | 441 | 143370.18 | 147417.44 | 3314.66 | -4047.26 | 102.823 1dice7fUk 16000 0.24414 | 178918 | 43498 (0.24377) | 134941 | 479 | 328033.09 | 314390.96 | 2056.09 | 13642.12 | 95.841 1dice7W2A 24000 0.36621 | 174521 | 64038 (0.36803) | 109963 | 520 | 503330.95 | 509788.75 | 1012.97 | -6457.79 | 101.283 1dice8EMZ 32000 0.48828 | 926538 | 451613 (0.48817) | 473506 | 1419 | 734450.90 | 716571.23 | 2924.16 | 17879.67 | 97.566 1dice97EC 32768 0.50000 | 422891 | 210756 (0.49941) | 211258 | 877 | 555106.22 | 543980.04 | 5720.40 | 11126.18 | 97.996 1dice9wcM 48000 0.73242 | 271032 | 198946 (0.73548) | 71551 | 535 | 262910.68 | 257133.39 | 5454.88 | 5777.28 | 97.803 1dicec9k7 52000 0.79346 | 53579 | 42195 (0.79387) | 10956 | 428 | 54896.71 | 53754.86 | 1187.20 | 1141.84 | 97.920 1dicegEAr 56000 0.85449 | 39908 | 33766 (0.85627) | 5668 | 474 | 58548.72 | 58077.37 | 400.24 | 471.35 | 99.195 1diceDCd2 60000 0.91553 | 54119 | 49144 (0.91567) | 4526 | 449 | 56642.49 | 56234.29 | 0.22 | 408.20 | 99.279 1dice9wVt 64000 0.97656 | 13137 | 12126 (0.98067) | 239 | 772 | 22469.29 | 22074.52 | 239.70 | 394.77 | 98.243 ---------------------------------------------------------------------------------------------------------------------------------------------- small (bets < 4 BTC) | 2684278 | 1099463 | 1570533 | 14282 | 614337.60 | 601241.32 | 225.42 | 13096.28 | 97.868 big (bets >= 4 BTC) | 95981 | 45375 | 50317 | 289 | 2273204.12 | 2240695.62 | 22562.70 | 32508.50 | 98.570 ---------------------------------------------------------------------------------------------------------------------------------------------- | 2780259 | 1144838 | 1620850 | 14571 | 2887541.72 | 2841936.94 | 22788.12 | 45604.78 | 98.421 ----------------------------------------------------------------------------------------------------------------------------------------------
SD Profit before fees: 45604.78423613 BTC (1.579%) Cumulative Fees Paid: 1978.33107500 BTC SD Profit after fees: 43626.45316113 BTC (1.511%) Pending Liabilities: 12.49110279 BTC Final SD Profit: 43613.96205834 BTC (1.510%) ---- Since Satoshi Dice started, there have been: Blockchain Tx: 9057473 : SatoshiDice Tx: 5119162 (56.5%) Blockchain MB: 3865.4 : SatoshiDice MB: 2102.1 (54.4%) ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FKhiBZ1q.png&t=665&c=BcAyOAO27L32mw) ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FJ9kpT2H.png&t=665&c=-NVhEF8-1HhJZQ)
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 09:30:56 PM |
|
I don't really understand that double-spends page - I would expect it to show pairs of conflicting transactions, but it doesn't as far as I can see.
Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge. I found that if I click on any of the transactions on the double-spends page it shows me a link to the corresponding double-spend transaction. I posted about 3 such transactions here, and retep replied, pointing out that these double-spends could have been made by anyone, not necessarily the big spender. I hadn't thought of that before, but it's quite interesting. Anyone can double-spend any transaction they see on the network by rewriting the transaction without needing access to the sender's private keys. It doesn't change any of the inputs or outputs, but it does change the transaction hash, and so changes the SD lucky number.
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
Bugpowder
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 09:32:44 PM |
|
Amazing!
Over 1,100,000 BTC bet this month?!?
That is over TWICE last month's volume, which I thought was insane and unsustainable.
So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.
|
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 09:37:38 PM |
|
Can you figure out, how and where did the coin get to those accounts?
I've looked in the past but got lost in the blockchain. There was no obvious source of the coins, just a bunch of addresses I didn't recognise. So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.
The big loss wouldn't be such a concern if it wasn't paired with a bunch of double-spends on transactions from the whale's addresses. As I pointed out in the previous post, anyone can transmit double-spent bets by padding the signature of an input with an extra zero byte. They can do this only for bets that have won (or lost, depending on which way they want the graph to move).
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 10:04:11 PM |
|
I don't really understand that double-spends page - I would expect it to show pairs of conflicting transactions, but it doesn't as far as I can see.
Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge. I found that if I click on any of the transactions on the double-spends page it shows me a link to the corresponding double-spend transaction. I posted about 3 such transactions here, and retep replied, pointing out that these double-spends could have been made by anyone, not necessarily the big spender. I hadn't thought of that before, but it's quite interesting. Anyone can double-spend any transaction they see on the network by rewriting the transaction without needing access to the sender's private keys. It doesn't change any of the inputs or outputs, but it does change the transaction hash, and so changes the SD lucky number. Bear in mind that it looks like (to me) that the tx was modified to only add an OP_FALSE to the input script. While this doesn't affect the validity of the transaction, it does make it non-standard, meaning that it's not as trivial as just (receive-modify-broadcast). In fact, for this to work, you'd probably need a miner to explicitly help mine it. That's one reason this is suspicious -- it's not just a conflicting transaction: it's a conflicting non-standard transaction that was mined anyway... On the other hand, if I misread where that extra 0x00 byte was going and it was actually padding on the signature itself ... well that's exactly why sipa and gmaxwell have been trying to do: nail down unique representations for every serialized type in the transactions, and making anything that deviates from that non-standard. Then it would have the difficulties of the OP_FALSE description above: the conflicting tx would still be valid, but it would be difficult to propagate since no one would accept it by default.
|
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 10:16:58 PM |
|
Bear in mind that it looks like (to me) that the tx was modified to only add an OP_FALSE to the input script. While this doesn't affect the validity of the transaction, it does make it non-standard, meaning that it's not as trivial as just (receive-modify-broadcast). In fact, for this to work, you'd probably need a miner to explicitly help mine it. That's one reason this is suspicious -- it's not just a conflicting transaction: it's a conflicting non-standard transaction that was mined anyway...
On the other hand, if I misread where that extra 0x00 byte was going and it was actually padding on the signature itself ... well that's exactly why sipa and gmaxwell have been trying to do: nail down unique representations for every serialized type in the transactions, and making anything that deviates from that non-standard. Then it would have the difficulties of the OP_FALSE description above: the conflicting tx would still be valid, but it would be difficult to propagate since no one would accept it by default.
There have been both types of double-spend in the last day or two. I've seen one instance of a zero byte (OP_FALSE) being prepended to the input script, but 3 instances of the signature itself being padded. Both of these ways of changing a transaction's hash can be done by a 3rd party with no knowledge of the sender's private keys. This old thread shows that the issue has been known about for a long time, but apparently isn't fixed yet.
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
Bugpowder
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 10:27:44 PM |
|
The high roller uses the following 8 addresses, by the way: 15HJgkvj6roZQvNRC3pUJNKP2YgfEuD8wo 17sjYPaYJAvtwXM2q5ojzrCiYewnQMBi9y 1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV 1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk 1DBH7Xum2re7LXd8YNSe1uRznttsqeMXGK 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
The 1B5h9sf6xNLYGa3NBk48hwYbxyNZ22PRJk address topped up the 1Di6ux address with a 4104 BTC deposit after it ran dry... http://blockchain.info/tx/4fbce1a17a74947e8714fc43e2d17af36b243ab860ca94eb65f37da0f8de03a1
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 30, 2013, 11:40:53 PM |
|
There have been both types of double-spend in the last day or two. I've seen one instance of a zero byte (OP_FALSE) being prepended to the input script, but 3 instances of the signature itself being padded.
Both of these ways of changing a transaction's hash can be done by a 3rd party with no knowledge of the sender's private keys.
Agreed. My only point was that the one that involves non-standard transactions requires a much more resourceful attacker, since you can't just broadcast it. You have to know a miner who's willing to accept your non-standard transaction. However, padding the signature does not require anything special -- if you have a good connection to the person broadcasting, you can receive the tx, padd the signature with a zero byte, and forward the result to the rest of the network that hasn't seen it yet. It will be "fixed" by the core devs trying to make such transactions non-standard: any signatures with excess zero-byte padding will be non-standard.
|
|
|
|
MPOE-PR
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 09:31:10 AM |
|
Amazing!
Over 1,100,000 BTC bet this month?!?
That is over TWICE last month's volume, which I thought was insane and unsustainable.
So what if S.DICE got unlucky near the end of the month. Variance is part of the game, and is why the whales keep playing. The important thing is the steepness of the red line.
As long as we're sure there isn't a hole, yeah. It's funny to me, because balance has been finally fully realized. Up until this point the only "s.dice is evil" theory was the "it's being fluffed" conspiracy. This would realize a net loss for the 90% shareholder, but arguably that is lower than whatever benefits incurred (publicity, whatever). Now we can have the corresponding "it's being skimmed" conspiracy. This would realize a net gain for the attacker, and a net loss for everyone invested in S.DICE (so both large and small investors are on the same side here). I imagine as the publicly held % varies over time the prevalence of (blind) conviction behind either of these will follow roughly.
|
|
|
|
Kryptox
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 98
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 09:36:25 AM |
|
Yes I read that. I'm a noob when it comes to cryptography. How do you actually verify it? Is there software for this? EDIT: Ok, I guess maybe I'm being unclear. Here is an example of a previous transaction from SatoshiDice. http://www.satoshidice.com/full.php?tx=38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8hmac_sha512(nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz,38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8) -> 003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 003e -> 62 So that's lucky number was 62. How do you get from: ThisnJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GX And this38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8 To this003edf82a3b5a6680a6ede36a573cbf59f7f8d9f1200884755573c66d6d68190 Do we just take it for granted that this is somehow correct? Download and install Python. It's free, and comes with all the crypto libraries you need. Then you can calculate lucky numbers for yourself, as follows. Your example is from before the rule-change of Jan 3rd. Before then, all the bets in a transaction got the same lucky number. Here's how you would calculate it for your example (the bold parts are the parts you type). See how it spits out '62' at the end? $ python Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib, hmac >>> txid = '38f381893d3cdcc8f7ea3e11d098f8e7b4daa60e904a62ef0ab4798fa996def8' >>> secret = 'nJawTR7RIrciXb3JIYp9Qoh7YJ1QALxlnQJw3veDN4UkecWcMNa2woxV6y891GXz' >>> int(hmac.new(secret, txid, hashlib.sha512).hexdigest()[:4], 16) 62 >>> For bets made after Jan 2nd 2013, the lucky number is different for each bet in the transaction, so you need to specify the output number (nout), as follows. Let's use a bet I made as an example, and calculate all 10 lucky numbers: $ python Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import hashlib, hmac >>> txid = 'df7a5cb1ed439f1e0f314cfed88f77ab0f0fdf4a4d2e4714a8287834791fbd95' >>> secret = 'DIGtgGbebAIjJeuh1tlzMW5Xzs8ds0V9azgs40JvWOd24NpFEttZEFM32OHgEqFd' >>> for nout in range(10): print nout, int(hmac.new(secret, "%s:%d" % (txid, nout), hashlib.sha512).hexdigest()[:4], 16) 0 10351 1 37909 2 63099 3 19569 4 13550 5 36796 6 28032 7 53908 8 64653 9 36560 >>> See how they match up with the numbers shown on the SD page (although the SD page shows them in the wrong order, it does now show the 'Idx' column so you can match them up): ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FyrSGfMQ.png&t=665&c=NzAZL2pmeZ9tPw) Thank you dooglus for explaining this so clearly! I didn't realize SD allows you to split a single transaction into multiple bets now. From what I understand, there was an update to the Bitcoin network not too long ago that doesn't actually allow you to use the exact same transaction ID twice.
|
|
|
|
dooglus
Legendary
Offline
Activity: 2940
Merit: 1333
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 07:55:29 PM |
|
Thank you dooglus for explaining this so clearly! I didn't realize SD allows you to split a single transaction into multiple bets now. From what I understand, there was an update to the Bitcoin network not too long ago that doesn't actually allow you to use the exact same transaction ID twice.
It's not splitting a transaction into multiple transactions. It's putting multiple bets into a single transaction. If you're using the reference (satoshi) client, go to the 'send coins' tab and then click 'add recipient' a few times. That way you can send bets to many different satoshidice addresses in a single transaction. You can't send multiple bets to the same address using the standard client, but apparently can with some of the other clients.
|
Just-Dice | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | Play or Invest | ██ ██████████ ██████████████████ ██████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████████████ ██████████████████████ ██████████████ ██████ | 1% House Edge |
|
|
|
|