Closed michielbdejong closed 6 years ago
also possibly need to include a hash, otherwise it gets confusing if a peer sends two different messages but with the same transactionId - which are you confirming then?
Maybe the initiator can send:
And confirmer responds with:
the ledger now uses senderId+msgId as its unique id.
Messages can and should be repeated indefinitely until both sides have seen some message from the other side which makes that ledger entry final (committed).
When comparing two ledger entries, you can't tell which one came first if the senderId doesn't match, but you at least have a full ordering of entries initiated by one users, and ones initiated by the other user.
that way, ledger integrity is not lost when messages are lost in transit. reject messages if the sequence number is not the next number expected.