Quote from: casascius on April 14, 2013, 07:20:47 PM

1. Add a new requirement to the Litecoin chain such that a valid Litecoin block must contain either a record of the most recent Bitcoin block header hash, or a repeat of the hash found in the prior Litecoin block (with a limit of repetitions). Litecoin blocks that contain outdated Bitcoin intelligence should be disfavored by nodes capable of detecting that. Further impose the requirement that Bitcoin block headers must be represented contiguously in the Litecoin chain - Bitcoin blocks cannot be skipped (which shouldn't be a problem, when Litecoin blocks happen 4x as often as Bitcoin)
2. In the event there is an active Bitcoin block chain fork, the requirement is loosened such that the Bitcoin block header hash requirement can be satisfied by any leg of the chain, not just the one Bitcoin considers valid.
3. Add a feature to Litecoin clients that allow Litecoin users to decide to prefer or not-prefer branches of a Bitcoin fork while one is in progress. The default for this should always favor the Bitcoin leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitcoin block chain. The user/miner/pool-op should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing Bitcoin blocks.

This general idea of yours for sync'ing the Bitcoin block header hashes into the Litecoin blocks is an interesting suggestion.

I failed to understand why would we need "a repeat of the hash", according to your suggestion isn't it true that the next Litecoin L_0 block will either include the next-needed Bitcoin block B_0 hash or the last Litecoin block L_1 hash, so after L_0 was generated, the following Litecoin block should include either the header hash of L_0 or the next-needed Bitcoin block, so there are no repetitions? Actually, wouldn't it be better to require that the next Litecoin block must always include the header hash of the previous Litecoin block, and optionally also to include the next-needed Bitcoin block header hash?

What you said about "any leg of the chain" is a bit unclear, nodes aren't required to keep competing legs (a.k.a. branches). I think that what you meant is that if the node sees that its preferred Bitcoin branch disagrees with the branch continuation of Bitcoin hashes inside the Litecoin blocks, then it should still accept these Litecoin blocks, as long as that different Bitcoin branch is valid (even though it isn't the longest Bitcoin branch according to what the node gathered while listening on the Bitcoin network) ?

About allowing users to decide to prefer or not-prefer branches, I've written before in another context that I think that it's a terrible idea:

Quote

It sounds risky to allow each user to manually select which branch to use, instead of automatic rules that all nodes follow. If enough clueless users make a mistake, then the blockchain forks and the situation might escalate, because people in different forks begin to have financial interest to stay in their fork?