While I realize you just meant it as a light "fun fact", I think it's worth pointing out that walletexplorer is very primitive and semi? unmaintained -- and you won't be able to trick any serious analysis tool with a coinjoin like that. [Although coinjoins can do an amazing job at tricking them! But you really need the coinjoin to look like a normal transaction for that]

It's pretty annoying, but a transaction doesn't encode the input amounts or fee. So you have to derive it yourself.

If you look at your first input of your transaction was:


So we need to fetch that transaction and look at the 0th  (first)   output which says the amount ( in this case: 0.01398886 tBTC). When you do that for all inputs, you can calculate the amount of bitcoin sourced. Subtract how much the transaction sent, and the left over is the fee.

---

BTW if you're only looking at unconfirmed transactions, a lot of the rpc methods in core will actually tell you the fees of it.

You always need to design the system to work without notifications (e.g. sometimes you might miss one). So they're kind of always an added luxury. It's pretty easy to build a robust system with no notifications at all (e.g. just poll "getbestblock" every N seconds).



You don't really *need* a notification system. The since you *have* to already cover the case where you miss notifications (i.e. downtime or w/e), the notification system is just a little luxury to speed things up.



What I've done is scan the mempool (hardest) and top blocks to find deposits, and put it in the database was `credited=false` and then only when it gets N depth, set `credited=true` while crediting them.  If you want to get fancy, you should also support *uncrediting* deposits (e.g. in the case of reorgs) which makes it safe to reasonably safe to accept deposits with very small amount of confirmations.


If you want way better privacy properties, use a core wallet for both deposits and withdrawals. Bitcoin Core's coinselection however is really not designed for this usecase, so you'll end up paying a lot more in fees than the 2-wallet approach (since you can consolidate from receive-wallet to send-wallet with super tiny fees) but you'll require less float.

I'd recommend adding them as a luxury later on. You need to make sure your system works without notifications (i.e. incase it misses one). So you can start with polling every 10 seconds or something, and then use notifications to speed it up.


Core has an rpc api you can use

I've implemented this sort of thing probably now like half a dozen times for different businesses, so I'm probably pretty qualified to answer this one.


The way I'd strongly recommend:

Get a trezor, and copy the master pubkey for deriving addresses. Use this to generate deposit addresses.

Create a table in your database with like 3 columns:  (derive_index, user_id, address)  which basically is "We derived X address for user Y by using deriv index Z". Use indexes for all columns.


Now the simplest deposit system you can get, would be to:
* Ask bitcoin core for the best block height
* Subtract N from that, and download that block   (where most exchanges might use N=6)
* Create a list of all addresses that that block "paid"  and then ask your database which of them are deposit addresses.
* Credit everyone who made a deposit.

---

So now basically your deposits should be working, and going into cold storage. Now to process withdrawals automatically, you can use the same core instance as a "withdraw only" wallet and keep topping it up, by sending from your trezor into it (ideally with super low fee transactions).

---

Note: this way is not the best, but it's the simplest. It has pretty crappy privacy properties, but is operationally the most simple and you don't need to worry about dusting attacking or coin-selection gone wild.

I understand your point, but to not mince words, Dean is a scammer and unambiguously scammed the original investors to his great personal profit. He literally structured his ICO such that he would make money when crypto prices went up, and lose money when prices went down. When prices went up, he took the personal profit. When prices went down said "lolz, sorry!"


Not to mention, he's also a serial-liar. Like just today I saw  his post lying about pirating software. I know he's full of shit, because I'm the one who wrote most of that code and it's obviously being used (even before some obfuscation, it literally even had the same debug stuff I was personally using, rofl).


Knowing that, if you want to invest or play -- go ahead. But I do think it's important that people realize they are dealing with a liar and a scammer before they use the site.

I actually don't think whales had much to do with it. Bustabit in the original days was (intentionally!) very unappealing to whales. For a significant time, while it underwent a significant amount of growth with a max bet under $100 USD. So i think the whales came later, after it was popular and had a big history of being trustworthy.

It's hard to know for sure, but I suspect one of the biggest factors was actually the withdrawal system.

As you mentioned, bustabit has consistently processed huge withdrawals instantly without bullshit. Pretty much everyone else screws this up. It blows my mind that other casinos will make people wait a day or more days to get their winnings, so they can "investigate" or what ever. You often get someone who's super happy about having won money (and thus had a great experience) and then stress them out while they're anxiously awaiting their withdrawal. I realize there's a security trade-off to be made, but I'm pretty sure that instantly processing huge withdrawals and wins is the right way to go.

