As stated in my mining guide (see sig), HW errors are mainly caused by thread-concurrencies that are too low (the RAM buffers for LTC start to overwrite one another and you get apparent data corruption)

reaper doesn't check for memory usage errors thrown by the cl kernel, so I would try using reaper instead before doing anything else.

yep

Okay, makes sense.  Drop an address here for LTC or BTC and I will send the reward.

Okay, thank you.  So the transactions on the network are all propagated through the miners in a peer-to-peer fashion, with each miner including his or her coinbase transaction after the tree root?  Is there anything that stops miners from excluding transactions that they don't want going through the network when they mint blocks?

https://bitcointalk.org/index.php?topic=140099.0

What do you think?

Please post a link to the pool where you're mining so we can all stand in awe

...goodbye cheap litecoins.

i told you assholes

Hi,

I read the following links:
https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Dump_format#CBlock
https://en.bitcoin.it/wiki/Block_hashing_algorithm

And I'm still a little confused on how the block header is hashed.

First off, how are the transactions that are not part of the coinbase transaction attached to the block?  Why does hashMerkleRoot change if a new transaction enters the network?  I understand the these are being updated constantly, but are there two hash trees in any given block, one for normal transactions and one for the coinbase transaction?  How is the hash tree assembled for for the normal transactions?

When we hash the block header, are we hashing all 640 bits contained inside of it (which constantly change)?  I understand that the hashing goal is to produce a result containing a certain number of trailing zeroes based upon the difficulty, but I'm confused about the data we're hashing and how the addition of transactions changes it, and how the inclusion of our coinbase value and address changes it.  I know the first transaction for any given block is the coinbase transaction, but I'm confused as to how the addition of this into the block we're hashing changes this.

The people who are denying the reality of ASICs at this point in time are delusional.

After testing today I found that 7950s respond the same way to core/mem ratios as the other 7xxx cards, here I am pulling 650kh/s per card with 3x 7950s:



With mem at 1550 MHz and core at 1150 MHz my hash rate actually goes down to about 560 kh/s per card

i own two, have had them mining ltc for 4 months without a hiccup.  get 580kh/s each on ltc, 1.037v, 1000mhz core, 1350mhz mem.  be warned they have no vrm cooling, so make sure they aren't over 90C in gpu-z.  otherwise they are great cards and run very cool (mid or low 70s at 22C ambient)

7950s are pretty much the best ltc cards

Yeah, I got mine for $100 5 months ago... might want to try between $60-80 shipped

ty guys for donations   i have updated some of the links!

I see nothing to worry about as far as litecoin is concerned, because litecoin actually introduces something of value: an ASIC/FPGA resistant hash algorithm.

The problem with TRC is that regardless of your developer bounties or your support in updating to the latest port of bitcoin-qt, there's still nothing at all innovative about TRC.  Why SHA256 mine TRC when you can already SHA256 bitcoin itself, which has massive support?

So there's the problem with TRC: no novel core functionality to spur on its adoption or worth.  If you want me to I could make a Terracoin2 fork in three minutes by changing three lines (genesis block, block reward, and block time) in bitcoin-qt with I don't know, say 12.5 coins per block and an average block time of 7 minutes?  But, who cares?

The drivers have been wacky lately, 13.1 breaks BTC mining while 12.10 breaks LTC mining.  12.11b seems to be the best.

I would disagree with ckolivas' statement (PM for alternate implementations of scrypt ckolivas), but if you really wanted to you could make a fork tonight with large memory usage.  See my memcoin thread w/r/t that: https://bitcointalk.org/index.php?topic=122256.0

The problem is that when you crank memory usage scrypt becomes absurdly slow, resulting in poor performance for all nodes in the network.

There are ways you can make the chain more ASIC resistant, and I hope to eventually publish a new protocol for that in the future.

My answer is, no, I doubt you can.  Any algorithm involved in hashing will likely be easily made parallel.  It's difficult to actually find any algorithms for simple problems such as sorting that run faster on a CPU as compared to a GPU.  There are quite a few papers by AMD, Intel, and nVidia in which Intel tries to find algorithms that runs faster on a CPU and almost always one of the GPU companies responds with a faster implementation on a GPU.

Many people misinterpret scrypt as requiring X amount of memory too; scrypt can be implemented such that it does not require large amount of memory (on the fly table reconstruction and look up) but instead requires a larger number of ALU cycles to complete the hash.  Scrypt basically yields a tradeoff: either the algorithm requires a lot of memory and not a lot of ALU cycles, or it requires a lot of ALU cycles and not a lot of memory.  The point is that either way you go it's expensive, and it usually seems to favour the higher memory implementations as long as the memory is silly fast (eg GPUs).

Wubi doesn't work?