home | help
LIGHTNING-MULTIFUNDCHANNEL(7)			   LIGHTNING-MULTIFUNDCHANNEL(7)

NAME
     multifundchannel -- Command for establishing many lightning channels

SYNOPSIS
     multifundchannel  destinations  [feerate]	[minconf]  [utxos] [minchannels]
     [commitment_feerate]

DESCRIPTION
     The multifundchannel RPC command opens multiple payment channels with nodes
     by committing a single funding transaction to the blockchain that is shared
     by all channels.

     If not already connected, multifundchannel will  automatically  attempt  to
     connect;  you may provide a @host:port hint appended to the node ID so that
     Core Lightning can learn how to connect to  the  node;  see  lightning-con-
     nect(7).

     Once  the	transaction  is  confirmed, normal channel operations may begin.
     Readiness is indicated by listpeers reporting a  state  of  CHANNELD_NORMAL
     for the channel.

     *	destinations  (array  of  objects):  There must be at least one entry in
	destinations; it cannot be an empty array.:
	*  id (string): Node ID, with an optional @host:port appended to it in a
	   manner understood by connect; see lightning-connect(7). Each entry in
	   the destinations array must have a unique node  id.	If  not  already
	   connected,  multifundchannel will automatically attempt to connect to
	   the node.
	*  amount (sat_or_all): Amount in satoshis taken from the internal  wal-
	   let	to  fund  the  channel (but if we have any anchor channels, this
	   will always leave at least min-emergency-msat as change). The  string
	   all can be used to specify all available funds (or 16,777,215 satoshi
	   if  more is available and large channels were not negotiated with the
	   peer). Otherwise it is in satoshi precision; it can be a  whole  num-
	   ber,  a whole number ending in sat, a whole number ending in 000msat,
	   or a number with 1 to 8 decimal places ending in btc. The value  can-
	   not	be  less  than	the dust limit, currently 546 satoshi as of this
	   writing, nor more than 16,777,215 satoshi (unless large channels were
	   negotiated with the peer).
	*  announce (boolean, optional): Flag that indicates whether to announce
	   the channel with this. If set to False, the channel	is  unpublished.
	   The default is True.
	*  push_msat  (msat, optional): Amount of millisatoshis to outright give
	   to the node. This is a gift to the peer, and you do not get a  proof-
	   of-payment out of this.
	*  close_to  (string,  optional):  Bitcoin  address to which the channel
	   funds should be sent to on close. Only valid if both peers have nego-
	   tiated option_upfront_shutdown_script Returns close_to set to closing
	   script iff is negotiated.
	*  request_amt (sat, optional): Amount of liquidity you'd like to  lease
	   from  peer.	If  peer supports option_will_fund, indicates to them to
	   include this much liquidity into the channel. Must also pass in  com-
	   pact_lease.
	*  compact_lease  (string,  optional):	Compact  representation  of  the
	   peer's expected channel lease terms. If the peer's terms don't  match
	   this set, we will fail to open the channel to this destination.
	*  mindepth  (u32, optional): Number of confirmations before we consider
	   the channel active.
	*  reserve (sat, optional): Amount we want the peer to maintain  on  its
	   side  of the channel. It can be a whole number, a whole number ending
	   in sat, a whole number ending in 000msat, or a number  with	1  to  8
	   decimal  places  ending  in	btc.  The  default  is 1% of the funding
	   amount.
     *	feerate (feerate, optional): Feerate used for the  opening  transaction,
	and  if commitment_feerate is not set, as initial feerate for commitment
	and HTLC transactions. See NOTES in lightning-feerates(7)  for	possible
	values. The default is normal.
     *	minconf  (integer,  optional): Minimum number of confirmations that used
	outputs should have. The default is 1.
     *	utxos (array of outpoints, optional):
	*  (outpoint, optional): Utxos to be used to fund the channel, as an ar-
	   ray of txid:vout.
     *	minchannels (integer, optional): Re-attempt funding as long as at  least
	this  many peers remain (must not be zero). The multifundchannel command
	will only fail if too many peers fail the funding process.
     *	commitment_feerate (feerate, optional): Initial feerate  for  commitment
	and HTLC transactions. See feerate for valid values.

