|
I've opened an issue with the XChange team and Mazi to investigate. Two things happening:
1. MtGox changed, slightly, their URI paths for their v1 API. A slight change is a major f'up.
2. XChange 1.7 using the MtGox v2 API should work, but it isn't. There is a problem with Mazi.
So, as soon as I hear back I'll provide any response that gets my copy working.
|
|
|
|
|
And, btw, WTF is going on with MtGox. Can't connect in AidoATP since last night?!?
blah+
|
|
|
|
Hello Aido,
I've read up a bit on your bot but didn't see a stop loss feature. Is your bot able to do trailing stop loss? I prefer to do all buys on my own but can't watch my BTC investments 24/7 so a trailing stop loss function would be very convenient for people like me. If Mt. Gox ever implemented a trailing stop loss function, I'd definitely use it.
The Max Loss config parameter is part of the interview process. This will cap the percentage weight of, in case of high risk algo, the amount to sell when indicators are aligned to sell. 'Stop loss' or, probably better said, a price floor, doesn't really exist in Aido. What does happen, however, is that for each consecutive trade executed the weight is reduced by the formula: weight / 2^num of consecutive trades. This has an effect of a big trade (if indicators are satisfied, and trendarrow is high) at first, but the subsequent 4 other trades that might follow will be reducing in size fairly rapidly. You could call this a somewhat loose stop loss. This is why I've been modifying my local copy of AidoATP to be much more responsive, larger weights, with the initial trades, then let the pseudo stop loss take it's course. I found the high risk algo to be too conservative with the indicator configurations I'm using. |
|
|
|
|
FYI.
Due to all of MtGox's annoying lag events I'm will be modifying my local AidoATP copy to perform the following behavior for indicator tick size scaling.
1. Calculate average rate of change of MtgGox tick timestamps over shortMACDTickSize tick value to establish MtGox responsiveness.
2. Compare result of item 1. with Polling Interval configuration value.
3. Scale all configured tick indicator sizes UP/DOWN inversely compared to result of item 2.
This should preserve, roughly, the waveforms created by EMA and MACD in the event of a slowdown or speed-up of MtGox responsiveness.
The integrity of the indicator waveforms for period of time are paramount to executing on the intent/tactics defined by the AidoATP user.
If interested, I'll post a copy of the code somewheres.
|
|
|
|
|
I liked Dwolla for the ease of shorting to my bank acct via ACH.
Are there any other reasonable options for ACH to banks of small amounts of USD?
This is shitty.
|
|
|
|
I should have bought ASICMINER shares when I was offered them at 0.3 BTCBut yeah, hindsight is 20/20  Yep, ASICMiner. It was a beauty of an investment....awhile back. Maybe Bitfury will provide some balance with his "0.7 W per GH" chip. If it ever materializes. |
|
|
|
It's not like there's a top bitcoin pool in Kansas City or anything... oh wait...
Dhenson: consummate idiot.
Feel like defending your intelligence now?
Unusually, I have to come to Josh's defense on this one. Just the slight oversight of Josh's datacenter and hashing hosting operation to consider. umm, dur. |
|
|
|
BFL_Josh: "Originally Posted by swissminer Hi Josh
I understand your frustration. Having worked in IT as an engineer and project management consultant, I believe that you could not survive in a corporate environment if you would tell your customers or superiors, it is done when it is done.
Certainly there were numerous key mistakes made along the process or BFL would not be in this situation. Giving a concise end date, when really overall schedule uncertainty was in the order of >100% was one of them. Huh... my past employment history would seem to disagree with your assessment. I have told many a supervisor that it will be done when it's done. That's the thing about being in a position where your skills are valued and you aren't just another cog in the machine. You are the one driving the timeline, because you produce results. If someone is telling you when something will be done, you aren't the one delivering results... the guy or gal telling you when to do it is the one delivering results. You're just a replaceable part at that point." What a load of BS. All companies, big and small have product roadmaps. Some of them are kept confidential internally, but for BIG business for *BIG market segments Product Roadmaps are a staple. *One could argue that Bitcoin ASIC miners ARE the BIG market segment. So, should be treated in accordance with standard business practices for public companies - oh, right, they aren't public. Still, it's not unreasonable or rare that private companies publish product roadmaps. This is just more BS "telling us like it is - like it should be" from Josh's opinion. And, I'm afraid, those opinions aren't, and never have been in regards to BFL's products, ones based in the little place called reality. Spin, spin....eat, drink, take a shit, spin some more. Reality check: It's a bad operation - not publishing data is just an escape route from any added responsibility. Done. Edit: I can't resist. I've worked as a PM and engineer at GE and HP. If I heard the sort of premise and attitude being displayed by Josh - that person would be canned. Simple. Results oriented middle management are not push-overs - don't let Josh make you think this. We had a slang used in management meetings called a "Come to Jesus" meeting. Those meetings were never good - since somebody f'ed the pooch - and they either capitulate or career - game over. We need one big "Come to Jesus" meeting for BFL. I have a feeling rain of fire, the four horsemen, and the end of days would result if that even had a chance of happening. Damnit: I broke a cardinal rule of giving personal info. Uhg. |
|
|
|
When's someone gonna take them to court then?
It would have to be initiated by a govt agency if criminal. Most likely State's Attorneys. Btw, State's Attorney(s) have already been in contact with BFL due to shipping delays. There is one document with BFL's response to the S.A. floating around the forums somewhere. If there were even a hint of fraud (patently false advertising), and considering the volume of disgruntled customers, I have a feeling the FTC or a State's Attorney would take interest in BFL again. If you really want to see where that path goes, contact your S.A. and the FTC. |
|
|
|
|
I can only hope that massive adoption of Bitcoin 'version 2' has occurred.
The fundamental tenets of Bitcoin are sound, but the technical implementation needs work - aka - a very hard fork.
The major issue, as I see it, is the lack of strata for transactions, so to be able to define transaction SLA's.
When I say strata, I mean discrete, definitive (within a very reasonable margin) stratum buckets for tx's.
Without this BTC has no hope for widespread, day-to-day usage. Exactly what BTC needs for adoption.
|
|
|
|
I've noticed that this phone of bfl's chip have geostamp pointing to Unive in Fremont, CA: http://ow.ly/i/1EM8oThe company produces ASICs from 130nm to 600nm. Ummm,... Hypothetically, let's say the Fab has an updated web site. Would this mean there is a possibility that BFL's ASIC's are not, in fact, 65 nm. And, if so, that would constitute quite a serious charge of fraud. Surely, they wouldn't be so careless. Disregard. Or speculate. Whatevs. (I'll just leave this here. BFL chip power spec 5x what was 'anticipated') That'd be hilarious, I recall seeing someone from the Avalon team suggesting this possibility months ago Hilarious, maybe. But there would be serious criminal charges. Even if only part of the solution is 65 nm (ie - one of the ancillary chips) a jury would convict BFL after hearing the evidence. So, I doubt BFL would have put themselves in such a position. *shrugs* |
|
|
|
I've noticed that this phone of bfl's chip have geostamp pointing to Unive in Fremont, CA: http://ow.ly/i/1EM8oThe company produces ASICs from 130nm to 600nm. Ummm,... Hypothetically, let's say the Fab has an updated web site. Would this mean there is a possibility that BFL's ASIC's are not, in fact, 65 nm. And, if so, that would constitute quite a serious charge of fraud. Surely, they wouldn't be so careless. Disregard. Or speculate. Whatevs. (I'll just leave this here. BFL chip power spec 5x what was 'anticipated') |
|
|
|
I'm getting this error, running v3.1
...
[2013-05-11 21:56:39] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:56:41] Accepted dd30e6b2 Diff 1/1 GPU 1 pool 0
[2013-05-11 21:56:41] BFL0: Error: Get result reports: Temperature (celcius): 32.2
BUSY
[2013-05-11 21:56:42] Accepted 317f83a5 Diff 5/1 GPU 0 pool 0
[2013-05-11 21:56:43] Accepted ff9856a7 Diff 1/1 GPU 4 pool 0
[2013-05-11 21:56:46] Accepted 3a40124f Diff 4/1 GPU 1 pool 0
[2013-05-11 21:56:46] Accepted b2508626 Diff 1/1 BFL 0 pool 0
[2013-05-11 21:56:47] Accepted ba0f9179 Diff 1/1 GPU 3 pool 0
[2013-05-11 21:56:51] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:56:51] BFL0: Error: Get result reports: Temperature (celcius): 32.2
...
The hash rate of BFL Single goes down after the the first message appears, but it will go essentially to 0 after some period of time.
Restarting cgminer solves the problem but problem will reaper after some interval of time.
I think there is a hardware error inside the device, which gets USB buffer for the device out of sync with cgminer. Is it possible to make cgminer to recover after this error by flushing the USB buffer or some other internal reset without a need to restart cgminer?
Hmm - but it should resync anyway ... I presume it is doing that in the log after where you cut it off? (as it did the first time shown) The actual cause of the problem is the timeout (-7) where the device took more than 999ms to reply (i.e. BFL0 stuffed up  ) If the device really has failed, it will change state to ZOMBIE, but if it does keep working, then in this case it's simply got out of sync fue to a hardware problem and then resynced not long after. If it resyncs, then reinitialising it wont do any better. Restarting cgminer does solve the problem - this is why I think that something could be done within the cgminer to recover from it. After restart (of cgminer only), it may work for days without any error messages. As I said: after the problem first present itself, it doesn't go to 0 hash rate right away - it takes several minutes for the hashrate from the device to get to 0, meanwhile I keep getting those errors. Here is the full log until the restart: (I only took out GPU shares) [2013-05-11 21:58:03] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:07] Accepted 0402178f Diff 63/1 BFL 0 pool 0
[2013-05-11 21:58:08] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:10] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:12] BFL0: Error: Get result reports: Temperature (celcius): 32.2
[2013-05-11 21:58:20] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:28] Accepted 10e25dc2 Diff 15/2 BFL 0 pool 0
[2013-05-11 21:58:28] Accepted 586be719 Diff 2/2 BFL 0 pool 0
[2013-05-11 21:58:32] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:33] BFL0: Error: Get result reports: Temperature (celcius): 32.7
BUSY
[2013-05-11 21:58:35] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:37] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:58:38] BFL0: Error: Get result reports: Temperature (celcius): 32.4
[2013-05-11 21:58:39] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:00] Accepted 7d9c161a Diff 2/2 BFL 0 pool 0
[2013-05-11 21:59:02] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:04] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:05] BFL0: Error: Get result reports: Temperature (celcius): 32.4
[2013-05-11 21:59:06] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:10] Accepted 7cc24416 Diff 2/2 BFL 0 pool 0
[2013-05-11 21:59:10] Accepted 7e8e4ce0 Diff 2/2 BFL 0 pool 0
[2013-05-11 21:59:13] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:15] BFL0: Error: Get result reports: Temperature (celcius): 32.5
BUSY
[2013-05-11 21:59:26] Accepted 0f4fe67d Diff 16/1 BFL 0 pool 0
[2013-05-11 21:59:28] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:31] Accepted b43e14ae Diff 1/1 BFL 0 pool 0
[2013-05-11 21:59:32] Accepted b63cf524 Diff 1/1 BFL 0 pool 0
[2013-05-11 21:59:37] Accepted 12c29573 Diff 13/1 BFL 0 pool 0
[2013-05-11 21:59:37] Accepted a777e978 Diff 1/1 BFL 0 pool 0
[2013-05-11 21:59:40] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:42] BFL0: Error: Get result reports: Temperature (celcius): 32.2
NO-NONCE
[2013-05-11 21:59:47] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:48] BFL0: Error: Get result reports: Temperature (celcius): 32.2
BUSY
[2013-05-11 21:59:52] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:53] BFL0: Error: Get result reports: Temperature (celcius): 32.3
BUSY
[2013-05-11 21:59:57] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 21:59:58] BFL0: Error: Get result reports: Temperature (celcius): 32.2
BUSY
[2013-05-11 22:00:04] Accepted 1dcc5b01 Diff 8/1 BFL 0 pool 0
[2013-05-11 22:00:09] Accepted 192cc2d1 Diff 10/1 BFL 0 pool 0
[2013-05-11 22:00:09] Accepted 3565e5f9 Diff 4/1 BFL 0 pool 0
[2013-05-11 22:00:11] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:00:14] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:00:14] BFL0: Error: Get result reports: Temperature (celcius): 32.2
[2013-05-11 22:00:20] Accepted 28c03bc3 Diff 6/1 BFL 0 pool 0
[2013-05-11 22:00:20] Accepted 8a11dea1 Diff 1/1 BFL 0 pool 0
[2013-05-11 22:00:23] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:00:25] BFL0: Error: Get result reports: Temperature (celcius): 32.6
BUSY
[2013-05-11 22:00:33] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:00:35] BFL0: Error: Get result reports: Temperature (celcius): 32.9
BUSY
[2013-05-11 22:00:45] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:00:46] BFL0: Error: Get result reports: Temperature (celcius): 32.3
BUSY
[2013-05-11 22:00:48] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:13] Accepted 13c60315 Diff 12/1 BFL 0 pool 0
[2013-05-11 22:01:18] Accepted d859eee1 Diff 1/1 BFL 0 pool 0
[2013-05-11 22:01:22] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:23] BFL0: Error: Get result reports: Temperature (celcius): 32.6
BUSY
[2013-05-11 22:01:25] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:28] BFL0: Error: Get result reports: Temperature (celcius): 32.8
BUSY
[2013-05-11 22:01:34] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:34] BFL0: Error: Get result reports: Temperature (celcius): 32.7
BUSY
[2013-05-11 22:01:43] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:45] BFL0: Error: Get result reports: Temperature (celcius): 32.7
BUSY
[2013-05-11 22:01:55] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:01:55] BFL0: Error: Get result reports: Temperature (celcius): 32.9
BUSY
[2013-05-11 22:01:57] BFL0: Error: Request temp invalid/timed out (0:-7)
[2013-05-11 22:02:05] Thread 6 being disabled
[2013-05-11 22:02:05] Thread 7 being disabled
[2013-05-11 22:02:05] Thread 2 being disabled
[2013-05-11 22:02:06] Thread 3 being disabled
[2013-05-11 22:02:06] Thread 5 being disabled
[2013-05-11 22:02:06] Thread 4 being disabled
[2013-05-11 22:02:06] MTX: BitForce USB failed to release 'cgminer-usb-2-3' err (288)
Hello, folks. Just to confirm that this is a reproducible problem. If someone can look in to the USB Device 0 issue with cgminer I'd really appreciate it. It happens quite a lot and the behavior mimics a throttle event.  |
|
|
|
BitFury, let me invest some cash in your operation Is this what you are looking for? Quite possibly, thanks for the info! |
|
|
|
Considering the notion of Elden Tyrell's 'Process Invariant' metrics, I have a feeling BitFury's efficiency per Watt will be high. i.e. BFL's logic translated to transistor arrangement is poor considering, purportedly, on a 65nm process node. And I'm quite sure that BitFury will not overlook the simple logic of setting the ASIC clocks to idle when there's no work in the queue - unlike BFL. Too bad BitFury's opinion is that mining will eventually centralize - that can be used to speculate that BitFury is going to keep all of his hashpower in the hands of a private organization. Blah.... sucks. Edit: BitFury, let me invest some cash in your operation |
|
|
|
I'll just leave this here...  |
|
|
|
The Bitcoin market is more polar. i.e.  Depending on the frequency of steps in the polar graph. I've mastered Bitcoin trading with this pattern.....  you can plot a slight variation over the complex plane in a much more insightful way:  code in Sage: var('x y'); complex_plot((x*sin(2 * x^2)^3), (x,-2,2), (y, -2, 2), plot_points=300)Nice. Good tip. I will be sure to place all of my asks in the black hole region. |
|
|
|
Re: Go's special channel interfaces. Any benefit for a Bitcoin client?
Of course - it would be a huge waste to not use such a great feature, and also go routines... Though not really so much of it, at least at this stage. If you grep the sources for "chan" or "go", you can find the places. Sweet. I'll take a look. It would be interesting to see how Go's special benefits could be proven in a bitcoin client. |
|
|
|
But as serious weapon 3D printing is not practical. Firearm must be reliable to fire tens of thousands of rounds. It must not break when dropped or grabbed by enemy in close quarter combat.
Sharing blueprints of real guns is the way to go. Maybe initially optimized designs like Sten SMG or Makarov PM. Then someone with right tools and materials can make copies.
I'm not so sure about that. Yes, "real" guns are certainly much better long term. But perhaps the question should be more something like this: Could John Wilkes Booth have used this effectively? Bingo. Nothing like something one-time-use lethal to kill your least favorite rich person or politician.  |
|
|
|
|
Awesome. Thanks for bringing Go to Bitcoin.
Re: Go's special channel interfaces. Any benefit for a Bitcoin client?
|
|
|
|
|
Show Posts
