Topic: Thread about GPU-mining and Litecoin - page 7. (Read 33227 times)

In my opinion, so long as a CPU rig can earn coins at a significant percentage rate of a GPU rig, then Litecoin is serving its purpose.  You have to keep in mind that a $1,000 CPU mining Bitcoin is going to take 60 years to find a block, while a $1,000 GPU rig will take about 2 months.  The CPU rig is .2% as efficient as the GPU rig.

Let's make the same comparison to LTC.  A $1,000 CPU rigs will make 30LTC a day while a $1,000 GPU rig will, according to rumor, make 600LTC per day.  The CPU rig is 5% as efficient.  There is a difference of 25 times between the inefficiencies of CPU's to GPU's regarding Bitcoin and Litecoin.

Even in a world of GPU miners, with Litecoin, the CPU is still very effective, especially when there is no initial outlay of money for the rig itself.  With Bitcoin, no matter how good your CPU is, it is utterly worthless for mining; this isn't even close to the case for Litecoin, if the rumors of GPU miners turn out to be true.

I see no reason for any changes.

Because it doesn't support litecoin?

Anyone can explain me why i am getting this error?

2012-02-17 22:01:10 Error 6 getting work. See http://curl.haxx.se/libcurl/c/libc
url-errors.html for error code explanations.
2012-02-17 22:01:10 Couldn't connect to server. Trying again in a few seconds...

I tried website mentioned, but cant find.
I used reaper 12 from http://wiki.solidcoin.info/wiki/Reaper

Well the common man isn't mining it and likely will never mine ANY coin.  Mining isn't necessary for usage.  Mining like any commodity business will be limited to those with highest efficiency.  Lots of people buy/sell/trade gold a much smaller number of people actually mine it.

Still even if one believes CPU = greater adoption (and ignores the issue of botnets) just having a GPU miner doens't mean someone will use it.  If one can get x mining LTC and get 2x mining BTC on the same hardware well it doesn't really matter does it?

LTC GPU performance isn't just competing against LTC CPU performance but also BTC GPU performance as well.  You can mine ShortBusCoins with GPUs and have been able to for some time but hashing power is a tiny fraction (even adjusting for relative difficulty) of Bitcoin meaning most miners with the ability to mine ShortBusCoins simply chose not to.

Unless it is more profitable to mine LTC instead of BTC on a given piece of hardware it would be illogical make the switch.  Everything is fungible.

I can get LTC a variety of ways:
$$$$ -> LTC
$$$$ -> CPUs -> LTC
$$$$ -> GPUs -> BTC -> LTC
$$$$ -> GPUs -> LTC (unproven)

I think you should find out more about why Coblee created litecoin :-

https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin



Either litecoin is a CPU coin or the major reason for its existence just disappeared?

From the latest stats it appears GPU mining scrypt is 25-35x faster than CPU, is able to be stacked in the same PC and is 6-10x more efficient.

Check out SolidCoins mining page for info on how a correct implementation of CPU/GPU hard algorithm should figure in performance.
http://wiki.solidcoin.info/wiki/Mining_Hardware_Performance

I agree with DeathAndTaxes on this one. It's not worth trying to limit hardware because it's improving all the time. By the end of this year Intel is expected to release their new Knights Corner 50-core CPU. That will be a good one for mining Litecoins, according to Artforz on btc-e. Are you going to try and stifle that one too?

Do you have any hopes of Litecoin ever becoming mainstream? It won't happen while 50% of the mining is done by botnets! That's why the Litecoin price is so low: nobody is going to put any serious money into a botnet currency.

A GPU miner is the best thing that could happen to LTC because botnets don't have GPUs. Let's leave Litecoin as it is and let's get mtrlt to release an open source version of his miner. I read that he spent only a few hours working on it so the Litecoin community should be able to buy it from him. I'm willing to donate 10 BTC towards this goal.

True but the probability of GPU reaching L1 cache parity is much higher in the short term.  I would expect it within 1 generation (8000 series) but if not there it will certainly be there in the next-next generation.

So realistically you are talking about a 2-3 window before GPU have cache parity with CPU.  Using an algorithm which relies on that inequality is "futile" over even the short term.

Honestly I don't see the value in trying to limit hardware.  At this point GPU mining (which we don't even know exists) is still more valuable on Bitcoin.  So if someone was convinced Litecoin will take over the world it would still be cheaper to mine BTC and use that to buy LTC.  If miner i just interested in fiat profits well all that matters is which coin generates higher return on a given piece of hardware (or even more abstract a given amount of capital).

