Topic: LIP0001: At blockreward halving scrypt memory parameters will double (Read 2141 times)

That's correct, originally it was intended to be CPU minable and now it's GPU minable, and the ability to mine on GPUs and only GPUs is one of the major selling points for it right now.  This will help maintain GPU minability.

The problem is getting the user base to adopt this...  BIPs are notoriously difficult to implement.  Since this change will not occur until about another couple years though, all coblee really needs to do is simply add this to the blockchain parameters in the program and get users to download the new version.  The miners will also have to be updated, but that should be trivial.

Probably someone will need to do a testnet version as well that rapidly changes r values, so that we can ensure the pliability of r and test GPU mining with various r values.  But these are all really minor changes.  Coblee hasn't said anything about this one way or the other, maybe because he's too busy with other things.

I really think now's the time to future-proof the chain, though.

Whether or not the chain is ASIC minable or not remains to be seen, too.  We know that a scrypt core only requires about 20,000 circuits (not much different than a SHA256 core).  The clock rate of this core should be about 0.7x the memory.  If an ASIC is only operating at 200-300 MHz, it shouldn't be hard to slap on some DDR3 memory clocked at ~800MHz and get vastly higher power efficiency than a GPU.  The major difference will be that it will not be 100x faster than a GPU, and will probably only mine slightly faster than a GPU.  The power consumption of this ASIC would probably be about 25-35W versus 200W for a GPU.  That means you're looking at less than an order of magnitude enhancement in efficiency moving to ASICs, which should offput their widespread adoption for some time.

The easiest way to make a chain non-ASIC minable is to make the circuits insanely large and force them to utilize all the onboard components of the AMD GPUs.  It will need to be architecture specific to ensure that the entirety of the GPU is being used, and there will need to be extensive testing to ensure that it does not have vulnerabilities in circuit simplification.  The construction of such an algorithm will be a complicated matter.

Edit: I neglected to remember that SHA256 is included in the implementation used in Litecoin, so then I think ~45,000 circuits would be require for a whole core on the ASIC.

This seems like a good idea in the spirit of making litecoins harder to mine with specialized hardware, which was the reason they went with Scrypt in the first place no?

Well, with the development of parallella I think we should look at the lightcoin protocol again more closely.


In 2013 we will see LTC miners in the form of parallella computers able to mine at a much better per watt rate (maybe 50-100% greater efficiency) as compared to GPUs, since the current protocol only requires 128kb of memory per thread.  Of course, if these cost $100 each they will be competitive in no way, but once scaled up to the 2014 model they should be (the 2014 chip would do by my estimations, comparing them directly to AMD SPs, 350 kh/s with 30-40w).

The easy way to circumvent this is to simply increase the amount of memory required by each litecoin hashing thread.  Increasing the memory incrementally like this will also make it a nightmare for ASIC manufacturing, since it will HAVE to depend on slow RAM rather than on-chip memory.

BFL premines all remaining BTC prior to shipping their ASICS, they laugh and us holding ltc laugh as well.

Coming soon, Pirate Banks and Savings Trust for Litecoin !!!

...nobody for or against?  I personally see a ton of people moving to LTC after the release of ASIC mining for BTC, and I think the chain should be fortified against ASIC release in the long run.

Personally, I also think we should multiply by 4 or 5 instead of 2, as LTC is scheduled to halve block reward in four years, during which we can expect RAM capacity of video cards to more than quadruple.

LIP0001 (Litecoin Improvement Protocol): At blockreward halving scrypt memory parameters will double

http://www.tarsnap.com/scrypt/scrypt.pdf

Short version: scrypt hash memory requirement = O(log2(N) * p * r * 128)

Holding N (=1024) and p (=1) constant,
scrypt hash memory requirement = O(r)

So, if the parameter r doubles, the memory requirement should also double.  Therefore, with LIP0001, at blockreward halving r = 2 * r and the memory requirement is doubled.

The main purpose of using scrypt in litecoin was to prevent initially GPUs from mining the chain and now it is well held to prevent ASICs from mining the chain.  By increasing memory requirements at every blockreward halving it should maintain memory hardness and ASIC resistance.

See also:
https://github.com/litecoin-project/litecoin/wiki/Scrypt-proof-of-work
https://bitcointalksearch.org/topic/looking-for-an-fpga-with-cache-for-btc-and-litecoin-mining-any-ideas-98535
https://bitcointalksearch.org/topic/tenebrix-scaling-questions-45849
https://bitcointalksearch.org/topic/thread-about-gpu-mining-and-litecoin-64239

Edit: N should be the parameter changed, fixed.
Edit 2: No, it looks like r is okay.  I'd like some input from others on this proposition, though.  Bubble boy claims: "log2(N)*p*r*128", so r should be okay.