Matt Morehouse
Matt Morehouse
Yes, right!
Maybe we should also change `DecodeHopPayload` to enforce the correct size, rather than `UINT16_MAX`.
@erickcestari I vaguely recall that you were having issues with fuzzing CLN invoice requests, due to validation being scattered throughout the codebase. Is this still the case?
I think it would be good to have issues for tracking when we can remove these workarounds, and also TODOs within the code itself.
There's a spec [requirement](https://github.com/lightning/bolts/blob/14272b1bd9361750cfdb3e5d35740889a6b510b5/02-peer-protocol.md?plain=1#L775) to use a minimal encoding on the writer side: ``` The sending node: - MUST use the smallest bitmap possible to represent the channel type. ```...
> Has the fuzzer found an actual bug or is it just another impossible edge case? I think technically these are bugs -- `amount_msat_scale` and `amount_sat_scale` are supposed to return...
> Makes me wonder why `scale`'s type isn't unsigned in the first place... Probably because there's no way to represent an unsigned float.
> The test results in the following LeakSanitizer error when run on its corpus: I looked closer at this. The accused line of code does a naked `malloc` (no `tal`...
> This time, the leak occurs when we try to send a `channel_update` message for a channel that the peer hasn't already received a `channel_announcement` for. CLN asks the seeker...
> Yeah, we discussed this over our meeting a while ago, and we decided upon creating a new file for each fuzz run. I tried to do that but the...