Quote from: WilliamLie2 on June 11, 2014, 01:42:18 PM

Quote from: HunterMinerCrafter on June 11, 2014, 01:25:27 PM

I thought we covered this already...

Under this scenario you *could* just generate the map from the top block, but you are not *forced* to until the block you are working on becomes too old. Yes, your submitted work would include the hash of the block you think is top (as normal) as the previous block reference, you just wouldn't be forced to use this most recent block as map seed. As such, forced map resets would be 4 times less frequent. We could use any number for the allowed depth, really, and could even have this number adjust dynamically based on block rates, to keep map refresh frequency relatively consistent with network hash rate.

As I tried to explain you, no one cares about what you submitted if you didn't protect it by some proof-of-work. Therefore, it is unnecessary to complicate protocol by sending useless stuff (like previous block hash in your example).

Argh, you "got it" once already, I swear! Cheesy

It would be like writing the new transactions into the ledger, but not signing next to them - instead signing next to all the old transactions. When someone else came in later with some new transactions (also potentially "still unconfirmed") they would be signing next to your old transactions, giving them their confirmation.

Yes, transactions in these blocks still need to be treated as if they are actually still sitting, unconfirmed, in txpool but there is disincentive to ignore those transactions as the only way to do so is to ignore that block, and ignoring that block means you need to come up with two new blocks to overcome it with a longer chain.

EDIT: Also this doesn't require any extra data to be sent to the network. Previous block hash is already there and we would just steal 2 bits (for N=4 anyway) out of the nonce to store the depth of seed. Block size wouldn't increase at all.