This sounds interesting although I'm not familiar with this path. If you could describe details on how to implement this setup that would be great. i.e. what cabling and connectors are needed? Thanks,

Hi Steamboat,

Thanks for a great project

Now that batches 1 - 4 have been ordered, do you have a confirmed ship date or arrival date from Avalon for each batch?

Earlier in this thread I think 9-10 weeks was given as the order lead time estimate from Avalon on chip purchases, but did Avalon provide any specific information after placing the batch orders? Just curious.

Thanks!

Fair enough, thanks for the replies everyone.

In for 160, email & TX ID sent.

Thanks steamboat for a great project.

Now I'm just wondering if should double the order

Quick question, does anyone have an indication on what the yield is expected to be on Avalon's bulk orders?

Does Avalon pre-test the chips and only send 10,000 known-good-die? Or do they simply cut up the wafers and ship, so some group buy purchases may end up with 9,900 working chips out of 10K, whiles others yield 5,000 working chips out of 10K?

For PCB board assembly there is an additional yield lost. Even if all 10K die work in a shipped batch, post assembly some die will fail. How will that be handled?

I am VERY interested in this and think steamboat is doing a great job putting this project together.

But that said, it seems we might be rolling the dice a bit. If you order 20 boards, maybe 100% will work, but maybe only 50% will.

Hi Yohan,

Understand you guys are busy with other projects, but just wanted to check in and see if the Cairnsmore2 project is something you are still considering or not.

Personally, I would prefer to scale a mining operation with the design path you outlined in this thread, and so have been holding off on other options. So it would be great to know if you still plan to pursue this project along the time frame originally outlined, or if your thinking has changed.

Thanks!

Someone who got into BTC a few years ago, and sold 14,000 at what let's say is an average price of $225, just made $3.1 million.

I wouldn't exactly call that being a dockhead...

I had this exact same rate when my thread_concurrency was too low, bumping up the TC to 4x the number of shaders fixed it.

So the best performance I've been able to come up with for a rig with two 5870s is a mere ~290Kh/s per card with the following settings.


I've read through this guide and tried many many combinations of the above settings, with limited results. This rig is a Windows XP x64 box.

It seems people have been able to get above 400Kh/s per 5870, which is a significant gap from the impact from changing the settings above and what I've been able to achieve.

Any suggestions or thoughts?

Thanks!

tacotime, Thanks a lot, running setx did fix the error above.

For any others, after doing the above I then received the new error below.

Changing "-g 2" to "-g 1" fixed that.

I'm now getting ~255Kh/s from each 5870, so guess it's time to try and optimize.

Hi, I am trying to switch my 5870 mining rig from BTC to LTC and am running into the problems below, if anyone has any ideas how to fix this I'd really appreciate it.

A 5870 has 1600 shaders, so my understanding is thread-concurrency should be set to around 1600 * 4 = 6400.

However if I set TC to 6400 with cgminer with,

I get the following error:

The only way to eliminate the error is to use TC of 1600

But with this I can only a) get around 250Kh/s per 5870 and b) get ~3 Hardware errors per minute (which I've read is caused by concurrency being too low).

My machine is Win XP x64 and it has plenty of ram.

Has anyone run into this before or have any ideas? I've had this system mining BTC very stable with no HW errors for over a year and switching back to BTC causes the HW errors to disappear so the rig is fine, its just the LTC settings.

Any suggestions would be very much appreciated. Thanks!

That's because Enterpoint is a real hardware company in operation for many years, it also means they'll be able to deliver on what they offer

And that is just M0 base money, once the banks take that $2.8B/day of printing and lever it up you end up with over $50B/day of money created out of thin air.

Imagine $50B/day being poured into BTC.

BTC are either going to the moon or crashing to zero.

There are practically no BTC offers above $110.

Now if this was fiat FED funny money, the FED would increase the amount of funny money to create "stability" (and give it to bankers and polititins in the process). And if this was gold the FED would "lend" it out in mass quantities (effectively creating fractional gold out of thin air)

But since the supply of BTC is FIXED, I guess we will finally get to see what happens when an item is in high demand, but supply is forced to behave by well defined rules....

Yes, interested in a system of that scale, look forward to more details when they are available.

A shorter way to phase this is:

Who would the restarted miners receive the double spend transaction from? Any network node a restarted miner connected to should have already rejected and expelled the 2nd transaction as a double spend, so even if nodes did not rebroadcast the original transaction, they would have already rejected the double spend and would not have propagated the double spend to a restarted miner.

It seems the only possible scenario is if the attacker connected directly to a restarted miner and submitted the double-spend to the miner first. This is statistically unlikely.

Again, these responses do not answer the original question which focuses on a different area, instead of attacking, attacking, attacking, maybe you could try to understand the question.

My question was why didn't the network of decentralized nodes block this double spend attack before it ever even propagated to the miners? There are multiple aspects to bitcoin that prevent double spends and the mined record-keeping blocks are just one of these many aspects. The responses above refer to the behavior of the rebooted miners, whereas I asked about the behavior of the decentralized client nodes.

Here is the sequence of events:

1) Block chain forked, pre-0.8 miners on one chain, 0.8 miners on another.