I also think busta* is a pretty neat size, where it's big and professionally run enough so you know it's not going anywhere. But small enough you can still easily talk to the owner, get good support etc.

It doesn't need to be self-contained, but people need to be sure the methodology was decided before the seed was found. (otherwise you can change the methodology of interpreting a hash, if you didn't like how it looks).



You're 100% right. Somehow I didn't realize the "help" had a drop-down. (I actually clicked it to try, but i never noticed the drop down). But I did a really bad job at looking, so I'll give you that. The jsfiddle link is quite obvious in hindsight.



People only care the games are fair, and the hash chain is used to do that. You did prove you didn't grind, the hashchain (since you did the seeding event otherwise correctly) and you're also not doing anything weird (it's just BaB's v1, with a few constants changed) to convert a hash into a game result. So personally I am reasonably convinced the game seeding was done fairly, but I'm not sure it's done well enough to say it's provably fair (maybe "probably fair" is more appropriate?)

So for reference, here's your seeding event:

https://bitcointalk.org/index.php?topic=5133118.0


and here's the part that makes it useless:



Now, for comparison here's bustabit's original seeding event:

https://bitcointalk.org/index.php?topic=922898.0

Now, notice how it says how it uses the hash. (i.e. provides code in the format of "crashPointFromHash").

--

So in summary, bustabit seeding event  proves the *GAME RESULTS* are fair. While yours proves the *GAME HASHES* are.

see the difference?





P.S.  I'd not worry too much about the trust system. It's not a huge amount better than a glorified guestbook (although a lot more complex, i'm not entirely sure how it all works actually but some of the most trusted people are just people who have done a lot of little deals with a lot of other trusted members etc.) .

Yes, I could be more diplomatic. Yes, I could tone down the hyperbole. But each time you just ignore my (legitimate!) point, to emphasis how thin your skin is.  I'm not sure it's a good look.

Your seeding event was done by literally copying bustabit's, but then removed important guarantees. So was this a mistake, incompetence or was this intentional? Are you planning on fixing it, or remedying it?


The whole point of the seeding event is to prove your have committed to a set of rolls, from a fair-distribution and proof you didn't grind it.  If you commit to a hash-chain, but not an interpretation of it, we have no way of knowing if you grinded an interpretation or not. So at that point, there was basically no extra guarantees by even doing a seeding event.

Do you have the code that's used to convert a hash into a game result? From that it should be pretty easy to compute the house edge. I couldn't find it on their website.


They are clearly not a good actor. They have a history of software-piracy, faking stats, not caring about their reputation, etc.


I took a look at their seeding event:

https://bitcointalk.org/index.php?topic=5133118.0


and it's done in a way that proves nothing. Hard to say if it's intentional, or incompetence. But considering all they copied bustabit's seeding event and then removed the part gives me pause.  For the seeding event to make sense, you have to commit to a hash chain and how to interpret the hash chain. Or it's all for nothing.

--

So I guess, why even bother with them? There's like a dozen legitimate bitcoin casinos that run a fair business well, why screw around on the one that's nothing-but-red-flags.

I believe it's 33%, not 50%. As Daniel said 3:1  offsite:onsite.  So I assume it means if your offsite is 3 btc, your onsite should be 1 or greater if you want to further divest your onsite.


So my understanding is there were basically 2 changes. The first which was longer ago was a change of max-offsite ratio of 5:1 to 3:1. No one was grandfathered into the new limit, however the limit only kicks in when investing/divesting in a way that increases your offsite percentage (i.e. no one was forcibly divested).


Then there was a second change, which was effectively setting the max-offsite ratio to 0:1. However, people with an existing offsite were grandfathered in with the old max-offsite ratio (3:1) when divesting onsite, but also restricted from further increasing their offsite.

BTW a neat trick to decrease your onsite:offsite ratio is to invest onsite at the same time as divesting offsite. That means you don't have to pay dilution fee.   (as you're not changing the size of your stake against the "virtual" bankroll)

Not exactly a true vanity address, but I have played with using "private vanity addresses" which are kinda like a vanity address if you know how to "unlock" it.  (e.g. sha256(address || privateSeed)  starts with 0x000000  or something.

And you have the privacy aspects of a normal address, but you (and anyone you give the privateSeed to) have a very quick way of knowing if an address is yours (with a small amount of false positives). It's pretty sweet for scanning the blockchain for instance (just discard everything that doesn't match your private vanity address).

