List of legacy exceptions to protocol rules

[mDuo13]

As the XRPL has evolved, there are plenty of things left over from previous versions of the protocol which can't be created today, such as validated historical transactions that are invalid under modern rules or account settings that can't be set today. It would be handy to have a page that collects these with notes for people processing whole ledgers or historical transaction data.

Related: #1670

Some examples:

• Prior to mid-2014, transaction memos could contain a lot of weird stuff. They were eventually limited as a result of https://github.com/XRPLF/rippled/commit/a5297d13c4f6a2ffb643e697d9ff1fcda385b932 and https://github.com/XRPLF/rippled/commit/e3a7aa0033849150cdc397680921959c2c986381 . These changes weren't on an amendment or a timed switch, so they just happened when validators upgraded to a new software version In a few rare cases, modern rippled can't even deserialize these transactions to JSON without modification. (Example transaction: https://livenet.xrpl.org/transactions/E64A81D9FDE13F2FE28A98F337809D894E3279C75ED8E784114C650A04DFC65C/raw )
• Mainnet's "Recent" LedgerHashes entry has a FirstLedgerSequence field with the value 2. This field is not used and is not created on new ledgers.
• The maximum transfer fee used to be the maximum value of a UInt32, before it was dropped to a maximum of 100%. But accounts that set their TransferRate higher than the new limit before it was in place are grandfathered in, and their transfer fees are still processed at the recorded value. (Prior to the introduction of freeze functionality, setting a transfer rate to the maximum was a hack that was used a couple times when an issuer wanted to implement a de-facto global freeze.)
• Two early SetFee pseudo-transactions had identical transaction hashes. Later on, the LedgerSequence field was added to SetFee pseudo-transactions to make them unique, so the first two are the only instances of different transactions (same data, different ledgers) having the same hash.
• Early on it was possible for an account to make trust lines to itself. This was then disallowed, and much later there was an amendment to remove the two existing instances on Mainnet.

There are quite a few other cases not noted here as well.

[intelliot]

On other blockchains, making previously-valid transactions invalid is a soft fork, so such changes do not need an amendment or timed switch. Restricting what memos can contain - tightening the rules - is a good example of a soft fork. On the other hand, loosening the rules would be a hard fork, of course. We are potentially a bit over-cautious in putting all protocol changes on amendments since technically, soft forks don't need to be coordinated in lock-step as old servers will not consider blocks following the new rules to be invalid.