Yep, I would also like to know how 'close'.

In fact, if you want to be fair, what you would have to do is return the 0.05 BTC people have paid for the upgrade and upgrade everyone for free or a reduced marginal cost. That's what you had previously announced, afterall.

Yes there are lots of expenses when creating a company, registration, fiscal advisors... but if you don't fully satisfy your current customers, you risk loosing future sales. And the 'cost' of missing on future sells is certainly higher than not getting 0.05 BTC per upgrade.

I honestly don't know how people is okay with paying again. Me for instance, when I purchased the simple bot I paid 0.60 BTC. Now you sell the newer one at 0.45 BTC and I still would have to pay 0.05 BTC if I want to be fully upgraded. So no, I still don't see the fairness in all this until everyone gets upgraded to a fully featured new version, not a cut down version, I believe I paid enough to have that 'privilege'.

I admit I saw your reply yesterday and thought "Maybe he's going to make things right..." and now you come up with this.

When we purchased the bot there was a simple premise "You get support and updates for the price you have paid." as it says in this topic. On your site it also says:

"The crypto coins are changing almost every week, coins come and go and exchanges sometimes change there API. To keep up with those changes the software will be updated on each change. All registered users will be updated as soon as there in a update availible."

Updates, my friend, mean that if you decide to launch version 3 of this bot, that's an update. It doesn't mean 'cutting back all the new features from the new version back into the old one'. So no, this new proposal does not keep your word and claims about the bot that you have made in these forums (quoted by Istie) and in your website.



For example, you called this an 'update'. See where I'm going? Yes, you promised updates for the price we paid as I quoted above. Now it seems it's more like 'updates are not included for the price we paid'.

Then you went onto the 'symbolic quantity':


And now it does seem like:

A) We don't get updates in the price we paid

B) You will ask us to buy the software again. Asking 40$ sounds like that.

I hope you really reconsider this more intensely than you have seemingly done since yesterday. You might get new customers, but annoying your current customers is surely not the best way to go if you want to ensure the future success of your new project.

