PaymentInitiator

Type Members

1. case class InvalidInvoice(message: String) extends IllegalArgumentException with Product with Serializable

   

2. case class PendingPayment(sender: ActorRef, remainingAttempts: Seq[(MilliSatoshi, CltvExpiryDelta)], r: SendTrampolinePaymentRequest) extends Product with Serializable

   

3. case class SendPaymentConfig(id: UUID, parentId: UUID, externalId: Option[String], paymentHash: ByteVector32, recipientAmount: MilliSatoshi, recipientNodeId: PublicKey, upstream: Upstream, paymentRequest: Option[PaymentRequest], storeInDb: Boolean, publishEvent: Boolean, additionalHops: Seq[NodeHop]) extends Product with Serializable

   

   Configuration for an instance of a payment state machine.

   Configuration for an instance of a payment state machine.

   id

   id of the outgoing payment (mapped to a single outgoing HTLC).

   parentId

   id of the whole payment (if using multi-part, there will be N associated child payments, each with a different id).

   externalId

   externally-controlled identifier (to reconcile between application DB and eclair DB).

   paymentHash

   payment hash.

   recipientAmount

   amount that should be received by the final recipient (usually from a Bolt 11 invoice).

   recipientNodeId

   id of the final recipient.

   upstream

   information about the payment origin (to link upstream to downstream when relaying a payment).

   paymentRequest

   Bolt 11 invoice.

   storeInDb

   whether to store data in the payments DB (e.g. when we're relaying a trampoline payment, we don't want to store in the DB).

   publishEvent

   whether to publish a fr.acinq.eclair.payment.PaymentEvent on success/failure (e.g. for multi-part child payments, we don't want to emit events for each child, only for the whole payment).

   additionalHops

   additional hops that the payment state machine isn't aware of (e.g. when using trampoline, hops that occur after the first trampoline node).

4. case class SendPaymentRequest(recipientAmount: MilliSatoshi, paymentHash: ByteVector32, recipientNodeId: PublicKey, maxAttempts: Int, finalExpiryDelta: CltvExpiryDelta = Channel.MIN_CLTV_EXPIRY_DELTA, paymentRequest: Option[PaymentRequest] = None, externalId: Option[String] = None, assistedRoutes: Seq[Seq[ExtraHop]] = Nil, routeParams: Option[RouteParams] = None) extends Product with Serializable

   
   recipientAmount

   amount that should be received by the final recipient (usually from a Bolt 11 invoice).

   paymentHash

   payment hash.

   recipientNodeId

   id of the final recipient.

   maxAttempts

   maximum number of retries.

   finalExpiryDelta

   expiry delta for the final recipient.

   paymentRequest

   (optional) Bolt 11 invoice.

   externalId

   (optional) externally-controlled identifier (to reconcile between application DB and eclair DB).

   assistedRoutes

   (optional) routing hints (usually from a Bolt 11 invoice).

   routeParams

   (optional) parameters to fine-tune the routing algorithm.

5. case class SendPaymentToRouteRequest(amount: MilliSatoshi, recipientAmount: MilliSatoshi, externalId: Option[String], parentId: Option[UUID], paymentRequest: PaymentRequest, finalExpiryDelta: CltvExpiryDelta = Channel.MIN_CLTV_EXPIRY_DELTA, route: Seq[PublicKey], trampolineSecret: Option[ByteVector32], trampolineFees: MilliSatoshi, trampolineExpiryDelta: CltvExpiryDelta, trampolineNodes: Seq[PublicKey]) extends Product with Serializable

   

   The sender can skip the routing algorithm by specifying the route to use.

   The sender can skip the routing algorithm by specifying the route to use. When combining with MPP and Trampoline, extra-care must be taken to make sure payments are correctly grouped: only amount, route and trampolineNodes should be changing.

   Example 1: MPP containing two HTLCs for a 600 msat invoice: SendPaymentToRouteRequest(200 msat, 600 msat, None, parentId, invoice, CltvExpiryDelta(9), Seq(alice, bob, dave), None, 0 msat, CltvExpiryDelta(0), Nil) SendPaymentToRouteRequest(400 msat, 600 msat, None, parentId, invoice, CltvExpiryDelta(9), Seq(alice, carol, dave), None, 0 msat, CltvExpiryDelta(0), Nil)

   Example 2: Trampoline with MPP for a 600 msat invoice and 100 msat trampoline fees: SendPaymentToRouteRequest(250 msat, 600 msat, None, parentId, invoice, CltvExpiryDelta(9), Seq(alice, bob, dave), secret, 100 msat, CltvExpiryDelta(144), Seq(dave, peter)) SendPaymentToRouteRequest(450 msat, 600 msat, None, parentId, invoice, CltvExpiryDelta(9), Seq(alice, carol, dave), secret, 100 msat, CltvExpiryDelta(144), Seq(dave, peter))

   amount

   amount that should be received by the last node in the route (should take trampoline fees into account).

   recipientAmount

   amount that should be received by the final recipient (usually from a Bolt 11 invoice). This amount may be split between multiple requests if using MPP.

   externalId

   (optional) externally-controlled identifier (to reconcile between application DB and eclair DB).

   parentId

   id of the whole payment. When manually sending a multi-part payment, you need to make sure all partial payments use the same parentId. If not provided, a random parentId will be generated that can be used for the remaining partial payments.

   paymentRequest

   Bolt 11 invoice.

   finalExpiryDelta

   expiry delta for the final recipient.

   route

   route to use to reach either the final recipient or the first trampoline node.

   trampolineSecret

   if trampoline is used, this is a secret to protect the payment to the first trampoline node against probing. When manually sending a multi-part payment, you need to make sure all partial payments use the same trampolineSecret.

   trampolineFees

   if trampoline is used, fees for the first trampoline node. This value must be the same for all partial payments in the set.

   trampolineExpiryDelta

   if trampoline is used, expiry delta for the first trampoline node. This value must be the same for all partial payments in the set.

   trampolineNodes

   if trampoline is used, list of trampoline nodes to use (we currently support only a single trampoline node).

6. case class SendPaymentToRouteResponse(paymentId: UUID, parentId: UUID, trampolineSecret: Option[ByteVector32]) extends Product with Serializable

   
   paymentId

   id of the outgoing payment (mapped to a single outgoing HTLC).

   parentId

   id of the whole payment. When manually sending a multi-part payment, you need to make sure all partial payments use the same parentId.

   trampolineSecret

   if trampoline is used, this is a secret to protect the payment to the first trampoline node against probing. When manually sending a multi-part payment, you need to make sure all partial payments use the same trampolineSecret.

7. case class SendTrampolinePaymentRequest(recipientAmount: MilliSatoshi, paymentRequest: PaymentRequest, trampolineNodeId: PublicKey, trampolineAttempts: Seq[(MilliSatoshi, CltvExpiryDelta)], finalExpiryDelta: CltvExpiryDelta = Channel.MIN_CLTV_EXPIRY_DELTA, routeParams: Option[RouteParams] = None) extends Product with Serializable

   

   We temporarily let the caller decide to use Trampoline (instead of a normal payment) and set the fees/cltv.

   We temporarily let the caller decide to use Trampoline (instead of a normal payment) and set the fees/cltv. Once we have trampoline fee estimation built into the router, the decision to use Trampoline or not should be done automatically by the router instead of the caller.

   recipientAmount

   amount that should be received by the final recipient (usually from a Bolt 11 invoice).

   paymentRequest

   Bolt 11 invoice.

   trampolineNodeId

   id of the trampoline node.

   trampolineAttempts

   fees and expiry delta for the trampoline node. If this list contains multiple entries, the payment will automatically be retried in case of TrampolineFeeInsufficient errors. For example, [(10 msat, 144), (15 msat, 288)] will first send a payment with a fee of 10 msat and cltv of 144, and retry with 15 msat and 288 in case an error occurs.

   finalExpiryDelta

   expiry delta for the final recipient.

   routeParams

   (optional) parameters to fine-tune the routing algorithm.