DICEonCrack attacked?

[nelisky]

So I'm not sure what happened yet, but it looks like diceoncrack.com was caught in a major blockchain reorg, either due to a split or a double spend attack.

I initially believed it was an attack as the rolled back transactions were almost all on the lost wagers, but a closer look made me realize the rolled back tx for winning bets not only existed, but they actually were of a total value of close to the lost wager ones. If it was an attack, it didn't go too well.

We have a few protections against the double spends but there's only so much you can do when accepting 0 confirmation tx, so for now and until I get to the bottom of this bets are processed immediately but only paid out when there's at least 1 confirmation on them, sorry for the hassle.

[1714873119]

1714873119

[1714873119]

1714873119

[1714873119]

1714873119

[🏰 TradeFortress 🏰]

Odd that satoshiDICE is down too...

[nelisky]

Yeah, if the low bet volume we have on DoC gave me a good 10 minutes of anxiety parsing transactions to make sure no foul play was involved (and I'm still not sure) I can imagine what a major block reorg would do to SD...

[nelisky]

Ok, so it was a full on double spend attack and all my prevention methods failed miserably.

Until I find a new way DoC will only process bets after they have been included in a block, but we are trying to come up with a safe way to address this limitation.

[John (John K.)]

Ok, so it was a full on double spend attack and all my prevention methods failed miserably.

Until I find a new way DoC will only process bets after they have been included in a block, but we are trying to come up with a safe way to address this limitation.

Ouch. What was your losses from this doublespend attack?

[deepceleron]

So I'm not sure what happened yet, but it looks like diceoncrack.com was caught in a major blockchain reorg, either due to a split or a double spend attack.

I initially believed it was an attack as the rolled back transactions were almost all on the lost wagers, but a closer look made me realize the rolled back tx for winning bets not only existed, but they actually were of a total value of close to the lost wager ones. If it was an attack, it didn't go too well.

We have a few protections against the double spends but there's only so much you can do when accepting 0 confirmation tx, so for now and until I get to the bottom of this bets are processed immediately but only paid out when there's at least 1 confirmation on them, sorry for the hassle.

You mean to say the win/lose status of the bets are only disclosed when there's at least one confirmation - that is the information needed to know whether to double-spend with better fees to erase any losses.

[nelisky]

You mean to say the win/lose status of the bets are only disclosed when there's at least one confirmation - that is the information needed to know whether to double-spend with better fees to erase any losses.

Yes, I realized that almost immediately after doing the change. In fact it was a good mistake as it allowed me to capture two winning bets from the same attack before they were paid, reducing ever so slightly the loss.

[SRoulette]

Sorry to hear you fell victim to this attack, we as we mentioned were steadily probed over the last 4 days by someone attempting double spends.

Thanks to code monkeys extra security around 0 conf bets, they were either correctly processed of the coins got stuck in the blockchain reorg. We had no losses and even made a modest profit of this would be hacker, no outage or slow downs experienced either

We have tweaked the sites log so that it now links to the txid information on blockchain / abe block explorer and game names now link to the games information pages.

We experienced someone attempting to exploit our site but fortunately all the checks code monkey put into place several months before the relaunch resisted all of them elegantly, monkey earned his banana ration this week

An interesting tx that appears stuck in the blockchain or rejected by it is: 0ecdbe9f27b186b387c5de79861e71d2cc546ca59e322dc02b15331419c90ee3
our own wallet can see the tx but it fails when using the getrawtransaction rpc call.
If and when the bet becomes unstuck it will automatically be processed, but it looks like a failed double spend and blockchain.info cannot see it.

We did notice massively long chains of unconfirmed dependant txid's where the last input transfer was one of our bet addresses.
They appeared to play against satoshidice long enough to generate ~20 dependant uncofirmed txids and then attempt to spend that at our casino and others.

Satoshidice due to the way it works constantly sends out potentially invalid txids, if everyone is playing fair then there is no issue with these payouts made using the players unconfirmed inputs. The attacker was using satoshidice to build a long chain of unconfirmed inputs  then spending the chain on another casino.

They also swapped to sending what code monkey called "pointless and costly" tx's, perhaps they hope to make our coins heavy and increase the running cost of the house ? These heavy txids were eventually validated and processed by our casino and the inputs redeemed without issue.

Stay strong and we hope you did not lose any significant amounts of coin as a result of this attack, keep up the great work on your site.

It may be worth noting that seals with clubs also experienced a massive DDoS and a received ransom demands of 60btc.

[evoorhees]

SD is fine, no losses whatsoever.

[nelisky]

Yeah, we lost a lot more than I care to admit, but the losses were of course limited to the hot wallet, so we'll just have to endure it and move on, smarter and more aware.

[MPOE-PR]

Yeah, we lost a lot more than I care to admit, but the losses were of course limited to the hot wallet, so we'll just have to endure it and move on, smarter and more aware.

What if you had put the money you lost + the money you spent up to this point + the value of your time doing it all into S.DICE stock?

[nelisky]

Yeah, we lost a lot more than I care to admit, but the losses were of course limited to the hot wallet, so we'll just have to endure it and move on, smarter and more aware.

What if you had put the money you lost + the money you spent up to this point + the value of your time doing it all into S.DICE stock?

I would have some S.DICE stock... your point being?

[MPOE-PR]

I would have some S.DICE stock... your point being?

That reinventing the wheel is not the best use of one's resources (unless it's all been a learning experience, in which case it's a net positive).

[nelisky]

I would have some S.DICE stock... your point being?

That reinventing the wheel is not the best use of one's resources (unless it's all been a learning experience, in which case it's a net positive).

I see your point now... but I did not reinvent the wheel at all, you must be confusing diceoncrack with one of the other clones

[MPOE-PR]

I would have some S.DICE stock... your point being?

That reinventing the wheel is not the best use of one's resources (unless it's all been a learning experience, in which case it's a net positive).

I see your point now... but I did not reinvent the wheel at all, you must be confusing diceoncrack with one of the other clones

Registered On   October 14, 2012

Come on, seriously?

[nelisky]

I would have some S.DICE stock... your point being?

That reinventing the wheel is not the best use of one's resources (unless it's all been a learning experience, in which case it's a net positive).

I see your point now... but I did not reinvent the wheel at all, you must be confusing diceoncrack with one of the other clones

Registered On   October 14, 2012

Come on, seriously?

This is really beginning to feel like a meta discussion... So you mean the domain was registered after SD, I'll give you that. Was it based on SD? Sure thing. Is it "just another clone (tm)"? Not at all.

It was born out of a need to extend what SD had to offer. Not a generic need, but a particular need from another member with whom I had the pleasure of working in the past. Did you notice how diceoncrack shares the design with taabl (which is a newer version of the first automated lottery based on bitcoins, for real) and lbaat (which you might notice is different from everything else out there)?

What I mean to say is not that you are wrong at all, the new taabl betting system was an obvious rip off from SD, and DoC is obviously a superset of SD, but rather that you can't just point your finger and say "you are just a script kiddy copying other people's work" without at least doing your homework.

Granted, I could have "wasted" my time elsewhere and/or bought stock of SD, but seriously? I'm not an investor, I'm a coder, and I'm pretty sure our offer is quite different from SD, regardless of it being inspired (ok, that's an understatement) on SD.

