|
Hi, IGHOR
I have been testing several new features you added in the beta and it looks like they are working fine. So far I have only tested the "Amount to Receive at Sell Price". It appears to work properly. I am still testing the other new features as I go along. The added UI changes are also pretty useful.
|
|
|
|
I mean SpinBox in UI or text field to display Total to buy and Amount to receive values.
Hi, SpinBox sounds like it would be ideal. |
|
|
|
Everything "looks" correct. (I have small doubts as I don't know how the internals of your program keeps tabs on previous sold prices)
What is "tabs on previous sold prices"? Oh, "tabs" means to remember a previous price. (Sorry I forgot I am not speaking to someone with native english understanding) In other words, I do not know how you keep a previous price point in memory so the formula can compare two different amounts. If the routine to keep the old price is kept in memory then the formula works as you described it. If the program calculates the previous price based on the currently available balance in the account then depositing or withdrawing funds (BTC or USD) might throw off the calculation of the program. If your program pulls the previous sold price via the API then that would also mean your formula works. I don't mean to make it complicated, I just don't know how your program calculates the previous price at which something sold or bought. |
|
|
|
I noticed only a few typo's on the UI sample that you sent. "bo" should be "to". Otherwise it looks good!
Thanks. I'm trying to understand you, but my English is not perfect. Is values required to be visible to make what you want? Is this variables calculated this way you need? Total to buy at last price = BalanceUSD/LastPrice-Fee Total to Receive at last price = BalanceBTC*LastPrice-Fee Everything "looks" correct. (I have small doubts as I don't know how the internals of your program keeps tabs on previous sold prices) "Is values required to be visible to make what you want?" Could you explain what kind of visibility you are referring to? |
|
|
|
 I noticed only a few typo's on the UI sample that you sent. "bo" should be "to". Otherwise it looks good! |
