My Internet connection just came back after being down for 24h or so.  I've not had a chance to look at your recent changes.  One thing I'm wondering about is why the losing streaks on your graphs show up as straight lines rather than exponential downward plummets.  Are you not plotting intermediate losses?

Sure, you can reduce the risk by matching trades, which is why in my example they only had 1 customer...

But even with matched trades, it the price moves too far you end up liquidating the losers' positions (you pretty much break even on those - you can use the money they lose to pay the winners, and keep the spread for yourself) but then you're left with an unbalanced book.  The winners still have positions which now aren't matched by anyone taking the opposite position, since they've been liquidated and so I guess you have to pass their positions on to your hedging accounts at gox.

Ah, yes.

I was misunderstand what an Exponential Moving Average was.  A 10 day EMA takes more than 10 days' worth of data into account.  In fact it takes all previous prices into account, but exponentially less so the further back it goes.

It looks like the formula for calculating EMA is:

  new_ema = last_ema + (new_close - last_ema) * 2 / (periods + 1)

where periods is the number of time periods (10 or 21).

Nice post!  There are a couple of things I'd improve about it, and since it's a quality post maybe it's worth fixing/clarifying the OP:


Define p before using it.  I'm not sure if it's my chance of winning or losing at this point.


In the previous thread, you were using 'round' to refer to "a sequence of plays ending in a win".  I think now you may be using it to mean "a single bet, win or lose".  Is that right?  With martingale betting each round (a sequence of plays ending in a win) ends with a net win equal to your initial bet.  (-1 + -2 + -4 + -8 + 16 == 1) so people may have a target number of these kinds of rounds, giving a target net win.  Or they may have a certain amount of time, and so a target number of bets.  Best to make it clear which you're talking about.


I think I need to multipy by a little more than 1/q to recoup my losses.  If the house edge was 0% then multiplying by 1/q would be enough, but it's not.  To keep the net win the same whenever the win happens, define m = 1/(1 - 1/mult) where mult is the payout multiplier.  This still ignores the fact that you're paid half a percent of your stake when you lose, and are charged 0.0005 BTC on every payout, win or lose).
[/quote]

I regularly post statistics on https://bitcointalk.org/?topic=80312

About 24 hours ago they were 3000 BTC up overall:

The video poker plays well.

One comment: I'd like it to show how much I win when I win:



I bet 10 and full house pays 9x - but I don't see "90" anywhere.

I think there's a misunderstanding here.

payb.tc is asking "can I use 'bitcoin -server' as the SERVER, instead of using bitcoind" - yes, you can

grue thinks you're asking "can I use 'bitcoin -server' as the CLIENT, instead of using bitcoind" - no, you can't

The confusion arises from the fact that bitcond can act as both an RPC client and an RPC server, and bitcoin can act as both a graphical app and an RPC server.

Hope that clears it up!

It shouldn't matter whether you use bitcoin -server or bitcoind - they should react the same way to RPC calls.

I'm unable to reproduce having bitcoin fail like it is for you - but also I've not been able to find version 40101.

I only see the following tags in the repository:

$ git tag -l | grep v0.4
v0.4.0
v0.4.00rc1
v0.4.00rc2

and when I build v0.4.0:

$ ./bitcoind getinfo
{
    "version" : 40000,
    [...]

the version string is 40000.

I'm using Linux not Windows.

I'd suggest updating to a recent version of bitcoin and see if that fixes the problem for you.

I'm also wondering what happens if you try running bitcoind from the command line rather than using the PHP interface:


You may find you need to omit the single quotes around the {...} in Windows - I'm not sure - try it with and without.

I've been using nothing but Linux for many years.  I've tried a bunch of different distributions but usually end up with Ubuntu.  I used Arch for a while and the documentation is great, but there was something about it which I just couldn't live with.  I forget which it was now - maybe it used to freeze every 24 hours or so.  Or maybe the wireless Internet wasn't very reliable on it.  Something like that, which I couldn't find any solution to other than switching to Ubuntu.

Also, when I was using it the packages weren't signed at all.  If the repository I was using was every compromised, Arch would happily download and install trojaned packages.  I read that there were plans to upgrade the package manager to be able to handle signed packages, and to start signing the packages, but don't know if that's standard practice now or not.  That seems like quite an oversight for a serious distribution.

I just built a version 4 bitcoind.  I didn't let it touch my wallet, so I don't know if it would work fully, but it gets as far as complaining that the account I'm sending from has insufficient funds.

Can you try code like this and tell me what it shows?

Do you get any kind of an error message when it quits?  Is there a logfile with errors in maybe?

Where did you get your copy of jsonRPCClient.php from?

What's 40101 the version number of?

I was made aware of it by one of Derren Brown's TV shows - possibly this one.  I'd check but I think the storm outside is making my Internet connection too flaky to do anything much at the moment.

The charts are from gnuplot using data generated by a modified version of the extras/sample_armory_code.py script in the armory git repository.

What do you see if you do this:


The var_dump should show you what's going wrong.

Maybe it's
  "PHP Fatal error:  Uncaught exception 'Exception' with message 'Request error: {"code":-6,"message":"Account has insufficient funds"}'"
or
  "PHP Fatal error:  Uncaught exception 'Exception' with message 'Request error: {"code":-13,"message":"Error: Please enter the wallet passphrase with walletpassphrase first."}'"
or some such other error.

It should give you an idea of what's going wrong though.

(FTFY)

Try typing Hayek on a German keyboard and see what you get...



The 'y' and 'z' are switched:

After all that unpleasant maths back the your regularly scheduled tables of numbers and graphs...




I noticed a sharp drop of 100 BTC or so on the red line about a day ago and looked to see what happened.

This bet is responsible for the loss.  2 BTC on each of lessthan 1500, 2000, 3000, and 4000, with a lucky number of 920 winning all 4 bets.  A 223.90897599 BTC return for an 8 BTC outlay!

As I understand it he aims to make withdrawals as pain-free as possible without actually making them automatic.  See these 2 quotes:



I imagine the goal is for him to be able to look at the list of requested withdrawals, see that they look reasonable, and click something to submit them to the computer that actually has the ability to make the payments.

That makes sense, and is I guess how it worked.

Assuming the price of BTC started at $10 and ended at $1, when the customer closes his position you can buy back the 100 BTC for the $100 you made by selling 10 BTC when the customer first shorted, so you end up with $10k and 10k BTC again.

The problem is that now your 10k BTC are worth only $10k, whereas before they were worth $100k.  You've lost $90,000 on the deal by being long BTC while the price crashed.  Maybe this is why Bitcoinica borrowed BTC from customers, so they wouldn't be exposed to the currency risk.

Here, for 6 heads in a row.  The expected length of a round is the sum of the probability of each outcome times the length of that outcome:

Outcome	p(Outcome)	len(Outcome)	p(Outcome)*len(Outcome)
T	1/2	1	1/2
HT	1/4	2	1/2
HHT	1/8	3	3/8
HHHT	1/16	4	1/4
HHHHT	1/32	5	5/32
HHHHHT	1/64	6	3/32
HHHHHH	1/64	6	3/32
			-----
			63/32

so 63/32 flips.  The expected number of rounds to get 6 heads is 64, the expected length of each round is 63/32, so the expected number of flips is 64*63/32 = 126.


... and you were, a couple of times...    But only in little ways.

This reminded me of both Penney's game and the discussion around this question, both of which you may find interesting if you didn't see them before.