|
The marketplace has changed. There is no point ordering anything from BFL anymore until they actually have stock on hand.
The ROI on BFL pre-orders has been terrible, most people will not make the money back they have paid out for the pre-order because of the slow production line. The practical solution is not to order. I am not suggesting don't buy BFL, just don't pre-order, wait until they have stock so you can punch into a Bitcoin calculator and work out if it's worth buying. The gen1 product is obviously not worth buying unless they at least halve the price. The Monarch quite likely will not be worth buying if it ships in February. Best hold on to your money until February and then make the calculation. You could easily find BFL will have to halve the price of the Monarch in February to be competitive, so it would be crazy to pay for it now.
I know other ASIC vendors will be reducing their prices before the end of the year. KNCminer have already announced price reductions on Nov delivery.
The ASIC industry is coming up for a massive shake out, the winner will be the companies that have stock on hand.
Selling places on a pre-order queue is absurd.
|
|
|
|
You just need to offer your services to Ripple community, because every Rippler can make a direct payment to any bitcoin address from his Ripple wallet via something called "Bitcoin Bridge". Basically, every Rippler is actually Bitcoiner too  Just what we need, a centralized interception of Bitcoin transactions too. Was Ripple designed by the NSA? |
|
|
|
They wanted it to be rack mountable for data centers. Racks are typically 19" wide.
The case is nowhere near 19" wide. They could have made the case 19" so it actually could be rackmounted and would have had enough space to mount a (user supplied) ATX PSU inside AND put the modules in a line. I never said they were 19". You can put something in a rack that is less than 19" with a shelf but you can't put something in a rack that is over 19" wide which the case probably would have been if they put 4 boards next to each other. They could have made a 3 module 300GH/s unit for 19: racks with the modules nicely side by side in a good push pull cooling setup. |
|
|
|
Exactly 12blocks will be mined at the starting diff.
Seriously, you really think a 110% increase every 12 blocks is going to slow down 400+ mhs? ~BCX~ No. Not for long ...  I'm still hopeful to get a block. Maybe two... But he is right, you don't start a coin off on a crazy low diff like .0002, I would be starting with difficulty set to 0.035 would would allow a 1MH/s rig to find a block in 2.5min average. |
|
|
|
That's no different than an normal coin launch scenario.
Valid point, but care to guess how many of those blocks I will mine at 400+ mhs with a starting diff of .0002? ~BCX~ Exactly 12blocks will be mined at the starting diff. |
|
|
|
Currently tyrion70 has signalled that his pool and block explorer is standing by at block 63,999
As am I. You do realize by announcing the time this far ahead, the chain is going to be hit with a massive amount of hash power from all sides and multiple forks will take off in several directions due to the very low diff and fast retarget, don't you? That's no different than an normal coin launch scenario. |
|
|
|
|
And when the attacker strikes again what then? Another checkpoint.
|
|
|
|
Keith from KNC says: There has been a slight revision in our casing that we had neglected to previously explain.
The case has had an airflow improvement to ensure increased thermal efficiency.
We have ensured the hot air from the front two heatsinks is redirected, avoiding the rear chips, and is expelled from the casing by installing fins affixed to the upper casing section (despite appearing in the CAD as part of the lower section of casing). In turn this allows a sufficient amount of cool air exits to ensure a cooler operating environment for the rear heatsinks to operate comfortably.  What I don't understand is why they didn't make a wider case with all four modules side by side instead of trying to direct the air with baffles. |
|
|
|
|
Some things that concern me.
Before KNCminer have shipped a single product they have:
- Discontinued the Mars product line.
- Disconnected the Mercury product line.
- Reduced their prices for future batches, thus people waiting for delivery at the old price must feel ripped off to know they have that much profit margin to play with.
|
|
|
|
Who knows, despite many requests, nobody will publish the IP of a node that's on the right chain to sync to. |
|
|
|
You are all wrong.
The problem started before block 63485, it started during the time warp. The coin is still under attack!!
Please take off your blinders and quit holding on to old resentments and realize that these minor fixes are creating more problems. Rollback to 63380, and remove the block time from 1 minute and change it to 4 minutes, change the confirmations to 5 instead of 6.
Read the code noob, the block time 1min doesn't kick in until block 64k it had nothing to do with the problem I pointed out. else if(pindexLast->nHeight >= 63999)
{
nTargetTimespan = 120; // 2 minutes
nTargetSpacing = 60; // 1 minute
nInterval = nTargetTimespan / nTargetSpacing;
|
|
|
|
I've not examined every single block but I've only noticed 1 block which appears to go back in time by a matter of a few seconds, we're not talking hours here as would be expected if someone just dumped blocks on the network. All of the rest appear to go in sequence albeit getting generated ever faster due to the rapidly dropping difficulty.
There is an error in the code which allowed it to go to the absolute bare minimum difficulty and stay there. I have confirmed as much myself in testing. That is what has caused the massive number of blocks so yes I am going to validate the blocks up to 63,999 as this is the point that all clients agree on before going their separate ways.
What is the payout address that mined almost all the 500+ blocks between 63486 and 63999 in less than 20min? |
|
|
|
I don't believe the issue existed in v0.8.2.1, I believe It was introduced in v0.8.3.1.
The fairest solution to all is to roll back to the last block that all clients will have accepted which was 63,999. At this point I intend to create a separate fork by mining exactly 1 block. This new block 64,000 will be added as a checkpoint and this is where we will be starting from in the next client version.
I have abandoned the plan to reduce the block time from 2.5 minutes but I'm not going to increase it either. I will however be bringing retargets to 12 blocks apart and I intend to make the maximum adjustment 110% although it will remain on 400% for the first few retargets to bring us up to around a ~0.25 difficulty by block 64056.
The next client version will also ban all versions lower than itself from the get go so the update will be as mandatory is it can possibly get.
I am currently running isolated tests from my new baseline block 64,000 to ensure that it is behaving as expected so don't expect a new release too fast. I'd much rather fix issues now than have to do all this again.
I am amazed, how many time in this thread do I have to say the attack started at block 63485 can't you people simply look at the block chain at that point and the timestamps to confirm what I am saying? You are proposing to validate the bad blocks between 63485 and 64000 by introducing a checkpoint I don't believe this nonsense! |
|
|
|
The point everyone seems to miss is the problem started at block 63485 not block 64000, prior to block 63485 blocks were being found every couple of minutes, then they suddenly were coming in every few seconds, I was watching the count on one of the pools stats pages, not on the block explorer that came later. Someone started to inject fast blocks at block 63485. Then when we hit 64k some of the blocks were 400 coins long but most were still 1000 coins. I would say the 400 coin long blocks were the legit ones, and the 1,000 were an attack or bad cleint. A fundamental flaw in all the crypto coins bases on Bitcoin code, is the ability to accept mined blocks at a faster rate than a per-determined lower limit. eg. if you want your block rate to be 60sec then peers should not accept blocks that are time stamped ad being mined less than 30sec apart. The client software should use the many time servers on the Internet to set the time accurately, then reject impossible time stamps such as pre-mined chains from an attacker. IRC peers should be disabled by default in the client software, and a few reliable seed nodes in the code. I good coin should use NTP timestamps not timestamps agreed by the coin network. The problem is discussed here: http://culubas.blogspot.com.au/2011/05/timejacking-bitcoin_802.html |
|
|
|
After block 64k, difficulty dropped and no increase of difficulty since then. Looks like there is some bug in the new version.
No as I pointed out there was a fast block injection well before block 64k, I assume an attack as there was no payout address on the mined blocks. You can see after block 64k that most of the blocks were still paying out 1,000 coins meaning is was an old or hacked client. I would say that block 63485 onward was a forked chain and we need another checkpoint release if it doesn't correct itself. I certainly wouldn't be doing any transactions. |
|
|
|
|
The GME diff just went down again, at block 63456 now Difficulty: 0.192
Someone is trying to fork the chain at block 63484 with a fast block injection attack.
This is where selecting peers carefully comes into play.
|
|
|
|
It is possible that the "Attacking" chain is isolated on a private network and hashing away. If/When it is longer than the "Legit" blockchain it can be put online and invalidate any of our work.
You may not be able to see the "attacking" chain now but it might exist.
The only real defense against this would be to have more hashpower on the "legit" chain than any attacker would have.
Or keep a record of the valid block id's and reverse the attack with a checkpoint if it happens. Meanwhile some Overclockers Australia (OCAU) members have chucked 30MH/s of gear onto mining GME for a little while to help the blocks tick over a bit quicker to the next diff lowering, just in case you are wondering why the sudden block rate pickup. /UPDATE the difficulty just changed at block a little while ago from Difficulty: 3.078 down to 0.769 which should help reach the 64,000 target a bit quicker. |
|
|
|
|
Show Posts
