Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

Matt noted during the last round of review the following:

>Oof. Sorry I missed this until now. This is not, in fact, "only used for retries", we use it on claims only, in fact. If a user is relying on the event field for PoP, what this can mean is that we can initiate a send, restart with a stale ChannelManager, notice the payment is pending, then when it claims fail to provide the invoice (only the preimage) to the payer.
>In practice, to fix this, we'll need to include the PaidBolt12Invoice in the HTLCSource::OutboundRoute, I believe.

This commit is trying to store the PaidBolt12Invoice inside the HTLCSource::OutboundRoute, but
this is not enough because we have to store the invoice also inside the PendingOutboundPayment.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

It moves the PaidBolt12Invoice (BOLT 12 invoice)
into HTLCSource::OutboundRoute to ensure the invoice
is available for proof-of-payment and event emission,
as discussed in issue lightningdevkit#3714. The commit also updates
hashing implementations and derives to ensure correct
behavior when the invoice is present, and propagates
the invoice through relevant payment and event structures.

This fixes a potential issue where the invoice could
be lost on restart, affecting PoP reliability.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

It moves the PaidBolt12Invoice (BOLT 12 invoice)
into HTLCSource::OutboundRoute to ensure the invoice
is available for proof-of-payment and event emission,
as discussed in issue lightningdevkit#3714. The commit also updates
hashing implementations and derives to ensure correct
behavior when the invoice is present, and propagates
the invoice through relevant payment and event structures.

This fixes a potential issue where the invoice could
be lost on restart, affecting PoP reliability.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

It moves the PaidBolt12Invoice (BOLT 12 invoice)
into HTLCSource::OutboundRoute to ensure the invoice
is available for proof-of-payment and event emission,
as discussed in issue lightningdevkit#3714. The commit also updates
hashing implementations and derives to ensure correct
behavior when the invoice is present, and propagates
the invoice through relevant payment and event structures.

This fixes a potential issue where the invoice could
be lost on restart, affecting PoP reliability.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>

It moves the PaidBolt12Invoice (BOLT 12 invoice)
into HTLCSource::OutboundRoute to ensure the invoice
is available for proof-of-payment and event emission,
as discussed in issue lightningdevkit#3714. The commit also updates
hashing implementations and derives to ensure correct
behavior when the invoice is present, and propagates
the invoice through relevant payment and event structures.

This fixes a potential issue where the invoice could
be lost on restart, affecting PoP reliability.

Link: lightningdevkit#3714
Signed-off-by: Vincenzo Palazzo <[email protected]>