I am soliciting offers for the purchase of my 103 BTC balance at Bitfloor.
How do you plan to make the sale effective? do you sell your account? All means of Bitcoin transfers have been shutdown on bitfloor. I would expect Roman to faciliate the tranfer of obligations to your account. Well, I don't have an account and it's closed for registration. Other than that I'd offer 25, deal? Not even close. Bitfloor in liquidation is worth at least 40% of the reported losses. Plus gross negligence on Roman's part should make it straightforward to get a judgement against his personal assets. Why didn't you state up front that you were looking for at least 40% instead of berating people for sending what they believe to be a reasonable offer? You are the only person doing any berating in this thread. What I did was kickoff a very necessary discussion into the valuation of Roman's presently defaulted obligations. Do you have anything constructive to contribute? If not, please take a Midol and the rest of your life off from posting to me. |
|
|
|
I am soliciting offers for the purchase of my 103 BTC balance at Bitfloor.
How do you plan to make the sale effective? do you sell your account? All means of Bitcoin transfers have been shutdown on bitfloor. I would expect Roman to faciliate the tranfer of obligations to your account. Well, I don't have an account and it's closed for registration. Other than that I'd offer 25, deal? Not even close. Bitfloor in liquidation is worth at least 40% of the reported losses. Plus gross negligence on Roman's part should make it straightforward to get a judgement against his personal assets. |
|
|
|
I am soliciting offers for the purchase of my 103 BTC balance at Bitfloor.
How do you plan to make the sale effective? do you sell your account? All means of Bitcoin transfers have been shutdown on bitfloor. I would expect Roman to faciliate the tranfer of obligations to your account. |
|
|
|
|
I am soliciting offers for the purchase of my 103 BTC balance at Bitfloor.
|
|
|
|
|
I find myself in the inconvenient position of being an involuntary creditor to Bitfloor and Roman Shtylman in the amount of 103 BTC.
I am taking offers for the purchase of this debt and all related legal rights.
|
|
|
|
But we know they are with pirate.... I don't think anyone suspects any of the PPT operators of stealing the coins. If it is in bitcoins or USD is not important.
You are trying to absolve the PPT operators of any wrongdoing. Is that you Patrick? The nature of a Ponzi operation is very simple. It works as long as the inflow of funds exceeds the outflow. Once the net flow of funds turns negative the end is inevitable. It is merely a question of when the scheme folds up. A more narcissistic operator may be overwhelmed by the high of the attention and adulation he is the recipient of and ride the whole thing down to a negative balance as Madoff nearly did, whereas a calculating thief will pull the plug in fairly short order from the turn in cash flow. If you want to time a Ponzi, information on the flow of funds is critical. Knowing when the cashflow turns will always give you advance warning of the endpoint for the process. #1 - I am not PH, but thanks for the compliment. Also I am not trying to absolve anyone of anything... I am just trying to talk through things that don't make sense in my brain. #2 - This is *exactly* my point of things that just don't 'add up'. If I were pirate AND I were running a ponzi then I would not want PPTs for exactly the reason you stated. It just doesn't make sense. For one thing, it gives him co-conspirators. They massage his ego, and act as a shield against the truth tellers on the forum. And now, they may very well be chips he is using to negotiate a more favorable sentence. Add that to the equation and see if things start making sense in your little woolen brain. |
|
|
|
But we know they are with pirate.... I don't think anyone suspects any of the PPT operators of stealing the coins. If it is in bitcoins or USD is not important.
And now the reason for the creation of your sock account is made clear. You are trying to absolve the PPT operators of any wrongdoing. Is that you Patrick? The nature of a Ponzi operation is very simple. It works as long as the inflow of funds exceeds the outflow. Once the net flow of funds turns negative the end is inevitable. It is merely a question of when the scheme folds up. A more narcissistic operator may be overwhelmed by the high of the attention and adulation he is the recipient of and ride the whole thing down to a negative balance as Madoff nearly did, whereas a calculating thief will pull the plug in fairly short order from the turn in cash flow. If you want to time a Ponzi, information on the flow of funds is critical. Knowing when the cashflow turns will always give you advance warning of the endpoint for the process. PPT operators were ideally situated to have that information and act upon it. Once a particular fund's flow turns negative, an operator with ill intent could safely start his own shadow Ponzi; holding all deposited funds himself, and increasing withdrawal rates over actual customer demand. If you are a PPT operator and want absolution, a good starting point would be to disclose your deposit and withdrawal addresses so that there is proof that you continued to flow funds to Trendon in a transparent manner right up until the end. |
|
|
|
I do think the total performance issue is a function of my network performance and pool performance. I also think a little more time tweaking icarus-timing might push it over the hump. Thanks for the advice Makomk. I will give the new bitstreams a try once things settle out and my brain is on the same time zone as my body.  Paid 25 BTC to Glasswalker 25 BTC to Makomk 5 BTC to Kano Thanks for all the hard work you've put into this guys! |
|
|
|
I will give my opinion. Others may think differently, there is such a broad range of hardware performance that everyone is going to have different experiences. Below is the performance of 8 recently build boards (>04xx) after running Makomk's latest 200MHz bitstream for 4 days. cgminer version 2.6.4 - Started: [2012-08-17 13:46:13]
-------------------------------------------------------------------------
(5s):6241.1 (avg):6106.0 Mh/s | Q:998120 A:576799 R:366 HW:0 E:58% U:79.1
TQ: 1 ST: 16 SS: 0 DW: 26304 NB: 840 LW: 0 GF: 2106 RF: 8
Block: 000005866228c10025bc465254296925... Started: [15:04:14]
-------------------------------------------------------------------------
ICA 0: | 381.4/381.9Mh/s | A:38392 R:34 HW:0 U: 5.27/m
ICA 1: | 387.2/382.1Mh/s | A:39066 R:26 HW:0 U: 5.36/m
ICA 2: | 390.1/382.1Mh/s | A:39067 R:20 HW:0 U: 5.36/m
ICA 3: | 388.1/382.0Mh/s | A:38908 R:25 HW:0 U: 5.34/m
ICA 4: | 386.1/384.1Mh/s | A:38836 R:22 HW:0 U: 5.33/m
ICA 5: | 380.6/381.9Mh/s | A:39043 R:21 HW:0 U: 5.36/m
ICA 6: | 390.7/384.2Mh/s | A:38854 R:31 HW:0 U: 5.33/m
ICA 7: | 385.1/382.0Mh/s | A:38711 R:23 HW:0 U: 5.31/m
ICA 8: | 390.9/384.4Mh/s | A:39281 R:24 HW:0 U: 5.39/m
ICA 9: | 382.9/382.0Mh/s | A:38805 R:24 HW:0 U: 5.32/m
ICA 10: | 371.0/375.4Mh/s | A:15949 R: 9 HW:0 U: 2.19/m
ICA 11: | 371.0/375.4Mh/s | A:16269 R: 9 HW:0 U: 2.23/m
ICA 12: | 384.3/382.2Mh/s | A:38974 R:22 HW:0 U: 5.35/m
ICA 13: | 378.8/382.1Mh/s | A:38997 R:36 HW:0 U: 5.35/m
ICA 14: | 386.5/382.1Mh/s | A:38864 R:25 HW:0 U: 5.33/m
ICA 15: | 392.9/382.0Mh/s | A:38784 R:15 HW:0 U: 5.32/m
-------------------------------------------------------------------------
The total utility of 79.1/minute corresponds to 708 MH/s per board but this is being dragged down by one badly performing board. If I remove that board from the calculation, I get an average performance of 740 MH/s. That is still a hair under bounty target. But it is close enough that I think the spirit of the offer has been satisfied. There is also some risk that the value of bitcoin will dump in the near term as the pirate dust settles (or hits the fan). I don't want them to get shorted in such a situation. So, I intend to pay out my share of the bounty reward equally to Makomk and Glasswalker as they agreed. I have an address for Makomk already; Glasswalker if you PM me a deposit address, I will pay out the bounty the next time I have access to my wallet. |
|
|
|
boards which i had thought it was buggy after a power cycle and plug out plug in usb cycle ( and plugin first "buggy" boards) it started to work again .
I ordered new hub switches and new fans but they dont be received till wed/thu , so i will have to wait to test new things.
I'm using w7 64bits and the admin privileges issue ahows up randomly no matter if I'was or not in admin mode , and when it appears allways the board is in "my frozen mode" COM's OK ,orange led...
you get the same error if you try to run a second instance of cgminer over a running board but in "my" case it show up slowly as it was checking something on the board.
Edit: not the same in "my case" before the admin privileges line it shows up the lines
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2
what do you mean a second instance of cgminer over a board? My windows boxes always mine from the last 2 COM ports of any board, and the first board starts with COM20. So I have always (6 different win7 boxes here) started with -S "\\.\COM22" -S "\\.\COM23" |
|
|
|
|
I've programmed 20 odd boards with the Makomk 190 Mhz bitstream. They are mostly all hashing at over U: 5 / m. There are a few ~10% hashing painfully slow 1 or less. I won't have time to debug those, so I'm just letting everything run.
Startup was painful in a few cases, but generally, replacing cables and power cycling the boards seemed to resolve those problems.
Makomk, regardless of whether you with the bounty, there will be significant bitcoins coming your way from me!
Do you think you can push it farther?
|
|
|
|
well after 24h testing one board with makomks 160 it worked well for a while but after 8-10h (in the morning) ICA 1 was hashing at half its power... after reseting board with SW1 1-off it started to run again at full speed. it seems as one of the 4 fpga had stopped.
Are ICA 0 allways the same 2 fpgas? 0-1? 0-3? or they are randomly assigned ?
can you detect wich fpga is frozen apart from watching which fpga green led is not blinking? ( my boards are too high and i need to use a ladder).
I think my issues can be temperature ones. Here in Seville 40ºC (outside) is normal in summer. I would like to watch temp in my cgminer so I could analize behavior ( maybe next controller?)
I bougth a new conceptronic 4 port powered usb hub and it works perfectly in my aspire one. My old soyntec doesn't even work with my laptop
In windows ICA 0 will always be the com port that you point CGminer to with -S first. I think linux might swap port assignments around if you restart. 40C is probably hot enough that you are overheating the FPGAs. Enterpoint's thermal solution is very good, but it's constrained by cheap packaging of the Spartan-6. With 8-9W I think you would be above the rated t-j for this device. |
|
|
|
I can't reveal my sources, and it's been difficult to get confirmation of parts of this story, but this is what I've heard. - The mage that is building the SC masks was riding his unicorn to work last week when he was jacked up by a band of renegade Keebler elves.
- The unicorn fell on him so he couldn't use any spells and the elves messed him up pretty bad. (He builds optical masks so his specialty is Illusion - do I have to explain everything?) He finally managed to use his ring to summon an earth elemental and drive the little cookie making demons off. But they captured his unicorn.
- So now he has to use spellpower to get to work. Bottom line, things will be delayed 3 months or so.
- There is some good news though! A random comment by the cleric that was healing his wounds led him to realize how he could couple the hashing algorithm with one of the frozen planes of hell to reverse the computational thermodynamics of the process. This means that every time you find a share, you will also generate a few joules of electricity. With an SC mini-rig in the backseat you should be able to drive your Prius from San Francisco to New York without ever stopping for gas!
I know; some parts of this are hard to believe. But my source has been reliable in the past. And, if you knew anything about semiconductor design and manufacturing, it's far more plausible than BFL's story. |
|
|
|
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? On the 160 Version CGminer reports an Icarus failure and changes the board status to 'off'. 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. I will try a couple different boards and USB cables later tonight and let you know how it goes. I really appreciate all the work you have done. |
|
|
|
Makomk's 190Mh bitstream have qualified for the bounty!
760Mh on 8 of my 10 boards, the 2 boards are not stable on the 0/1 pair and running the 180Mh bitstream on this pair. I think that is no bitstream issue, it's hardware.
I have allready donated some btc to him, thats why i'm not donated to the threads bounty wallet address.
eb
You are awfully eager to declare the winner of a bounty you didn't even participate in don't you think? 190 fails Icarus detect in CGminer every time I try it. |
|
|
|
I tried the 190 OC flashed to the SPI and it seems to be working on 2 of my FPGAs. 2 COM ports are detected (22,23 for me). The weird thing is see the LEDS light up on 4 of the FPGAs as work is found, but MPBM is only reporting work from 2 of the FPGAs.  The only thing that I had to do differently is leave SW6 #1 ON in order for it to hash. Guess it's the same issue I have regardless of which bitstream I'm using. I'm only getting work from 2/4 of the FPGAs. Any help would be greatly appreciated. Thanks! When the leds flash, do they flash on the pair of FPGAs at the same time? If so, you have the DIP switches set wrong on P1 and P2. sw2 on p1 and p2 need to be OFF to run the array in paired Icarus mode. |
|
|
|
Makomk's 190Mh bitstream have qualified for the bounty!
760Mh on 8 of my 10 boards, the 2 boards are not stable on the 0/1 pair and running the 180Mh bitstream on this pair. I think that is no bitstream issue, it's hardware.
I have allready donated some btc to him, thats why i'm not donated to the threads bounty wallet address.
eb
I couldn't get the 160 to run for more than a few dozen shares. |
|
|
|
Right now the greatest uncertainty factor is how 'soon' Enterpoint will provide their dedicated CM1 bitstream unleashing the full power of the board. Nobody would start working on a new bitstream when we fully make it dependent on non controllable third party events - it must be a combination of intra- and interdependent compensation.
I agree that it is unfair to cut off the bounty solely on an Enterpoint release, and would discourage anyone from working on it. Part 2 of your proposal makes me dizzy and you're going to get into debates on the actual values for each delta to calculate it. I will make one caveat here. I will not pay a single Satoshi for delivery of a bitstream with any form of copy protection, that includes ET's sharecropping scheme or anything else that would prevent loading on any compatible board. I will match Zefirs commitment of 50 BTC for any bitstream that meets or exceeds the 750 MH/s rate and 48 hour stability up until August 31st, or the earliest Enterpoint release of a 4 processor hashing bitstream whichever happens last. Further I offer 100 BTC as a bonus under the following conditions: 1. At least 300 BTC including my 50 BTC above is committed to the bounty by the community under the terms finally agreed upon (minimal free riders) 2. All the files required to build the bitstream are published and released under a version of the GPL or more permissive license terms. 3. The bitstream is released on or before August 5th. 4. No Enterpoint bitstream using all 4 FPGAs has been released beforehand. |
|
|
|
|
My blue LED problem went away by completely powering down the affected boards and restarting. Twin_test came back up and the boards ran normally.
Out of 40 boards, I have 39 hashing. 36 of these are at full twin_test speed. The remaining 3 are running around half speed, and the one not operating is due to a corrupted windows driver. I don't think that is bad at all for prototype boards one month into production.
I had 2 USB cables that gave intermittent issues. Once I started swapping cables and scrapping any where the problem didn't reproduce with a second cable, life got a lot easier.
The other thing is making sure the DIP switches are set correct. I don't know if it's my dyslexia or I'm just stupid, but I had a terrible time with the orientation of the USB settings images. I ended up drawing my own settings list oriented from the power end of the board. Yohan, it would help if you rotated the switch images 90 degrees counterclockwise before posting.
37 boards plus the controller PC are drawing 975W peak according to my kill-a-watt.
|
|
|
|
The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actuall depends on which is the highest voltage. Notionall they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.
Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.
Here there is a possibility of simply clearing the config SPI flash of the 2 non-working FPGAs so there is nothing to interfere. Actually that gives me a thought of whether we can remove power from these 2 devices. You do need power for JTAG to work but otherwise it might work. A line parking build might do the same. I'll look at that as an option as it can be done quiclkly.
Often in bus powered systems the drop on the cabling and hubs would make the 12V derived fed win. However a powered hub might make this different. It's good and bad. First because
Cutting current draw from the USB when the 12V line is live would definitely be a good thing. Right now, bad things happen when you exceed the current capacity of the the USB input hubs. My best guess is that you need >150 mA per port to be safe. I am supplying my system with 250 mA / port to be safe. Presently I'm dealing with a very strange issue. After adding a few boards several of the boards already on the chain seem to have reverted to the ship test bitstream. In idle and in operation some boards have blue LEDs live 100% of the time, which I have only seen with ship_test. All boards had the flash programmed to twin_test before being connected. I have recovered some by reprogramming twin_test again. But a few board won't take the programming and throw USB errors. The programming is being done with an independent Win7 x64 system, and I have been able to program other boards without problems. |
|
|
|
|
Show Posts