Sorry but this is not what you had said before. You mentioned it would be an irrelevant amount just to go legal, you even mentioned something like 1€ if I remember correctly (I don't feel like going back in the posts to check). Now however it's around 40$. That's not quite the same that you had previously mentioned.

I also have a company and you can make the invoices for 1 cent, if you want to. So I find no real justification for that price, at least go openly and say 'I want to make profit in this update' and then I will still be pissed but at least it will be closer to the truth. Sorry if I sound harsh, I just feel like you have told us one thing and done another.


I assume in this option we will not get any of the new features, so is it hardly an option?

Well, I see why it happens, but it breaks any kind of profitability analysis you might want to do. Adding 2 extra variables to store the last buy/sell prices when that function is triggered should do the trick.


I assume price went below 24.5, which caused the drop-loss to trigger, and then it sold at 'market price', which was currently 24.988.

There seems to be a problem in the Benchmark function when the new "Last buy and sell price reset" option is used. The profit (or lack thereof) is not calculated correctly.

I have highlighted the problematic fields, as you can see they show earnings as 0.0 rather than than the value. I guess it happens only when that new function is triggered as there are other working values there.

These last days I've been spotting a room for improvement when it comes to MACD. I don't know if this is very financial as I'm not really deep into stocks, but I believe it would improve overall behaviour and that it makes sense.

Take for example this MACD right out of my bot:



I have highlighted what I would call 'Phantom signals'. That is, places where there is either a sell/buy signal that only lasts 1 cycle, and that eventually cause the bot to sell/buy when in reality it's not certain where the market is heading. What I would like to suggest is to have a configurable amount of 'consecutive' signals that you want to require before the bot takes the final sell/buy decision. I can't guarantee this results in more profit, but I have the feeling it might have. And if it's optional, it would just be an extra thing we could try, and the default would remain like it is. I believe the bot has done some poor decisions at times because of this, you only need to look at the last one I have highlighted, that's 5 diferent buy/sell decisions so it's clear that with that data we can't really make a buy/sell decision.

Also, did you read my previous suggestion?

The only option right now is ticking "Disable raise/drop safety" in advanced settings. The downside is the bot might decide to sell at a loss. In fact I haven't been able to find fully satisfying settings that make profit with that setting ticked, so be sure to benchmark it. Sometimes it wins a lot but it can also lose a fair amount.

And since we are speaking about it, I would like to suggest Stephan to turn that option into 2, separate ones, one for Buy and one for Sell. That would allow to ignore only one of the 2 safeties, in my case the one I want to ignore is the buy safety, and then the bot would always try to make profit. If the market reversed strongly, the stop-loss function could work in conjunction and prevent losses.

This would prevent having to find 'the perfect' settings with ignored safeties like right now, because honestly, I am quite not succeeding, and I tried a fair amount of combinations 

I would like to report a issue and a couple suggestions:

- The graphic and indicators stop drawing at some point. I don't know exactly why it happens but it usually stops between 2500-3500 updates for me... It continues to trade fine, though.

- As reported before, when adding a indicator it starts drawing from the current update but placed at 0, causing it to differ visually from the graphic. My suggestion would be to fully redraw the new indicator with the whole previous data like in the benchmark function, and then continue in real time. It should be relatively simple to do and would allow a much more clearer understanding of how the newly added indicator would work.

- I also miss the opportunity to change the indicator settings from within the Benchmarking function. I believe some fields there, for example if you have MACD-MA selected to have 3 editable fields to change the values and see the changes in realtime would be golden. Right now it's quite annoying to add indicator, see benchmark, go back, delete indicator, readd, relauch benchmark and so over.

I would say it's because coin position should be Bought. Sold = you have USD and want BTC, Bought=you have BTC and want USD.

If it reaches the sell trigger and it doesn't sell, that means the indicator you are using is not giving a Sell signal. This can be 'normal' or it can mean a problem with the indicator.

Then, if the market goes down fast, it might already be out of the sell trigger before the indicator gives a Sell signal, so then it wouldn't sell. It's not cool but it's not a problem of the Bot, sometimes indicators don't respond fast enough to certain market movements, they're not perfect.

Personally it has been working well for me, especially after last update. And next update looks even better with the solutions Stephan is working on for out of scope, which is one of the remaining issues right now.

Simply login into your account and click the Download link, you will download the newest version.

I don't think it's about XPM replacing YAC, but I think there's mainly 2 things that are putting in danger YAC and preventing its raise:

- The sudden, N increases. I don't know if it's possible to 'smoothen' the effects without a hard-fork, but it would be worth considering. The average foe is probably not OK with their hashrate halving overnight and difficulty taking 5-6 days to adjust. Since the N concept probably has to stay this way as it's 'the concept' of the coin, I guess the change should come with difficulty reacting faster after a N change.

- The lack of development news (not blaming the dev(s), I understand you can't do miracles with few numbers, but it's an issue from outside).

If these 2 things are tackled I don't see why YAC couldn't become more widespread. If nothing changes, well, I'm afraid we'll all have a good amount of very cheap coins.

Indeed, the "All in" trick seems to work only for the next trade.

Been observing it more, it just bought and the "All in" amount didn't get updated with the deducted fee. I believe the problem lays there, it buys whatever amount of coins but the fee is not deducted from this amount after the buy operation so when later trying to sell it errors since it's trying to sell more coins than what you have.

I was having the same issue and I think I identified the cause.

I had "All in" ticked when I first started the bot, and it bought for whatever amount was the 90% of my total. Then I simply left it to do its thing... just that yeah, it was not selling despite lots of Sell signals being displayed. Finally today I had the 'genius' idea of unticking "All in" and ticking it again, and voila, instant sale.

So I believe there is a bug when calculating the All in amount sometimes, maybe after the buy in. Perhaps an automatic recalculation of this amount every certain time/intervals could help prevent any issues here.

I don't know exactly what caused it, but with 'All in' ticked it should never try to sell more coins than you have unless you manually change the value, and I believe that's what was holding back my bot from selling (that thing Stephan is working on should be helpful to identify these issues if it includes things like that "Sell failed because the amount of coins to sell is bigger than what you have" or something similar).

I also encountered the update issue. I had the next situation happen to me just now:

- Had Bot 1 active trading BTC/USD for several hours. Bot 2 was simply capturing BTC/USD data with a different update timer (doing some benchmarks there).

- Changed Bot 2 to LTC/USD since I saw some interesting movements. The graph did not update, it still displayed BTC/USD with the previous data. Changed timers and nothing changed aswell. Bot 1 was not touched at all during all this period. Some time later (don't know exactly, but more than 20sec. I'd make a wild guess at 1-3min) I find BOTH bots' data reset, which was quite annoying. Bot 2 started displaying the proper graph obviously, but at the cost of resetting Bot 1 when it shouldn't have had. I didn't do the Settings trick to refresh when I changed bot 2 precisely because I didn't want to lose data on Bot 1, so it happened by itself. Hopefully you can reproduce it with this explanation.

So, do you already have that information or we need to tell you which of us want a refund?

Indeed, we are all trying to be patient but it is hard to understand that you have not sorted Batch1 refund yet, when all you need to do is get in touch with JohnK and confirm the members involved.

It looks like a few minutes job that will make Batch1 members happy and that will rid you of a fair amount of pressure as well, everyone wins...

I feel like it's worth to put things in perspective considering some of the replies I've read.

The option of 'having miners ASAP' is not realistic, otherwise I guess everyone in this group would want exactly that. We are in the situation where ASAP has no definite date, and that's why we are voting.

In short, the options are (someone correct me if I'm wrong):

1) Wait an undetermined number of days until the chips are shipped. Apparently no one knows how many. Maybe Avalon, but they're not sharing that info with us. Or maybe not even them. It could be days, it could be weeks, maybe even over a month. I would suggest to make your risk assessments and ROI calculations, with the increasing difficulty taking all those factors in mind and the optimistic/avg/pessimistic estimations before deciding.

2) Ask for a refund, a rare occurrence in the world of Bitcoin investments. Considering Avalon is nice enough to offer the chance for refund, I think it's wise to consider it. Getting a refund does not necessarily take us out of the mining picture, we could reinvest these funds into real on-stock miners from other companies, or Avalon itself when they have the new generation ones. Even buy them directly from Steve when he gets them in stock and starts his shares model.

All in all, I am obviously in the group that prefers a refund, but I've tried to explain the situation from a neutral point of view. In my opinion these are the 2 situations and that's how you should decide the refund for Batch 1, not based on non-realistic desires.

Regards.

Just compile it with the adequate flags:

You don't need a special build, you can compile the scrypt-jane minerd on ARM, though I needed to do a couple minor source code modifications so that it compiles.

In case you are wondering, it's not worth it, hash rate is (with current N=512) 0.23kh/s out of the box, 0.24kh/s after some ARM compiler flags