Bitcoin Forum
June 14, 2024, 09:44:12 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: LIP0001: At blockreward halving scrypt memory parameters will double  (Read 2124 times)
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
August 31, 2012, 02:11:36 PM
Last edit: August 31, 2012, 04:06:40 PM by tacotime
 #1

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

Quote
Theorem 2. The function SMixr(B, N) can be computed in 4Nr applications of the Salsa20/8 core using 1024Nr + O(r) bits of storage.

Users of scrypt can tune the parameters N, r, and p according to the amount
of memory and computing power available, the latency-bandwidth product of the
memory subsystem, and the amount of parallelism desired; at the current time,
taking r = 8 and p = 1 appears to yield good results, but as memory latency
and CPU parallelism increase it is likely that the optimum values for both r and
p will increase.
Note also that since the computations of SMix are independent, a
large value of p can be used to increase the computational cost of scrypt without
increasing the memory usage; so we can expect scrypt to remain useful even if the
growth rates of CPU power and memory capacity diverge.
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://bitcointalk.org/index.php?topic=98535.0
https://bitcointalk.org/index.php?topic=45849.0
https://bitcointalk.org/index.php?topic=64239.0

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.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
September 02, 2012, 06:51:58 PM
Last edit: October 27, 2012, 08:17:53 PM by tacotime
 #2

...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.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
mem
Hero Member
*****
Offline Offline

Activity: 644
Merit: 501


Herp Derp PTY LTD


View Profile
September 03, 2012, 06:58:03 AM
 #3

...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 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.

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 !!!

tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
October 27, 2012, 08:11:47 PM
 #4

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.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
sangaman
Sr. Member
****
Offline Offline

Activity: 342
Merit: 250



View Profile WWW
October 30, 2012, 04:26:38 PM
 #5

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?
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
October 30, 2012, 04:53:28 PM
Last edit: October 31, 2012, 10:10:43 PM by tacotime
 #6

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?

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.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!