This is all in theory. Is there are coin that successfully pulled this off?
You can adjust every parameter you want, it's just about if community accepts it (eg. downloads the new client).
Topic: Changing a coin's proof of work? (Read 710 times)
This is all in theory. Is there are coin that successfully pulled this off?
You can adjust every parameter you want, it's just about if community accepts it (eg. downloads the new client).
don't go messing with the time warp rabbit trick silly rabbit you could warp the blockchain !? 
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
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?
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
trivial case is to add something like
if (block.nheight < switchoverheight) {
block.checkblockOld(hash);
} else {
block.checkblockNew(hash);
}
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
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.
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.
Whatever happened to Zenithcoin?
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.
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.
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.
Has anyone does this yet?
Change a coin's proof of work after millions of coins have been mined?
Change a coin's proof of work after millions of coins have been mined?
Jump to: