2023 Mar 29

• Cryptopals challenge 31 - timing attack.

• Trying out this issue

  • outboundpayment.abandon_payment is called in many different places

    • For this we’ll probably have to create another function - abandon_with_reason

    • In retry_payment_internal there are a bunch of fail conditions - is it useful to actually communicate all these? Maybe? Otherwise could just lump under a RetryError variant and tell them to check logs

  • outboundpayment.fail_htlc is also called in different places

    • this is mainly called by fail_htlc_backwards_internal which is called in many places - hard to narrow down when source = Outbound

    • sigh, need to add another function here too?

    • or maybe can do smth fancy like return the event or something and push the thing with the reason outside this function?

  • check_retry is really only called in one place ✅

  • Need to fix tests - mainly the macro expect_payment_failed

  • Important thing to note

    • outbound_payment::send_payment_internal is the only one that uses the handle_route_err which is the one that abandons based on PaymentSendFailure because it will want to retry - this is only used when you use send_payment_with_retry

      • For immediate errors this instead sends RetryableSendFailure

    • OutboundPayment::send_payment_with_route is the one that’s used in the normal ChannelManager::send_payment which will not do any retries for you and will immediately return the PaymentSendFailure on err