Changing a coin's proof of work?

[solracx]

Has anyone does this yet?

Change a coin's proof of work after millions of coins have been mined?

[1715612554]

1715612554

[1715612554]

1715612554

[1715612554]

1715612554

[mustyoshi]

It shouldn't be too hard, just in the implementation, create a consensus of when the fork occurs (block height wise) and the wallet software does so accordingly.

[meta.p02]

It is probably possible, like mustyoshi said.

However, if that is to be done the difficulty has to be taken into account, since different hashing algorithms have different speeds. Moving from, say, SHA-256 to Keccak, would entail a significant hashrate alteration (some searching around gives me 12.5 cycles/byte for Keccak and 14.3 cycles/byte for SHA-256, a difference of ~15%), resulting in probable difficulty plunges or spikes. A good difficulty adjustment algorithm would be able to handle this properly.

[sumantso]

Whatever happened to Zenithcoin?

[solracx]

It is probably possible, like mustyoshi said.

However, if that is to be done the difficulty has to be taken into account, since different hashing algorithms have different speeds. Moving from, say, SHA-256 to Keccak, would entail a significant hashrate alteration (some searching around gives me 12.5 cycles/byte for Keccak and 14.3 cycles/byte for SHA-256, a difference of ~15%), resulting in probable difficulty plunges or spikes. A good difficulty adjustment algorithm would be able to handle this properly.

If the re-target algorithm is fast enough, then this should not be too much of a problem.

I wonder what the effect will be for existing blocks that used the older proof of work.

[daggerismo]

Whatever happened to Zenithcoin?

potato

[meta.p02]

I wonder what the effect will be for existing blocks that used the older proof of work.

I think it won't have much effect.

The hash is of the program version, the hash of the previous block header, the hash of all the transactions in the block and a few other things. I don't see it referring directly to any of the previous blocks (only to the prevHash), so it should be fine.

^{Disclaimer: I am not an expert}

[minerapia]

I wonder what the effect will be for existing blocks that used the older proof of work.

I think it won't have much effect.

The hash is of the program version, the hash of the previous block header, the hash of all the transactions in the block and a few other things. I don't see it referring directly to any of the previous blocks (only to the prevHash), so it should be fine.

^{Disclaimer: I am not an expert}

you have to have backward compatibility for blockchain integrity checks but its not too hard to implement.
trivial case is to add something like
if (block.nheight < switchoverheight) {
  block.checkblockOld(hash);
} else {
  block.checkblockNew(hash);
}

[solracx]

I wonder what the effect will be for existing blocks that used the older proof of work.

I think it won't have much effect.

The hash is of the program version, the hash of the previous block header, the hash of all the transactions in the block and a few other things. I don't see it referring directly to any of the previous blocks (only to the prevHash), so it should be fine.

^{Disclaimer: I am not an expert}

you have to have backward compatibility for blockchain integrity checks but its not too hard to implement.
trivial case is to add something like
if (block.nheight < switchoverheight) {
  block.checkblockOld(hash);
} else {
  block.checkblockNew(hash);
}

This is all in theory.   Is there are coin that successfully pulled this off?

[ASICSRUS]

don't go messing with the time warp rabbit trick silly rabbit you could warp the blockchain !?  

[minerapia]

This is all in theory.   Is there are coin that successfully pulled this off?

Not that I know of, but its totally possible (and this comment is not just a theory).
You can adjust every parameter you want, it's just about if community accepts it (eg. downloads the new client).