Changing the hashing algorithm

ghostlander

I have been wondering what effect on the block chain the algo change would make?

Is it just the mining that would be affected or would it also affect what is held in the block chain? Would there need to be any specific Code to deal with blocks before a cut off point and blocks after.

This may seem like a silly question to those in the know but if this is the case would every client of the block Chain would need this workaround?

Blocks will be mined with one code before the switch and other code after. It also applies to block verification. A hash is a hash no matter what produces it as long as it’s a valid one. There is nearly a zero chance of two blocks to have the same hash even if they’re produced using the same hashing algorithm.

A switch is a hard fork and every client needs to be updated in advance preferably. The mining transition is more complicated.

kris_davison

So would it still be possible to verify every block if downloading a client for the first time?
Is there just

if(block < firstChangedBlock)
{ use old algo }
else
{ use new algo }

Or something similar inside the code?

Would it be possible to regenerate all the old blocks using the new algo so that we don’t need the switch over. Although that’s like rewriting history?

ghostlander

So would it still be possible to verify every block if downloading a client for the first time?
Is there just

if(block < firstChangedBlock)
{ use old algo }
else
{ use new algo }

Or something similar inside the code?

Something like that. I’m not sure if it’s better to switch on block number rather than date/time (time stamp).

Would it be possible to regenerate all the old blocks using the new algo so that we don’t need the switch over. Although that’s like rewriting history?

Absolutely no.

This may be completely daft but would a random dynamic switched algorithm be possible? I mean like something like 6 possible algorithms and the algorithm in use could be determined by an evaluation of the hash from the last block or sequence of blocks.

Put extremely simply using 2 algos

if(last block hash = odd number)
{ use algo1 }
else
{ use algo2 }

