Security and FAQ about harmonia HOT 8 CLOSED

The other offers in point 2 are the flash return rate offers in the market. They're the offers that you see on Bitfinex. Harmonia only keeps one offer active per process.

Here are simple examples to illustrate the points:

1. "If a flash return rate is bid, hit that bid"
   Here, the market (everyone else's orders) may look like: USD Swap demand: 1 order for 30 days flash return rate per day for $10,000. Harmonia will see this order and take it. As a result, you will have an outstanding swap provided at FRR for 30 days.
2. "If a flash return rate is the best offer (lowest percentage), join the other offers"
   Here, there are only fixed rate demands, e.g. USD Swap demand: 1 order for 30 days 0.05% per day for $10,000. On the offer side, the flash return rate will be lower than other offers, e.g. USD Swap demand: 1 offer for 30 days FRR (0.07%) for $10,000 and 1 offer for 30 days 0.09% for $10,000. Harmonia will see the FRR order and post an order with your remaining deposit balance for 30 days FRR.
3. "If a fixed rate is the best offer, join the best fixed rate that is higher than the best fixed bid"
   Here, the demands may look something like: 1 order for 30 days 0.07% per day for $10,000. The offers may look like: 1 offer for 30 days 0.065% per day for $100; 1 offer for 30 days 0.08% per day $500. Harmonia will send an order at 0.08% as the other offer is lower than the highest demand rate.

Do you currently send out manual offers? If you do, what is your logic when you send the offers?

I do not currently have plans to cryptographically hash the credentials. If it isn't clear, the "credentials" are the API keys. By using the API, you can't do things like trigger withdrawals. So, it's somewhat safer than using the actual username/password credentials. Harmonia is intended to be run on a trusted host in a jailed/container environment. If the API keys were cryptographically hashed, you would still need the cryptographic key to decrypt the API keys. I am pretty sure the API keys are sent each time an order is sent, so they need to be available whenever new deposit currency becomes available. If you know that API keys are somehow only used to establish a session, please correct me. However, even if the keys are used to maintain some HTTPS socket, the API keys would need to be available in the event of a socket disruption (lost ISP connectivity, etc.). It strikes me as too much hassle to have to repeatedly enter API keys in that case. Just keep the process in a jail and run it as a regular user with a non-trivial password. Does this make sense?

from harmonia.

Thanks evdubs for the reply and extented explanation. Also congrats on the bot, it works great and the code is neat and no malware in it. On the security front, maybe there is a way for the exchange to combine API access with YubiKey technology or else; until then a VM will have to suffice, I guess.

Regarding the 3 "rules" of harmonia under which it operates; I think I fully understand them now. Rule 1&2 make sense given that FRR is most of the time the rate you want to hit.

More Questions about terminology and algorithm:

1.) Does the Auto-Renewal Feature by the Exchange to be switched off for your bot to work? (My guess is no..)

2.) I also have a few questions regarding the CLI output:

What do these terms and its values stand for?

CurrentRate
newRate
Comparing best ask outside best bid amount
Estimated total accrued interest

Is your tool calculating this accrued interest for 1 day period? I see this is is growing (not always) when polling, how is this possible with a fixed rate?

3.) Would it be possible to maintain multiple harmonies (for multiple accounts) alongside each other?

4.) How do you yourself ensure harmony keeps running ?

5.) Does your bot hit Fixed rate at a 2 day lending period?

6.) What do you think about reducing the polling / interaction rate down to once a minute? I guess changing line 227 to read 600000 would do the trick?

Thread.sleep(20000);

from harmonia.

1. Auto renew should be switched off. If you leave auto renew on, Harmonia and the auto renew feature will possibly be sending conflicting orders and make it harder for you to offer competitive swaps.
2. Current rate is the rate of your outstanding offer. New rate is the newly computed rate that has not yet been sent to Bitfinex. "Comparing best ask outside best bid amount" has to do with making sure the current Harmonia offer is not alone. It is possible for Harmonia to "join" (send an offer at the same rate) someone else's offer that they later cancel. In this case, we want to leave that offer and join another one. This line makes sure that the overall amount offered with Harmonia's offer indicates that there are other offers.
   Harmonia calculates accrued interest by checking the total amount reported in the deposit account. If this amount has changed from a previous iteration, Harmonia assumes this means the daily swap payment has been made and will print out that amount as well as the total estimate. Otherwise, it will assume each active offer was active for the previous 20 seconds and total it all up for the estimate. This amount grows because you have active swaps outstanding. All swaps pay/receive interest in proportion to the time they are active.
3. It is possible to run several instances of Harmonia for multiple accounts on the same host. Let me know if you try this and run into issues.
4. You can log in to Bitfinex and make sure the whole deposit account is used in active swaps and that any remaining money is in a resting offer (hasn't yet been taken).
5. The bot won't ever hit fixed rate demands. It will only hit FRR demands. It will very likely send fixed rate offers, but it will wait for someone to demand the same rate and duration in order to provide a swap.
6. That line is what you should change to lengthen the interval between executions. If that's something you want to do, go right ahead.

from harmonia.

1. Multiple accounts on the same host: Yes I tested this, and issues so far are: If one instance crashes, all go down, e.g. if an exception of insufficient funds is hit. Would it be better to let the instances run in different project directories?

from harmonia.

Do you have a stack trace? The main loop of Harmonia contains a try/catch block that tries to catch known exceptions. If it isn't catching an exception related to insufficient funds, it probably should.

from harmonia.

So far so good, tool runs nice, even between standby modes - probably a security issue, but so far I like the convencie of not having to enter access codes again. Regarding the Insufficient Funds: Will post the trace as soon as it hits again. But there is another problem encountered:

java.net.UnknownHostException: api.bitfinex.com

https://gist.github.com/nottinhill/209dbd653372db8aad4a

Also I am constantly getting on start up:

[WARNING] Checksum validation failed, expected 5c393ea756b50e77c0f0583c89a000b6e9aeb893 but is 634a0310a90f248ca5eb127936f10af60b510384 for http://repo.maven.apache.org/maven2/com/xeiam/xchange/xchange-bitfinex/maven-metadata.xml

from harmonia.

Entering the access code on start up is annoying, but it strikes me as being slightly better than having a file where the API keys are stored. For me, the only time I handle the keys is when I generate them and enter them into Harmonia. If I need to restart Harmonia for whatever reason, by not having recorded the keys in a file, I just generate new keys. I think it's an okay practice to continually be regenerating keys (and deleting old ones). Of course, you could wrap Harmonia's execution in a script that passes in the keys rather than ever manually input them, if you so wanted.

The unknown host exception shouldn't have crashed Harmonia, right? The main loop catches IOException (the superclass of UnknownHostException). Was your internet interrupted or DNS down at some point?

The checksum warning is odd. Perhaps delete your ~/.m2 folder and run mvn clean and mvn compile before running again?

from harmonia.

Are you up and running with Harmonia?

from harmonia.