If you aren't preserving the proof-of-work, then what are you preserving?
I was just saying that either we preserve conflicting blocks like this:
So, would there be an issue with having otherwise valid blocks referencing additional parents considered as a valid proof-of-work if one or more of their additional parents are invalid? I'd have to think through that...
Or we don't link them like this:
Thus, the thing that miners should do in this situation is, until they believe that they have enough orphans stored up, don't have them link with the other orphans. Make them all have completely different transactions. Then, when you're ready to take back the chain, merge them all in a single block.
But for the latter to be possible, miners would need to be able to keep unmerged blocks days/weeks behind in the chain.
Sorry, I'm still not understanding this. Even if I did, I fear that it'd make my head hurt...
I also just realized something. This chain-strengthening system is a little too powerful, and it took that example about "soft limits" for me to see it. Anything that can be "gracefully upgraded" today on Bitcoin by making the blockchain more restrictive in some way would be consumed by this, causing a chain fork. The people who upgrade would be fine, but the people who don't - miners and users alike - could be easily scammed because the upgraded chain is mergeable to them, but the reverse isn't true. They'll always have the longer chain.
That's true. But, is it really that big of a problem? Have such protocol restrictions been made so far?
I think I'd trade the benefit of not "fearing" a chain freeze over this restriction... That's actually the only >50% attack I think we should worry about, the for-profit double-spend isn't nearly as dangerous.
That's really the big philosophical question, isn't it? There's no right answer to it.
Thus, we're forced into the trust model. If we want the network to be upgradable, we'd have to allow certain people to hold a kill switch (it'd likely be something that several pre-defined trusted people would have to sign) that would revert the old clients back to the old rules for calculating total PoW. Luckily, when you really think about it, even if someone fires off this kill switch with malicious intent, they'd still require over 50% of the network's hashing power to cause any damage.
No, that sounds bad... even if it isn't dangerous, I don't think it would be received well.
I know, but I can't think of any other way to do it...
I don't think it is such of a drawback to have every "chain rules change" being a backward incompatible change (specially when you compare with the potential benefits of what's being discussed here). These changes would need to be scheduled months in advance, intensively communicated to the main pool operators, developers of p2p pools etc.
Would your opinion about this change if I were to tell you that
this very change that we're describing is, itself, one of those backwards compatible changes? It could be implemented in Bitcoin
today with just 50% miner support. Do we want to force such innovation to wait until the next backward incompatible change?
Such a thing will inevitably have to happen for the block size limit one day anyway. We should be prepared for more backward incompatible changes, if they are really needed.
Which is a blessing and a curse. On the plus side, Satoshi left us the perfect reason to go back and fix our mistakes. If PayToScriptHash ends up being something we regret, we can undo it then.
On the downside, we will wait as long as possible before we do such changes. You need to have a VERY, VERY good reason to do a backward incompatible change. The system in this very thread would not qualify if it required that. Also, did you know that Bitcoin calculates the next difficulty level incorrectly, and that it can be exploited to reduce the difficulty? Did you also know that it isn't scheduled to be fixed until we hit the block size limit? That's why I consider this to be a difficult issue.
We really only have two logical choices here:
1) We shelve this idea for at least 20 years so that Bitcoin can finish maturing.
2) We add a kill switch that allows the network the benefit of this additional protection, but without the downside of making everything a backwards incompatible change. If necessary, the kill switch itself could have a permanent kill switch that requires fewer people to activate.
