Stable pricing algorithm?

[bearbones]

Considering the volatility of the exchange rate, I've temporarily abandoned any automated exchange rate pricing.  I had been using the 7 day average of mtgox.  Right now that is 21.6929.

It seems to me, though, that an automated system will always be the fairest.  I've often updated exchange rates and wondered how a big jump would be taken by a customer perusing prices.  If some judicious weight of the available rates and averages can be written into an algorithm, the price changes would be far more gradual.  Has anyone implemented this sort of system?  What is the most judicious algorithm?

The easily available rates are:
30d average
7d average
24h average
24h high
24h low

These can be weighted however yields the best result.  Obviously, there is no ideal solution.  Given some market assumptions (say, long term deflation) it seems easier to determine which side to tip.  The following code is a simple script I threw together to update the bitmunchies exchange rate as per http://forum.bitcoin.org/index.php?topic=14278.0.  If you read the terms of the sale, you will see that it is intended to be an extreme case.  I would like to moderate the extremity of the deflation assumption for use after the sale ends.  I'd appreciate any comments or critique.

Code:

<?php
$markurl = "http://bitcoincharts.com/t/markets.json";
$markjson = file_get_contents($markurl);
$markprices = json_decode($markjson, true);
$high = 0;

for($i = 0; $i < sizeof($markprices); $i++) {
    if($markprices[$i]['symbol'] == "mtgoxUSD") {
        $high = $markprices[$i]['high'];
    }
}

$wpurl = "http://bitcoincharts.com/t/weighted_prices.json";
$wpjson = file_get_contents($wpurl);
$wprices = json_decode($wpjson, true);

$peg = 32;
$day = $wprices['USD']['24h'];
$week = $wprices['USD']['7d'];
$month = $wprices['USD']['30d'];

$price = $peg;
if($price < $month) $price=$month;
if($price < $week) $price=$week;
if($price < $day) $price=$day;
if($price < $high) $price=$high;
$price = round(1/$price, 3);

try {
    $update = "UPDATE currency SET rate=".$price."' WHERE code='BTC'";
    mysql_query($update);
} catch(Exception $e) {
    die("MySQL error: couldn't update exchange rate.");
}
?>

[1714771667]

1714771667

[1714771667]

1714771667

[1714771667]

1714771667

[1714771667]

1714771667

[bearbones]

No comments, but for any silent readers, I've advanced this concept a bit.  The following is an updated script, which will publish a json array with various weighted rates.  Some key figures are:

array['bbrates']['sale'] => current bitmunchies exchange rate
array['bbrates']['retail'] => proposed retail exchange rate
                                      takes the mean of the following: 24h average, 24h high, 24h low, sell snapshot
                                      then subtracts mtgox exchange fee for final rate
array['bbrates']['saleperc'] => percent off of retail at current sale rate

You can see current rates here.  This is updated every 15 minutes.  Feel free to use/modify the concept for calculating rates for yourself.  I intend to keep the linked rates.json file up to date, but you should use at your own risk.  It will almost certainly change structure, as I continue development.

I believe that the current retail rate is fair.  It will lag, but also takes outlying values into account.  For instance, the 24 low and sell rates are currently dragging retail price down significantly.  This is currently resulting in a retail exchange rate higher than mtgox.  On the other hand, if we rebound from this low and sit near the high, the opposite will be true.  Some catch for extreme price movement (i.e. capping at standard deviations) might even things out, but I haven't run the numbers yet.

Again, I'd appreciate any thoughts you may have on the fairness of this system.  If you were buying something from bitmunchies, how would you feel about paying the proposed retail rate?

Code:

<?php
$peg = 32;

$sale = $peg;
if($sale < $month) $sale=$month;
if($sale < $week) $sale=$week;
if($sale < $day) $sale=$day;
if($sale < $high) $sale=$high;

$retail = ($day + $ticker['high'] + $ticker['low'] + $ticker['sell'])/4*(1-0.0065);
$lowfee = ($day + $ticker['sell'])/2*(1-0.0065-0.0015);
$normfee = ($day + $ticker['sell'])/2*(1-0.0065-0.0035);
$saleperc = round(($sale-$retail)/$sale, 2);

$bbrates = array("peg" => $peg, "retail" => $retail, "lowfee" => $lowfee, "normfee" => $normfee, "sale" => $sale, "saleperc" => $saleperc);

$jsona = array("ticker" => $ticker, "averages" => $averages, "bbrates" => $bbrates);
print json_encode($jsona);
?>

[xaxistech]

I would take the rate from the previous week, and the average rate from the current week, average those 2, and then get a good average.

[bitoption]

Just to jump in here; most traders think in terms of VWAP; definitely germane to the bitcoin pricing discussion.

Volume Weighted Average Price; that would be a useful metric to publish, and keep track of.

[bearbones]

Just to jump in here; most traders think in terms of VWAP; definitely germane to the bitcoin pricing discussion.

Volume Weighted Average Price; that would be a useful metric to publish, and keep track of.

That is a very good point.  I hadn't considered weighting volume, thought it would be quite useful in thin markets.  This seems like it would take a massive computing effort, though.  I can't see any way of doing this except getting the volume of each order and then putting them in with the rest.  Is there some easy way to do this, that I'm missing?

[bitoption]

Nope.

That said, VWAP on Gox is easy to calculate using the websockets interface. You could even introduce some simple time decay if you wanted to get fancy.