Topic: PROFITS - ATPx [Automated Trading Platform eXtended] - page 5. (Read 7655 times)

Python is a much better "glue" programming language than JavaScript.

In a trading strategy, You can need for example to get/fetch "news" or various data

Python will be much more convenient for that purpose.

That's a nice idea and those are cool tools, but this is written in Java not Python.
We aren't saying let's develop a new language, we're talking about exposing the internals of the system via an existing scripting language such as Javascript, to allow more granular control and a faster turn around time for custom strategies.

Otherwise I would just leverage algo-trader http://code.google.com/p/algo-trader/wiki/AlgoTraderDocumentation#Strategy_Development

You should have a look at

goxtool: ncurses based MtGox live monitor and trading-bot-framework
https://bitcointalksearch.org/topic/ncurses-based-mtgox-live-monitor-and-trading-bot-framework-148462

and

zipline / Quantopian - backtesting / trading framework
https://bitcointalksearch.org/topic/m.2165581

Python is a very nice language for writing trading strategies

It will be nice to add to a backtesting framework to goxtool
(using something like zipline)
and to add other exchange to goxtool

I don't think that developping a new language is a good idea.

I agree, and it would be quite possible to have each Signal expose itself to the Javascript API.

BTW here is the way the new ATPx modular API works.
A module is a completely self contained mini-app, it implements runnable and has 0 or more dependencies.

Each instance runs a single ExchangeModule.  
The ExchangeModule, among other things is responsible for listening to Ticks coming from the Exchange.
Every time a tick is captured, it passes the tick to a SignalManager.  The signal manager's job is to record the tick to the DB and relay the tick to all subscribed signals.

A signal is a discrete unit of logic and is comprised of 3 elements, Direction, Amount and Intensity.  For instance if the VWAP for BTC doubled in price, the signal would be VWAP|Advancing|100|1.0 (This was done to allow DSP's to more easily digest signal data).

Trading logic (aka individual trading modules or strategy modules in some parlances) subscribe to the individual signals it needs, notifying the signal of it's interest, and then is notified that a signal has changed through the trading logic's onSignalChanged method.

A javascript based trading logic module would just subscribe to all available signals and use onSignalChanged as its entry point.

VWAP cross then becomes a simple


Of course Object here would be converted to an Order and then handed to the ExchangeModule, but that would be handled seamlessly in the background by the javascript trading logic module.
This would allow you to change trading logic on the fly fairly easily.

Thoughts?

kinda lost me at the moment with the syntax

but saying that I thought AIDOATP trading logic was a bit alien ( I'm talking just the config file,  I am no Coder)
now can quite happily change and play with it at leisure

Im sure if I saw other working examples of the syntax I would get my head around it

early days yet

was just looking at TA-lib

now think I need to go back to school.................  sigh!    

I will be the simpleton test monkey!!

Interesting. It uses a simple enough syntax for new users to understand yet could be very flexible and powerful for people familiar with JavaScript.

My original idea to use a trading logic in AidoATP kept things very simple by keeping everything boolean.....easy to understand logic and easy to code. A couple of months ago as part of a discussion with daybyter I had toyed with developing a more comprehensive trading language using ANTLR.


I think daybyter tried to get some discussion started on a similar idea on a Formal definition of a trading language but I'm not sure if it got off the ground.


But why create a whole new trading language syntax when something similar to a eclipsetraders JavaScript syntax can give a lot of power to experienced users but still be relatively simple for new users to pick up.

Not really, Holy Grail is just allowing peer discovery via bitmessage, i.e. you don't need a domain name or IP address.  Our code base has the same thing and calls the concept Whispernet.  You put in the whispernet address of the other bot and the message system finds them.  The message has the potential to execute actions, hence it's opt in, probably with a whitelist. 

For instance if you put a BTC-e connected ATPx instance in Russia and a MtGox connected one in Tokyo, neither of those exchange connected servers would need to know where the other is located at, just which whispers to listen for.  They would then work out on their own how to solve arbitrage windows and you could profit from this.

Process looks something like this.

I put up a MtGox bot, you have a BTC-e bot.
They chat back and forth about currencies and an arbitrage window is noted.
It's buy on BTC-e and sell on MtGox with a 5USD spread.
The two bots agree as follows.
 
1. BOT1 - SELL|1 [email protected]
2. BOT2 -  BUY|1 [email protected]
3. BOT2 -  XFR|1 BTC[BOT1.BTCADDR]
4. BOT1 -  XFR|102.5 USD.OKPAY[[email protected]]

You'll note that the only part of this that actually needs to execute is 3 & 4 though, so the entire thing is the plan, but 3 & 4 are the contract.

Yeah you're probably right.

I don't understand the need for trust.  If the payment is non-reversible what do you gain?  I can understand this in regard to trading but not everyone trades.  Many people just buy or sell or buy and hold or mine and sell; the number of people who trade and need trust is small.  I also think this is off topic and you run the risk of diverting the audience from the "task at hand".

My BTC0.02

hhmmm.

The first thought that came to mind was what happens with a dispute between a highly reputable party i.e. very high trust score and party with a low trust score. As the score is logarithmic, the 'pain' of a dispute is unfairly weighted on the party with the higher trust score.

Or am I totally misunderstanding the concept?

Slightly off topic, have you been following developments here: https://bitcointalksearch.org/topic/the-holy-grail-i-wish-i-could-kiss-the-author-of-bitmessage-on-his-face-212490 and here: https://bitcointalksearch.org/topic/holy-grail-bounty-225954

My head hurts trying to understand it but it seems to negate the need for trust or reputaion: http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure/834#834

This has nothing to do with the altcoin I was mentioning before and altcoins aside, I've come to realize as I'm building this that there needs to be some sort of trust based system in place for the peer 2 peer exchange element to really take off.
I want to bounce an idea off you guys.

Imagine a trade scenario like this...
I have paypal and it's in good standing, I've never issued a single chargeback, but because there are lots of folks who have, there is no easy way for me to convert paypal to bitcoins and of course the reverse.  There is always the risk of a chargeback.

However if someone knew that I was reputable, then they would probably take paypal for my bitcoins and vice/versa.
But how do I prove to the world that I'm trustworthy?

How can we enforce trust in this system?  Specifically how can we disincentize bad actors while encouraging good actors.
I'm envisioning a trust-chain.  Similar to bitcoin's blockchain but comprised exclusively of reputation credit.

For each transaction that completes successfully, there is a report made to the system and both sides get 1 point. 
However if a dispute later erupts, either side can relay the dispute and the trust-credit is automatically revoked for both. 
Here's the kicker though.  Trust is semi logarithmic.

To get a trust score of 1 requires 10 transactions, 2 is 100, 3 is 1000, 4 is 10000 etc.
However a dispute will take you down 1 whole step.

To prevent the obvious hack of filling a million transactions between machines you own, the trust score would need a regulation mechanism, i.e. a max increase per period of time, so perhaps it takes a month to go from 1 step to another and that counter resets each time a dispute is filed.

Note that this would just be a publicly viewable shared database, it's not intended for use as a currency, coin, store of value or money transfer system.  It's just meant to be a reputation management system.  It's intended to reward good actors but to severely punish bad actions.  First reputation is added and then disputes are subtracted from the logarithmic total.  So if you have a dispute it will take you 10 times as long to get any future step as someone who had no disputes.  There are also those who may chose to only deal with established operators who have a year or more with no disputes.  To prevent blackmail or extortion, it would probably be a good idea to have a dispute expire out after a fixed length of time such as a month or a year if there are no other disputes in that time frame and to also limit dispute counts against you to 1 per party, but since both sides take a reputation hit, either of those may not be necessary steps.

Thoughts?

Got my eye on this too

Sounds like I should get some more disk space

And also a pref option on the location of the space

As my system disk is a small Ssd

watching

You are understanding it completely
I just don't want to announce until I'm sure of 2 things.
#1 it will work
#2 it won't cause anyone to violate the law

Here is a sort of pre-announcement.
The value of the crypto coin will itself be pegged at some ratio of XDR the IMF's special drawing rights currency. 
This will give it stability even in the face of significant market fluctuations in 1 or more fiat coins.

It will not be similar to bitcoin, litecoin or any other crypto coin. 
It will be a metacoin that can be freely exchanged with these but the exchange rate will be fixed on a daily basis.

Unlike any other crypto coin, there will be no single canonical blockchain.  I'll have to explain how that part works later, but the jist is you should be able to spend your funds without any more information and connectivity than could be placed on an EMV compatible smartcard.

It's based on the thought that generation, validation and spending are different actions and different paths through the same system.

Furthermore the generation process is completely different from any other alt coin.  To generate funds you have to do more than simply add hashing power.  You need to donate real computing power and real storage & network capacity.  The rate at which you generate currency is directly proportional to the amount of computing, storage and network capacity you add to the system as well as your proximity (in terms of ping time) to other miners.  This means that currency generation could never be asic'd even if the validation of the currency can be.  It also means with this altcoin you are much better off with a run of the mill desktop computer, than with a GPU, FPGA or ASIC rig.  It also means you can use the miner for this currency to mine other crypto-coins (including bitcoin & litecoin) simply by adding it as a "useful work" request and spending into it.

Clearly this is not something I can implement at the moment.  ATPx provides a framework to allow for it and thus ATPx is the first step of many along this pathway.   It will present itself a nothing more than a currency module for ATPx.  When it's ready to roll, anyone running ATPx will be able to participate in it simply by enabling it as an option and setting their donated CPU, Storage space and Network speed allotments.

Wow I'm really excited about the mention of this new altcoin! If it can somehow be traded between OpenPay clients as a representative of value of various currencies this might pave the way to a decentralised exchange between OpenPay clients!

...Or am I misunderstanding the implications of this completely?

I've had a couple of PMs about this so I figure I'll answer these questions here so I don't end up repeating myself.

The whispernet system (and by extension the GUI) will utilize the FIX protocol for communications.
Specifically the QuickFIX/J implementation.

Also the bitcoin wallet will probably just be a loose wrapper over bitcoin RPC so you can communicate with whatever wallet you want (make sure it's configured for RPC over SSL).  
It should also make dealing with other altcoins easier.

I modified the original description to include a description of currencies and wallets.

You can run multiple bots on a single machine.  The purpose of having each exchange run as it's own bot is to prevent the whole system from crashing just because an exchange changes something (*cough* MtGox's cheapy SSL certs *cough*).  This allows you to quickly determine if the software puked, or if they changed something.  (Oh my MtGox bot is offline, maybe I should investigate it). 

It also makes scaling easier later on, eventually I envision that there will be exchanges in every country specializing in their own particular market.  The current design uses 1 thread per currency per exchange that needs to go away.  Even on my Quad Core laptop it's taxing to just trade all the pairs on MtGox. 

Having a single thread per module makes a lot more sense and so does having them put their data into a DB or a memcache structure of some kind if latency could be an issue, then communicating between themselves using a whispernet.

One other design change I failed to mention.  There will be a wallet for each supported currency.  I will definitely be implementing a bitcoin wallet and will likely implement a litecoin wallet if I can find some help on it.  Our own internal altcoin will also of course have a wallet in the system, but the new altcoin is the subject of another discussion because I need to ensure that it will pass legal muster first.  For the record, the internal altcoin won't have any particular preferential treatment in ATPx, ATPx will just treat it like any other currency. All currencies can be handled through the use of individual wallet modules, someone just needs to write them.

 

The cost is free, it's an open source project.  The costs for commercial modules will depend on the supplier.  
For the ones I create, I won't be able to provide long term support to individual customers so my plan is to sell the distribution rights to the highest bidder with the expectation that they commercialize it.  What they charge will be up to them.  My business plan entails taking the proceeds from module sales and using it to fund the other aspects of the OpenPay ecosystem that need cash (smartcards, regulatory fees, etc).  Then OpenPay will be gifted to the community.
If they want to charge a percentage or a yearly or monthly licensing fee or just a one time cost that would be up to them.

Those who participate in the development of ATPx like Aido will of course have a license to commercial modules for whatever purpose.  It's just that for instance a true AI, would technically constitute "the giving of investment advice" and so I'm not sure it can be sold by anyone who isn't a licensed stockbroker.  It wouldn't stop the adventurous from participating in the development and using their copy for their own personal gain though.  

Yeah Aido I hope so.  Your programmable trading logic is going to need to be broken out into a seperate module and frankly I'm not 100% sure on what half that stuff does. 
I will get you specs as soon as I finish writing them.  At the moment the entire spec is in my brain waiting for me to code a reference implementation and a harness to test it.

We will be moving off the current system of tracking the tickers in an array list and instead store them in a DB and having the ticker monitor for an exchange fire an event to registered listeners when a tick occurs.  It will be up to the listeners to fetch the historical data from the DB (they will get the current tick though).
That is the key difference from your perspective.