Flip Tulipcoin, I understand exactly what you're suggesting. Thus, here's a much more specific question: how would you combat the potential for a sybil attack, without the assumption that every client must be connected to the network at all times?
How close a sibling are we talking about? Would a sibling attacker have, say, private keys known only to it's sibling? I don't mean to be circular, but how a node's "identity" is defined would be some persistent property of the node when disconnected from the network and verifiable by other nodes during the time the first node is connected. Other nodes must a recollection of the identity, such as a public key, to validate a signature exchange. Consensus of all participants validating each other on an ongoing basis with changing keys would probably be a part of it, as it would make flooding the network with confederates who would validate an attacker ineffective.
Handling failure of consensus is an implementation issue I would have to break down to use cases. If there's an overarching simple answer, I'm not seeing it.
The property of identity itself need only persist between connections, not forever. Although I dislike the SecureID system for various reasons, their implementation of object authentication requires that an object's identity be "freshened" by occasional connection to the network, it is not a static property. Now if only their token database wasn't centralized maybe they wouldn't have gotten hacked so easily this past year.
So instead of a proof of work it is proof of identity ... in an anonymous network. Which is easier to implement millions of fake identities or millions of megahashes? The network would require consensus (as in 100% agreement) or majority (51%)? Consensus in a distributed network where anyone can join? LOLZ. How would you deal w/ entities who made identities simply to break consensus (voting "false" on every transaction). On the other hand 51% bad identities (even if all from a single entity) would control the network.
Handling failure of consensus is an implementation issue I would have to break down to use cases. If there's an overarching simple answer, I'm not seeing it.
Calling that a copout is the understatement of the year. I thought it would be trivial.
So in summary:
"Bitcoin is wasteful, and here are much better ways to do it. I haven't got the implementation down because there is no simple answer but Bitcoin is wasteful because there are much better ways to do it."