Everlasting cryptographic receipts using sequencing commitment

[freshair18]

Kaspa's pruning means without external data full nodes cannot be used to prove a specific historical transaction was accepted to the DAG.

Instead an alternate paradigm needs to be adopted where users are responsible to create and store cryptographic receipts of transactions they potentially care about. If the need arises, these receipts could be verified by full nodes at any point in time.

Previously KIP6 was meant to allow the creation of light weight receipts (via a logarithmic shortcut), however the required changes were left out of the crescendo HF and will not be incorporated in the near future if at all.

KIP15 (already implemented) however does allow for similar functionality, which would be useful to support explicitly:
Say a user wishes to create a receipt for tx0, which was accepted at chain block B, and let C=Post_posterity(B) be the first pruning block at the future of B (which is stored to eternity). the fact that tx0 was accepted on B can be forever testified to by providing:
(a) all accepted transactions Merkle roots en route from B to C, i.e. the hashes needed to recreate the sequencing commitment of C from that of B.
(b) the Merkle witnness of tx0 in the sequencing commitment of B.
(c) tx0 data itself

Comparison with KIP6 cryptographic receipts

KIP6 was not only for transaction receipts per-se but also allowed for a more general primitive called proof of chain membership, which could have had other usages. In particular creating proofs of publication (for unaccepted transactions) as mentioned in KIP6 is not possible via the KIP15 sequencing commitment.

Size wise the logarithmic shortcut was very parsimonious, and KIP6 receipts were expected to be no larger than a few kilobytes in size. KIP15 receipts will not be competitive with that but the net result is still good due to the need to only store hashes and not headers:
If we assume a very conservative lower bound of the average DAG width being 2, there are 144000 chain blocks per pruning period, so the size of the receipts would be a maximum of
32bytes*144000=4.60800MB + miniscule terms regarding the tx data itself and the Merkle witness for its acceptance in the eventual block. In practice it will be significantly lower.

In the future it may be worthwhile to increase the frequency of "posterity blocks" to further decrease this size, as well as improve the wait time required to be able to create a receipt.

Previous Implementation
In implementing this feature, one may base their work or take inspiration from the now obsolete (partial) PR on KIP6:
#609

However the task at hand is much simpler, and much of the logic can and should be simplified substantially.