RETURN VALUE
     This  command opens multiple channels with a single large transaction, thus
     only one transaction is returned.

     If minchannels was specified and is less than the number  of  destinations,
     then  it  is  possible  that  one or more of the destinations do not have a
     channel even if multifundchannel succeeded.  On success, an object  is  re-
     turned, containing:

     *	tx (hex): The raw transaction which funded the channel.
     *	txid (txid): The txid of the transaction which funded the channel.
     *	channel_ids (array of objects):
	*  id (pubkey): The peer we opened the channel with.
	*  outnum  (u32):  The	0-based output index showing which output funded
	   the channel.
	*  channel_id (hash): The channel_id of the resulting channel.
	*  channel_type (object): Channel_type as negotiated with  peer.  (added
	   v24.02):
	*  bits  (array  of  u32s):  Each  bit	set in this channel_type. (added
	   v24.02):
	   *  (u32, optional): Bit number.
	*  names (array of strings): Feature name for each bit set in this chan-
	   nel_type. Note that anchors_zero_fee_htlc_tx is a deprecated  synonym
	   for anchors. (added v24.02):
	   *  (string,	optional)  (one of "static_remotekey/even", "anchor_out-
	      puts/even",    "anchors_zero_fee_htlc_tx/even",	 "anchors/even",
	      "scid_alias/even", "zeroconf/even"): Name of feature bit.
	*  close_to  (hex,  optional):	The  raw scriptPubkey which mutual close
	   will go to; only present if close_to parameter was specified and peer
	   supports option_upfront_shutdown_script.
     *	failed (array of objects, optional): Any peers we failed  to  open  with
	(if minchannels was specified less than the number of destinations).:
	*  id (pubkey): The peer we failed to open the channel with.
	*  method  (string)  (one  of  "connect", "openchannel_init", "fundchan-
	   nel_start", "fundchannel_complete"): What stage we failed at.
	*  error (object):
	*  code (integer): JSON error code from failing stage.
	*  message (string): Message from stage.
	*  data: Additional error data.

     On failure, none of the channels are created.

ERRORS
     The following error codes may occur:

     *	-1: Catchall nonspecific error.
     *	300: The maximum allowed funding amount is exceeded.
     *	301: There are not enough funds in the internal wallet (including  fees)
	to create the transaction.
     *	302: The output amount is too small, and would be considered dust.
     *	303:  Broadcasting  of the funding transaction failed, the internal call
	to bitcoin-cli returned with an error.
     *	313: The min-emergency-msat reserve not be preserved (and we have or are
	opening anchor channels).

     Failure may also occur if lightningd and the peer cannot agree  on  channel
     parameters  (funding  limits, channel reserves, fees, etc.). See lightning-
     fundchannel_start(7) and lightning-fundchannel_complete(7).

     There may be rare edge cases where a communications failure  later  in  the
     channel  funding  process	will  cancel  the  funding locally, but the peer
     thinks the channel is already waiting for funding lockin. In that case, the
     next time we connect to the peer, our node will tell the peer to forget the
     channel, but some nodes (in particular, Core Lightning nodes) will  discon-
     nect  when  our  node  tells them to forget the channel. If you immediately
     multifundchannel with that peer, it could trigger this  connect-forget-dis-
     connect  behavior,  causing the second multifundchannel to fail as well due
     to disconnection. Doing a connect with the peers  separately,  and  waiting
     for  a few seconds, should help clear this hurdle; running multifundchannel
     a third time would also clear this.

AUTHOR
     ZmnSCPxj ZmnSCPxj@protonmail.com is mainly responsible.

SEE ALSO
     lightning-connect(7), lightning-listfunds(), lightning-listpeers(7), light-
     ning-fundchannel(7)

RESOURCES
     Main web site: https://github.com/ElementsProject/lightning

EXAMPLES
     Example 1: This example opens three channels at once, with  amounts  20,000
     sats,  30,000  sats  and the final channel using all remaining funds (actu-
     ally, capped at 16,777,215 sats because large-channels is not enabled):

     Request:

     $ lightning-cli multifundchannel -k "destinations"='[{"id": "nodeid030303030303030303030303030303030303030303030303030303030303@127.0.0.1:19736", "amount": "20000sat"}, {"id": "nodeid040404040404040404040404040404040404040404040404040404040404@127.0.0.1:19737", "amount": "0.0003btc"}, {"id": "nodeid050505050505050505050505050505050505050505050505050505050505@127.0.0.1:19738", "amount": "all"}]' "feerate"="10000perkw" "commitment_feerate"="2000perkw"

     {
       "id": "example:multifundchannel#1",
       "method": "multifundchannel",
       "params": {
	 "destinations": [
	   {
	     "id": "nodeid030303030303030303030303030303030303030303030303030303030303@127.0.0.1:19736",
	     "amount": "20000sat"
	   },
	   {
	     "id": "nodeid040404040404040404040404040404040404040404040404040404040404@127.0.0.1:19737",
	     "amount": "0.0003btc"
	   },
	   {
	     "id": "nodeid050505050505050505050505050505050505050505050505050505050505@127.0.0.1:19738",
	     "amount": "all"
	   }
	 ],
	 "feerate": "10000perkw",
	 "commitment_feerate": "2000perkw"
       }
     }

     Response:

     {
       "tx": "02000000000101multif50000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000500005000050000",
       "txid": "channeltxid01050000500005000050000500005000050000500005000050000",
       "channel_ids": [
	 {
	   "id": "nodeid030303030303030303030303030303030303030303030303030303030303",
	   "channel_id": "channelid1100011000110001100011000110001100011000110001100011000",
	   "channel_type": {
	     "bits": [
	       12,
	       22
	     ],
	     "names": [
	       "static_remotekey/even",
	       "anchors/even"
	     ]
	   },
	   "outnum": 1
	 },
	 {
	   "id": "nodeid040404040404040404040404040404040404040404040404040404040404",
	   "channel_id": "channelid1200012000120001200012000120001200012000120001200012000",
	   "channel_type": {
	     "bits": [
	       12,
	       22
	     ],
	     "names": [
	       "static_remotekey/even",
	       "anchors/even"
	     ]
	   },
	   "outnum": 1
	 },
	 {
	   "id": "nodeid050505050505050505050505050505050505050505050505050505050505",
	   "channel_id": "channelid1300013000130001300013000130001300013000130001300013000",
	   "channel_type": {
	     "bits": [
	       12,
	       22
	     ],
	     "names": [
	       "static_remotekey/even",
	       "anchors/even"
	     ]
	   },
	   "outnum": 1
	 }
       ],
       "failed": []
     }

     Example 2:

     Request:

     $ lightning-cli multifundchannel -k "destinations"='[{"id": "fakenodeid03030303030303030303030303030303030303030303030303030303@127.0.0.1:19736", "amount": 50000}, {"id": "nodeid040404040404040404040404040404040404040404040404040404040404@127.0.0.1:19737", "amount": 50000}, {"id": "nodeid010101010101010101010101010101010101010101010101010101010101@127.0.0.1:19734", "amount": 50000}]' "minchannels"=1

     {
       "id": "example:multifundchannel#2",
       "method": "multifundchannel",
       "params": {
	 "destinations": [
	   {
	     "id": "fakenodeid03030303030303030303030303030303030303030303030303030303@127.0.0.1:19736",
	     "amount": 50000
	   },
	   {
	     "id": "nodeid040404040404040404040404040404040404040404040404040404040404@127.0.0.1:19737",
	     "amount": 50000
	   },
	   {
	     "id": "nodeid010101010101010101010101010101010101010101010101010101010101@127.0.0.1:19734",
	     "amount": 50000
	   }
	 ],
	 "minchannels": 1
       }
     }

     Response:

     {
       "tx": "02000000000102multif60000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000600006000060000",
       "txid": "channeltxid02060000600006000060000600006000060000600006000060000",
       "channel_ids": [
	 {
	   "id": "nodeid040404040404040404040404040404040404040404040404040404040404",
	   "channel_id": "channelid1520015200152001520015200152001520015200152001520015200",
	   "channel_type": {
	     "bits": [
	       12,
	       22
	     ],
	     "names": [
	       "static_remotekey/even",
	       "anchors/even"
	     ]
	   },
	   "outnum": 1
	 }
       ],
       "failed": [
	 {
	   "id": "03a389b3a2f7aa6f9f4ccc19f2bd7a2eba83596699e86b715caaaa147fc37f3144",
	   "method": "connect",
	   "error": {
	     "code": 401,
	     "message": "All addresses failed: 127.0.0.1:19736: Cryptographic handshake: peer closed connection (wrong key?). "
	   }
	 },
	 {
	   "id": "nodeid010101010101010101010101010101010101010101010101010101010101",
	   "method": "connect",
	   "error": {
	     "code": 402,
	     "message": "disconnected during connection"
	   }
	 }
       ]
     }

Core Lightning v26.06.1 			   LIGHTNING-MULTIFUNDCHANNEL(7)

home | help