tCm3nc / ga-bitbot

Automatically exported from code.google.com/p/ga-bitbot
GNU General Public License v3.0
0 stars 0 forks source link

bid_maker.py and bcbookie.py do not set any orders active? #42

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Hello!

    I was very excited to see the addition of bid_maker, but unfortunately it seems that either my db is contaminated, or the my bid_maker and bcbookie refuse to cooperate. bid_maker seems to run fine, but bcbookie reports errors like pasted below all the time [output abbreviated a bit]:
______
update: current price: 13.320  account market value: 195.6005 @ Wed Jan  2 
10:39:58 2013
checking open orders
checking held positions
main: Availble Funds (USDS,BTCS) :(186.5505, 0.67942741)
scanning for active bids by priority
66830eb427d01cd3d163e01ebe7b9778 priority: 0 enabled: 1 target: $0.0 discount: 
100.0
c3305d462059672f4f6a8daa3f885728 priority: 0 enabled: 1 target: $12.10925 
discount: 9.08971471471
d561bc709dfea4059ebefe200ddc168b priority: 0 enabled: 1 target: $-1.0 discount: 
107.507507508
5fd57626d7ae95bb45a454f78ed6ce67 priority: 0 enabled: 1 target: $12.86118 
discount: 3.44459459459
0bdb6a52c098156a12aa17d0511717d6 priority: 0 enabled: 1 target: $12.75955 
discount: 4.20758258258
d062b161818d6e8ab37c46c6d5ec1e2b priority: 0 enabled: 1 target: $-1.0 discount: 
107.507507508
fd88f00ecdac76785fffb05ee69099f9 priority: 0 enabled: 1 target: $0.0 discount: 
100.0
82ff966f847c86839ec2a9110373d320 priority: 0 enabled: 1 target: $-1.0 discount: 
107.507507508
main: warning - ignoring invalid target order:
{u'bid_maker_time_stamp': 1357119350.424017, u'buy': -1.0, u'score': 0, 
u'gene_id': u'c869ac6e8acd82d1-d8d41286d56607fd'}
main: monitor mode or target order not validated.
sleeping...
__________________________________________________________________________

Please, advise how to proceed. Should we also be running the report_gen along 
side of the bcbookie or could we just forget about it if we do not care about 
the graphs of active gene_def?

Grateful in advance.

P.S.
    All the best wishes for 2013! ;)

Original issue reported on code.google.com by purge...@gmail.com on 2 Jan 2013 at 10:16

GoogleCodeExporter commented 8 years ago
Ow.. Seem to get it.. Is the idea not to flood the mtgox with orders that are 
too far away from the current price, but to wait for the 0.1% or less of a 
price difference between current price and the target order and just then make 
the actual order?

If so, maybe a more appropriate default for a price difference would be a bit 
more than the 0.1%? So the order is already in the mtgox queue when the price 
drops far enough so the order is fulfilled immediately?

Original comment by purge...@gmail.com on 2 Jan 2013 at 10:49

GoogleCodeExporter commented 8 years ago
It's funny that you should bring this up, I literally just checked in a change 
to increase the window to 5%

The reason for gating the order is just as you suggested, to prevent orders 
which are too far from the current price. 

However, there is another need for this gate. bcbookie scans the bids from 
highest to lowest priority, when an 'active bid' (which just means it meets 
some sort of filtering logic) is found it breaks from the scan. Without some 
sort of gate you could end up with the case where a higher priority bid may be 
15% away from the current price would block a lower priority bid which may be 
only 1% from the current price.

The $-1 target was for debugging. There are a couple of different cases where 
bid_maker sets the bid to zero. The -1 was so I could differentiate between 
them. You can ignore the warning.

Also, you no longer need to run report_gen.

report_gen is most probably going away (along with wc_server). report_gen takes 
to much processing time to generate charts that 99.99% of the time no one will 
look at. bid_maker is single focused on generating the bids. To cover the 
reporting gap, I'm thinking about how to implement charting on request through 
the node server (which is replacing wc_server).

Thanks for the feedback and Happy New Year!

Original comment by brian.mo...@gmail.com on 2 Jan 2013 at 11:12

GoogleCodeExporter commented 8 years ago
Although I marked the original issue as fixed, there is still room for 
improvement. Suggestions are welcome :)

Original comment by brian.mo...@gmail.com on 2 Jan 2013 at 11:17

GoogleCodeExporter commented 8 years ago
Changed status to accepted.

Original comment by brian.mo...@gmail.com on 2 Jan 2013 at 11:18

GoogleCodeExporter commented 8 years ago
How long should it take on average before the system starts trading? I've been 
running for a few weeks now, but no trade has been initiated by the system yet. 
Bcbookie is running. I did restart on a new gene pool a few times, but the old 
ones have been running a few days, using several computers (about 22 
connections on average). Any hints?

Original comment by tim.st...@gmail.com on 12 Feb 2013 at 11:55

GoogleCodeExporter commented 8 years ago
Depends a lot upon your 'active' gene configs and calculated genes. If none of 
them suggest a trade in the range up to 10% lower [AFAIK] than the current 
price, than the bcbookie will just do nothing wait for said conditions to 
occur. You can try to add a gene_def that will trade with minimal markup 
[~1.2-1.3%, dependent on your mtgox commision rate], so it will do trades more 
often [check the report_gen output for a overview of the frequency and the 
spread of the trades]. If the trades are plentyfull, but tightly grouped around 
the few spots along the timeline, you can try to tweak the gene_def parameters 
stbf [check bct_alt.py for a rough description] and buy_wait [number of minutes 
that config will wait between trades].

Are you running the bid_maker? AFAIK, he's the one that scans BOBs and marks 
the appropriate ones as potential orders for bcbookie.

Brian, feel free to correct me about all the stuff I got wrong =]

Original comment by purge...@gmail.com on 12 Feb 2013 at 12:13

GoogleCodeExporter commented 8 years ago
10% looks a bit more like 5% ;)

Original comment by purge...@gmail.com on 14 Feb 2013 at 9:35