WizardWatson p2p commodity price algorithm

[David Watson]

I posted this on the "agile banking" google group, reposting here for
those here not on that list.
****************************************************************************************************
If anyone's interested..big if maybe, as you have to believe that I
have structured the problem in a meaningful way in order for possible
solutions to be meaningful.....here's a brief explanation of the
"market pricing problem" in the context of a decentralized monetary
system.

Forget any user-interface concerns for the time being as all this
commodity/currency/relative pricing can be completely abstracted away
for basic users, and can be abstracted enough for advanced users to
have no problem with the concept.

In order to have p2p 'money' everyone needs to be able to trade with
everyone else, and there is no commodity common to all nodes. Using a
graph diagram, we can imagine this scenario as a type of bi-partite
graph where commodities are nodes of one type, and members who own
certain shares of those commodities are of a different node type.
Member nodes only connect with Commodity nodes, and vice versa.

Now in traditional economic theory given perfect information,
eventually the market will come to the 'true price' of the
commodities. In the real economy this manifests as an array of prices
compared to the standard exchange unit. So our governments in an
attempt to stabilize, focus on stabilizing the 'price' of money, and
when they can't, all their actions pretty much amount to damage
control, when our 'equilibriating' market starts acting like bull at a
rodeo, trying to rid itself of huge pockets of malinvestment.

In a decentralized model, the chaos is baked in from the start. There
isn't any money or market.

So one of the 'core' algorithms that I can foresee would be something
like:

1. Users set conversion rates between commodities
(currencies,guarantee socities, etc.)
2. Algorithm calculates median conversion rates compared to global
total.
3. Users collectively alter to the algorithms calculated "best fit"
conversion rates.
4. Execute transactions.

What an algorithm like this would allow, is each user would be able to
execute a transaction at the same price no matter what path the
payment resolution takes. There are obviously other issues related to
payment resolution and free-riders that also need to be addressed, but
many of these issues have already been hashed out.

The algorithm requires the user set conversion rates between all the
commodities/currencies he has on the system, and also that the user be
assigned some % share of that commodity (for the weighting, its
conceivable to have other designs where the weighting is based on some
different metric than % ownership, but in most cases you could
transform whatever other metric you use into a % share for algorithmic
purposes)

The other condition is that there be at least one path from each node
to every other node. If you actually try to do this in a simulation I
came up with an algorithm for this part of the process that works
pretty well.
--------
SUB-ALGORITHM: this is only part of the 'main' as yet unfinished, not
proved, could be goose chase algorithm

The sub-algorithm tests graph connectivity (at least one path from
every node to every other node) from the assumption (I'm too lazy to
write proofs, or even look them up) that if the graph is connected as
described, you should be able to remove one commodity node at a time
in such a way that you never have more than one member node that only
has one connection to a commodity node. In other words, you should be
able to remove commodity nodes in such a way that it doesn't split the
graph and leave any members disconnected.

With a small random graph sufficiently connected you can find a 'clip
order' most of the time randomly. But once the ratio of
nodes:connections per node becomes sufficiently high, the graph become
too irregular. To solve this I assign each commodity node a number of
connections to other unique commodity nodes, by doing a one-hop path
search. I then start clipping the ones with the lowest connections.
This method finds a clip order 99% of the time for random graphs with
100000 commodity nodes, and average 10 connections per node.
----------
So that's the sub-algorithm that gets you a clip order of commodity
nodes. I'm using this clip order as the order in which I 'merge' the
commodities. Once I've merged all of them I have one node remaining
and x number of members whose % share is now comparable to global,
then the second pass of the algorithm would go backwards finding and
assigning the median 'fictitious market equilibrium values' and
extrapolating the median conversion rates from it.

Current status is I'm actively working on it. I'm at the point where
it's working through 75% of the process, but still buggy (I've never
claimed to be a great programmer, I do work for the government after
all). When its in its working I'll be happy to share it, there isn't
really any magic contained therein that I haven't explained on here or
else where anyway.

Well, these are the basics, if anyone wants to take a crack at it,
make an observation, or even better, show me where someone has already
solved this! that would be splendid. : )

-David

[Thomas Hartman]

> Forget any user-interface concerns

so, for me, as you can probably guess, this is putting the cart before
the horse.

For everyone else, if you're looking for algorithm feedback/fixes, I
would suggest posting your working code with failing tests, and say
what tests fail and why.

It's a lot of work to wrap your head around someone else's algorithm / code.

--
Thomas Hartman

Darcs hosting: patch-tag.com
Build a webapp with haskell: happstack.com

[wizardwatson]

On Jul 20, 11:55 am, Thomas Hartman <thomashartm...@googlemail.com>
wrote:

> > Forget any user-interface concerns
>
> so, for me, as you can probably guess, this is putting the cart before
> the horse.
>
> For everyone else, if you're looking for algorithm feedback/fixes, I
> would suggest posting your working code with failing tests, and say
> what tests fail and why.
>
> It's a lot of work to wrap your head around someone else's algorithm / code.

Everyone has to find their own way, and my take from most of the
people on these boards is that there are a lot of lone wolves. I
think this makes us on the whole, better problem solvers but worse
collaborators.

I try not to be too off-putting, but usually fail it seems. As you
say, it's barely accomplishable to wrap your head around your own code
and algorithm's, I'm not trying to be judgemental of the projects of
others, I'm only sharing my strategic opinions and ideas, in hopes
that it might help generate a sufficient consensus on the problem,
that real collaboration can emerge.

I don't really have the technical credibility to judge the specifics
of what anyone is working on, especially being barely aware of any
details. I point out things as I see and understand them and welcome
correction.

The fact that we're here talking here at all, to me is a positive
sign. But as for more collaboration than simply playing email tag, I
think the only consensus we've formed so far is as you said on the
agile banking thread:

"There's something wrong with the financial system, and something
needs
to be done about it. "

-David