This is a proposal to implement 1st bullet point of raiden-network/light-client#2730 (raiden-network/raiden#7113) in a way which keeps clients compatible with pyRaiden 2.0 (aka Bespin) release.
This implements 2 main changes:
- Clients should not require to be the first/next address in
LockedTransfer.metadata.routes[*].route: Address[] array, and instead should be able to search themselves on this array and validate that the address after is the outgoing partner/next hop.
- on 2.0, PC expects to always be first/next route on , i.e. it expects that the previous node has prunned this
route array from all previous address up to them, and would not fail the mediation if this was not strictly the case
- With above in place, it's possible to implement immutable metadata, i.e. passthrough exactly what was received, and the
additionalHash to be calculated as the exact metadata object received, JCS-serialized.
- on 2.0, PC hashed the
metadata differently from what was serialized: the hash was over the checksummed addresses, but the serialized message was sent with the lowercased addresses. Also, additional/unknown properties in metadata were not preserved.
Spec
- A new capability is added,
immutableMetadata
- New clients implementing it set it to
1, otherwise, assume the fallback value of 0 (previous, 2.0 behavior). New clients:
- When receiving a
LockedTransfer message from an immutableMetadata=0 partner (legacy), we should transform addresses in metadata before calculating the additionalHash used to verify its signature. Otherwise, additionalHash should be calculated as the keccak256 hash of the canonical JSON serialization of the unvalidated/undecoded metadata.
- When creating an outgoing
LockedTransfer to an immutableMetadata=0 partner, the additionalHash must be calculated with checksummed addresses (we may decide to serialize it either as checksummed or lowercased, the change is required only for the signed/verified hash, although if also serializing the LockedTransfer.metadata payload addresses as checksummed, we'd have the serialization compatible with both old and new approach). Otherwise, as stated above, the hash must be of exactly was sent.
- Again, on the legacy outbound path, we must prune the
route array of every address up to and including us, such that partner will be the first/next address in route. In the new behavior, route is always left unchanged.
Conclusion
With the above spec, we can implement immutable metadata passthrough in a backwards compatible way, allowing us to implement new feature which depend on it, for example, secret encrypted in metadata. Of course, those features will need all hops on a path to be on the new behavior, but if not, at least they won't get out of sync and will simply fall back to the old behavior.
This is a proposal to implement 1st bullet point of raiden-network/light-client#2730 (raiden-network/raiden#7113) in a way which keeps clients compatible with pyRaiden 2.0 (aka Bespin) release.
This implements 2 main changes:
LockedTransfer.metadata.routes[*].route: Address[]array, and instead should be able to search themselves on this array and validate that the address after is the outgoing partner/next hop.routearray from all previous address up to them, and would not fail the mediation if this was not strictly the caseadditionalHashto be calculated as the exact metadata object received, JCS-serialized.metadatadifferently from what was serialized: the hash was over the checksummed addresses, but the serialized message was sent with the lowercased addresses. Also, additional/unknown properties inmetadatawere not preserved.Spec
immutableMetadata1, otherwise, assume the fallback value of0(previous, 2.0 behavior). New clients:LockedTransfermessage from animmutableMetadata=0partner (legacy), we should transform addresses inmetadatabefore calculating theadditionalHashused to verify its signature. Otherwise,additionalHashshould be calculated as the keccak256 hash of the canonical JSON serialization of the unvalidated/undecodedmetadata.LockedTransferto animmutableMetadata=0partner, theadditionalHashmust be calculated with checksummed addresses (we may decide to serialize it either as checksummed or lowercased, the change is required only for the signed/verifiedhash, although if also serializing theLockedTransfer.metadatapayload addresses as checksummed, we'd have the serialization compatible with both old and new approach). Otherwise, as stated above, the hash must be of exactly was sent.routearray of every address up to and including us, such that partner will be the first/next address inroute. In the new behavior,routeis always left unchanged.Conclusion
With the above spec, we can implement immutable metadata passthrough in a backwards compatible way, allowing us to implement new feature which depend on it, for example, secret encrypted in metadata. Of course, those features will need all hops on a path to be on the new behavior, but if not, at least they won't get out of sync and will simply fall back to the old behavior.