Ittay Eyal and I just put together a writeup that we're informally calling Bitcoin-United for preserving the value of coins following a permanent fork:
Half of the core idea is to eliminate double-spends (where someone spends a UTXO on chain A and the same UTXO on chain B, at separate merchants) by placing transactions from A on chain B, and by taking the intersection of transactions on chain A and chain B when considering whether a payment has been received.
The other half of the core idea is to enable minting of new coins and collection of mining fees on both chains, while preserving the 21M maximum. This is achieved by creating a one-to-one correspondence between coins on one chain with coins on the other.
Given the level of the audience here, I'm keeping the description quite terse. Much more detail and discussion is at the link above, as well as the assumptions that need to hold for Bitcoin-United.
The high bit is that, with a few modest assumptions, it is possible to create a cohesive coin in the aftermath of a fork, even if the core devs are split, and even if one of the forks is (in the worst case) completely non-cooperative. Bitcoin-United is a trick to create a cohesive coin even when there is no consensus at the lowest level.
Bitcoin-United opens up a lot of new, mostly game-theoretic questions: what happens to native clients who prefer A or B? What will happen to the value of native-A or native-B coins? And so on.
We're actively working on these questions and more, but we wanted to share the Bitcoin-United idea, mainly to receive feedback, and partly to provide some hope about future consensus to the community. It turns out that it is possible to craft consensus at the network level even when there isn't one at the developer level.
Happy New Year, and may 2016 be united,
- egs & ittay