Notice how everyone trying to minimize this situation has a DaDice signature.

Unfortunately for DaDice, sig jockeys aren't a stand-in PR team.

Login and go to https://www.moneypot.com/investment

Current stats:

http://i.imgur.com/ryBBup4.png
(1,000,000 bits = 1 BTC)

They have a quick tut on how to do it yourself: http://raspnode.com/diy.html

The fact that this works makes the DaDice operators in this thread look super cringeworthy since it's been revealed before on multiple occasions.

e.g. just two pages ago: https://bitcointalk.org/index.php?topic=973765.1380

Instead of posting condescending images, consider fixing your site guys.

It baffles me to see dooglus pumping a random toycoin.

It's not "guys". It's just "guy". One guy that quit while he was ahead, which is the only action in this game with +EV outcome on a long enough time scale.

Eric already pointed out that OP needs to comply with the license. It was simply ignored. Eric posted again to rescind his support for this project until OP complied with his license. OP responded with (my words) "we're both in a field that's full of scummy actors, so what did you expect? Despite what the license says, I'll open-source it only if I feel like it" (link).

Unfortunately for OP, problems don't go away just because the other party can't be fucked to babysit you on an internet message board.

Thankfully, this community has Dooglus — sleepless watchman, crusader of justice — who has a long history of contributing his time to expose dishonest actors. That's one of the reasons he's laden with trust-clout which was used to annihilate OP's trust-rating and spur him into [slow, begrudging] action.

Cringe.

OP immediately abandons the few qualities that matter in this scene: trust and character.

Maybe your CSS modifications will make up for it.

The bulk insert is applied atomically, but each inserted row still has to respect its constraints.

One big reason you'd want to accumulate rolls in-memory and then commit them to the DB in bulk is if each roll needs to be applied sequentially to the DB and you don't want sequential roll insertion to be the bottleneck.

For example, imagine if each roll needs to calculate the total house bankroll to adjust the edge of the roll. The bankroll changes each roll. If each roll has to hit the DB server, then you're going to be dealing with a lot of insert contention.

Instead, let's say you only make one DB insertion at the turn of each second. As rolls come in, you buffer the results in memory (assured that the DB cannot change during this time) and then commit all the rolls at once.

Here's an idea: imagine if you write a function `roll(prevDB, params)` that returns `newDB` where prevDB and newDB are just associative datastructures that represent the state of the DB in memory.

That means you can `reduce(roll, prevDB, [params, ...])` where `[params, ...]` is a sequence of user roll parameters coming down, say, a websocket.

At the turn of each second, you stop the reduction, take the latest newDB value (the result of all the buffered rolls), and commit it to the DB. The post-commit value of the DB is now your `prevDB` that you feed back into the reduction and resume processing rolls.

The main point of focus for building a gambling site is ensuring data/domain integrity at the database level.

You need to be able to answer questions like:

- What happens to in-flight DB transactions when they fail or the app crashes?
- Are all of your domain-atomic data updates wrapped in transactions? For example, if the server crashes right after you increment my account balance but before you decrement your house bankroll, is my balance rolled back or did you just persist a bad ledger?
- If your provably-fair mechanism depends on sequential, gapless nonces (like Just-Dice's "bet number"), can you actually guarantee a gapless sequence? For example, AUTOINCREMENT in MySQL and SERIAL In Postgres do not produce gapless sequences.
- What do you do when the values change out from under your DB transactions? If some button should only increment a value in the DB once per hour and someone double-clicks it (launches two queries in flight at once), is the value incremented twice (bad)? Is it incremented once only because the queries both incremented the initial value (bad)? Or is it only incremented once because the second query fails because of your one-increment-per-hour domain constraint (good)?

The stack you use for your application layer matters very little because what matters is your ability to sufficiently answer these types of questions.

Insightful interview!

Although the US Fed usually has the internet spotlight, don't forget that your own country has a national reserve authority as well.

That's not how auditing works.

If you were to be audited by the IRS, they generally start at a very transparent transaction (like the purchase of a house), then work backwards to determine the source of funds. The onus, of course, is on you to lead them down the trail, and the general case is that your paid taxes don't add up to expended funds, so they extrapolate your purchase history as unreported earnings. Then you're retroactively responsible for those taxes + punitive fees and possible litigation.

It's no different than if you launder money. No matter how complicated and untraceable your laundering practice is, investigation starts at wherever your money rears its head in a transaction and you're going to have to explain it. The government doesn't just "give up" if it's too complicated: They just place the burden on you to uncomplicate it, else they attribute the disparity to negligence (at the very least).

I'm not a lawyer and this is only my observation.

This is precisely one of the reasons why advocates of a central monetary authority (like the Federal Reserve) want to keep a unary legal tender.

You can't arbitrarily inflate or manipulate a currency when there is no barrier to using other currencies.

I can convert it to a Drupal theme when I get home to my desktop computer this weekend (nothin' like cruising the Bitcoin forums on Spring Break).

I'll make the download bar more minimal and push it to the top of the page below the navigation so it doesn't interrupt the flow of information. There are other tweaks that have been suggested since that was posted.


That's a good idea that keeps trivial changes from getting bottlenecked by you or Sirus.

edit: I see that partyp made another version. I'll go ahead and convert my mockup into a Drupal theme just for some closure and post it here.

What do you mean by Bitcoin-based?

I logged in and posted a test project successfully, but now I get an error when I try to visit the website.

Haha, yeah. That's like spending old American coins (like war dimes) that were made with silver. You can still slot them into vending machines, even. But you're slotting away something worth far more than 10 cents.

It's more accurate to say that government-mandated coins are legal tender, and some of them happen to be made with precious metal!

The answer to this actually answers the OP question of why it's important that Bitcoin gains prevalence as an accepted method of payment.

What gives currency value is the existence and high-availability (currency liquidity) of transaction counterparties -- that somebody always wants to be at the other end of your transactions. The second you can't find a buyer for your Bitcoins or a seller that will let you buy into the Bitcoin system, Bitcoin no longer has value. After all, the value of a Bitcoin (like the USD->BTC conversion rate) is a direct measure of how many people want Bitcoin.

Until there's a commercial market for Bitcoins, all Bitcoin counterparties are fellow speculators and investors and the Bitcoin exchange is fueled by fickle things like novelty rather than reliable things like food and the human desire to buy things that we don't really need. The intrinsic value of a currency isn't its ductility or conductivity (i.e. gold) -- they are flatly irrelevant --, but actually the reliability and ease of finding a counterparty to your transaction. A commercial market is what entrenches the transactional reliability of a currency. It creates cycles of exchange and networks of trade that entrench and distribute the investment of the currency across a lot of people, which increases the chance that there's always someone out there that wants to trade with you.

There's some talk in this thread that portrays a future system that's any different than what it is today.

It doesn't have to be. And it probably won't be.

Waiting for confirmations to propagate is impractical for the same reason today's vending machines won't accept checks: Confirmation takes too long.

That's the whole reason why we have electronic spending with credit and debit cards. It's what enabled our fractional reserve system in a global economy. Your assets are just a number in a database that only represents Dollars, Bitcoins, and Zloty.

The instant transaction layer on top of Dollars and Bitcoins means that the actual transaction of real currency can take an arbitrary amount of time (if it even happens at all!).