Sure. The simplest would be if you had a lightning node with pre-existing inbound capacity. Then spin up a disposable node, use it spend the utxo into a channel with a 3rd party (make sure not to open a channel with yourself, or it defeats the whole purpose). Use lightning to send everything to your node with inbound capacity. Now close the channel. And destroy the temporary node.

It's not exactly perfect, but it should more or less do the trick.

That's not the case. Like the name suggests the licenses (Actually sub-licenses) are from Curacao, not Costa Rica. (Costa Rica is a popular place to incorporate a casino though, because it effectively has no gambling laws for foreign bets).

And they do not verify the engine (and if they did, it could silently changed, or they verify a different version).


As someone who's previously been granted a gaming license, I can tell you they're pretty much totally useless for a player. I think the only thing they're good for is showing that the company isn't a "fly-by-night" operation as they invested a few thousand in legal and licensing costs.

And if you're cheated by them, it gives you a potential avenue for recourse but it'd be a a pretty up-hill battle. And if they're malicious, they could've even gone through the whole licensing process with totally fake information and be anonymous.


--

So my strong advice for players would be to use a system they can verify themselves (i.e. provably fair) and a long history of being good standing with the community (as that's something worth millions of dollars, no well-run company would want to risk that).  I'd also check out: https://cryptogambling.org/   while I don't know every name in the list, the ones I do know are pretty solid options.

Is this parody? You're recommending a site that scammed investors after doing an ICO, and then suggesting that a site asking for money for an ICO is a "trustable move".

All things being equal, I agree it's best not to expose your pubkey.  But let's not overstate things. For instance here's an address with 69471 BTC on it 1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx  the pubkey is 02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c


That's basically a 350 million dollar bounty right there. (and that's not nearly the only address like that).  The sky isn't falling on ECC just yet.




Address re-use is absolutely terrible for bitcoin-privacy, I think it's the single-biggest thing that makes blockchain analysis really easy (you can do pretty reliable spend-clustering). So I do my best to try encourage people to never reuse addresses, but the direct security implications are pretty minor.

If you're a programmer, generating a bech32 bitcoin address might be a bit easier than you expect if you can import a few libs.

Basically you get the public key in compressed format, SHA256 it. Then RMD160 that. Now you kinda have to do this weird prepend of the 0 byte (for version) and bech32 encode with a prefix of 'bc' (for bitcoin).

Obviously you'll need to use the BIP for a deeper understanding than my description, but it's not nearly as hard as it sounds if you have access to a few libs.

I assume he's referring to the server seed? Pretty much all [1] investing sites you have to put 100% faith in the operator, as the operator knows the server-seed and can use it to undetectably cheat investors.



[1] I think bustadice is a possible exception. But the guarantees are still weak enough that you might as well treat it the same.

I very much agree with your reasoning, but not really your conclusion. I've had a lot of success with bankroll-investing (and margin-lending in fact), but I think the absolute key thing is just being extremely disciplined with how much you invest. Many people have this (imo, misguided) idea of finding a "great investment" and then put a lot of money into it. But I think it's way better to find "good investments" and put a tiny bit of money into them.

There's definitely a lot of high-fixed costs into any investment (e.g. research) but I think it's really worth while even for nothing but practice. Because yeah, as you alluded to -- almost everyone who wants your money for "investment" just wants it for their own pockets.

(Also another important thing about diversification is continually taking your profits out. Otherwise it might only look well on paper, but it's all fake profits (e.g. a nascent ponzi) and you end up having too much exposure).

Apparently Dean is now telling people that it is a misconception that he promised the terms of buy-backs in the first place. He seems to be claiming people who used them as a USD hedge were misunderstanding the terms of ICO. While this is kind of silly for people who were around at the time of Dean repeatedly making such promises (and me having private chat logs of him promising it's personally guaranteed by him and encouraging its use to decrease my BTC exposure just days before he scammed everyone with it).

If anyone has the time, could they help compile a list of quotes of where Dean publicly stated the buy-back policy or endorsed investors understanding of it (especially regarding it being a USD hedge)? It would be nice to have a post to link someone to that definitively demonstrates Dean did make such promises and they were the common-understanding between him and investors.