We had a decent solution to old state “revocation” involving additional transaction kernels but @tromp came up with a more elegant solution that we think is pretty much as minimal as we can get, effectively reusing the NRD kernel from the “close” and “settle” halves of the slow transaction as part of the “revoke” process. It seems unlikely a payment channel implementation can be done with any less data than this.
I added a section to the RFC with a high level description of this revised approach, with payment channels as the motivating factor for introducing NRD kernels -
The “kernel pos” PR is getting close to done. Still need to implement pruning/compaction and clean the code up a bit but the index itself is implemented.
There is another PR up in draft with some initial work on the serialization/deserialization of NRD kernels themselves.
This PR led us down the path of thinking about exactly how to roll this out with the hardfork in terms of block and transaction validation rules. Still some more thinking to do around that but making progress on the PR.