As you guys have done really interesting stuff in the space if transaction privacy, I'd really like to collect any feedback you have on this:
https://github.com/RHavar/bips/blob/master/bip-bustapay.mediawiki


It's in early draft stage, and I'd especially be interested in how suitable you'd feel it would be to support or if there was something that would make supporting it easier.

(I also have a rough reference impl if something's not clear)

I think game-protect should clearly be banned, he just spews a ridiculous amount of bullshit to drum up his crappy site that does nothing other than ask people to sign up with his referral links. Almost all his posts are just shilling it, or directly linking to it.

While I don't necessarily agree with, I don't think JollyGood should be banned though. Definitely having and bumping 4 different threads complaining about betking though shouldn't be allowed, and they should be merged or 3 of them locked or something.


I agree with your general point though, the quality of the forum is really going to shit. Partly due to unchecked spamming by people like game-protect, and partly by the huge amount of low-quality posts people are (literally!) paid to make as part of their sig/avatar campaigns.

Most of the time, that's going to be pretty awful behavior. Say fees are high, so your algorithm is going to try avoid consolidation for as long as possible. Then finally say there's a big transaction that can only be created via spending the whole wallet at a high-fee time. With very high fee rates, that mistake can easily end up thousands of dollars in fees :/

I suspect most people would rather avoid that degenerate case, and instead just keep a bit extra money in their wallet. Or even erring with a "hot wallet doesn't have enough balance" and topping it up is probably preferable. If you look at the coinsayer API, you'll see it recommends setting maxInputsToSelect to 3. which is the sort of behavior most people want (although you're free to set it to what ever you like, if you don't mind sweeping the wallet like that)

Well yeah. When I ran a wallet, I would never allow it to pick more than 3 inputs for a given transaction. So you'd have an "effective balance" which is much less than the sum of all the utxo values.

You can mitigate a lot of the risk of having a fat wallet, by having a wallet that has a concept of a "min balance" and will never go under it.  So say you have a 100 BTC of utxos, you might want want to configure the wallet to have a "min balance" of 70 BTC.  So under normal circumstances, you're only risking 30 BTC (Say your service gets hacked). If things go catastrophically wrong (e.g. your locked down wallet machine gets hacked) you're risking the full 100 BTC. And then for everything else, you use fully cold storage.

Works pretty well, honesty.  But I guess it depends on how much float you can afford to be using 

I've done a lot of work in this space (see: coinsayer.com). This seems like a reasonable approach for consumer wallets to use, but I don't think it's going to scale very far.

I actually think the most important thing you can do for UTXO consolidation is by going out of your way to avoid creating change. This is a super powerful optimization, and the more utxo's you have the easier it is.


But consolidation transactions are probably always going to be important for businesses, because you can massively low-ball the fees. If it takes a week to confirm, it's not a big deal. But you probably can't be making actual payments with that sort of priority.  Especially services that do batched sends very quickly accumulate uxtos, so being able to reliably sweep them up (cheaply) is important.


On a side note, I've been working on trying to evangelize bustapay which does consolidation at send-time. Which is perhaps not super-ideal from a fee point of view, but it does prevent utxo growth for the receiver, which is kind of neat.

One thing I've always wanted to do -- but have never had the energy for -- was to run multiple implementations of bitcoin (e.g. btcd and bitcoin core) and only transact while they are in agreeance.

For most bitcoin businesses, a few hours of not processing deposits/withdrawals is actually not a big deal, and happens pretty regularly anyway (for no fault of bitcoin itself). While on the other hand transacting after an accidental chain-split could really be devastating.

Any updates on this police raid?

The 100% guarantee is just marketing noise. They guarantee *they* will be up 100% of the time, and on the business plan will comp you 100% of the downtime value. So say they're down for 1 entire day, they'll credit you a whopping $6.66 (and on the free/pro plans, you'll get nothing).

But that's all besides the point, because cloudflare itself is remarkably reliable [1]. The issue is always really on your end (and often because of the sheer volume of abusive requests CF will happily proxy).

[1] The only time I've ever really had issues with CF itself was when battling against the korean botnet guy, who was ip spoofing CF I managed to convince CF to help me out and put me on the experimental websocket stuff. Immediately after they did that, the seoul POP went down.  

For all intents and purposes there's no difference between the plans for anti-ddos purposes. (As of a year ago) I tested all of them, and they all work the same way. The difference is just in the features they offer and the guarantees. They all provide perfect level-3 DDoS protection, decent HTTP protection (but still happily let in huge bursts of traffic, which can overwhelm most services not written specifically for it).

And of course, there are a lot application layer DoS that CF can totally not help with. As a simple example, bitcoin-core will prefer spending confirmed inputs over confirmed inputs. So if a wallet has N inputs, by making <=N withdrawals (before a block) you can force the wallet to have wtf-bad coin selection (and reveal all its inputs). And the wallet is capped a theoretical N*25 withdraws per block.

Nothing insurmountable, but often fighting DoS's is very frustrating. Feels like playing wack-a-mole. I remember spending a week "battling" against this korean botnet owner dude (who had something like >25k computers) who kept taunting me for a week, and pulling off some very clever attacks. A few times I was on the verge of tears

 If the game results were determined purely based upon a server seed, the server would be able to "try" a whole bunch, and find one it "likes" and use that.  That's why there's a client seed, which is controlled by the client.  It's important that the server picks the server-seed first, and it commits to it by giving you the "server seed hash". (should the server seed change, the server-seed hash would as well).

This proves the server seed is picked in advance of the client-seed, and not changing. If you make sure to pick your own client-seed, then there's no such thing as a "bad" or "good" server seed.

That looks correct, although it's a bit weird to have a x/y/z type fraction. It's a bit nicer to simplify it instead as:  (0.99 / M) - (0.99 / (M+0.01))


Which is actually kind of neat, because we can see the structure of it. Before we said 0.99/M is the probability of winning.

So if you look at that formula, it is easy to see that it's "The probability of winning at M  subtract  the probability of winning at M+0.01"

Out of curiosity, how much do you make a month? I assume writing so much nonsense is a pretty tiring job. BTW what ever happened with your imminent police raid on bitcasino lol.


And trying to look at this jackpot issue as objectively as possible, I don't get the problem. Unless someone won the jackpot, but Dean refused to pay them -- which I see no indication of -- this entire thread seems totally retarded.

There's also a sort of irony in the same posters attacking the jackpot for being shitty while attacking Dean for removing the jackpot.

I'm sorry for what ever set of events triggered all this, but you guys deserve major respect for the way you're handling it and not just simply going dark. I like to think that in the future crypto-casinos will lose the "wild west" sort of image they have, and instead be appreciated for the significant advantages they offer. And I really think the way you ran (and shut down) the casino really go a long way to achieving that.

If there's any assistance I can offer, I'd be happy to lend a hand =)

You can adjust your offsite without paying dilution fee. You only pay dilution fee when your (onsite+offsite) goes up. So if you decrease your offsite at the same time as increasing your onsite, you pay nothing (by design)

My guess is its due to bustadice having a multi-party provably fair system, which gives investor there some guarantees that are not offered on any other casino. And not only does the multi-party provably fair system offer some protection for investors against the house playing on the site, it also offers good protection against the casino being compromised (i.e. even if the site was fully compromised, an attacker couldn't predict rolls to make it look like he's a lucky person. So he'd be more restricted to robbing the hot funds)

Well bustabit has a 1% house edge, so the chance of getting to >= X is simply 0.99/X.


 And the chance of not getting to X, would be 1 minus that.



1x bust is kind of a special case. You can't bet at 1x, because there's a 1% house edge it means that 99% of the time you win (nothing) and 1% you lose (everything). This is a bit retarded, so it doesn't even make sense to let people bet at 1x.

So any time a result that comes up that would cause someone betting >= 1.01x  ... it is called a 1x. So to figure out the probability of that, would be:

chance of >= 1.01   is ....   0.99/1.01   ...  or 98.02%
so the chance of not getting it is  1-that. Or 1.98%



...i think

I don't think this is a good idea. Bustadice uses a pretty unique provably fair system that gives investors and Daniel himself much better assurances than any normal provably fair site (including bustabit). Even should the bustadice server and database get hacked, the hacker would still not be able to predict rolls. This means that if a whale comes on bustadice and wins a lot of money, Daniel has very strong assurances the wins are legitimate (or me being also hacked or the hacker). Likewise this ends up extending considerable protections to investors (assuming they believe me and Daniel to be independent).

 And unfortunately these same guarantees can't be extended to bustabit itself, due to the real-time nature of bustabit. And you can't really combine the bankrolls without inheriting the security aspect of the weakest. And I think in practice these are extremely useful guarantees, and should not dismissed lightly. But also taking a step backward, the bustabit/bustadice bankroll both already allow >30 BTC wins which is already higher than any non-busta casino out there. My intuition is that there's probably not much advantage for having a much bigger bankroll anyway, and Daniel's time would be a lot better spent on improving player-facing issues.

I can assure you that it wasn't the design intention (although it's frequently (mis?)used for that purpose).


Hm? I don't think reflects how most people think. I trust Daniel, but it also doesn't make me blind to the fact there are risks in giving someone your money. There's really a lot of potential ways things could go sideways -- but even forgetting exotic hypothetical scenarios, I have no idea if there's a plan in place to make investors whole if he got hit by a bus.

All of these scenarios (and more) fall under "counterparty risk". The solution of course is "don't invest at all" because even when you factor the counter-party risk it can still be profitable -- but it's absolutely logical to try minimize your counterparty risk.


As I mentioned in my previous post, the benefit of doing that would be the difference between losing 1 and 2 bitcoin if the site simply disappeared.  I'm not 100% sure, but I remember Daniel talking about "margin call emails" to warn you when you were getting close. I'm not sure if this is actually implemented or was just hypothetical though.


Unfortunately this doesn't really work. The ideal if a "max whale" is betting is 1x kelly (by definition). But lets say a whale was betting 1/10th the max bet, then the ideal leverage would be 10x. But if everyone dynamically adjusted their leverage like this, it's *identical* to everyone just being at a 1x kelly. So I don't think there's any justification for implementing an actual leverage system, as it's just an unstable way of having the same net result. The whole point of an investor system is so you can support large whales, but a leverage system results in people (either intentionally or by -BRG) leveraging less when whales are playing.   


I'll leave that to Daniel, I'm not entirely sure if I'm still up to date with how it related to the kelly.



In bustabit (in constrast to bustadice) there are two limits. One is the essential "total-max-profit" limit, which is total the bankroll can possibly lose in a single round. But since BaB is a multiplayer game, it is be awful if a single could win the entire thing (and force other players to cash out) which was a real plague in the BaBv1 -- so in the current BaB  there's a restriction that a single player can only win (50? or 75%?) of that limit, so there's some left over to not affect other players.

So normally a whale will be hitting against the max-win-per-player limit, but if they multiclient they'll be hitting against the total-max-profit  ... which will represent extra risk for investors.

At the moment, probably the max offsite if I had to guess. But keep two things in mind:

a) It's very explicitly not a leverage system, it's an offsite system. It's designed to allow you to keep money in your own cold storage, while "risking" it. If you use it as a leverage system, you're probably going to have a bad time.

b) What is "ideal" based on the recent betting, might not be ideal going forward. The last time there was some serious whale action on bustabit, the site profit was 747 BTC and then got totally smashed and finally recovered to 613 BTC. Which makes it look like investors were hurt a bit. But in reality I was invested in that time period, and made a profit. The reason? Some of the overly leveraged investors got margin called on the way down, and the remaining investors made a profit on the up.

Really the entire purpose of offsite investing is to reduce your counter-party risk. But it doesn't do a super great job against maliciousness (e.g. if the house was intentionally draining the bankroll) as to use the offsite system properly you should be topping up your investment. But it provides very strong protection if the site were to suddenly vanish, or something of that nature.

This is a pretty good resource: https://dicesites.com/bustabit

which works for quite a few sites, including crypto-games