Chen Jianhai has agreed to return at least $140,000 and 20,000 BTC under the condition that Bitcoinica LP will not start a police investigation about the hack. I have made it clear to him that I will have zero tolerance on this wrong-doing and if the promised amount is not paid back, I will make his identifiable information available to the police, and possibly public.
Yeah, not shady at all. I wonder if the next e-mail from zhoutong will be one saying that the Bitcoinica Consultancy members have gone to the police and blaming them for the fact that the promised money won't be forthcoming. Somehow I can just imagine everyone here buying into that and blaming it on the person who allegedly called the police on the thief, letting the guy whose passwords and accounts were used and in whose direction the evidence points off scott-free. |
|
|
|
running as pr above but on + poclbm gives (approx)
ICA 0: 360/360 U: 4.30/m
ICA 1: 355/360 U: 4.15/m
ICA 2: 355/355 U: 2.05/m
ICA 3: 360/360 U: 6.75/m
overall U: 17.3/m
hint? is ICA2 not flashed properly despite VM saying it was a success?
It probably did flash properly, it's just that one of the FPGAs on ICA 2 has frozen. Probably FPGA1, that always seems to be the one that falls over first on ebereon's boards. |
|
|
|
makomk,
what are DCMs?
spiccioli.
They're the things that generate the clocks for the rest of the FPGA. No working clock means that the FPGA is almost literally frozen. |
|
|
|
If I'm correct it must be the FPGA pair 0/1, on 3 of my boards FPGA1 freeze after some hours with 200, 190, 180, 170, 160. So i flashed the 150Mh bitstream, after 1 day and 12 hours it has freeze again on 2 boards, the 3th is still running at 4.89 U/m. I will test now the 140Mh on the FPGA1 on the 2 problematic boards. Just try it. It's probably the DCMs losing their lock, had a chat with Glasswalker and he confirmed it's a problem on the Cairnsmore1 boards. I may have a workaround out in a couple of hours if the Xilinx gods smile upon us all. A proper fix will be trickier. |
|
|
|
Well in light of all this, I had a chat on IRC with makomk, and we have decided that I'm going to release all my work so far, (even though it's still unstable, we're rapidly working on fixing that). And makomk will share all his "tricks" and work so far. Together we're working with some additional help from TheSeven as well. To collaborate on a single opensource bitstream project which hopefully will have many improvements for everyone.
Initially this will be targeting the Cairnsmore, but we're going to try and keep it "hardware agnostic" if possible. And of course 100% opensource, including project files required to build it, and it can be built purely in Xilinx ISE (no third party tools).
In addition, I'm now officially open sourcing my new bitstream (the new hashing core) which is still incomplete, but has huge potential I think. So with all this combined, this bitstream has the potential of being a great new boost to the bitcoin FPGA mining community as a whole.
Anyway, with this agreement, we've agreed, that if the community decides that we "qualify" for the bounty, we will be splitting the bounty down the middle 50/50.
This way we're no longer competing, but instead cooperating to deliver a new improved bitstream to the community. Which is good for everyone.
Hopefully makomk will pop in here shortly and confirm this from his end with a post. Just a quick note to (mostly) confirm this. I may still be releasing my own bitstreams in parallel to working on the new project - they're focused on very rapid testing of small incremental improvements, whereas developing a new hashing core is really hard - but regardless of which "wins" in the end I'll still be splitting the bounty down the middle with Glasswalker. The duplication of effort was seriously getting out of hand and I didn't realise quite how much so until recently. |
|
|
|
On the 160 Version CGminer reports an Icarus failure and changes the board status to 'off'. Weird. Unless I'm missing something - which I might well be - the only thing that would cause that to happen would be the USB serial device disappearing out from underneath CGminer. While that has been happening to a lot of people, it shouldn't be affected by which bitstream you use. Then again, nothing's impossible, particularly with the CM1. For the 190 version, it fails Icarus detect. 'get 000000 should...' I tried the 190 on a couple different boards with the same result. The best I ever got was one half of the array detecting successfully. This hashed for about 6 hours before failing in the same manner as the 160. Now that's more common unfortunately. I don't suppose you have the numbers it reported? |
|
|
|
The 140 bitstream works fine. 160 hashes a few dozen shares and then falls over. 190 simply fails Icarus detect. Yeah, this is honestly a mystery to me. I have no idea why it wouldn't work on cgminer. What error messages did cgminer give exactly? |
|
|
|
Makomks 160mhs bitstream ran on my 3 boards for 9,5h before failing, a board had dissapeared from device manager.
I would say, thats a USB cable problem. As I had the same issue with 4 boards and since I changed them, everything is ok. Yeah, a bad bitstream shouldn't be able to cause that - USB's handled by a different chip, which presumably runs off seperate power rails to the FPGA and a seperate clock source. Though you never know with the Cairnsmore1. |
|
|
|
OC'd to what? the numbers in the filename are todays date right....or are they?  Sorry, should've said. 170 MHz, 180 MHz and 190 Mhz. According to the Xilinx timing analyzer the maximum clock rate for this bitstream is 166 MHz. |
|
|
|
You have the wrong one, the one you want (trust me) is:
shortfin_icarus_cm1_test_160.bit
Yeah, there probably shouldn't be any reason to use the older non-shortfin variants anymore. The newer ones are 99.9% the same except with improved reliability. makomk 160.bit on board #62-0008 gives a U: of 0.5 - 0.8 after an hour of hashing using cgminer 2.4.3 on linux.
Wait, does that mean your board serial number is 8? If so, don't bother - apparently my bitstreams don't work on boards 1-50. Unrelatedly, untested overclock time! WARNING: the bitstreams in the following archive are overclocked bitstreams. This means that they run the FPGAs on your board outside of their specified limits. This may void your warranty, damage your hardware, and/or cause cats and dogs to sleep together. Use at your own risk. http://www.makomk.com/~aidan/shortfin_icarus_cm1_20120730_oc.zipEdit: though saying that, even the fastest of these shouldn't overclock your board any more than trying to run a standard Icarus bitstream on them would. I'm not sure whether that's reassuring or worrying. Never mind, confused with something else. |
|
|
|
New Results with makomk 160.bit running smooth so far in cgminer 2.6.0.
Its getting there!
ICA 0: | 357.4/358.3Mh/s | A:194 R:0 HW:0 U: 4.50/m
ICA 1: | 361.1/355.3Mh/s | A:205 R:0 HW:0 U: 4.75/m
Nice! Out of interest, did you have trouble getting the board to pass cgminer's validation? I'm hoping I found the cause of that problem and fixed it, but... |
|
|
|
OK, thanks to some minor tweaks I've managed to create a bitstream that does actually run properly at 160 MHash/s. You can download the new set of bitstreams from http://www.makomk.com/~aidan/shortfin_icarus_cm1_20120729.zip - instructions are the same as for the previous set. Might release a mildly overclocked 170 MHash/s bitstream next. Also, donations to 1CCorPPK8X6Px5iNxCBc5Eciw81iZPVBPh are welcome. I was actually holding off on replying to eberon's comment asking me to post a public donation address until I had good news to report; it just took a bit longer than expected. |
|
|
|
That's the paradox that needs to solved or a system to prevent abuse. Solidcoin's 51% attack schema worked, trust me I tried a dozen times from every angle I could. Unfortunately I think it was the wrong approach or better said, the wrong execution of the right idea. You didn't try hard enough. |
|
|
|
If Zhou really did this that would make him a opportunist not a con.
(If we assume that bitcoinica was a genuine operation, which it was, for a time imo, since it was profitable and sound)
He claimed it was both profitable and sound. From the leaked memos, it seems the new operators never managed to make the levels of profits that Zhoutong claimed he was making. Unrelatedly, the article makes a really good point here: The good news is that most con men get caught because they are so good at convincing people of mistruths that they con themselves into believing they wont get caught. Over-confidence is what traps most of them. They over-reach their skills or underestimate the victim. They get sloppy or lazy, making bad assumptions after some successes. Conversely, they may become too ambitious, have too many irons in the fire, and trip themselves up. Some scams collapse under the weight of too many lies or are exposed when a third party identifies the pattern. Others crack wide open when a victim realizes that hes been rooked and contacts authorities to complain. |
|
|
|
Relevant?
Session Time: Fri Jul 13 00:00:00 2012
[00:49] * phantomcircuit (~phantomci@c-67-188-9-35.hsd1.ca.comcast.net) has joined #intersango
[00:49] * ChanServ sets mode: +o phantomcircuit
[01:01] * phantomcircuit sets mode: -o phantomcircuit
[01:01] * phantomcircuit is now known as steve_bobs
Session Time: Fri Jul 13 00:00:00 2012
[00:49] * phantomcircuit (~phantomci@c-67-188-9-35.hsd1.ca.comcast.net) has joined #bitcoinconsultancy
[01:01] * phantomcircuit is now known as steve_bobs
Session Time: Fri Jul 13 00:00:00 2012
[00:49] * phantomcircuit (~phantomci@c-67-188-9-35.hsd1.ca.comcast.net) has joined #bitcoinica
[01:01] * phantomcircuit is now known as steve_bobs
I call fake on that chat-log. I can't find any evidence of that anywhere. It's not fake. I found essentially the same thing in my chat logs for #bitcoin-dev; sadly the public logs don't seem to contain nickname changes. I'm not sure what it means though... |
|
|
|
That makes sense. If you think BCX will succeed and are immoral, then the way to profit at the exchange's expense is transfer a lot of LTC in to an exchange and sell them for BTC during the fork.
If the attack is successful then the LTC deposit is rolled back and you can sell them again. Assuming there is somebody still willing to buy them.
In any case, lots of buying before the attack then lots of selling while the fork is being created is the pattern I would expect to see. Of course, that is the same pattern as a plain pump-and-dump scheme...
I'm not sure how well that attack would actually work. As soon as the 51% fork hits the network, the existing miners will immediately start trying to reinsert any non-conflicting transactions it rolled back. You'd basically need the co-operation of the 51% attacker in some form or another to make sure that your transactions conflicted and couldn't be re-introduced. |
|
|
|
I think you should be able to use those DIP settings for both programming and running the mining FPGAs. |
|
|
|
OK, ebereon seems to reckon this works so let's give it a go. http://www.makomk.com/~aidan/makomk_icarus_cm1_20120726.zip contains two Icarus-style bitstreams clocked at 140 MHz and 150MHz that should run on all the FPGAs of the Cairnsmore1, effectively turning it into a pair of slightly slow (280 Mhash/sec each) Icarus-like boards that you can use on your existing miners. The 150 MHz one's untested so I'd recommend starting with the 140 MHz bitstream. 560 MHash/sec per Cairnsmore1's certainly not all that bad. You want the normal (non-Glasswalker2-alpha) controller for this. Set SW1 and SW6 according to the "Twin Build (Icarus)" diagram on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html and SW2/3/4/5 according to the "Initial Shipping Build (low performance) diagram. Load firmware, start your mining software and cross your fingers. Source code is... ahahahahah. It's included as required by the license, but unfortunately a lot of undocumented manual fiddling is required to get from there to the bitstreams. |
|
|
|
|
OK, this may sound like a very strange question, but what precisely is connected to pin A4 of the four XC6SLX150s? Particularly on FPGA2/3?
|
|
|
|
Ok a short update on progress with glasswalker's build that we are playing with. We have this now running on 3 FPGAs with a good stability and good mining results currently at a 175MHz clock rate. The 4th FPGA position still has some problems and we have a few more things that may make it viable in it's current form yet to try. Either running as 3 or 4 FPGAs we will aim to make a controller release available for it later today as it will give you all better hashing rates and U values. We will discuss with glasswalker how current bitstream is released and there may be more than one variant of the bitstream to suit each FPGA's particular needs.
The current issues are related to noise on the com lines which coupled with a weak UART design which either allow a false edge trigger and/or incorrect data to be received. At the penalty of a rebuild this can be fixed with a more robust UART design should the other methods that we are currently playing with fail.
Well, I guess that explains a lot... |
|
|
|
|
Show Posts
