so, that blockchain can fork; so now the question is, can it be merged again? I've long thought that PoW blockchains could become less wasteful by allowing the integration of multiple candidates for next block or blocks (and the corresponding transactions) back into the chain (not quite a chain any more), very much like merging multiple branches back into main
I wonder, is there any crypto coin based on git repos? say, you create a wallet by generating a GPG key, and adding a directory to the repo named after the GPG key id, containing a file named key, with the public key, and a file named balance, with zero. commit that, gpg-signed with that key, and you got a wallet. public repos can accept fast-forward pushes from anyone, to the main branch (if they feel like it), or to any other branches pushes are only accepted if they satisfy the rules that every commit is either a key-creation (as above), a balance transfer (that reduces the signer's balance, and adds the same amount to another wallet), or a merge commit that combines branches that meet these constraints, and add some tiny amount to their balance that reflects the complexity of the verification and consolidation such public repos AKA transaction processors merge branches to main, fetch from and push to others, trying to attract pushes to merge, and to merge and push to others
it probably can't be based on git proper, at least not with its current cryptographic hashes, but with a stronger hash function... we could call it hacking money ;-) now, besides the hash function, there are lots of tricky issues to address, from defining a compensation function for merging to be a decent economic incentive to figuring out how to recover from double spending when a merge/consolidation would bring make one's balance negative it makes me wonder if a single branch for all balances is really the best way to go. per-wallet linear branches, with 'send' commits and 'receive' merges (that list the send as the other parent, though only the amount is carried over) could make for smaller trees and histories. a simpler single-writer append-only log model, like twister's and ssb's, could work fine for this, but double-spending detection and recovery might be a challenge without attempts to form a global merged transaction history. more (or actual :-) research is needed