Issue Description

In most cases, the ledger entry ID of an object in the ledger can be (re-)derived from the protocol & the fields of the object as stored. There are some exceptions to this rule, which means that an object is not self-contained and you need additional context or information to calculate the ID for that ledger entry.

This is not ideal; when traversing ledger data it would be nice to be able to tell right away, for example, "whose signer list is this?" without needing to iterate through all the accounts and figure that out. In some cases the additional information you need is the sequence number of a transaction, which would require you to trace back through enough transaction history to find the transaction if you just started with the object as stored.

Missing fields

The exceptions I've found are:

• Escrow and PayChannel objects don't have the Sequence of the transaction that created them.

  • Solution: add a Sequence field (sfSequence, probably) to new PayChannel and Escrow objects.

• SignerList objects don't have the AccountID of their owner

  • Solution: add an Owner field (sfOwner, probably) to new SignerList objects.

Note: These changes affect transaction processing so they must be on an amendment.

Now, this is not super important, and arguably it adds "bloat" to the ledger since the ledger itself is able to carry on just fine without these fields being stored. But it would improve the ability to navigate around, process, and verify the integrity of the ledger. It would also be kind of nice for consistency.