But hey, everyone is entitled to their own opinion, right?

[SRoulette]

SD is fine, no losses whatsoever.

Glad to hear, unfortunately it was your sites method of payout that helped enable the attack.

Satoshi Dice lets user create very long chains of unconfirmed transactions, all attacks we saw used Satoshi Dice to generate  a chain of 20+ unconfirmed tx's.
The user then uses the chain of unconfirmed inputs generated by satoshidice and spends them against another 0 conf casino.
The user then takes the 1st unconfirmed input of the chain and spends it with another input that already has confirmations and tada, there is a very high chance of the chain of 20 txids being invalidated.

* Satoshi Dice suffers no loss, this is because they spend the unconfirmed inputs of the bet in the payout thus starting &/ continuing the chain.
Any successful double spend of the bet invalidates the payout txid.  SD may have to rescan their wallet/s to validate their unspent inputs.
* The Attacker Suffers no loss other than normal gambling losses that are reduced by double spending losing bets.
* The attacked casino if it accepts and processes such a long chain of unconfirmed inputs loses.

It is a clever use/ abuse of satoshidice and we guess blockchain.info wallets which provides a nice gui for creating double spends.
There are additional checks you can impose on an incoming txid to avoid this, I will have codemonkey fire off an email to share our method and code if needs be with diceoncrack.

