The grpc-gateway library that is used to transform REST calls into gRPC
uses a different method for reading a request body stream depending on
whether the RPC is a request-streaming one or not. We can't really find
out what kind of RPC the user is calling at runtime, so we add a new
parameter to the proxy that lists all request-streaming RPC calls.
In any case the client _has_ to send one request message initially to
kick off the request processing. Normally this can just be an empty
message. This can lead to problems if that empty message is not
expected by the gRPC server. But for the currently existing two
client-streaming RPCs this will only trigger a warning
(HTLC interceptor) or be ignored (channel acceptor).
"summary":"ChannelAcceptor dispatches a bi-directional streaming RPC in which\nOpenChannel requests are sent to the client and the client responds with\na boolean that tells LND whether or not to accept the channel. This allows\nnode operators to specify their own criteria for accepting inbound channels\nthrough a single persistent connection.",
"title":"Stream result of lnrpcChannelAcceptRequest"
}
},
"default":{
"description":"An unexpected error response",
"schema":{
"$ref":"#/definitions/runtimeError"
}
}
},
"parameters":[
{
"name":"body",
"description":" (streaming inputs)",
"in":"body",
"required":true,
"schema":{
"$ref":"#/definitions/lnrpcChannelAcceptResponse"
}
}
],
"tags":[
"Lightning"
]
}
},
"/v1/channels/backup":{
"get":{
"summary":"ExportAllChannelBackups returns static channel backups for all existing\nchannels known to lnd. A set of regular singular static channel backups for\neach channel are returned. Additionally, a multi-channel backup is returned\nas well, which contains a single encrypted blob containing the backups of\neach channel.",
@ -537,6 +580,49 @@
]
}
},
"/v1/channels/transaction-stream":{
"post":{
"summary":"lncli: `sendpayment`\nDeprecated, use routerrpc.SendPaymentV2. SendPayment dispatches a\nbi-directional streaming RPC for sending payments through the Lightning\nNetwork. A single RPC invocation creates a persistent bi-directional\nstream allowing clients to rapidly send payments through the Lightning\nNetwork with a single persistent connection.",
"summary":"SendPaymentSync is the synchronous non-streaming version of SendPayment.\nThis RPC is intended to be consumed by clients of the REST proxy.\nAdditionally, this RPC expects the destination's public key and the payment\nhash (if any) to be encoded as hex strings.",
@ -2929,6 +3015,59 @@
}
}
},
"lnrpcChannelAcceptResponse":{
"type":"object",
"properties":{
"accept":{
"type":"boolean",
"format":"boolean",
"description":"Whether or not the client accepts the channel."
},
"pending_chan_id":{
"type":"string",
"format":"byte",
"description":"The pending channel id to which this response applies."
},
"error":{
"type":"string",
"description":"An optional error to send the initiating party to indicate why the channel\nwas rejected. This field *should not* contain sensitive information, it will\nbe sent to the initiating party. This field should only be set if accept is\nfalse, the channel will be rejected if an error is set with accept=true\nbecause the meaning of this response is ambiguous. Limited to 500\ncharacters."
},
"upfront_shutdown":{
"type":"string",
"description":"The upfront shutdown address to use if the initiating peer supports option\nupfront shutdown script (see ListPeers for the features supported). Note\nthat the channel open will fail if this value is set for a peer that does\nnot support this feature bit."
},
"csv_delay":{
"type":"integer",
"format":"int64",
"description":"The csv delay (in blocks) that we require for the remote party."
},
"reserve_sat":{
"type":"string",
"format":"uint64",
"description":"The reserve amount in satoshis that we require the remote peer to adhere to.\nWe require that the remote peer always have some reserve amount allocated to\nthem so that there is always a disincentive to broadcast old state (if they\nhold 0 sats on their side of the channel, there is nothing to lose)."
},
"in_flight_max_msat":{
"type":"string",
"format":"uint64",
"description":"The maximum amount of funds in millisatoshis that we allow the remote peer\nto have in outstanding htlcs."
},
"max_htlc_count":{
"type":"integer",
"format":"int64",
"description":"The maximum number of htlcs that the remote peer can offer us."
},
"min_htlc_in":{
"type":"string",
"format":"uint64",
"description":"The minimum value in millisatoshis for incoming htlcs on the channel."
},
"min_accept_depth":{
"type":"integer",
"format":"int64",
"description":"The number of confirmations we require before we consider the channel open."