Open mDuo13 opened 10 months ago
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.
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:
rippled
can't even deserialize these transactions to JSON without modification. (Example transaction: https://livenet.xrpl.org/transactions/E64A81D9FDE13F2FE28A98F337809D894E3279C75ED8E784114C650A04DFC65C/raw )FirstLedgerSequence
field with the value 2. This field is not used and is not created on new ledgers.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.)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.There are quite a few other cases not noted here as well.