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?

How does the secret compute against the Transaction ID to produce the lucky number?

Quote

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.

You obviously know what you are doing 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

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)

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?

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?

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:

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.

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

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.

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.

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.

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.

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?

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:

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):

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.

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.