2) Attacker submitted a transaction to the network. This transaction propagated throughout the network efficiently and was accepted by a large enough number of client nodes, both pre-0.8 nodes and 0.8 nodes.

3) A 0.8 miner confirmed the transaction in a block. Time passed and this block received 6 confirmations. However the pre-0.8 nodes still had accepted the original transaction in their logs, even if that transaction was not confirmed in a pre-0.8 block.

This is the part I don't understand - 4) Attacker submitted a double spend transaction to the network. My understanding is this double spend transaction should have been rejected on both the pre-0.8 and 0.8 branches.
4a) The 0.8 nodes would reject the attack because it was a double spend against a confirmed transaction.
4b) The pre-0.8 nodes would also reject the attack because they already accepted the original transaction. Again this original transaction had over 1 hour to propagate and be received by the network of nodes as the 1st and original transaction.

5) 0.8 miners shutdown, clear logs and reboot as pre-0.8 miners. These miners represent <1% of the total network nodes. They reconnect to the network to receive new transactions. The rebooted miners now should receive the original transaction, because both the pre-0.8 and 0.8 nodes should have rejected the attack already and expelled it from the network, with or without the miners.

The fact that the miners cleared their transaction logs seems like it should be irrelevant. After rebooting the miners connected to the same network that should have already rejected the double spend before it ever reached the rebooted miners, as above

Again the mined confirmation blocks is only one aspect that protects against double spends, there are other aspects to protect bitcoin and it seems these protections should have worked here, but didn't. All I want to know is why.

The only answer that seems possible is if the attacker connected directly to the miners right after they rebooted and submitted the double spend first, this seems statistically unlikely.

Thanks for the reply, but my confusion is why the original transaction that was shared throughout the network and picked up in the 0.8 blocks, was not also at the same time recognized as the first original transaction in the pre-0.8 nodes (even if not inserted into a mined block). This should have prevented the issue.

For example, if I send all the BTC from address a to address b in transaction 1, then wait 5 minutes and try to re-send BTC from address a to address c in transaction 2, the network will reject the 2nd transaction as a double spend even if no blocks have mined yet because the majority of nodes have accepted transaction 1. (There is always a risk that the mined block will insert transaction 2, which is why we wait for confirmations because that creates the official record...)

I was watching the bitcoin-dev channel at the time, and the arguments made to fall back to 0.7 were both chains should have the same transactions and the only losses would be for the miners who lost the block rewards. This was stated several times by multiple people as the consensus was reached, it also matches my understanding of how the network works.

My understanding is this should have been the situation for the pre-0.8 nodes, no block was mined yet, but the pre-0.8 network should have still recognized the 1st transaction.

Nemesis, I have read that thread, numerous other items, and the IRC logs from the event multiple times. The above is a serious question, I guess I can't help you if you don't understand what the question is or can't answer it.

Then go do it and get involved. I would love to see this also but don't have time to, which is why I won't complain about the current developers.

From my limited time lurking around the dev IRC channel, it seems this need is understood but it is a large undertaking that the current developers a) don't need themselves and b) don't have time to do.

It seems for an interested person new to the code, getting involved in protocol documentation would be a great way to get up to speed on it. You clearly know code and can write better than most coders, so go ahead.

It's not clear to me how this happened even with the 2 chains.

For a period of time (~3 hours) there were two competing chains with pre-0.8 nodes viewing one as valid and 0.8 nodes viewing the other as valid.

However at the same time there was only one network of client nodes sharing transactions and they all saw the same transactions propagate through the network. The original transaction that received 6 confirmations on the 0.8 chain was in the network for ~1 hour before receiving these 6 transactions.

The pre-0.8 nodes had more than plenty of time to see and agree on this original transaction, and should have rejected the 2nd spend as a double spend, even if the original spend had not confirmed in the pre-0.8 chain. My understanding is from a pre-0.8 chain point of view, this case had  a 0-confirm transaction that was in the network for some time, so the network should have rejected the 2nd as a double spend even if the original hadn't confirmed yet. This is also why all the other transactions on the 0.8 chain propagated onto the current chain during the reorganization that happened.

If anyone can provide insight here I'd appreciate it.

It was my error, the mining hash rate has dropped so much that my payout credit per block changed from around 0.006-7ish yesterday to 0.03ish today. I thought the ozcoin payout calculation was screwed up and halved from 6 to 3, instead I missed the decimal point increase...