I stumbled across Armstrong Economics a few years ago, not long after the Great Financial Crisis got going. I was trying to understand what on Earth was going on, and how the world economy got into this mess, and why the authorities didn't see it coming. His writing resonated with me and seemed to propose definite predictions and also claimed a good track record. I need to add it was never all consuming, and in the back of my mind I noted the major ECM turning points.

I bought his Gold Report in 2014. Later on, I decided to subscribe to Ask Socrates. I was keeping my eye out for the PRIVATE BLOG - GOLD reports. I was/ am(?) waiting for the drop to $ 800, else to see that taken off the table.

I stumbled upon this thread and also https://armstrongecmscam.blogspot.com/ a couple of days ago.

I had never managed to make sense of how to convert the forecasts into actionable trades, but I blamed it on my inability to comprehend, and kept telling myself that one day I would sit down in front of my computer and work through it all until it made sense. Or maybe upgrade my membership...

Around page 273 of this thread is where I saw some quantitative accounts of an experienced trader's attempts to use the forecasting system, and finding it was neither easy, nor accurate.

If an experienced trader can't make money out of it, then neither can I, never mind the underlying accuracy of the forecasting.

I don't remember finding a single worked example in the documentation on the Ask Socrates web site.

So I'm unsubscribed and will use other methods to focus on how to play gold and silver.

There is a trailing " on the end of the crontab entry you posted. Should it be there?

Try using the full path to the wget command. The $PATH used by cron can be different than the $PATH you have when logged in.

Look in /var/log/cron to check what is happening.

You should also try running the command on the command line.

I hold some crypto, as well as gold. I buy into an asset as the price falls using pre-allocated fiat at various price points. As the price rises, I sell out at predetermined price points, but for a new buy, I always retain 33% of the asset as a core position which I will "never sell". My target for BTC is USD 10000, at which point I might sell my core position (accumulated when the price was BTC 1 was less than USD 1000).

I therefore have no problem lending out my core crypto positions, as well as the USD that are allocated for rebuys when BTC, etc. crash much, much lower.

I think of it as being akin to selling picks and shovels during a gold rush. Apart from the currency risk (if USD is not your home currency), the only volatility is in the daily interest rate.

You don't lose money, you just make it at different rates.

I solved the lack of updates problem.

I put in a print_r statement that told me my nonce was too small.

That made me think maybe I was reusing some keys (1 iMac, 2 android devices, two BFX accounts).

I was right!

Any chance of adding Litecoin (LTC)?

It's fantastic that you've generalised to more currencies.

I was seriously thinking about hacking your bot myself to get multi-currency support in.

For a few weeks now, my marginbot setup has not been picking up account history, nor unused funding, but the cron job runs were being added to the BFXLendBot_CronRuns table.

I spent some time on it yesterday, and didn't get any ideas as to what might be wrong. Not least because my php binary will not execute a .php file.

But the problem shows up as a lack of history on http://.../marginbot/index.php

and a lack of entries in the table BFXLendBot_Tracking. The last entry was 2017-08-19.

So I noticed this morning 1.07b was available on the master branch.

I followed the update instructions, and the following occurred:

A new table BFXLendBot_CurPairs is created, and the 4 existing tables are backed up to copies with the suffix _BACKUP_v17

But I get this error on the screen http://.../marginbot/update.php?doUpdate=2


I am using

5.7.16
MySQL Community Server (GPL)

Poking around the MySQL tables, it seems the table definitions are still the same: decimal(12,2). But I can see some ALTER TABLE statements in update.php, that switch to decimal(12,8).
When I paste the ALTER TABLE for the Tracking table into MySQLWorkbench it thinks there is a syntax error in both MODIFY COLUMN parts of the SQL statement.



I am also wondering it it makes more sense to use decimal(16,8), as that way you can still support numbers up to 999,999,999. decimal(12,8) only goes up to 9,999.