One thing (somewhat theoretical) I would throw out there is that as GPUs become more "CPU like" they will devote the necessary resources (transistors and chip yield) to increased L1 cache.  GPU long since outstripped the growth in pixel counts so they devoted more resources to improved image quality at a fixed number of pixels and/or polygons.  The GPU resources are growing faster than developers ability to use them as devising more complex and realistic "effects" requires more human capital than simply doubling the polygon count or going from a 800x600 pixel count to 1920x1200 pixel count.  So it will be increases in GPGPU workload which increasingly drives development of future GPUs.   

GPU traditionally had very little local cache because there is no need when performing traditional graphics work.  That dynamic likely won't hold true in the future.  NVidia Tesla cards for example can be configured to double the amount of L1 cache because it is so useful in boosting performance of some GPGPU functionality.   Larger L1 caches will eventually trickle down into consumer grade products to.

No coin today is "anti-GPU" it is they can be described as "large L1 cache dependent".   Even if GPU mining is impossible w/ todays hardware the desire for GPGPU performance will drive higher cache in the SP for future GPU and eventually they will be able to perform with no limitation.

One "hard" alternative is to make the lookup tables so large they can only fit in main memory (say a 3.2GB lookup table).   That obviously makes the code less functional on those with limited system resources but given CPU access to memory is always lower latency that GPUs it becomes hard to defeat.  Eventually GPUs shared memory will be 4GB, 8GB, 16GB etc so possibly some algorithm which adjusts size of lookup table based on Moore's law might be needed (i.e. uses a 3.2GB lookup table at current block but that increases by 7% every 40,000 blocks as part of the protocol, maybe on a multiple of difficulty like every 8th difficulty adjustment is also a memory adjustment).

Well, my theorethical researches give some unswers to Problematic.
Is Gpu-miner possible - YES, depends on implementation it can be made somehow better as CPU miner.
The performance of GPU miner is caped by Memory bandwith (you can't store all the data in Local/Shared memory of Device and have to use global Memory.
Global memory has havy latencies to access but managing an implementation where you will "hide" latencies by calculating in this time can work. You'll  still have cap in bandwidth ... the Fastest Bandwidth we have on common GPUs (as far as i know reading http://www.geforce.com/Hardware/GPUs/geforce-gtx-590/specifications used Nvidia GPU cause they have better bandwidth as AMD) is 327.7 GB/s. Sure it's best possible performance for just sequent read/write it's impossible to reach this in Scrypt calculation on GPU but we can calculate a Cap. One hash needs 128k writes and 128k reads to and from Global device memory. this means we can't calculate more hashes as

327.7 * 10^9 / 2 / 128 * 10^3 = 1.28 * 10^6 hashes.

this means the cap of performance is 1.28 MH/s.

The real implementation would be worser by factor 2 or 3 ...

Is this a problem ... well could be, but i don't think so.

to have a fair comparison:

it's measured at my btc-mining-rigs, the point is, that i only count the extra-cpu-watt of the rigs, because they are mining btc and a cpu-coin is mined extra, when there is one, when there is no coin to mine i save the watt

core i3 / 2.4 ghz / 3 threads / ~  8 w only for this / 10 kh/s =>1.25 kh/w
CPU / GPU // CPU is 1.157 more efficient

core i3 / 3.1 ghz / 3 threads / ~ 15 w only for this / 12.5 kh/s =>0.83 kh/w
CPU / GPU // CPU is 0.768 less efficient

core i7 / 3.6 ghz / 7 threads / ~ 46 w only for this / 32 kh/s =>0.695 kh/w
CPU / GPU // CPU is 0.644 less efficient

for me i can't see the 5- or 6-higher-efficiency-factor of the gpu...

Right now salsa20/8 is used as a core part of of scrypt (8 rounds for the inner loop). Replacing it with something like salsa20/2 (just two rounds in the inner loop) would significantly improve performance on CPU, because 4x less calculations would be involved. And the memory access pattern would remain the same, resulting in almost no improvement for the miners which depend on memory performance (GPU miners and also to some extent Cell/BE miner). So what's the problem? The variants of salsa20 with lower number of rounds are supposedly significantly less secure, at least in some cases:
http://fse2008.epfl.ch/docs/papers/day_3_sess_3/29_Lausanne_FSE08_camera_ready.pdf
http://www.ecrypt.eu.org/stream/papersdir/2007/010.pdf

But I don't know how exactly this all applies to scrypt, because cryptography is definitely not my forte. That's why I think that bringing up the issue to the scrypt author can make some sense. That is after we get a better idea of realistic GPU performance.

This is all nice. But can we be sure that these convoluted hash calculations can't be algorithmically optimized and reduced to something that can run orders of magnitude faster?

1)
If I understand the rumors correctly, a single high-end GPU would be about 25x faster than a single CPU core, as opposed to 5x faster that was initially predicted by ArtForz? Still a lot less than the 400x speedup of bitcoin with 5870 GPU vs single CPU core?

