It sounds as if the attacker only got the hot wallet, but that unfortunately there was no cold wallet.

It beggars belief that people are still not using offline wallets for the majority of the coins they're responsible for.

I was in a hurry yesterday when I posted.  There are more options, including the one Seal proposed.  He suggested converting BTC into AUD at the current price, but allocating it to creditors at the old price.  Let's call that option Z.

In Z, we sell the 1 BTC for the new price of $10, but use the old price to calculate the total debt ($1 + $1 = $2).  So we can pay everyone out 500% of what they're owed: A gets $5 and B gets $5.  Actually that seems to be exactly the same as (X) above, except that everyone is paid out in dollars, not bitcoins.

From a practical point of view, I'd rather pay out in bitcoins.  Then I don't have to work out how to make international bank transfers, etc.  Paying Bitcoins is much easier.

I agree with Patrick that (Y) seems to be the fairest option.

I suspect that if put up a claims page, some percentage of accounts will remain unclaimed.  I have no way of contacting account holders; WBX never collected email address (although I expect Andre has a significant number of emails from disgruntled customers in his inbox).  It seems likely that the amounts in unclaimed accounts could offset any new creditors which come to light.  But that's just a guess; I have no way of knowing for sure how many customers made deposits which never got further than Andre's bank account, and never touched the WBX database at all.

You know what would be even more profitable and sustainable than running HC Lottery and HC Invest?

Just running HC Lottery.

Why run a -EV game at all?

My stance:

* I'd like to get payments made ASAP
* I don't have a full list of creditors, so don't know what percentage I should be paying everyone
* Andre is ignoring (or not getting) my email
* I am not a lawyer, and don't know what I am allowed or required to do with the funds I'm holding.

I don't know how to proceed from there.  I still have the 1800-ish BTC safe and sound.

As for what rate to use when paying out, I have been thinking about that.  Here's a simple example to try to make the picture clearer:

Suppose there are 1 customers.  A has $1 in his accounf and B has 1 BTC.  At the time trading stops the price is $1/BTC.  The $ goes missing but we have the 1 BTC still.  Then the price goes up to $10/BTC before we pay out.  I see two cases, X and Y:

(X): If we pay out using the old $1/BTC price, total debt = $1 + $1 = $2, we pay out 50%.
A gets 0.5 BTC = $5 and B get 0.5 BTC.

(Y): If we pay out using the new$10/BTC price, total debt = $1 + $10 = $11, we pay out 90.9%.
A gets 0.091 BTC = $0.90, B gets 0.909 BTC.

In X, where we use the old price, the dollar holders end up with more than they were owed, while the BTC holders end up with less.
In Y, using the new higher price, everyone gets the same fraction of what they were owed.

Y looks like the fairer case to me.  What does anyone else think?  Can someone make a case for dollar holders to be making a profit on the dollars they were holding when the price of BTC goes up?  Maybe I'm missing something.

It would be pretty trivial to make a web page that lets the user copy/paste in the txid and block hash and have it display all the bet hashes, winnings, and a total.  Perhaps offer 2 different addresses - one which counts the payment as a single bet, and one which treats it as a series of 0.25 BTC bets?  That way people can decide whether they want the variance or not.

I've seen some pretty wild accusations from Strike Sapphire people before; my girlfriend was accused of not existing, even though she had previously engaged in a Skype audio call with the management and I've seen a player accused of being US law enforcement for no apparent reason.

Evidence doesn't seem to matter; accuse first, think later seems to be the policy.  I think maybe alcohol plays a part in the problem, but can't be sure.

2000% of 10 is 200.  You don't just multiply, or 100% of 1 would be 100.

