Adversary can craft arbitrary PaymentId due to type confusion in deserialization

[SWvheerden]

An attacker with control over the user_data field in a PaymentId::Open can
manipulate its deserialization to be interpreted as a different type, such as
PaymentId::TransactionInfo. This can lead to unintended transaction
processing behavior depending on how the PaymentId is used.
The core issue lies in the deserialization logic, which relies on byte length and
pattern matching rather than a definitive type identifier. When handling larger
payloads, the function first attempts to parse them as AddressAndData. If that
fails, it defaults to TransactionInfo, creating an opportunity for type
confusion.
An attacker can exploit this by crafting the user_data field in a
PaymentId::Open to:

Be too large for a simple Open variant.
Contain bytes that fail TariAddress parsing, preventing it from being
interpreted as AddressAndData.
Have a structure that matches TransactionInfo, allowing control over
critical transaction parameters such as amount, fee, weight, and
recipient_address.

Recommendation

Introduce an explicit type tag as the first byte in all serialized PaymentId
variants to ensure unambiguous type identification.