|
|
|
For example:  If you look at the above image with the circle and highlights. If you want to gain extra bitcoins by trading then you can rely on the red circled indicator for vital information on what is a beneficial trade. If you want to increase the amount of USD (highlighted in yellow) in another trading strategy, this piece of information can be vital. If you want to base the trade on a positive profit without taking into account the original BTC amount you already had in hand, you could rely on the indicator highlighted in green. The problem is, I haven't found any straightforward way of making a ruleset that could take into account these three seperate values to make gains in the market. I had to rely on rules using "prices" rather than raw BTC gains or USD gains. (which are simple and straightforward values) Do you sort of understand what I am trying to achieve? |
|
|
|
Hi, I have been using this program for a while and it has some great features. I really like the rules feature. I noticed though that it would be great if you could add a feature that automatically buys if a certain profit level is achieved. See the pics below:  I noticed the encircled variable is not included in the ruleset building. (well, at least not directly) I rendered this to give you an idea of what I mean:  I'll donate 2 BTC if you can find the time to add it, thanks for your hard work! My original intention was to trade by changes in BTC values or USD price values. What is normally available in the UI as "Total To Buy" could be used as a trigger. (in both buying and selling opportunities.) |
|
|
|
Thanks for getting back to me on this, can it be either type?
If not, it would be great just to set it to buy/sell prices.
Do you mean to add more choices to be able chose between last and buy/sell prices? Yes, if it is not too much trouble. I can think of one or more situations (on different strategies) where one type would be preferable over another. |
|
|
|
I really like the rules feature. I noticed though that it would be great if you could add a feature that automatically buys if a certain profit level is achieved.
Hi. Do you want this values to be calculated using Last price, or buy\sell prices? Hi, Thanks for getting back to me on this, can it be either type? If not, it would be great just to set it to buy/sell prices. |
|
|
|
Remember children,  If you throw enough money at a problem...eventually even crippled butterflies can swim! |
|
|
|
So again... Only Avalon, BFL and ASICminer are shipping, like I said. 3 vendors with working chips in the field.
Translated (my interpretation): "I am worried about these folks. Please, do not buy the KNC devices. We can't do low nm chips at a time like this." and "Look, we are charging 60k+ for our mini-rig. KNC, they are charging close to a third of that. Pretty please, don't buy from them! <Insert mind numbing nonsense here>" |
|
|
|
[Speculation and humor] Date: July 24th, 2013 Rep: Tell me about the order we place "two weeks"® ago? Chinese Supplier: Well, my records show nothing at two weeks ago...do you mean the shipment of parts you sent us on the 23rd of June? Rep: Yes, that was it, two weeks® ago just like I mentioned. Chinese Supplier: Well, it looks like we haven't yet finished tooling for your assembling line. It will be ready in two weeks, perhaps? Rep: WTF, Two weeks®?! Is that really 14 days or 10 business days? Chinese Supplier: Well, we don't know that yet. Rep: <Starts sobbing.> Rep: You don't understand, we have already delayed beyond what is considered a crime. We have the Unethical Patrol for Your Occasional Uncertainty Resolution Society calling our front desk! Ready to file against us. (U.P.-Y.O.U.R.S.) Chinese Supplier: It may be up to 60 days, I am sorry, there is nothing more we can offer you. Rep: <hangs up in disbelief.> Rep on Forum: We are still waiting on your ordered Power Supplies. We know it has been a challenging "two weeks"® but it may be yet another "two weeks" before we have these in. "Troll" on Forum: Hey! Hold up a damn minute. You said this "two weeks®" ago! Why don't you tell us the truth?! Rep on Forum: STFUP, you shitty little troll. How dare you? If it weren't for our refund policy I would probably give you back your BTC. "Troll" on Forum: WTF, Refund my ass! Thats exactly what I want! Rep on Forum: FU, you'll get your shipment in "two weeks®" when everything is good and ready. <blocked and banned for good measure> "Shill" on Forum: I would have done worse, great job Rep! You kept your cool in the face of all this BS. You guys are doing a spectacular job, Keep it up! "Customer(s)" on Forum: WTH, he was right about everything! "Slock" (hes special) on Forum: STFU you lowlifes, get a fucking clue! "Shills" on Forum: What he said, you guys are just so fucking entitled. You think you get something when you pay for it....just stupid. |
|
|
|
Update: Since July 4, 2013, 24 assembling days have passed, thus 9,600 Bitcoin miners build by BF Labs Inc. is, or will soon be, in the wild.
According to Josh's own figures, and they must be correct because he's the COO of Butterfly Labs, only ~60 more days remain before all backordered pre-orders are in the hands of monumental assholes, all competing with one another to see who'll get an ROI first.
It's a massively cruel reality. Those at the end and middle of the queue get massively screwed. Those at the beginning (as long as they probably get it by september) will probably only just get by without much profit for the next year. |
|
|
|
|
Your not screwed until you are "BFL screwed"®. (13 months league)
|
|
|
|
Pablo should we be concerned? My bot "seems" to be working but every time now that I click on it, it has the error on the top trying to reconnect?
But if I just mouse over it, I can see my balance ok... Almost like its not really having issue but saying its having API issues???
Also looks like it did a buy at 1 or 2 am this morning ok.. I went to bed short and now I am long..
So what should we do???
Thanks!
Same issue here Kuroth. My bot missed the entry to buy this morning on mtgox several times because of the API issue. Then, because it "holds" the buy order until the API is up again, it did so when BTC was a $1 more than it had sold it for the day before. Not the bots fault, but its just frustrating. I know that you have to be patient with the EMA trading strategy, but this whole API thing is a real bummer. The bot seems to want to do its job, unfortunately however, the mtgox API is making it a losing strategy at this point. I have seen that happen plenty of times. Perhaps if the Bot keeps tabs on the last sold price it wouldn't commit such obvious mistakes?
EDIT: I misspoke when I said the transaction was pushed through our server, currently the bot only gets the price list from the server, I got confused with some development we have been discussing for future versions to help with certain issues. Please accept my apologies if I confused anyone.
It sounds like there is an important feature coming up? |
|
|
|
----------------------
What is catching me off guard is that you are supposed to be using TSL as a function to determine where there is a loss by the average price in a period going up (after a Sell_All_BTC gets triggered). Or did I just read that wrong?
Usually a "crash" is defined as a downward market. If this is the case wouldn't it be extremely profitable to ride the market downhill and at the lowest crossover signal to trigger a Buy_All_BTC?
Or is B-Bot's strategy completely different from what I have described? (I know, I know, "Trends" not "Day Trading")
I've been thinking along the same lines. The problem with going with "trends" in one hour increments owes to how volatile the BTC market is. Unlike the stock market, where crashes are protracted over days and weeks, crashes on MtGox and BTCE are protracted over minutes and hours. Those 1 to 2 hours could make all the difference in a crash situation, and the way the bot currently works with thresholds could lead to you losing a lot of money if say the first threshold for a sell is reached when BTC drops from say 90 to 80, its entirely possible that price to crash all the way down to 60 in that next hour or two. So you're looking at a situation where if you had say 10 BTC and a crossover occurred, you could have sold at say 85 when the crash was happening, instead of the 65 that will happen because the bot hasn't hit its thresholds yet. That's why I proposed the earlier feature that would allow a user to only buy and sell AT crossovers, or at least allow the mix of the two. For example I could see myself wanting to use thresholds in all my buy situations but only wanting to use strictly crossovers in all of my sell situations. Hi Dresden  , As Kuroth points out, this is all well and good in theory, but Back Testing continually shows that trading at crossovers is way less profitable than trading at threshold 0.25, 1 hour interval settings. I recall someone posting back testing data of this last week (again, I think it was Kuroth). Gomboo's thread goes into great detail as to why this is is and as to why EMA trading requires longer intervals of time to measure success than say, day trading (where P&L is immediate). We are working very hard to push out the Back Testing feature for the bot and we are well advanced on it. This feature should take care of this entire debate as you will be able to back test your strategy yourself against all historical data. For now, please believe that the settings we recommend, which are Gomboo's settings, are the best mathematically profitable and proven EMA thresholds out there. Regarding your point about flash crashes and the need for earlier signal: EMA is designed to be profitable over a longer period of tiem accounting for a few larger wins to profit over a couple of smallish losses hence taking a small loss on a trade is part of the cycle and current settings should make these losses comparatively small to your wins. Again, it's part of the cycle. Altering trigger mechanisms would anull the mathematics behind the bots logic. Just as a general FYI, we will be looking into incorporating alternative strategy modules (Besides EMA) in the V2-V3 life cycle so that everyone can use a strategy suitable to their risk profile (as EMA is mathematically provable but takes some patience). If anyone has any ideas as to what strategies they would like to see, please let us know . Pablo. ADX? http://www.youtube.com/watch?v=Csq7gDnbapI#at=46 |
|
|
|
Can different charts be allocated to different screens? Sort of like so:  Or at least...different browser tabs? |
|
|
|
I just want to let everyone know that we are on track for V2 release next week. The code has been entirely rewritten from scratch and several important features added such as: -Support for BTCE -Server Back End to improve stability and support -Fiat Reserve -BTC Reserve -Increased speed, and versatility. -No need to reset, just set it and go. -Recoding of "Trailing Stop Loss," bot is disabled when TSL is triggered to avoid rebuy fess. The website and the bot interface are also going to be relaunched, we hope everyone loves the new product! BUY NOW: There is still time to get in on the "Early Adopter" deal before we launch V2. Anyone who purchases before the V2 launch will receive a FREE 1 year subscription to V2, an HUGE value. If anyone has any questions, please drop me a line. Pablo. www.btcbots.com-Recoding of "Trailing Stop Loss," bot is disabled when TSL is triggered to avoid rebuy fess. Could you explain more about this particular feature? Hi, Yes, I'm happy to explain . Trailing stop loss allows you to set a value which is a percentage. Then the bot will sell all your BTC for USD if the max price of BTC since you turned on the bot falls below your Trailing Stop Loss setting by the percentage you have specified. It is a safeguard feature in case of a crash. In the past, if the TSL was triggered but the market went up again, the bot could in theory rebuy incurring possible losses through fees. We have recoded it so that a TSL trigger will pause the bot until an operator has had a chance to review everything and reset it. We believe this mode will be much more efficient. Please let me know if you have any other questions , Pablo. Trailing Stop Loss = A percentage value. (Got it) "Then the bot will sell all your BTC for USD if the max price of BTC since you turned on the bot falls below your Trailing Stop Loss setting by the percentage you have specified. " TSL is 1.0 % If Max_Price_of_BTC < TSL Then Sell_All_BTC_For_USD "It is a safeguard feature in case of a crash." Huh....? < I am confused. ================= I understand that TSL is made to tackle a very critical problem of the average price going up rather than down. In day trading you cannot honestly lose if you turned all BTC to USD and the price plummets. (except in cases where it reaches zero) You'd always want to increase your BitCoins by following a basic principle. A) Sell your BTC for USD At the highest peaks, B) then when the price plummets buy the coins you sold plus whatever else extra you can afford at the lower price point. C) Then, when the price goes up again, you resell the BTC for USD again and you end up with more USD than the first round. The only way to lose in this strategy is if (Part C) never happens again OR (In part A) you sell too low and misjudge where the peak is. So Trailing Stop Loss is there to prevent (Part A) from happening or limiting the loss (Stop Loss percentage?). Do I understand this correctly? Or is a Trailing Stop Loss different than a regular Stop Loss? ---------------------- What is catching me off guard is that you are supposed to be using TSL as a function to determine where there is a loss by the average price in a period going up (after a Sell_All_BTC gets triggered). Or did I just read that wrong? Usually a "crash" is defined as a downward market. If this is the case wouldn't it be extremely profitable to ride the market downhill and at the lowest crossover signal to trigger a Buy_All_BTC? Or is B-Bot's strategy completely different from what I have described? (I know, I know, "Trends" not "Day Trading") |
|
|
|
I just want to let everyone know that we are on track for V2 release next week. The code has been entirely rewritten from scratch and several important features added such as: -Support for BTCE -Server Back End to improve stability and support -Fiat Reserve -BTC Reserve -Increased speed, and versatility. -No need to reset, just set it and go. -Recoding of "Trailing Stop Loss," bot is disabled when TSL is triggered to avoid rebuy fess. The website and the bot interface are also going to be relaunched, we hope everyone loves the new product! BUY NOW: There is still time to get in on the "Early Adopter" deal before we launch V2. Anyone who purchases before the V2 launch will receive a FREE 1 year subscription to V2, an HUGE value. If anyone has any questions, please drop me a line. Pablo. www.btcbots.com-Recoding of "Trailing Stop Loss," bot is disabled when TSL is triggered to avoid rebuy fess. Could you explain more about this particular feature? |
|
|
|
The strange thing is Vircurex does not show any TrxID:
It is completely blank.
If your coins were moved out of your account and the exchange can show no record to track the transaction, including to where it was sent, it is a serious issue on the exchange side.  Sounds like there is a serious issue. The in's and out's don't even make any sense. It's going all over the place except where where it is supposed to go. The sad thing is my transaction was almost a third of the active trading volume in the Vircurex Exchange orderbook if I am not mistaken. For them to actually lose it all would be a serious blow to their handling of the most basic facet and purpose of an exchange. |
|
|
|
|
Show Posts
