> Pepo said: How do I know that all your incoming HF payments did have enough balance to send them to you at the time? Sure, I will fetch their source chains (at that payment time) and verify it. But again, this becomes recursive...

Because of the combination of a few of Holochain's core features, none of this recursion is necessary.

1. Countersigning: Countersigning involves making a simultaneous atomic change across multiple user's source chains. In other words, unlike in blockchain where only the sender signs, you should implement a single change to multiple chains as a countersigned element which is only valid if it has all the required headers showing it has been signed to the chains of all participants.

2. Progressive Validation of Agent Chains: Whenever you publish something to the DHT, the neighbors near your address receive copies of your activity and add it to their representation of your chain structure. These neighbors are the ones who are watching to detect chain forks, rollbacks, or attempts to withhold parts of the chain, and who any of my actions which produce warrants would be reported to.

3. Warrants: Holochain validation is strictly limited to deterministic functions so that every node performing it will arrive at the same validation outcome, or be awaiting dependencies such that it hasn't found yet. So, when an agent commits and publishes data that fails validation, that agent can be warranted as corrupt or malicious. The signed action of the agent acts as the proof that any other agent can verify, and add this agent to their block-list of corrupted nodes.

So you don't need to recursively resolve anything because both the sender and receiver are warranted on bad transactions, because neither should have signed it as valid.

Example: If I create a Sybil account A, which I hack to ignore the validation rules and send 1 million credits that it did not have to Sybil account B, and then send from B to my account C that I'm going to spend them from with you. How are you protected?

When you start the transaction with me, you ask my neighbors about my chain state. If they don't show that I have been warranted, and they show the same top of chain that I am presenting to you, then you can proceed to the next steps of validating my chain for the 100HF you asked about.

But in the A --> B --> C scenario, I would already be warranted, so you wouldn't even need to start computing my balance. Let's look at how that happened.

If I try to publish any action to the DHT, it's header will reference my prior action, and all nodes who have to store or use that header will verify the existence of the previous entry. In other words, data is validated inductively and you cannot leave out previous data it relies on. You cannot have a chain which includes the 1 million credits so that you can spend them, but has withheld the transactions which would be warranted.

So when the transaction from A-->B is published, both A & B are warranted, then C will also be warranted for doing a transaction on top of B's invalid state which caused it to be warranted.

You don't need global ordering.

You don't need recursive checking.

Because both sender and receiver sign transactions, they are both warranted for cheating, which transitively warrants anyone else on top of that cheat.