[vincenzopalazzo]

Summary

Increase BLIP 42's recommended maximum encoded invreq_payer_offer size from 300 to 384 bytes.

This changes only the two existing size references. It does not introduce new sender or receiver requirements, and the existing SHOULD NOT / BIP 353 fallback stays as written.

[TheBlueMatt]

Is there a reason to be so strict? Why not 512?

[TheBlueMatt]

Wait, doesn't this go in an invreq (i.e. onion message), not the payment onion?

[vincenzopalazzo]

Okay, the payment onion size limit has been on my mind all week. I was pretty sure I had run into it somewhere, which is part of why I proposed a compact offer in the LDK implementation (PR #5002).

Even if it’s not directly related to this PR, I’ll add an explanation of how this could matter in the spec proposal where offer size becomes relevant. I found this while looking at an old LDK PR where an async payment test was failing: PR #4210, comment.

There is no protocol reason to prefer 384 over 512.

So as of today we can use any BOLT12 offer size, but once BOLTs #1149 lands we may want to reconsider how we handle this.

The value 384 came from the analysis of what kind of TLV would be most likely used by some user for a bolt12 contact offer!

@TheBlueMatt What do you think if we remove the limit size completely and leave the 'SHOULD use the bip353 when the offer is big' or something like that?

So in this case, with the async payment merged, the blip is still valid and async payment just uses the bip353 in most of the case

[TheBlueMatt]

Ugh yea we need auxiliary onion data.... in any case, we shouldn't need to limit the size here, async payments payers can limit their offer size for async payments specifically. Indeed, in that case they should probably just always use a 353.