[jonreem]

Settle positions between two mutually non cooperating parties. Your github solution doesn't consider that many non cooperating parties may want to do conflicting things on chain and you need a trustless way to resolve those conflicts. First writer wins to a centralized database at github is not an acceptable settlement method for billion dollar transactions.

EDIT: A blockchain is not just about keeping a history, it's also about maintaining liveness of the chain and preventing censorship even when many non cooperating parties are involved with conflicting incentives.

[endisneigh]

you don't need a trustless way - the two mutually non cooperating parties could fork the repo, reconcile separately using traditional git tools and then have the new commit(s), representing the conflict, merged into the main branch.

this is literally already what happens with software development now.

[bob1029]

This is how I view the handling of the "well what about complex transactions..." game. You can create a totally separate branch to process that complex beast and then attempt to merge it back into the main. If there is a merge conflict (someone debited/credited the account line between branch & merge operation), the transaction would be aborted. Rebasing of transactions on top of the main branch would be possible and the semantics of this even make sense for real world use cases - "We attempted to reconcile your transaction into the main flow, but there was a change in the circumstances of the various basis accounts. Can you rebase your transactions on these circumstances and resubmit?" As part of that rebase operation, you would re-run your biz constraints on the complex transaction and then resubmit if you could still satisfy them all.

Depending on how you use and understand git for software, it is either a hauntingly-similar facsimile of any arbitrary blockchain tech today, or a completely alien technology with no practical relationship to blockchain whatsoever.

There also seems to be some notion that the time domain must flow in a continuous way. The time domain in git is discrete, but this does not violate any of the semantics. Just hypothetical processes around them.

[jonreem]

these are transactions with extremely high value and often extremely urgent and not possible to merge together - e.g. the both liquidate the same unhealthy loan position (could be worth ~$10m+)

the whole point is it's not remotely easy to just "reconcile separately" when you have two mutually exclusive financial operations - these are not code changes made by mutually cooperating developers happy to change their code to resolve merge conflicts, they are actively fighting against each other

edit: this also point out how having a centralized entity decide the ordering of transactions is a horrible idea - sequencing is worth enormous amounts of money and you could not be trusted to resolve transactions in a way that is sometimes against your interests but in the interest of other participants in the network

[endisneigh]

you might have to elaborate because I don't understand. all transactions between N-entities are inherently mutually cooperating.

how would a transaction between members be "fighting against each other?"

[jonreem]

outside of trivial transfer transactions there are much more complicated things you can do with smart contracts such as decentralized lending and decentralized exchange of assets

these are more like arbitrary atomic changes to on chain state that can affect many wallets and different contracts (and depend on the existing state) rather than just a transfer from my wallet to another address, which can be reordered freely

see protocols such as uniswap, compound, aave, synthetix, sushiswap, liquity, etc.

[ryan93]

It’s impossible to edit a Bitcoin transaction retroactively without spending obscene sums to get 50+% hash rate