2)
I suppose that increasing the memory size parameter of scrypt to a very large amount (megabytes...) which doesn't fit in the cache would mean that it'd be infeasible to do hash attempts in parallel with a GPU (and maybe even with several CPU cores), but it also most likely means that people couldn't use their computer to do other stuff while mining litecoins due to system responsiveness issues. Therefore it's possible that the current scrypt parameters as chosen by ArtForz and Lolcust are the best, espeically if bitcoin GPU mining remains more profitable than litecoin GPU mining.


3)
Switching to another hashing algorithm in this case is relatively simple, just need a protocol change that says that starting from block #x in the future the PoW will be checked according to the new hashing algorithm. By contrast, if it was the case that there's full pre-image attack on scrypt (which ain't gonna happen while there's no pre-image attack on sha256) then there would also be a need to add a new data field that contains the new hash to all the old blocks in the chain, otherwise an attacker could use the pre-image attack replace an old block with his own malicious block (see https://bitcointalksearch.org/topic/m.1585).
There would be no "downtime", you can let the miners vote (similarly to bitcoin p2sh vote, see https://github.com/bitcoin/bitcoin/pull/804) and see if they agreed to the switch before block #x is reached, and if there's no majority then the minority should withdraw their support before block #x so that this proposal would be cancelled in a smooth way. From the point of view of the fork being beneficial as a rehearsal to a similar bitcoin fork that could be useful in the future, I think that if the litecoin p2pool has relatively high computing power then it'd be interesting.

Don't give up of Litecoin!!
Everybody wants to see for sure that GPU-mining for Litecoins is a reality and efficient...

There are easier methods to protect a coin in the early stages than saddling it with a dual block structure long after it is no longer needed. 

Viper's solution is not without merit. It would make it harder to 51% a coin in the earpy stages because you'd need both a bitcoin farm and a botnet.

LOLZ.  Are you that dense.

I just used 1 + 1 = 2x as an example.  The split doesn't matter and obviously each block would have indepedent difficulty.

Let me make it simple.

THE ENTIRE LITECOIN NETWORK GENERATES X USD PER UNIT OF TIME.

X buys so much computee things (bleep, bleep boop boop -> hashs come out).   

Difficulty is a manifestation of X.  If X rises so will difficulty.  If X falls so will difficulty.  There may be fluctuations but equilibrium will be reached between difficulty and price.

Thus the COMBINED difficulty will always be a reflection on X.  Changing the number and types of blocks won't change anything.

Combined difficulty will always be a reflection on X.  Thus the cost to build enough hashing power will be a reflection on difficulty which is a reflection on X.

Only way the network gets stronger is if price goes up.  Period.  Moore's law doesn't help (it also helps attackers).  New tech breakthroughs (like GPU mining at higher efficiency) doesn't help because attacker can use it too.   Lower energy costs globally (say cold fusion) doesn't help because ... yup it helps attacker too.

The only thing that makes the network stronger is the revenue paid to miners in the form of fees/subsidies.  Since miners costs are in fiat what ultimately matters is the amount of fiat generated per day.

Fail again.  

The network won't be twice as strong.  It will have half the hashing power in CPU and half in GPU.  The cost to attacker hasn't risen.

Buying X CPU.
vs
Buying Y GPU.
vs
Buying 1/2 X CPU AND 1/2Y GPU.

The strength of the network is split between both components.   At any given economic value the network will reach equilibirum between price and difficulty. By having different block types the combined difficulty for both blocks (2 blocks total) will be no higher than 2x a single block now.

Lots of extra code for no benefit.  It will not be any harder for an attacker to get 2, 6, 20, 100,000 blocks ahead of the honest chain using 2 types of blocks or 50.

TL/DR:
You:  If difficulty doubles then the network is stronger.  See you proved my point.
Me:
You:  See 1 + 1 is obviously harder than 2.
Me:

Nothing.  There is no proof this magical miner exists.  Changing hashing algorithm is a massive change and certainly non-trivial.  If/when independently the efficiency of GPU mining is verified the solution will depend on how high that efficiency is AND how various methods degrade that.

Doing something based on no proof is exactly what you want to happen.


If you would like to continue trolling my simple idea that coblee could choose to run with or not, fine but please stick to the OP and be planning what should be done for the benefit of LTC... is this not a more productive plan?  Maybe you suggest an idea he/LTC community could consider doing?
[/quote]

You misunderstand 51% attack (like many other things).  With 51% (technically 50% + 1 hash per second) you will eventually have the longest chain., that is a mathematical certainty. 

Instead of attacker buying x CPUs or y GPUs he will now simply buy 1/2x CPUs and 1/2y GPUs.

easy.. the same rig on bitcoin would make $5.17 daily, whereas on litecoin it would make $6.11 daily. This is according to allchains.info.