Sorry if that is the most stupid suggestion yet :-[

I’d like to see the asic that could handle that lol

ghostlander

This may be completely daft but would a random dynamic switched algorithm be possible? I mean like something like 6 possible algorithms and the algorithm in use could be determined by an evaluation of the hash from the last block or sequence of blocks.

Put extremely simply using 2 algos

if(last block hash = odd number)
{ use algo1 }
else
{ use algo2 }

Sorry if that is the most stupid suggestion yet :-[

I’d like to see the asic that could handle that lol

In contrary to a common belief, Quark with their X6 and Darkcoin with their X11 aren’t ASIC resistant. Although they use a number of hash functions, all of them require very little memory and can be implemented in ASIC hardware easily. If these coins rise to at least 100M USD market capitalisation, you see ASIC announcements coming.

This is the core of Scrypt:

void scrypt_1024_1_1_256_sp(const char *input, char *output, char *scratchpad)
{
	uint8_t B[128];
	uint32_t X[32];
	uint32_t *V;
	uint32_t i, j, k;

	V = (uint32_t *)(((uintptr_t)(scratchpad) + 63) & ~ (uintptr_t)(63));
	
	PBKDF2_SHA256((const uint8_t *)input, 80, (const uint8_t *)input, 80, 1, B, 128);

	for (k = 0; k < 32; k++)
		X[k] = le32dec(&B[4 * k]);

	for (i = 0; i < 1024; i++) {
		memcpy(&V[i * 32], X, 128);
		xor_salsa8(&X[0], &X[16]);
		xor_salsa8(&X[16], &X[0]);
	}
	for (i = 0; i < 1024; i++) {
		j = 32 * (X[16] & 1023);
		for (k = 0; k < 32; k++)
			X[k] ^= V[j + k];
		xor_salsa8(&X[0], &X[16]);
		xor_salsa8(&X[16], &X[0]);
	}

	for (k = 0; k < 32; k++)
		le32enc(&B[4 * k], X[k]);

	PBKDF2_SHA256((const uint8_t *)input, 80, B, 128, 1, (uint8_t *)output, 32);
}

PBKDF2_SHA256 is PBKDF2-HMAC-SHA-256 actually. It takes a 80-byte input and produces an output hash of length desired. It doesn’t use much memory, something like a few hundred bytes. You can replace HMAC-SHA-256 with any hash function or even a dozen chosen pseudo-randomly or even chained together and it won’t be a problem for the ASIC designers anyway. Those mixing cycles with xor_salsa8() are the real complication. We need to replace Salsa with ChaCha or something else and probably focus on 64-bit code rather than current 32-bit one. It may increase performance of x86 CPUs which are all 64-bit and reduce performance of popular GPUs which operate with 32-bit ALUs mostly, but any future ASICs will also be affected.

voingiappone

We need to replace Salsa with ChaCha or something else and probably focus on 64-bit code rather than current 32-bit one. It may increase performance of x86 CPUs which are all 64-bit and reduce performance of popular GPUs which operate with 32-bit ALUs mostly, but any future ASICs will also be affected.

I back this up. It would make all the GPUs a little slower (for everybody) and give a small advantage to the cpu mining. This is (IMHO) a win-win situation: all the GPU miners will still fight on the same ground (same ratio with just different numbers) and meanwhile you can still mine even if all you have is a bunch of CPUs. I believe that this “setup not needed” factor is really important for spreading the coin to the non geeks. If that’s also a consequence of keeping ASICs away… from my point of view it’s a no brainer.

wrapper

Can we just go back to basics,

the change should be simple, it should prevent mining with current Litecoin Scrypt ASICs.

In order to thwart current ASICs, requires a change of hashing Algorythm.

The Sha256 hashing chip is the speedy part of the Litecoin ASIC It combines with additional memory and programming to make it able to process the Scrypt.

I think Ghostlanders idea of changing to or adding anotheSHA version is the way forward. We could test that as well, until the Blake alternate is available.

The best option is to look for a Hashing Algorithm that already has “miner support” in cgminer etc. This will greatly simplify the process for miners and coders. We should not re create the wheel unless there is a good cause.

With cAlert and fair warning to pools it should inspire more confidence that we can make necessary updates and get them out smoothly…

A lot of other coins have upgraded via hard forks as well, so I don’t think it is becoming such a big issue.

lizhi

Keccak or SHA-3 cann’t Scrypt ASICs, Give up it.

X11 can suppert CPU only, GPU cann’t be supperted. Give up it.

Blake is better.

https://github.com/alphazero/Blake2b

Salsa20 is another better, eg Nfactor scrypt-chacha20/8(2*2^Nfactor, 1, 1)

https://github.com/dubek/salsa20-ruby

so we need to use two kinds of algorithms, yet ! ::)

ghostlander

X11 can suppert CPU only, GPU cann’t be supperted. Give up it.

sph-sgminer

This is a kind of axiom: if a GPU can do something, an ASIC can also do it. It’s a matter of time and money.

wrapper

I agree with Ghostlander, the new ASICs are basically mini computers.

The top coin will dominate each new ASIC release for a while, then semi programmable ASICs will evolve. It is also another way the coin network can resists centralisation of hashing power.

lizhi

So I’m still interested in PoS solutions. This is fundamentally resistant ASICs.

ghostlander

PoS will not be researched any further until the new hashing algorithm is ready. Cannot do all at once.

Anixosees

I was reading Charlie Lee’s post about why Litecoin would not be changing their algorithm to prevent ASIC mining. For LTC it makes sense not to change as the ASICs would most likely be strictly mining LTC and, in the end, they could help make their network stronger and push adoption.

One of the things he mentioned is that he thought it would be hard to, “convince everyone (pools, exchanges, miners, users, etc.) to adopt the alternate code”. Again I could see that being the case for their coin. Does anyone anticipate a problem getting the whole Feathercoin community to change to a new algorithm?

rdnkjdi

How serious are you guys about changing to another algo? I’m watching to see where GPU’s go - or if they go anywhere.

Pretty sure all other scrypts are going to have to change or die with the ASICs judging by BTC \ ASIC history …

MrWyrm

I was just about to reply to your post linking you to this thread haha. Welcome.

lizhi

PoS will not be researched any further until the new hashing algorithm is ready. Cannot do all at once.

I agree that we need to move forward step by step. We are doing some directional selection,Including tracking and investigation.

I gotta say,

Long time feather enthusiast, and feather forum lurker.

This idea is both refreshing and innovative, I am confident that the active members will deliver.

I think this will both set us apart from the Litecoin crowd, and give much credit to all the stability of the Feathercoin.

Keep up the good work guys.

6ySt1dsCWpfkcGHdeBaBnVTBgKWkQhzUnU

lizhi

What we decided to do?

wrapper

Now 0.8.6.1 is released we can start to get back to investigating an appropriate ASIC Hashing Algorithm response…

1. I am completely against PoS (Proof of Stake), that is a complete change in coin Philosophy.

2. CPU mining should be discouraged due to Botnet use.

3. Changing the scrypt element will be easily reprogrammed on future more flexible ASICs

so

4. Changing to SHA-3 or similar for a 18 month wait for ASICs

For: mining codeing is done, investigation implementation possible,

Against: being used before, so similar problem with future ASICs to now with Litecoin.

or BLAKE etc .will give about 9 months delay

For: Will use standard Bitcoin Hash algorythm so current ASIC will work with some modification.

Against: Same

5. Develop a custom solution, 2 months -

For: Safer, greater expertise gain,

Against: More work, more to go wrong.

At the current time the general opinion is that Litecoin will effectively “own” Scrypt ASICs, which will be great. It is the way the coin network is supposed to develop, by encouraging miners to invest in new hardware. That would mean Litecoin is a “known investment”, like a company being formed or an infrastructure being completed. The choice will then move which will be the next coin to be worth promoting?.

In addition, this is a fragile open source development environment, trying to encourage new developments and community. So it is not just about what we do, it is also how we do it.

I’ve left the Testnet up, as Hashing algorithm changes now becomes proposed for inclusion in the next Feathercoind and Feathercoin-Qt release.

Just thought I would post this. It’s an interesting watch.

https://www.youtube.com/watch?v=bi2thGzzNSs