[MPOE-PR]

What I mean to say is not that you are wrong at all, the new taabl betting system was an obvious rip off from SD, and DoC is obviously a superset of SD, but rather that you can't just point your finger and say "you are just a script kiddy copying other people's work" without at least doing your homework.

Trust me, if I think that, I say that, exactly, in those words. I haven't said it, and it's because I didn't think so.

In general both value and innovation are born out of people being unreasonable. Making a clone of something where there's no cause for it is certainly the exact sort of unreasonable behavior that creates value and spurs innovation. This is called being entrepreneurial.

A large part of being entrepreneurial however is being. Unreasonable behavior rarely works out (as it may have been the case here). You have to live long enough to actually entrepreneurialize anything, which is why I took the liberty of pointing out to you the safe play. Not because I'm trying to pressure you into taking it, but because I would very much like to think that you are aware it exists. That's all and nothing more, just be aware it exists. In my (very limited) experience the primary difference between successful entrepreneurs and failed entrepreneurs is a certain guile, a sort of moderation that comes (I think) from constantly judging odds by comparison.

You're not on trial here, and no matter what you may have heard about my fangs and claws, I'm usually being helpful. In my own way.

[nelisky]

You're not on trial here, and no matter what you may have heard about my fangs and claws, I'm usually being helpful. In my own way.

Your fangs and claws? Heh, I'm afraid I didn't know there was a reputation to uphold, sorry

You are being helpful, please don't stop posting your logic particularly when you know it might be useful to others, I wish that was a more common trait. My reasoning, for the record, went like this: So I make this service which allows me to experiment with new things and hopefully improve a very good idea someone else had, there is a set back and your alternative is buy stock... If I was in this for the money then I wouldn't be putting the effort in things like lbaat, right? I though that much was obvious.

So while you flatter yourself a bit when you assume I'm defending myself and not just arguing my point of view, I do appreciate you spending the time to counter argue, as that helps me understand things a bit more thoroughly.

[Herbert]

SD is fine, no losses whatsoever.

Glad to hear, unfortunately it was your sites method of payout that helped enable the attack.

Satoshi Dice lets user create very long chains of unconfirmed transactions, all attacks we saw used Satoshi Dice to generate  a chain of 20+ unconfirmed tx's.
The user then uses the chain of unconfirmed inputs generated by satoshidice and spends them against another 0 conf casino.
The user then takes the 1st unconfirmed input of the chain and spends it with another input that already has confirmations and tada, there is a very high chance of the chain of 20 txids being invalidated.

* Satoshi Dice suffers no loss, this is because they spend the unconfirmed inputs of the bet in the payout thus starting &/ continuing the chain.
Any successful double spend of the bet invalidates the payout txid.  SD may have to rescan their wallet/s to validate their unspent inputs.
* The Attacker Suffers no loss other than normal gambling losses that are reduced by double spending losing bets.
* The attacked casino if it accepts and processes such a long chain of unconfirmed inputs loses.

It is a clever use/ abuse of satoshidice and we guess blockchain.info wallets which provides a nice gui for creating double spends.
There are additional checks you can impose on an incoming txid to avoid this, I will have codemonkey fire off an email to share our method and code if needs be with diceoncrack.

I would not say that SDice and blockchain wallet "enabled" this attack. To begin with, everybody should know that accepting 0-conf transactions is not secure. Repeat: accepting 0-conf transactions is not secure. It is tempting to use and offers great possibilities, but it will always be a risk game against the malicious users.
Having said that, I think including users inputs in the payments is the only effective way you can protect against (this kind) of double-spend attacks. And it is a totally valid and fair countermeasure to use. I am using the same approach on bitbattle.me, probably going even further by fully tracking all inputs of each user separately.
If you can not implement such a safety mechanism on your site then you should change your code or stop accepting 0-conf transactions altogether.

TL;DR:
If you fall victim to 0-conf attack, don't blame others. You knew the risk, everybody and their mother told you that accepting 0-conf is unsafe. It is fun as long as it works, but you have to expect fraud cases.