This is a scheme to limit the opportunity for fraud and increase peace of mind between honest node operators. Suppose that a large value packet comes across the link from node A to node B. The code at node B should nominally forward that packet on to node C but that puts operator B at risk of being obligated to pay C yet unable to collect from A if A denies having sent the packet.

We propose a protocol where a node occasionally sends a signed packet including the accumulator reading. The non repudiation nature of digital signatures provides some recourse to third parties. In the above example A may choose to assure B by sending such a signed packet immediately upon a large change in the accumulator such as when large value packets are sent.

This overcomes one of the ways that DSR can break down under large transfers. There remains the problem of an operator taking the money and disappearing.

There are small technical problems with synchronization. If the signed packet includes the transmission and reception packet counts then the balances should be precise. Alternatively one might settle for approximate checks. If balances are kept for each direction separately then the logic becomes simpler.

More Detailed Assurance

This is an incomplete idea. There may be nothing of value here.

If a node sometimes gets a signed packet with an amount that is less than he expects, the following protocol may help find the source of error between honest operators. Lost and duplicate packets are the likely source of discrepancies.

The either the sender or receiver of packets over an interface computes a hash of a summary for each packet. This summary includes the interface packet serial number, money field and packet error control value (checksum). The summary need not otherwise cover the payload. The exclusive-or of these hashes is included in the signed balance report. The commutative and associative xor is used since packet error control or other interface quirks may permute the order that the packets are seen.

Just now it is not clear to me what clues this scheme provides over the signed balance report. They can both be used to convince the sender that there is a bug in his code. A third party can now decide which node has a bug in its code if either side has kept the packet summaries.