Operation Acquire Bitcoin And Screw Bear Shorts

[tvbcof]

Operation Acquire Bitcoin And Screw Bear Shorts

Overview:

This is a system for a small group of people (as in 4 or 5) to
achieve two simultanious goals.

  1) Acquire BTC for long duration holding.  The author hopes
  that eventually such a possition can be put to use in
  furthering the goals of the Bitcoin project if they are indeed
  benevolent.

  2) Give bear shorts another thing to worry about and an
  occasional haircut if it can help facilitate #1.

*Note:  This system would be useful to any group who wanted to
join forces to manipulate markets.  I offer the idea in this
form (and forum) because I sense that it would be diffcult
to find more than two 'bear shorts' who would cooperate on a
project without exploiting it for personal gain and thus ruining
the effect.

Participation:

The low number is choosen because it is difficult to agree on
things and get things done with a higher number of people.
Although the described system seeks to limit these, there are
significant risks and trust relationships which need to work,
and that is exponentially difficult with more people involved.

The low number of participants indicates a relatively high
degree of capitalization.

One member of the group is elected as the 'trader'.  This person
will need to be very knowledgeable about trading and have his/her
finger on the pulse of the market.  I'll call this participant
the 'server' which happens to also represent a piece of software
under his/her control.

The remaining participants would be what I will call 'clients'.

Stack:

The 'server's job is to 'play' the markets accourding to a
strategy which will ultimatly achieve the desired goals of
the project.  The software he runs will have the ability to
understand the resources available for trading and execute
trades with coordination and precision.

A client keeps his own account and changes the amount of capital
involved at his descression.  The trades are made _by the client_
from his current capital pool, but at the direction of the
'server'.

Periodic meetings are held to communicate broad strategies and
expectations.  This will give the clients some level of compfort
as they watch their trades occur, and the server can understand
better the kinds of resources he can expect as well.

The IP and port upon which the server listens could shift
at will, though it would need to be communicated to the
participants of course.  This could provide some way to mitigate
against DDOS if somehow the addy in use was leaked.  Downtime
should not impact the system greatly if it were to occur.

Protocol:

The client pings the server once per unit time (5 min, 1 min,
whatever) with a unique, per-hit, URI.  Part of the URI is
a random hash which is generated from a key issued to that
particular client (think two-factor auth.)  In this way the server
can have confidence which client he is talking to, and that the
client is legit.  Various algorithms can also detect and respond
to fraudulent use as well.

A message would include information about the current funding
pool which the operator of the client has set.  In this way, the
server can understand the resources at it's disposal and the
client can make real-time djustments to the funding as well.

Occasionally the server will provoke a trade as a response
to the URI hit.  In this case, it would be an instruction to
execute a certain trade at a certain time in the future.  Say,
thirty seconds past the minute, and a follow-up one 32 seconds
past the minute.

I would anticipate that sophisticated trades would involve
both a high degree of coriography, and also a desire to do
different things with different clients in case things are being
monitored.  I believe that the system I've described could
implement this.

Risk:

The biggest risk is that the server could execute some really
bad trades and the clients end up with loss.  Accruing a large
loss would take some time, so attentive clients could mitigate
the damage by withdrawing support.  Some strategies might entail
a period of loss, but they could be communicated as describe
above, and disproportionate outcomes as a result of deliberate
mis-syncs between clients could be settled at that time.

Another risk is that participants would set up their own
side-bets taking advantage of the knowledge gleened from being a
member of the group.  I suspect that if a gentelmans agreement
about this was not sufficient, then such abuse would become
apperent over time should it deter the success of the system
generally.