Bitcoin Forum

OpenPay is a project I've been working on for over a year now, mostly behind the scenes with the goal of bringing cryptocurrencies, from Cyberspace to meatspace.

The OpenPay project consists of an entire ecosystem and is comprised of, a new altcoin (more on that later), an FPGA scrypt miner, a properly licensed currency exchange, a financial services company, an EMV qualified smartcard, a new payment network, and the ATP or Automated Trading Platform.

The ATP is a key element of the OpenPay ecosystem, because for cryptocurrencies to truly enter the mainstream (and by mainstream I mean for merchants to feel comfortable with them), there needs to be greater price stability.  There are also legal and regulatory hurdles to overcome, but we need to solve some technical issues first.

I am fortunate right now to have about 90 days of downtime starting this week.  During this time I will be working like mad to complete OpenPay and all it's components.  
I have the help of a few talented programmers and of course we're looking for more volunteers.

My first foray produced the Isis-ATP product which I had to temporarily abandon in the middle of a major refactor.
Aido was kind enough to carry on with it and make significant improvements on it during my absence.

However I'm looking at page after page of issues stemming from the initial design choices, and if I had the chance to do it over again I would do many things differently.  Therefore I will continue to make patches and improvements on the Isis-ATP mainline via Aido's version, but there will be a definite EOL to my participation in this branch in the near future.  IsisATP will eventually be replaced with the next gen system called ATP eXtended or simply, ATPx.

ATPx itself is part of a project called PROFITS.
PROFITS stands for PROFessional Inter-exchange Trading System and as it's name implies it will focus mostly on arbitrage across exchanges.  

Because it's built on top of ATPx it will still feature all the good parts of ATP like customizable programmable trading logic for seeking opportunities on a single exchange.  
In fact, much of the existing code will be copied over, stripped of it's dependencies on outdated APIs then converted to use limit rather than market orders.
This will form the core of the new engine.  

The distinguishing feature of PROFITS is a secure "whispernet" that you can enable (disabled by default).  
The whispernet feature is designed to allow you to run a private cluster of bots that can communicate and coordinate trades across exchanges in realtime.  
The plan is for you to run 1 bot to per exchange.  Each bot will have it's own identity, similar to a bit message identity.  This means that you can choose to run solo or you can swap IDs with friends, and you will automatically be able take advantage of arbitrage opportunities even on exchanges you don't have an account on (you will be able to configure limits to this as well).

A group of ATPx bots cooperating together make up the PROFIT System.
  
Ever wanted to arbitrage across exchanges, but don't want the hassle of holding accounts on both?  
You can do it with PROFITS!  

The new design for ATPx is greatly simplified and much more modular.  
It is designed to be easy to extend and maintain so new users can jump in and fiddle with things and power users can do amazing things.  

ATPx is comprised of a core set of features called the ATPx engine.
The rest of the functionality is implemented as modules.
There will be modules for each exchange.
Trading logic will also be pluggable in the form of modules.  
This means if you'd like to use a stochastic oscillator instead of the default VWAP Cross, you just drop it in and go.

There will be a common API for these modules, so it should be a simple matter to add a new exchange or new trading logic by dropping a module in the modules directory and telling it to reload.

Trading Logic Modules...
I will only be implementing VWAP Cross trading logic for the trading module, there will be other trading modules such as a stochastic oscillator and a pure AI module available commercially.

Everything Aido implemented will also be carried over and I will attempt to put it into a module with his assistance.

The first exchange modules will be for BitBox.mx (formerly BitMe), MtGox.  BTC-e will follow along shortly after.
I am doing it in this order because what little funds I have are all on these exchanges, thus they're the only ones I'm planning to build for at this time.

I will take requests for additional exchanges in this thread, however I cannot promise that I will be able to get any, or all of them implemented in the time frame that I've got.
The hope is that others will pickup on the module concept once the API has been specified and develop extra modules, even if it's a commercial effort.

Currency Modules & Wallets...
Currencies and Wallets are implemented as modules.  For our purposes a currency is something you can actually manage within a wallet without the need for an exchange to facilitate transfer in almost all cases this will be crypto-currencies, the sole exception I can think of is CAD which may have a path for electronic trading via their new "MintChip".  I'll have to look into that further before I can make a comment on it.   This is different from currency pairs which are managed virtually on an exchange.  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 a path for it. 

Our own internal altcoin will also of course have a wallet module 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.

Potentially all currencies can be handled through the use of individual wallet modules, someone just needs to write the modules.

Finally, there will also be a GUI that you can run to communicate with your ATPx bots.  
This GUI will communicate over a secure encrypted connection to get updates in realtime.  It will use the same whispernet system that the bots use to communicate with one another, so you will be able to stream live trading data direct to your GUI and literally see what your bots are thinking.
By doing it this way if someone wants to offer a better GUI, it can be built directly on top of the protocol.

I hope you find this exciting.  The work to do this has already begun and the first commits will occur this week.  
There will be a defined weekly development cycle and I've got a project plan I will make available on the OpenPay github site in the coming days.
Enjoy!

I'll be the first to ask for CampBX to be added.  :)

Great news

Yes I am one that will pay for the Ai version

One question

If your billy nomates or simply don't trust anyone

Are you able to run multiple bots on one machine or would you run them in different VM's?
Love that idea of the cross market trading

Also

Do you have a rough idea on cost

Or have a version that take a percentage of profits

Or even. Have an introduction offer for early buyers  ;)

So many questions,

Thanks

exciting and ambitious stuff!

I'll assist wherever I can.

Yes very. Can't wait

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.

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.  :)

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.

 

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

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.

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?

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.

