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.mediawikiIt'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.
|
|
|
Another important requirement was that if there is a spendable balance on wallet, and a payment order comes to spend this balance, it should be sent - the developer using an API should not bother about if there enough big utxo available, or if the transaction limitation might be hit, or whatever - if there's enough funds for the order amount (and network fee, if the fee is taken from the wallet, and not from recipient) - send it, use every utxo available, even if it means sending several txs.
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)
|
|
|
Yes, but if you have too much small utxo, and you need to send large payment at inconvenient time (when fee is high) - you will pay a premium, as delaying payment is often not an option. Also you might hit transaction size limitations, and will need to send several transactions to satisfy one payment.
Holding both fair amount of big utxo and a lot of small utxo in hot wallet might mean your hot wallet balance is higher than necessary, and your risks are also higher.
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 bitcasino.io fraud scheme is irrevocably crushed and very soon it can happen that the police will confiscate wallets and then customers will not be able to withdraw like it happened with btc-e.com!!! Yes, if and after wallets are confiscated, you can submit your claim to the police, but the authorities will first take the $ millions evaded taxes and fees and we do not know if thereafter will be something left. You are warned and if you will lose money it is your own fault!
|
|
|
There is almost no difference between Free and Pro but there is a significant difference between the Free/Pro plans and the Business Plan because paying $200 per month guarantees "24/7/365 uptime". Paying $200 per month should guarantee virtually any site uptime so to read you tetsed it and it did not work sounds strange.
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.
|
|
|
If the previous owner was tired of the DDOS can you please confirm which Cloudflare package was being used (Free, Pro at $20pm or Business at $200pm).
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
|
|
|
Hi guys, I know all provably fair casinos (for dice games anyway) create the roll result by combining their server seed + the client seed but how can you know if the seed generated by the casino server is truly fair? What if you were betting on rolls 10> but they altered their seed so it has a bigger chance of generating a <10 number? Thanks.
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.
|
|
|
What's the probability of it busting at M? Would it be: 0.99/M-0.99/(M+0.01)
For example, probability of busting at 1.02 would be:
0.99/1.02-0.99/1.03=0.97058823529411764705882352941176-0.96116504854368932038834951456311=0.00942318675042832667047401484865
Probability of busting at 10:
0.99/10-0.99/10.01=0.099-0.0989010989010989010989010989011=0.0000989010989010989010989010989
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"
|
|
|
Were players aware that the odds to win is 10 billion to one?
Advertising a literally not winnable jackpot is the criminal offense of willful deception!
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.
|
|
|
Hello guys,
This is William/Baryom, I have a good news ! We will reopen soon and let only the players with a balance to withdraw it. You won't be able to deposit/play/chat etc.
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 =)
|
|
|
I'm slightly "leveraged" (not really, I have those coins outside) and after considering this, I regret my decision. For now I'm not changing anything as it sucks to remove the offsite amount after having paid the dilution fee, but I wouldn't use any offsite amount from now on unless this is changed.
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)
|
|
|
Has anybody an idea why Bustadice currently has a higher bankroll than Bustabit?
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)
|
|
|
2. What's the formula to know the probability of bust before a round reaches X?
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. Some more questions:
1. What's the probability of bust at 1?
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
|
|
|
4. I insist on please checking a way to share Bustadice and Bustabit bankrolls for those of us interested, it would in practice make both bankrolls bigger, maximum bets bigger, and expected returns from investing higher. Good for everyone.
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 understand the purpose of allowing offsite investments, but I bet it's mostly used as a proxy to use a higher Kelly multiple (leverage).
I can assure you that it wasn't the design intention (although it's frequently (mis?)used for that purpose). I doubt people investing are worried about counterparty risk. If we didn't trust Devans, we just wouldn't invest at all.
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. If I'm willing to invest say 2 BTC, because I like the investment and I trust Devans, why would I invest just 1 and have to spend all day watching for whales and be ready to deposit the other BTC if things go wrong (and still trust Devans at that point, which some investors wouldn't as they may be suspicious)?
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. Even considering that some leverage was optimal, having to manually adjust it and monitor the investment makes it way less attractive than if it was automatic. Allowing investors to choose to risk up to 0.5, 1, 2, etc. Kelly (as you explained in a previous post) would be way better and we could stop that "offsite" farce. I think there was already a casino using that method, Safedice if I remind correctly.
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. Right now, using 1:2 leverage would mean that a max bet would be 2 times the Kelly criterion?
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. I read mentions to people multiaccounting involving a higher risk for the casino, but I didn't understand that part well.
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.
|
|
|
Considering the distribution of bets, what would be the optimal leverage ratio? If people were constantly max betting, then no leverage should be used, but the fact that most bets are smaller (safer for investors), should make some degree of leverage optimal.
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.
|
|
|
Is a history of Bustabit profits posted anywhere?
This is a pretty good resource: https://dicesites.com/bustabit which works for quite a few sites, including crypto-games
|
|
|
|