...ok... so just tried to hash the entire .bitcoin/blocks on my node... that takes a long time lol. Something like: (following) might work better/ be more practical...

sha256(sha256( nonce + NormalValidBlockData + hash2(hash2(first n bytes of all previous blocks/blockhashes concatenated + nonce)) ))

where n is difficulty2...

come to think of it... there really is no need for difficulty2... difficulty1 (the normal difficulty) will have to come way down after the block interval goes way up due to 1) asic deprecation and 2) more complex hash function...

effectively putting the big hash in the inner loop of the little hash.

This would be very difficult to build an asic for... specialized hardware is fast ram. a commodity.

incentives to keep blockchain size down. way easier to verify than to hash... but it breaks node pruning.

Could be very simple to include the hash2(hash2()) value... just encode it in a transaction in the block. Nodes check to see if the transaction exists by calculating the hash per the reported nonce and looking at OP_RETURN or something... if not... the block is invalid.

...another idea to prevent an initial shock to the block creation time is to initialize n as a function of the regular difficulty such that n = 1 at the current difficulty (on flag day).

I'm pretty much there also. Block needs to be SHA2'd just like before... as well as "something else'd" to be valid. If we roll out SW and ideally LN strikes at the exact same time... the affect would be pretty effective. In my understanding-- there would still be the difficulty lag, which would be overcome with SW/LN ... no hardfork. What's not to like?

How about (just another fun log to throw on the fire... feel free to pick it apart... not too thoroughly though out...) miners need to hash THE ENTIRE BLOCKCHAIN + the new block?

....yeah... I don't think that works... For reasons others commented in the thread.

Keep working on it though-- the mutually assured destruction angle seems interesting. It may be possible to salvage the concept. I might even give it a few cycles.

Agreed-- I'm not suggesting developers lobby for the POW changes. Obviously, this has to be a grassroots economic stakeholder driven process. I proposed a few mechanisms whereby the POW is somewhat dynamic to avoid the normalization of HFs in the context of, perhaps unavoidable, hardware optimization. In a perfect world, we wouldn't even have the need for this dialogue today.

Though, today, it is becoming clear that high percentage miners can hold the network ransom and make all kinds of DOS threats, so I'm not sure exactly what constitutes an attack from your perspective.

Although I never really took the coin seriously due to their spammy and scammy sounding marketing, I think it's interesting how Myriad Coin attempts to introduce a plethora of POW algorithms... Something like this... an integrated feature whereby it is trivial for nodes to introduce new POWs, which all maintain their own difficulty is interesting in this context:

It appears to be the case that any one choice of POW will lead to eventual hardware specialization, and the way to fight this is to add hooks to make investment in any one hardware specialization scheme ineffective. Dynamic POW may achieve this.

I'm no expert on the hardware implementation of ASIC SHA, and have read earlier in this thread that simply switching to 3xSHA2 would be enough to break current hardware optimizations... what if the dynamic POW affected the depth of SHA required to find a hash?

To summarize, a few ways forward include:

1)  Nodes choose POW dynamically... some single algorithm... valid for some number of blocks... before switching to a different one. Nodes communicate, perhaps with POS backing... which POW they currently accept?

2)  Difficulty is assessed in both nonce as well as hash depth... though it would seem to me that it would be possible to develop specialized hardware which can perform sequential SHA calculations... (now that I think about it... why isn't this possible with current SHA2 chips?)

3)  We just do this a few times... pick some new hash function with a HF... re-decentralize mining-- until it becomes clear that in general, it is not profitable to develop specialized mining hardware... so maybe we have to do it less in the future. maybe eventually never.

Satoshi wasn't accounting for extrinsic economic motivations or shortcomings in miners' ability to assess what is in their own best interest.