watching :-X

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

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?

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://bitcointalk.org/index.php?topic=212490.0 (https://bitcointalk.org/index.php?topic=212490.0) and here: https://bitcointalk.org/index.php?topic=225954.0 (https://bitcointalk.org/index.php?topic=225954.0)

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 (http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure/834#834)

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

Yeah you're probably right.

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 BTC.MTGX@USD.CURRENT
2. BOT2 -  BUY|1 BTC.BTC-E@USD.CURRENT
3. BOT2 -  XFR|1 BTC[BOT1.BTCADDR]
4. BOT1 -  XFR|102.5 USD.OKPAY[bot2@myemail.com]

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.

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 (https://bitcointalk.org/index.php?action=profile;u=49866) 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 (https://bitcointalk.org/index.php?topic=130966.0) 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.

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!!

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?

You should have a look at

goxtool: ncurses based MtGox live monitor and trading-bot-framework
https://bitcointalk.org/index.php?topic=148462.0

and

zipline / Quantopian - backtesting / trading framework
https://bitcointalk.org/index.php?topic=202808.msg2165581

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.

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

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.

Jython?


http://wiki.python.org/jython/

Quote:

• Embedded scripting - Java programmers can add the Jython libraries to their system to allow end users to write simple or complicated scripts that add functionality to the application.

I think it will probably be easier to just embed Javascript, but I guess there is no reason it HAS to be javascript.
http://docs.oracle.com/javase/6/docs/technotes/guides/scripting/programmer_guide/

Been playing with integrating scripting and it's coming along pretty well.
I think it will make a great addition.

As a proof of concept, I was able to integrate the MtGox ticker stream by using the weberknecht Java based websocket client and then exposing it to the scripting engine.

Obviously I will put this back into Java, but it was just neat to try it out.  We officially have a MtGox ticker now which is at least half of what we need for the exchange module.

Wasn't there a java scripting framework back in the days?

Yes there is and it's what I used to get those results.  
It doesn't support websockets directly though.  Hence the need to bring in the weberknecht java websocket client and expose it via the scripting API (so I could run the mtgox ticker in javascript for a quick test).

For the record I could have just as easily written the glue in python/jython, groovy or a host of other languages.  JSR-223 is as it turns out pretty widely used.
I'm not a big fan of python, it's not that I have anything against it in particular, but I've never found a problem that could be solved in python any easier than I could solve the same problem in Java.  Nevertheless I'm also not a fan of language lock-in and I have nothing to contribute to the great language debate that hasn't already been said.

So when you go to ATPx you will be able to pick your scripting language for writing your particular custom logic.
I'm going to stick with Javascript for demonstration purposes.  But be advised that the choice of language is runtime configurable and you will be able to mix and match to a limited extent.  Script variables that are set in the scripting context are not shareable and a single script file must be in a single language,  but any module exposed to the scripting logic will tend to be a singleton so modifications made to it inside of one script will persist to another.  That persistence is not an intentional design choice on my part, just a side effect of the way things are put together because modules are generally singletons. (except where they're not, which isn't that often as it turns out).

I wholeheartly agree with your comment on java vs python...that's why I still use java, even if the folks at IRC greet me with 'java must die'... :)

I don't really understand, why the scripting framework needs sockets, since I thought, your framework connects to the exchange? But don't get confused by my silly comments and keep rocking the trading world with java!!! *thumbs_up*

Ciao,
Andreas

Where's the github for this again? Or are you working under Aido's fork? I'm getting a little lost as to what code is what these days...?

Thanks in advance and great work :)

I got my own code and just released the API implementations so far:

https://github.com/ReAzem/cryptocoin-tradelib

Yeah sorry didn't mean to confuse with that.  The test was to see how deeply I could ingrain Javascript and if I could use it to directly implement a module.
Most .js won't ever need to touch the sockets ever.  However they're there if someone wants to do something custom later on without resorting to messing around in the internals etc.

Ok guys, good news and bad news.  The bad news is that I've been away for a bit. I am now finishing up a document for someone else and then I have 1 month with
nothing but 80 hour weeks on this particular project.

Still, I've been away for a bit and haven't had a chance to code since my last post on the topic.  Which is why you have not seen commits on the repo yet, because I don't want to commit something that is only partially functional.

Now for the really good news.  
I have decided to take this month and devote myself exclusively to this project.  In the meantime I am changing both the direction and the focus of the project.  I know I said before that I don't want to get married to this project.  However recent events have forced me to reconsider that position.

To that end I have taken on a partner who is securing long term funding for this project and together, will be building a company to keep this thing alive and breathing.  
The company will of course be seeking talented developers (yes Aido this means you if you've got the time, same with anyone else who was daring enough to try their hand at a fork.)  

Coming soon will be a website with a community forum where anyone can participate.

Having a company also means that there will be a few licensing models in place.  

A free and open GPL community edition with entirely FOSS modules will be the main emphasis.

We want to create a healthy and competitive ecosystem here around both the product and the underlaying network.  To that end the API and the network protocol will be open, people who wish to make their own modules or even competing products available, whether they are FOSS or some other license will be free to do so and can even have their own forum section upon request.  (Think bitcointalk devoted to p2p exchange products using a common network rather than a common coin).

There will be no "enterprise" edition or anything silly like that.  Because of this, everything we do with the exception of custom work will always be open.

Nevertheless, besides the FOSS model, there will also be 2 subscription models available.
These are support models.  One grants you "early access" to the newest source code and modules before anyone else.
Bug and security fixes are to be immediately backported, so early access really is to give a temporary monopoly for new features only.
FYI the exclusivity period on new modules will typically be quarterly, eventually all new modules which were not custom developed (i.e. paid for by an individual or business) will become part of the open source collection.

There will also be a personalized support subscription to address specific problems or requirements you may have.  
Regardless of the choice.  
The cost of licensing is expected to be very minimal, we are considering a flat fee or a percentage model, and may choose to make both available.
However those who subscribe to both subscriber classes will also get the aforementioned AI module to play with.

The business will fund itself on custom module development, the subscriptions are mostly intended to recoup development and support costs.
This means we will maintain a free open-source core project and a a collection of open source modules to meet general needs (90% of you will never need anything else).

Now understand that this means there is a material project change to deal with.

Out the gate, the focus of the project will be on peer to peer exchange.  
There is too much happening in the world right now to try and focus on any single outside exchange and the more I think about it, the more I realize that these exchanges are both a means to an end, and to some extent a pinch point.  I feel that in their present capacity as the sole gatekeepers they present a serious danger to the bitcoin community.  Looking at how exchanges come and go, it would be good to be able to still participate, without taking a chance at losing your a$$ets.  Thus the renewed focus on whispernet p2p (which may be getting a new name just to make it sound less scandalous).

Now this isn't to say that we won't be supporting the major exchanges, in fact MtGox and BTC-e are where I trade, and I also keep some assets at bitbox.  
Thus there will be modules for these exchanges and they will be open source.  

Also if you choose not to participate in the p2p exchange mechanism, that's your right and you won't be forced to do so.  However I believe it is far better to spend primary effort on a true peer to peer exchange mechanism and then integrate the exchanges as additional resources rather than the previous way of looking at it; which was to place the exchanges as primary and the p2p aspect as secondary.  For most purposes, which is primary and which is secondary are purely academic and of no consequence.  But from my perspective, I'm trying to make it so you can exchange freely with anyone worldwide without the need for a middle man or manual intervention.  I never want to be in a situation again where all of my liquid trading assets are trapped in 1 currency and 1 exchange because "sorry but we aren't taking orders at this time..."  Dangit! It's my money and I want it now! To paraphrase the worlds most annoying commercial.

This is not intended as an indictment against any exchange.  I would love to see any and all exchanges participate in the new network.  If anything it will save new and existing exchanges major headaches in the IT and regulatory compliance areas.  It could only be  a net positive for everyone, because it would provide significant liquidity and it would prevent future problems such as an inability to trade due to regulatory capture or DDOS issues.  The network is designed to view that sort of thing as censorship which is treated as a type of damage and route around it.

I have already been contacted by 1 exchange that will be launching in Q4 of this year.  They will not only have a custom module you can run to trade on their exchange, but they expect to function primarily as a liquidity provider for the network.

So consider this an offer.
I am officially inviting any exchange that wishes to participate, to contact me directly and I will work one on one with you to help you create a customized integration to assist in polling orderbooks, matching and fulfilling orders and anything else you would like to see from this new network.  

I hope you enjoy the announcement everyone!

At this point I'm taking a break from the engine for a couple of days and working on the UI from a "view first" perspective.
Originally I was going to create the UI as Java swing application, or possibly a webapp of some sort running on top on an osgi container.

I've discovered javaFX and FXML and I think it's perfect for what we're doing here.
Now if you want a new UI all you have to do is draw it using JavaFX scene builder, set the controller class and then set the onAction methods to match those from the controller class.
This approach also allows you to control the look and feel via combination of XML and css files.

You can also create your own controllers if you're feeling handy with Java.  
Finally I'm binding the Javascript engine directly to the main controller classes so you can create and extend controllers using javascript.
This should give new users simplicity while allowing power users (and modders who want to profit from mods) ultimate flexibility.

The overall goal being to allow you to make the UI whatever you want it to be.
Just wanted to give an update on the progress, I'll post some screenshots soon.

Sounds very cool...

I use Swing for my app but also added a server mode, that should be controlled by a mobile app at some point.

Very excited with all the news
Thank you for updates

Yes swing was my first choice too.  However as I was about to try may hand at yet another layout using netbeans I stumbled upon JavaFX and realized it gives all the power of swing with the flexibility and clean separation of view and controller that would be needed to allow a modding community to spring up around this thing.

One of my primary goals is to allow a healthy ecosystem to crop up around this.  The modding community can be a powerful force.
Power users should be able to mod their UI's how they see fit. 
People who want to mod semi-pro or even pro can do so with a minimal amount of hassle, just ship out a zip with their new skin and layout and *poof* brand new app.
The system is designed to actively look for a new "primaryui.zip" file in the working directory and load that at run time.

All the while compatibility is maintained and hostile forks are at least somewhat prevented :)

I do like that JavaFX now runs on Android and iOS so you'll (in theory) be able to run the same app on your desktop or phone to control your traders.

Ok so the time has come to discuss the peer to peer networking aspects of this application.

I was originally going to use a system similar to bitmessage where an anonymous encrypted message is passed around from machine to machine, each machine making an attempt to decrypt the message.  Obviously if you can decrypt the message then it must be meant for you.

While that's a nice idea, the system load at scale is horrific.  Bitmessage drains my laptop from a fullcharge to 0 in less than 30 mins.  I normally get 4 hours of regular use on a charge.  Also I simulated it and realized that all it would take is someone flooding the system with junk messages and the entire network could be denied.  Thus routing in this method is not optimal for our particular situation.  I still love bitmessage, it's just not the right tool for what we're accomplishing here.

So here is the solution I've worked up and what will be in the v1 when it's released.

The basic trading principle is one of aggregation and diffusion or put another way, scatter & gather.
There is a common channel where broadcast messages (trades) are sent to all highly connected peers by other highly connected peers.
A trade request enters the broadcast channel and is diffused into a series of smaller trade requests through a collection of closed loop tightly connected peers (called a peernet).
The peers in a peernet quickly work amongst themselves to attempt to facilitate as much of the trade as possible by matching their own internal resources against the trade. If the trade matches some threshold that is set on a per peer basis (by it's owner) then the peer produces a partial match.
These smaller partial trades are aggregated by the primary node and presented to the channel as a match.
The two primary match nodes then communicate directly to find a settlement option that works for both of them and then they perform settlement according to the agreed upon rules.

Here is an example.
I am connected to MtGox & BTC-e, my bot notices a $10 descrepancy and wants to arbitrage that for as long as the window remains open.
I have 100BTC and $500USD.  My bot directly arbitrages the trade within it's own darknet but sees that the window is still open.
My trading window has netted me 150BTC and I now have $0 USD to purchase more.

My bot would make an announcement (to it's peer controller, more on that later) of 150BTC@USD:BO:SEPA|OKPAY|PAYPAL|DWOLLA|ACH (BO is best offer, the others are proposed settlement methods in order of preference).
This is carried onto the primary channel where it is picked up by 4 primary nodes and diffused/scattered to 40 secondary nodes.

The first node is connected to SEPA, the second through OKPAY etc.(They could be multiconnected, but for now let's assume a single node/settlement method).
Rather than any single node taking the full risk of the transaction, each secondary node comes back to it's primary node with a partial match according to it's own internal rules.

Node1, subnode 1 matches 1BTC@110USD:SEPA, subnode 2 matches 1BTC@109.95USD:SEPA etc.  For a total of 40BTC@105USD:SEPA
Node2, subnode 1 matches 1BTC@117USD:OKPAY, subnode 2 matches 1BTC@116.90USD:OKPAY etc for a total of 90BTC@110USD:OKPAY
...

This goes on until 150BTC have been matched.
My node then presents settlement instructions to the primary nodes directly.  My node then sends the offered BTC to each primary node.  The primary nodes perform the fulfillment and distribute the BTC to their secondary nodes and settle according to their own negotiated rules.

Obviously there is a bit of trust involved here.  However there are rules in place to prevent a node from becoming a primary node if it has trouble with fulfillment, furthermore each primary node is in charge of rating it's secondary nodes to the network.  I call this trustnet and it's something I'll get into in another post, but I sort of touched upon it before.

Now as to the network itself...
When the application is launched for the very first time it will generate a UUID and an encryption certificate.

It will join 4 or 5 IRC servers on a specific channel, let's say #expressnet
Unless you have selected the darknet option and put in your friends UUIDs, once joined, it will poll a list of all nodes (clients) sitting on that channel and perform a DCC offer to each client currently sitting there. 
For our purposes a peernet and a darknet are essentially the same thing. 
The difference is that a darknet is a "pre-authorized" peernet, for instance you and a group of close friends would constitute a darknet.
It's a self agreed network operating to the exclusion of others, it is "dark" to the outside world.
In the trustnet setting, a darknet node is automatically given a trustscore that you assign.  If you fully control it you may as well assign it a 10.

A good example for using a darknet might be someone with nodes located close to each major exchange who just wants to create a network directly between those nodes for the purposes of direct arbitrage.  Personally I would see this option being used as a way of becoming a "major player" on the expressnet, due to the highspeed interconnects and direct connection to sources of liquidity, but I digress.

If you've selected the darknet option, it will only poll for pre-authorized UUIDs and only communicate with those pre-authed IDs.
(There is a mixed dark/open option too, but it's waiting on the trustnet implementation which will be a few more days before I can talk about in depth).

Back to the implementation details...

A DCC roundtrip time will be calculated between every node.
A new client will then sort the nodes into an array ordered by roundtrip time.
The default nodelist size is currently 12, but that number is configurable. 
On a quad core that's probably the max you want, with about +2 nodes per additional core if your machine is going to be fully dedicated to this task. 
If this machine won't be fully dedicated to trading, I recommend cutting that size in half.  Eventually I'll put in a self optimizing algorithm, but for now this is what we've got.

DCC is a direct connection and it is setup between two peers, bypassing the IRC server once the connection has been established.
It is beneficial to use this method rather than rolling our own because most firewalls and routers understand it and will co-operate, there is therefore no need to try and explain ports and configuration which frankly is more of a headache than it's worth.
 
However it's unencrypted and none of the libraries I could find knew how to use  transport layer encryption without puking in the event of a self signed cert.
Therefore we will need to implement a TLS style, Diffie Helman key-exchange and secure the message body itself while in transit.

This will produce a series of loosely connected closed loop peernets (or darknets) that are great for high speed clearing between themselves, but will suck for long range message traversal.  Obviously messages under this scheme will come in, but they won't come out.

For most purposes this is what we want, we want to trade frequently with people in close physical proximity to ourselves.
However there are two classes of message, standard and broadcast.
Standard messages are internal control and prep signaling, essentially the system is going to try and aggregate multiple smaller trades in the closed loop peernets.
It will also work in the reverse, that is to say if a big offer is detected, it's going to try and fulfill it by diffusing it through the local darknet and presenting it as a single completed trade to the network.  (darknet & peernet are interchangeable here).

Broadcast messages are reserved for the big trades.

To correct for this, one peernet node will remain in channel and when it receives a broadcast message it hasn't seen before and cannot be completed internally, it will relay the unfulfilled portion back on to IRC, exactly once (ideally aggregated with other internal offers that cannot be fulfilled internally).

Only one node per peernet will be given voice or authority to speak on behalf of the peernet.  This is to limit inchannel traffic to only large trades that cannot be diffused or aggregated through a local peernet.
 
It will be enforced at least in the beginning by a bot operator that will set the voice attribute only on peers that have been particularly long lived on the channel.
Note that everything I've described above is extremely similar to how bitcoin does peer discovery, except that it doesn't do the voice exit to IRC option.

I hope this is exciting and I'm posting it here to invite feedback.  It is mostly code complete, however if anyone sees a significant problem with it, I would be glad to take it into consideration, I'm open to suggestions here.

Enjoy!

Still standing by to help test!

Yes. I would like to read this post a few times more to get my head around it

But excited

The darknet seems a good idea

But my question is

If you have no friends, or you simply dont trust anyone  then can you run multi Instances of this software to get the same goal

Or just configure multiple exchanges yourself?

I'll be setting up the system with pure crypto to crypto exchanging in the next few days.
The darknet option will be temporarily disabled, trustscore will default to 1 (0 is untrusted, 10 is fully trusted).
The system is setup to directly feed the ticker data from BTC-e into the primary channel and treat it as actual offers.
It will attempt to order match and clear transactions immediately, then it will attempt to refund each transaction within an hour during the testing period.
Trustscore gains (and losses) will carry over from testing to live.

Out the gate I'll be supporting BTC/LTC as the first pair on this and will introduce other currencies as the modules for them become ready.
Since I'm using the RPC API for BTC & LTC and I suspect other currencies use the same/similar API, are there any requests for other wallets?

Ok it's probably time to explain trustscore.

Trustscore is our way of tracking credibility.
Every time a transaction is agreed to by two nodes, a hash of the transaction is generated and signed by both nodes.
This information contains the publickeys of both sides and the currencies to each side but not the amounts.
This is signed and broadcast to the network and kept by all nodes.

It looks something like

Once broadcast, each party to the transaction gets 1 credit.

Credits are valid for 1 year then they expire out, that way no one needs to have gigs of trustscore blocks on hand.
Trustscore goes up logarithmically, from 0 to 1 takes 10 transactions, from 1 to 2 takes 100 etc.
Trustscore gains are limited to no more than 1 point gained rolling 7 day period regardless of the number of transactions performed.

Also the time the last transaction was performed factors into it.  
If you go 1 week without any transactions your trustscore drops an entire point for each week of inactivity, but this can be gained back after 7 days of daily activity.

If either node has a problem with the transaction (for instance once side fails to live up to their end) a "dispute" is notated by referencing the previous hash and announcing it as a dispute to the network, where it is added to the rest of the trustchain.
Disputes stay on the record for 1 year and they drag you down to the next lowest trust point.  
Thus if you were a 3 and you get a dispute you are now a 2.
In this instance 900 credits would be essentially wiped out for 1 dispute.
To negate the risk of bad actors, only 1 dispute can be lodged per trading pair.  
It is expected that if you have a dispute that you stop trading with that node, the client implements this behaviour by default but it can be overridden.

A dispute affects both equally in that it drags them both down by a whole point, this ensures that only disputes which are "worthwhile" will be reported.
There is no dispute resolution method, once filed it's there for a year.  
The default settings prevent the client from trading with a node that has a dispute open in the last 30 day rolling period, however existing relationships are not directly effected, just the risk model.

Now here is how the client implements risk modelling.
The trustscore translates directly into a percentage of assets at risk.  0 is completely untrusted, 1 is 1%, 2 is 2% etc.
It will cap at 10%, thus at no time is a trade to go through for more than 10% of liquid assets.
This can be overridden in the configuration and settings panel.  In fact for someone to get to 10 they would have to have 10,000,000,000 successful transactions with no disputes, so it can be considered safe.

In the next version trustscore will be broken out by currency pair and settlement method which will be much more informative, but right now we have a single combined score.

That's it for now folks.
PM me if you want access during the testing period.

Yes you can still run solo on a single exchange and you can also run your own darknet and arbitrage multiple exchanges.
You can do it as multiple instances, or a single instance, it's your decision.
It's not the preferred method, because we would like you to participate in the ExpressNET OTC board, but it is designed to still do the same things the original ATP was.

Nova! what would be better from a personal setup type system. I am thinking having one bot per exchange would make each bot more responsive to that exchange. I would assume that the benefit to one bot per currency pair would be limited. I also assume one bot per user limits its speed. I am not sure that I have it right but I think I do.

I am excited about this release. It seems to have a lot of potential

Yeah it's one bot per exchange by default.  However there is nothing preventing more than 1 per exchange, nor multiple exchanges per bot.  It's whatever you have resources for.
Not sure where you got the idea about a single bot per currency pair.  That was never my intent and I hope I didn't say anything like that.  The closest I can think of is the older ATP design where it was one pair per thread.  But that had serious limitations.

We're using an observer pattern with publish & subscribe as well as DSP.

FYI folks, I'll be changing nicks again soon.
I get too many inquiries about NovaCoin which has nothing to do with me.  However I am working on a new coin too (not coming very soon so don't hold breath) and the email traffic makes it hard to sort who's asking about what.

I've always liked A Midsummer Night's Dream, so I'll be likely be taking up the name Auberon here shortly (unless of course it's taken already too).  If they don't let me change nicks here, I may end up noobifying myself again like I did after the Isis incident.  Sure wish I could hold onto a Nick for awhile.

On another note.
Come the 15th of July, I'll be opening boards for ATPx on the expressvest.com site.
If you click before then, you'll notice the distinct absence of anything resembling a site.

I just re-secured the rights to the expressvest name.  It was originally for a fully licensed banking/trading/investment site and part of the OpenPay & OpenBank framework, but the investors fled the minute MtGox got their US assets seized.  I just managed to finally get the keys to the domain name handed back to me from the dissolution of the partnership.

We'll be adopting the ExpressVest name for the new business that will be sponsoring this project.  The software will be re-branded expressvest and whispernet will be probably be re-branded to something like ExpressNet.  Here's hoping Citizens Bank doesn't send me a C&D for trademark infringement.  I don't see them as closely related, but it wouldn't be the first time I've had to change direction due to a legal filing.

I'm open to other names for ExpressNet, if anyone feels like racking their brain on it for awhile. :)

Sorry no you didn't say anything like that. I was just thinking out loud on the one per pair. I was thinking of having one specific host per bot per exchange. Then I thought maybe there would be even less latency if it was one bot per pair. Sadly at some point the connection would saturate leaving the same latency issue just farther along. That and having a number of bots all on one API and keypair likely wouldn't help either setting up multiples would work but even then its more load on the server for maybe a small boost in trading speed.

Anyways on ATPx once more exchanges are added it would be fairly simple to add another bot to handle say MTGoX then have them able to arbitrage the difference.

If I understood you correctly you are going to have a streaming ticker on ATPx as well.

I promise to get a proper architecture document up when I release this thing to testing.  I'll probably make a wiki and link it to the javadoc or something. 
Arbitrage is just 2 (or more) bots talking to eachother, which is why we have the expressnet p2p network.  If you're going to arbitrage 2 or more exchanges you just setup 2 or more bots and have them connect to eachother (you can darknet this by preloading their keys which will mean they don't talk to other bots).

How do these bots communicate the total funds to know if arb is feasable?

Judging by the description I would say they don't. One bot puts up an ask another if there is enough money bids for part of the transaction. No bot needs to know about an opportunity directly. If there is an opportunity the ask will be filled.

Uhm...sorry, I don't get it...

Let's say, I want to do arb from btc-e to gox. I buy btc at btc-e and sell at gox. What matters is the difference of the price at the 2 exchanges, so no bot can place an order without knowing about the other bot?

Or did I misunderstand the whole concept?

Pardon my ignorance...

Your BTC-e Bot can place an order to the whole network. An order asking to buy some amount of BTC for some other currency. Another bot, yours or someone else's, can take part of your order and complete the trade. You wouldn't need a Gox account to Arbitrage MTGoX. Your MTGox bot could help with or complete the arbitrage for you depending on size. It sees an order for 100USD for some 1 BTC say. The gox bot sends some amount of that order. Lets say the price on Gox is 107, the bot jumps on the order noting a 7% profit. So on Gox some slightly under 1 BTC is sold and 100$ is sent to your BTC-e account. If there isn't enough interest in the order or profit the Gox Bot would take a pass and not trade. if there isn't enough funds then the Gox bot would trade part of the order.

If you are using the darknet option and depending on how the upper controls work it is possible that a total price and account values would be available at your controller. It sends some signal to your bots and they handle it. Initially there isn't a darknet option working so I don't know for sure. I would know more when it gets released.

But the btc-e bot must stop the order, if there's no profit! Not just buy the btc at any price! It has to know the data from the gox bot?

Not as much as know what it is willing to pay to keep a trade going. Yes likely it would to some extent either learn or at the very least catch up to where no one would sell at a price the bot would pay.
As long as BTC-e bot says buying 100$ at 100$ per BTC and the MTGox bot knew GoX price was 107 the trade would likely continue until the bots had a very similar price.
I do believe there is an overarching control system that likely would know what tickers values are at the exchanges you have bots at. But it wouldn't require a bot to make money from it as long as your bot is buying when its profitable for your bot.

EDIT:
Likely scenario would be reversed. Gox bot being higher price would post an ask for USD at say 105 with the current price at 107. BTCe bot would jump on it noting that it would make a 5% profit.....

The answer is, it depends on your configuration.

There is only a single bot per exchange.  This is to reduce system load.
However there is a highspeed, hightrust option that you can configure.  
This sets up up a direct connection between your bots and causes the bots to be intimately aware of each other's internal state.
Currency balances are considered internal state.
In this setup the bot's represent a currency as source.symbol
e.g. MTGOX.BTC or BTCE.BTC
It also causes them to preference the desires of the other bot.

This configuration is intended specifically for exchange to exchange arbitrage on a single pair.  BTCE.USD/MTGOX.BTC
However I haven't finished the closed loop solver on it so it can only arb as long as there are funds available at the source.
When the closed loop solver is complete it will seek to match the exit method of one exchange to a supported entry method on another exchange.
Example (note, that : means transfer and | means trade in this example)

The closed loop solver will ONLY be enabled in for owned bot arbi mode.
It's not helping any that OKPAY doesn't want to do business with exchanges anymore.  I expect the exchange modules are going to be the biggest upkeep responsibility here.

Your description appears to be correct for open net trades.

Your bot would just participate as a regular trader on the p2p network and function as a filter against the exchange's pricing.
It would read in the current pricing, add in the profit that it wants to see, and handle the negotiations on both sides.

Effectively shouting in a room either
"Hey guys, I got BTC, fresh hot BTC only $105 USD, I take paypal, okpay, or sepa, come an get 'em!"
or
"Hey guys, I got USD, warm, smooth and easy on the digestion, I'll give ya 105 of 'em for just 1 BTC, that's right folks I said 1 BTC for 105 of these tasty USD's, come over and see me!"

Good news everyone!

As you may or may not be aware, I really do suck badly at art.
I wanted this product to have a fun, fresh, clean & professional feeling to it.  I didn't want it to be loaded down with unprofessional programmer art, so I set out to find an artistic director.  I needed someone with a strong portfolio of artwork that would lend itself to exactly the look and feel I wanted to give the product.
Someone who can be responsible for the artistic aspects of the site, the documentation and the product.

I found one and boy what a catch! 
Everyone please welcome aboard Alex Wendzel

Alex is probably best known for his webcomic Out At Home, www.out-at-home.com
A fantastic little comic about a retired baseball allstar, his family & friends and their adventures.

I was inspired to ask him to join us after seeing this comic http://www.out-at-home.com/archives/2940 which pretty much sums up my own fears about how complex this product is starting to get.  :)
So everyone please welcome Alex aboard and check out his site, it's a lot of fun and he does a great job.

Ok so this might be a design breaker.
I've been slow on release because I wanted to make sure everything works correctly the first time for 99% of you with minimal setup and watching.

After I completed the MtGox module I noticed that it would run for awhile and then it would just sort of drop out.
It was working fine before I implemented the JavaFX based UI, and so I stripped the UI out and tried again, sure enough it worked just fine.

This of course begs the question, what the heck is the UI doing that's causing the MtGox module to choke up especially when the BTCe module seems to be alright.

As it turns out it has to do with the way the MtGox module works.  Since the MtGox module uses the streaming websockets API, it has an event driven architecture and consumes an "OnMessage" event each time a message arrives.  This message is passed to the scripting engine for further processing because frankly that's the easiest way to deal with it.

The problem is that JavaFX appears to be overriding the scripting API or forcing it to run on the event dispatch thread even though the MtGox connector is actually running on it's own thread.  This means that the UI has to fire an event for all the backed up MtGox events to be processed.  I'm assuming that JavaFX forces the scripting engine onto the event dispatch thread because it uses a lot of javascript itself, trying to be an HTML5 compliant tech and all.  However it's unacceptable for ALL javascript to be running through the UI.

The obvious solution is to completely refactor the MtGox connector so that it doesn't rely on the scripting engine at all.  However the scripting engine is used in numerous places throughout the code.  Not the least of which is the custom programmable trading logic module.  Since it's all event driven, having the system hold off on processing events until the UI fires an event onto the Event dispatch thread is not going to work out well at all.

I'm going to put more thought into this.  I don't want to chuck out all the work that's been done on the UI so far.  However it may be that I end up dropping JavaFX in favor of Swing if I can't figure out any other way around it, but generally speaking I'd prefer not to do so.

Has anyone worked with JavaFX and run into similar problems?  Thanks!

I don't really understand your overall design, but it sounds to me, like your UI is tied too closely to the API implementations.

I wouldn't even tie any UI to the trading engine. Was one of my mistakes in my app design.

I was thinking the exact same thing.  The "engine" and the way you "talk to the engine" are completely different animals (should be?) but I have not looked at any of the code or tried to use the software so my opinion means little in this context.  My sense, again not looking at any other this beyond the posts in this thread, is that you should be talking to the engine with a script language of some kind.  Lisp, for example.  Why do you need any user interface at all at this point?  (again, forgive my lack of knowledge on this specific software).

I could be missing the point as well. I like the UI idea. I love the limit orders and BTC-e support, MTGoX streaming ticker etc. Is there a way to make a  small change to have to UI only send data and get replies?

What I mean is maybe instead of having the modules as part of the UI apparently only have the UI send the module when it periodically checks the bots. Like send trading logic, request balances or send some specific trade related action command. If the Bot sees something have it act then send the results to the UI. That way the UI could try working on them whenever but the bot can still fire fast when a trade arises. I would worry that the trade might be held up waiting for a UI especially if different machines are used for bots with one UI.

I am betting it would require a fair amount of rewriting though.

I've solved the problem by revising the design.  It seems to be working fine now.

Let me try and explain what the problem was more succinctly and then you'll understand the solution.

You had 2 components at play here.  The ExchangeModule and the UIComponent.
I originally wanted the exchange module to run as a standalone service and just have the UI subscribe to a datafeed that would be streaming off the exchange module.
This design was unworkable because the UI isn't particularly interested in the exchange data so much as the signals data being generated by the other modules.
Because of the complex interplay between signals and exchanges, it made more sense to have the UI marshall the exchange and signals modules and for expediency they should all share a static informational nexus point.

The exchange module(s) update the nexus with the most current exchange data and nexus notifies the signals modules and ui modules with the latest data.

The problem was that the UI, because it was using JavaFX was forcing all javascript to run through the Event Dispatch Thread.
There is a lot of javascript at play.  A lot of it is just hooks to allow scripts to run and implement some custom functionality at key points, but the fact is there is a lot of it.

JavaFX for some reason is forcing all contexts onto a single context and a single thread.  This means that any data no matter what thread it was running on would have to wait for the EDT to fire an action before it could be processed.  This of course caused a back-up and even a halting to occur.
 
The solution was to drop JavaFX as the UI toolkit.  It was causing problems and I'm just lucky I caught it early enough.

The new design, which appears to be working, uses the NetBeans Platform and nbm bundles in place of what we were calling modules before.
The current UI is mostly swing, it really didn't take that long to re-implement and I think I like the netbeans gui designer a lot more than the JavaFX gui designer :)

I'll be posting some screenshots soon.  Also I'm waiting on the logo to come back then the site expressvest.com will be up later today or early tomorrow.

cant wait
 ::)

Nova have you been testing APTx lately?
I only ask because I am curious how it handles MTGoX's cloudflare on the API. The rest sounds super great. I am excited to see it work hopefully soon.

is expressvest  all ok

still getting the parked domain

or did I just get the wrong link

I hope NOVA is ok. It has been a while since the last update.
I also hope everything is going pretty good or great!

What he needs right now is a good mechanic in Utah, more than anything else.

Anybody know a good mechanic in/near Salt Lake/Provo/Grand Junction?



let's keep our fingers crossed he can get across those mountains.

Lets hope, he is doing ok. But most of the time, the type of the car is important for the choice of the mechanic...

I've found a list of shops, but I have no clue how good they are?

http://www.automd.com/shops/UT/

Maybe there's a car forum in the US, where you can find folks with more knowledge? (I'm in Germany, so I have no clue about such a forum).

I'm sure there are plenty of qualified mechanics in that area.  Here's a few who have a good rating:

http://www.automd.com/shops/search?question=&location=provo%2C+utah&make=&sort_by=1

I would start with the brand of the car and then look for a forum for that brand (i.e. Ford forum, or whatever car he drives).

The folks there should know a specialist in the area.

But it also depends on the kind of problems he has (engine, suspension etc).

His last communication, moments ago, was optimistic.  I think he'll be just fine.  I am a few hundred miles east of him so I can go get him if it starts to snow or anything but right now it is 35+ degrees so no worries of that :)

Hopefully Nova is ok. It has been a bit over 10 days since he had troubles.

I recently discovered an issue with MTGoX that likely Nova already knows about but just incase he doesn't I will post it.

MTGoX won't generate codes or move US Dollars from them to anything but a bank account by wire transfer. Because of delays and expense I think one of three things must happen eventually. 1, Only arbitrage currencies you can get a code for. 2, Don't arbitrage MTGoX at all. 3, By the time the money would get turned around you could likely lose money from float plus the wire fees. 3 is essentially lose money waiting on them.

I found the problem trying to arbitrage by hand a $15 difference between Gox and BTCe. I really really wish I could have sent cash to BTCe.

The more important part is I hope Nova is doing well and back on the road.

I didn't realize gox allowed codes for any currencies at this point.

Truthfully Gox likely doesn't.

It seems I am always a little under-informed. Since the issue that supposedly caused it related to USD I guessed other currencies might remain untouched. Then again why would it.

Either way it explains the overpricing of USD at GoX. I had no other currencies so I couldn't test at the time. Also it could be a location thing I thought maybe US peeps couldn't get codes but it might be far more widespread.

I would really enjoy an update on either profits or Nova!. I hope he has gotten somewhere by now. I miss this thread being active. Anyways because of Gox issues it would be awesome to have a bot that ran well on another exchange. Honestly between bleeding the fees, ticker going AWOL and the like I really hope there isn't a worse exchange to use.

Hopefully everything is working out.

I agree too

Hope he is well and will update soon

He is a nomad at the moment.  Just got an update this AM.  He is seeking a better wifi solution.  Hold tight...

hows things Nova?
you homeless at the moment ?

Last time, he was seen here, was july 15th ... ?

I was excited for this project as well.

So I am patiently waiting for NOVA! to post. It has been about a month since I last wondered about this. I hope NOVA! is ok, and I hope PROFITS isn't dying. I am hoping for an update with some sort of substance.

I really should have asked about NOVA!'s whereabouts before ComiCon in SLC. Maybe I could have found him in person being in that part of the country (unless he moved around since the last I heard about 2 months ago).

Comic con

That would be so cool

Do you think he would have dressed up?

If so who would he go as?    :)

NOVA! is OK.  He could use a rich uncle, though. 

Great! Thanks for the info!

Maybe we can collaborate in some stages of our projects...

How much money are we talking about?

In dire need of 2 X FPGA development boards ($900 ea).

I'm confident he could use ANYTHING at this juncture, gift or loan.

We have a couple of projects that are out of this world. Unfortunately
the Venture Capital money we were hoping for hasn't come through and
there are not many job prospects in the part of the country where he lives
for someone with his skillset. He is currently working as a day laborer.


Feel free to PM me.


/me states clearly and for the record that this is NOT a solicitation for investment because it would be illegal for me to solicit investments from the public before the SEC gets off their asses and finishes the regulations they have been dragging their feet on for the last year and a half!

/me grumbles and mutters as he walks away

Any news on nova? I hope this project is not dead yet, since I still hope for some form of collaboration in the future?

I had hoped to gift NOVA! some of my profits.

Sadly ATP and I don't really agree on when it should sell etc. So although the ATP had made money, I lost money due to fees at MTGoX. I had hoped that going to BTCe would let me trade using a similar methodology to how I traded by hand and I would gift some profits. The required swing to make money was the issue not ATP. Newer settings are helping me slowly crawl back to even.

I gambled free money (converted nmc from MM) so I am not really out much. Still I had hoped to have a great platform running on BTCe soon.

Hopefully NOVA! is ok still. I am sorry NOVA! is having troubles finding more appropriate work for NOVA!. I do hope both of you the best of luck and wait patiently for PROFITS!

Is Aido still around to help with a quick fix? I would help, but my code doesn't do longterm data caching yet, so I cannot do those ema crossing strategies yet.

To be honest what I did by hand was nothing that couldn't be quickly duplicated and would likely have a great profitability the way I traded carries virtually 0 chance of loss of principal.

Aido hasn't updated anything code wise in 5 months. Granted he did add a new scheme for risk for me. Really all I needed was a simple addition to how VWAP was calculated. It would be nice if instead of trading so close to average that you only lose money ATP would let you add an offset so that you could at have average block out the fee areas as well.

I'll have to complete some balancing bots and will then move on to some EMA crossing schemes. Maybe we could work on some strategies together then?

I had been thinking about not telling my "secret". Truly anyone could figure it out given a few minutes. If you want to limit most of your risk and avoid loss of principal on nearly any market move it isn't hard.

What I did.
on BTCe I would sell an amount of bitcoins so that I would receive an amount of fiat. The currency technically doesn't matter. Say its USD.
I would then put in a buy at my sell -$1.50. So as long as the market drops $1.50 I make money. Now I sold .02 btc when I buy it back I only buy .02btc. I buy back the principal but leave the profits to run. In other words I can let whatever isn't the .02 btc run as long as I want as I will never lose principal. I may lose some profit.

If the market heads down I do lose some expected profit. I just do more sells and buys on the way down. In relatively flat markets its easy to just keep selling near the top of the range and buying near the low. I only needed maybe $1 of swing to make money at $130 per bitcoin. The only time you risk losing money is in an upward market. This is a real risk. If the market goes up you will lose some principal as long as your buy back hasn't happened yet.

This strategy isn't fool proof. It is possible to risk a small percentage of your principal and build a balance that no matter what you do will always be a profit. I never had more then one paired trade on at a time. This limits your risk. As far as automation all one would need is a sell, some math to make sure you aren't going to buy just enough to pay the fees or lose money, and wait for your price to come in. Rinse and repeat. Until an upswing happens. For this more logic is needed like the maximum amount you are willing to lose. So if it goes up some amount you buy your principal back regardless. Then wait for a nice sideways or down market and start your paired trades again.

Essentially ATP with an offset of .2% for BTCe or .6% for MTGoX would be enough to make sure you only sell if the price is high enough and buy if the price is low enough you would make something. Of course adding to that offset will limit the amount of trades but increase the profitability. The idea is essentially the same. The method is slightly different. For ATP I would need 2 instances running. One to buy up everything in a sustained upswing and one to trade based on an offset VWAP system or actual loss reducing logic making the first required one unneeded.

I don't really understand, what you are doing here, but that's ok, since I'm a coder and not a trader. Anyway...if your strategy works, I wouldn't post it here. But that's just me. If you need help to create a bot for your concept, I might be able to help.

I just used paired trades with limit orders. The strategy wasn't hard to figure out. I don't expect anyone would bother trading it permanently.

The idea is that if I sold I set up a buy that price wise made me money. The limit order made sure I got that price or better. The amounts and the like are just mathematically calculated or made up. The part I liked about the system is that as long as you wait long enough that both parts of the paired trade complete successfully you will make what you would make on that trade.

Of course there are far more lucrative ways of making money by trading. I just used something simple enough I could put on a trade or 4 a day and make a little bit here and there without a ton of risk.

Is PROFITS dead?

Hopefully everything is ok for NOVA et all.

If PROFITS is dead does someone know of another java trading application besides ATP as it seems development wise also dead. I would really like something like ATP or PROFITS but that works on BTCe or at least works ok on MTGoX.

Could someone explain how this project works ? Or how it doesn't work ? Running bots in multiple exchanges is the easiest part, how can you actually trade between exchanges doing that ? Obviously you can't, there is something missing here and it is a huge thing to miss.

Yes I agree

Is profits or atp. Dead

What is our other options ?

As I understood it the plan was to use MTGoX codes and the like to move money between the exchanges. As MTGoX for sure doesn't allow that anymore I can't say. I was hoping PROFITS would live because BTCe has 1/3rd the fees so making money on the swing is easier. That having been said I think I pulled a rez on 2 very dead threads.

Transfering money between exchanges at the very best situation takes at least several days. So that idea is dead right now, yes ? What are you after ? Something that can trade at btc-e ? I'm sure there are several projects for doing that.

When the bot was in design and active development there had been a few ways to move money between exchanges. Some faster then several days. Heck I can get cash from coinbase credited to my bank account usually in 2. The old codes system closed for legal reasons. I assume the rest of the trading bot died for the same reason.

Just thinking outloud. If someone released a bot missing the legally "worrysome" items is there a real concern. I would guess not.

In the long run yeah I suppose the inter exchange arbitrage is dead. At least in the initial plan. The sub bots for different exchanges sounded great. The streaming ticker and BTCe both sounded way better then ATP. Mostly I was hoping to use a bot that lost .33% after fees at MTGoxs .6% fees each way. I made the assumption that if I traded the same logic at even 50% of the swing using BTCe I would make money. I really didn't want to setup a specific computer with Linux to run python or install chrome to run another. I already have java so I had hoped to go that way.

I have gone semi auto

As I never can sit by the computer

I have bitcoin trader app at the moment

Look at it once a day then decide what to do for the next day
And I have an app on the iPhone for the emergency trades

Used to use aidoAtp. Until Mtgox kept changing the API

Would love to get at an atp going again

I'm in the uk.

Did try to get my funds out of Mtgox ( 1 month ago)

Still waiting

And now sulking after such a foolish move

Just stuck in limbo.....

Hope that made the rest of you feel lucky today

Take care

I am not being sarcastic but that is really very sad. May their return to you be swift.

More out of a personal worry about my little stash on there did you try moving your money out as bitcoins? I would hope I can at least pop out some bitcoins if I ever get trading somewhere else.

The worst part is when I was trading limit orders by hand on BTCe I doubled my money in about 2 months. I only got an account on MTGoX to try using this bot after the big price crash. I figured it wouldn't go shooting off so fast again.

I know askit2, Thank you

I was trying to move GBP

NEVER AGAIN

May move over to Bitstamp or coinfloor

Once my trading apps works with the API