[redbar0n]

> Klepmann is correct but practically you don't control external accounts thus cannot authoritatively determine if they either exist, have ceased to exit, or the contents of their ledgers.

True. But it doesn't actually matter.

> Thus, a large number of transactions will always have hanging references.

No, it doesn't need to be any dangling references. Because you model external accounts with an internal account (node) in your ledger.

[contingencies]

you model external accounts with an internal account (node) in your ledger.

... achieving what, exactly? How is the set of outbound transactions already stored associated with a given external destination not precisely the same information? This is needless data duplication, AKA database design no-no 101.

[redbar0n]

Achieving an internal record that balances out, and has no dangling references. Later inter-company audits can also verify that neither company has unilaterally corrupted their books. To be clear: I’m just talking about the standard accounting practise here (as normally done with tables/books), nothing fancy. Just applied to graphs, so the graph has no dangling references/edges.

[contingencies]

In the database world it is generally recognized that doing data duplication to 'flatten' a particular view is a special case of normalization (adapting data to a model) which is encouraged to be done dynamically (eg. as an SQL view) and not in stored data (as this would create redundant information, which negatively affects the database in terms of ongoing management, authority and clarity). Generating reports in whatever format users prefer is generally a very cheap and fast operation.

Also, duplicating the data does not make it more correct or more authoritative. Do not confuse presentation with data. A rose by any other name would smell as sweet.

Edit: I can't reply to your response so will reply here. I suggest reading some basic database design books. Good luck.

[redbar0n]

How does that relate to what I said?