`Height` and `Time` derive `Deserialize` without checks about rust-bitcoin

[apoelstra]

Ouch. I think these De/serialize implementations are really weird and we shouldn't have released them.

For the two LockTime types I think we should de/serialize both as consensus-encoded u32s with checks. For Height and Time we should just use #[serde(from = LockTime)] and #[serde(try_into = LockTime)] (and we should implement the appropriate From/TryInto to make this work).

And for relative::LockTime we should in turn use #[serde(try_from = Sequence)] and #[serde(into = Sequence)].

In other words everything just passes through to the "real" type that's part of a transaction.

[apoelstra]

Other options are:

• Keep the current situation, which for relative::LockTime is actually fine (both Height and Time are represented as u16s and all values are legal). For absolute we have to add error checking as you say.
• Drop Deserialize and Serialize for Height and Time in both modules, since it's weird to be using these types outside of a LockTime.

[tcharding]

Flagging that, as mentioned above, this issue should only relate to absolute::{Height, Time} types.

[Kixunil]

OK, I suggest serde(try_from = "LockTime") for the absolute types and don't touch others.

[apoelstra]

Yeah, that seems reasonable to me, if a little inconsistent between the two locktime types.

My preference would be to either to try_from = "LockTime" for both relative and absolute, or drop Deserialize/Serialize for Height and Time for both relative and absolute.

[Kixunil]

a little inconsistent between the two locktime types.

Oh, I now realized why. It's a good question which is better.

[tcharding]

OK, I suggest serde(try_from = "LockTime") for the absolute types and don't touch others.

I don't understand this statement, I changed the issue description to be only about Height and Time - are you saying you disagree with the change?

IMO the serde stuff for both LockTime structs is correct as is.

[tcharding]

Could be considered as part of #2612