I wonder if people are sending 40 separate 0.25 bets rather than one single 10 BTC bet because that way they have 40 separate chances to 'win the jackpot'.  Perhaps you could treat a bet of 10 BTC as 40 separate 0.25 bets and calculate the winning for each separately (but appending a different number to the txid or block hash before rehashing it, and sending the resulting winnings in a single output.  That way people get the reduced variance of betting lots of small bets without needing to spam the network.

Also, I'd suggest not mentioning the original 0.25-only address in the OP, since that's the one people see first.  Some probably stop reading before they get to the new address at the end of the OP.

2000% of 10 is 200.  You don't just multiply, or 100% of 1 would be 100.

I wonder if people are sending 40 separate 0.25 bets rather than one single 10 BTC bet because that way they have 40 separate chances to 'win the jackpot'.  Perhaps you could treat a bet of 10 BTC as 40 separate 0.25 bets and calculate the winning for each separately (but appending a different number to the txid or block hash before rehashing it, and sending the resulting winnings in a single output.  That way people get the reduced variance of betting lots of small bets without needing to spam the network.

Also, I'd suggest not mentioning the original 0.25-only address in the OP, since that's the one people see first.  Some probably stop reading before they get to the new address at the end of the OP.

I would have provided a payment address at the time of the bet, and had it written into the contract.  For 10k BTC it's worth someone hacking the forum software to be able to send a PM as Vandroiy but giving their own deposit address.

I don't mind if someone wants to send me 10k BTC while I'm in a tent in the rain.  It will be perfectly secure until I get back to civilisation (he writes, from his cabin in the rain in the middle of nowhere...)

There's a very interesting and informative post here:
  https://bitcointalk.org/index.php?topic=87656.msg1145478#msg1145478
about how a gambling site can make sure that they have an almost zero chance of ever running out of coins to pay winners out with.

What's wrong with that is that if you allow people to borrow anonymously you vastly increase the probability of them never repaying their loan.  I didn't see any details of how you're going to credit check your borrowers, but if you let people somehow automatically and anonymously 'borrow' from you, I don't think you can expect to get many of your loans repaid.  Some people would be honest, but I suspect that most would think along the lines of "I'm not going to lose any reputation, and I'm not going to get into trouble if I don't repay this - some I won't repay this".

Maybe the loans won't be anonymous, and you're proposing some automatic way that I can prove I'm creditworthy to your script.  I'd like to see how that works...

Why not allow any amount between stated allowable min and max values, all to the same address?  If the value is not acceptable, you treat it how you currently treat any non-0.25 value.  I don't think you need to use different addresses or limit your users to certain round numbers.  If you're willing to accept 'bets' of 5 BTC, why not also accept bets of 4.932345 BTC?  That way people don't have to send multiple transactions.

You could even offer to split bets that exceed the maximum up into multiple bets of the maximum, and find some way to generate a different hash for each such bet.  Perhaps by re-hashing the txid after appending the bet number to it.  So instead of comparing the last digits of txid with block hash, you compare the last digits of sha256(txid + "0") for the first such bet, sha256(txid + "1") for the 2nd, etc.  Then I can "invest" an arbitrary amount without spamming the blockchain.

"JSON, or JavaScript Object Notation, is a text-based open standard designed for human-readable data interchange" -- http://en.wikipedia.org/wiki/JSON

It's just a way of formatting strings.  Since the server has two things it wants to keep secret, but doesn't want to flood you with too much information, it combines the two things into a single string of text before hashing it.  JSON is just a convenient way of doing it.  So if the server_seed is "xxx1" and the initial_shuffle is "yyy2", the secret formed by combining these two pieces of information would be:

{"server_seed":"xxx1","initial_shuffle":"yyy2"}

and that's what ends up getting hashed and displayed before the game starts.


That's the part I guessed would be a stumbling block.


Mersenne Twister is an algorithm for shuffling a list into an apparently random order.  It's not really random; it takes a list that you want shuffled and a number (called the seed) that determines how the shuffle will happen, exactly.  If you always use the same seed, you'll always get the same shuffle, but use a slightly different seed and you'll get a completely different shuffle.  It's a little like hashing in that respect.


Understood.  I guess it's hard to know how far back to basics to go when giving such an explanation.  I notice Mersenne Twister is linked to a page that explains it, but SHA256 isn't, for example.  I've gone through the process of explaining all this to someone with no relevant knowledge myself, and it can take a while to get through to them, even when you have immediate feedback of which bits they're struggling with.


So I guess a separate explanation for 'non-geeks' would be useful.  The specifics are important, otherwise there's no point in having it "provably fair".  The method used needs to be explained fully enough that though who care and technically able can go through the motions themselves and verify a few hands.

Trouble is by then everyone's got twice as many chips as me.

When someone has a much worse hand than you but calls your big bet anyway when they really should have folded, and then proceeds to get just the card(s) he needs to beat you, he has "sucked out" on you.

Say I have 2d 7d, and you have 5c 5s.  The flop comes 2s Kd 5h.  I have a pair of 2s, you have trip 5s.  I bet, you raise, I put you all-in and you call.  Then we see Qd 8d on the turn and river.  I've sucked out on you by catching a runner runner flush.

The reason you see a lot of suck outs on seals, especially on the freerolls, is that people are playing any two cards a lot of the time, and not caring whether they lose because there's another freeroll in less than an hour.  Play for play money on any poker site and you'll see the same thing over and over.

That's the first I heard of it.  I googled for it and found the article:
http://www.forbes.com/sites/jonmatonis/2012/08/31/bitzino-and-the-dawn-of-provably-fair-casino-gaming/


Did you read https://bitzino.com/about/fair ?  If so, is there something in it that's hard to understand?  Or is it just that you prefer to watch video than to read?  Or are you getting hung up on issues like "what is a hash"?

https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html goes into more detail, but I don't know if that's just going to confuse you more, since I've no idea what bit you're having trouble with.