Drop From<Vec<u8>> for UnsignedBolt12Invoice

[TheBlueMatt]

...and maybe others. They only write the invoice request's bytes out, not the fields for the Invoice itself. We shoould probably rename UnsignedBolt12Invoice::bytes to invreq_bytes (and possibly similarly in invreq?) to avoid this confusion in the future.

[TheBlueMatt]

While we're at it we might want to consider dropping the From<Vec<u8>> stuff for the unsigned types since they're not used, have a similar issue, and don't actually take ownership of the Vec anyway. When we're not taking ownership of the vec we should just deserialize as Readable, IMO.

[jkczyz]

...and maybe others. They only write the invoice request's bytes out, not the fields for the Invoice itself. We shoould probably rename UnsignedBolt12Invoice::bytes to invreq_bytes (and possibly similarly in invreq?) to avoid this confusion in the future.

It looks right to me. The constructor takes invreq_bytes by reference and contents by value, forming bytes from them to use in UnsignedBolt12Invoice.

[TheBlueMatt]

Ah, apologies, I was confused. In any case, I do think we should drop the From<Vec<u8>> impl because we aren't actually really being built from a set of bytes (it doesn't make sense for an unsigned object, its bytes arent final).

[TheBlueMatt]

Alternatively, we could use the bytes and pipe them through to the UnsignedBolt12Invoice instead of deserializing and then reserializing the invoice request fields. Oh guess we can't do that cause then we'd be signing things we don't understand..should we be failing to deserialize unsignedbolt12invoices that have unknown fields?

[jkczyz]

Ah, apologies, I was confused. In any case, I do think we should drop the From<Vec<u8>> impl because we aren't actually really being built from a set of bytes (it doesn't make sense for an unsigned object, its bytes arent final).

Hmmm... I don't think this is the case because ParsedMessage::try_from builds the message from the bytes. IIRC, we added the From<Vec<u8>> implementation since a remote NodeSigner may need to (de-)serialize the bytes.

Alternatively, we could use the bytes and pipe them through to the UnsignedBolt12Invoice instead of deserializing and then reserializing the invoice request fields. Oh guess we can't do that cause then we'd be signing things we don't understand..should we be failing to deserialize unsignedbolt12invoices that have unknown fields?

Since it goes through ParsedMessage, we'd fail to deserialize any unknown even fields.