Consensus-enforced transaction replacement via sequence numbers



Summary:

In an email exchange between Mark Friedenbach and other parties, the topic of the next version of a software being developed was discussed. When asked about the version number, Friedenbach clarified that he meant the next version after the current one, making it version 2. The conversation then turned to the idea of altering the txid through serialization, which would be a hard fork change, but Friedenbach argued that it would be backwards compatible and thus a soft fork. However, the fact remained that changing a field in the transaction would have an impact on its representation. It was suggested that the sequence number could be assumed to be 0xFFFFFFFF for all version 2+ transactions, leaving room for a new field for relative locktime. Additionally, it was proposed that some bytes could be kept for other uses, with the top 2 bytes ignored for relative locktime verify. Finally, the question was raised if there were any use-cases that required a RLTV of more than 8191 blocks delay that couldn't be covered by the absolute version.


Updated on: 2023-06-09T21:40:56.374124+00:00