Skip to content
Permalink
master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Commits on May 17, 2023

  1. Ignore lnd's internal errors (#2659)

    It seems like lnd sends this error whenever something wrong happens on
    their side, regardless of whether the channel actually needs to be closed.
    We ignore it to avoid paying the cost of a channel force-close, it's up
    to them to broadcast their commitment if they wish.
    
    See lightningnetwork/lnd#7657 for example.
    t-bast committed May 17, 2023

Commits on May 12, 2023

  1. Reject unreasonably low splice feerate (#2657)

    We let the initiator pick the feerate, but it must at least meet some
    sanity requirements.
    pm47 committed May 12, 2023

Commits on May 11, 2023

  1. Fix channels DB migration (#2655)

    We were missing a match on `channel_id`, which means we were rewriting
    every row N times!
    t-bast committed May 11, 2023

Commits on May 10, 2023

  1. Fix JSON Postgres index on channel's remote_node_id (#2649)

    We were creating an index on the `remote_node_id` based on the channel's
    JSON serialization, which isn't very robust. The data model changes for
    splicing have changed the JSON format and thus broken that index.
    
    We now use and explicit DB column for `remote_node_id`.
    t-bast committed May 10, 2023
  2. Define channelReserve() methods in ChannelParams (#2653)

    So it can be called from `InteractiveTx` for new commitments.
    pm47 committed May 10, 2023
  3. Remove restriction to regtest/testnet (#2652)

    Now that the model is stable we can remove restrictions.
    pm47 committed May 10, 2023

Commits on May 4, 2023

  1. Add cpfp-bump-fees API (#1783)

    We add a `cpfpbumpfees` API that lets node operators bump the fees
    of a package of unconfirmed transactions.
    
    Node operators can for example ensure their funding txs confirm before
    they hit the `2016` funding timeout. It's also very useful when you have
    a long chain of unconfirmed funding transactions and/or mutual close
    transactions and want to bump them all at once.
    
    NB: the node operator needs to figure out which outpoints belong to him
    (which should be fairly easy using existing APIs).
    t-bast committed May 4, 2023
  2. Included doc folder in the assembly zip (#2604)

    Included doc folder in the assembly zip. ** wildcard indicates all the files in the current folder and all the files in the subfolders of the current folder.
    
    Fixes #1645
    tareknaser360 committed May 4, 2023
  3. Cleanup ChannelKeyManager (#2639)

    There was a confusion between `fundingKeyPath` and `channelKeyPath`.
    
    Also simplified the funding key derivation. It's not backward compatible but current version of the code doesn't run on mainnet so it's fine.
    
    ---------
    
    Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
    pm47 and t-bast committed May 4, 2023
  4. Minor fixes for splices (#2647)

    * do not check features at all for splices
    
    It makes more sense than having to announce the feature to all peers.
    
    * check actual min_conf value in swichToZeroConf
    
    When we receive an early `channel_ready`, we may decide to not wait for
    confirmations even if the channel isn't formally zero-conf. However, when
    checking whether the channel is zero-conf, we currently only look at the
    `ZeroConf` feature, which is incorrect in the general case.
    
    This is normally invisible, because the race between:
    - local `WatchFundingTxPublished` event from the watcher
    - remote `ChannelReady`
    is normally won by `WatchFundingTxPublished`. But in tests
    `ChannelReady` usually wins.
    
    It causes us to go through the `swichToZeroConf` path even if the
    channel is already zero-conf, which then leads us to send a
    `splice_locked` for the initial funding tx.
    
    * check features before ignoring sig at reconnection
    
    Legacy single-funding channels may have
    `localFundingStatus=SingleFundedUnconfirmedFundingTx`, so we cannot
    just rely on the absence of `signedTx`.
    
    * fix post-migration startup of channels
    
    Legacy single-funded channels will all be restored with a
    `localFundingStatus=SingleFundedUnconfirmedFundingTx`, whatever the
    actual status of the funding confirmation. The idea is that we
    immediately put a `watchFundingConfirmed()` and set the correct state
    shortly after the first startup.
    
    However, we currently also send a `GetTxWithMeta`, which we should only
    do for channels that are in state `WAIT_FOR_FUNDING_CONFIRMED`,
    otherwise we will have loads of `unhandled event GetTxWithMetaResponse`.
    
    * ignore watcher events in CLOSED
    
    With splices, notifications from the watcher are tricky, there may be
    races due to dealing with multiple funding txs. When we eventually go to
    the `CLOSED` state, we should ignore those events, otherwise they may
    wrongly cause us to go back to `CLOSING`.
    
    * use correct expiry when accepting splice
    
    The non-initiator must use the `locktime` provided in the `splice_init`
    and not choose its own, otherwise transactions and signatures won't
    match if we splice around the time a block has been found.
    pm47 committed May 4, 2023

Commits on May 3, 2023

  1. Remove minDepth from InteractiveTxParams (#2635)

    We can recompute `minDepth` based on our default config, the channel
    capacity and our local features.
    
    The only parameter that could change is our local features, which could
    create issues if we enable/disable zero-conf in the middle of a funding
    attempt: we may accept an RBF attempt for a transaction that we previously
    treated as zero-conf, which will break the channel. But since activating
    zero-conf means we have trust in our peer, and this is an unlikely
    scenario, this is acceptable.
    
    Co-authored-by: Pierre-Marie Padiou <pm47@users.noreply.github.com>
    t-bast and pm47 committed May 3, 2023
  2. Use tlv type 0 for next_funding_txid (#2637)

    This is the official tlv type used in the dual funding specification.
    t-bast committed May 3, 2023
  3. Pass remote address to InterceptOpenChannelPlugin (#2641)

    This change allows plugins to make decisions based on
    peers' IP addresses.
    rorp committed May 3, 2023

Commits on Apr 15, 2023

  1. Fix test to prevent error from timeout waiting for no messages (#2640)

    A peer that receives Disconnect *may* also be sent the Init message. The Init message is ignored by the two disconnect tests so these tests should occur after all of the tests that do not result in a disconnect. Otherwise the extra Init triggers an error when we expect no additional messages to be sent to the peer.
    remyers committed Apr 15, 2023

Commits on Apr 14, 2023

  1. Better validation of onion message payloads (#2631)

    We now reject onion message payloads that contain unexpected fields and classify final payloads as being either an invoice request, an invoice response, an error or an invalid payload.
    Each of these cases are mutually exclusive, it is not allowed to send both an invoice request and an invoice at the same time for instance.
    Invalid payloads are not dropped immediately so that if they are the response we were waiting for, we can stop waiting and return an error without retrying.
    thomash-acinq committed Apr 14, 2023
  2. Add padding to blinded payment routes (#2638)

    The lengths of the encrypted recipient data leak the base fees as they are encoded with a variable length, to compensate for that we always add padding.
    thomash-acinq committed Apr 14, 2023
  3. Onion message test vector (#2628)

    Use latest test vector from the spec for onion messages.
    thomash-acinq committed Apr 14, 2023

Commits on Apr 13, 2023

  1. Dynamic funding pubkeys (#2634)

    Funding pubkeys are now dynamic and change for each splice.
    
    Main changes:
    - `remoteFundingPubkey` has been moved from `RemoteParams` to `Commitment`
    - `localFundingPubkey` is computed by appending the `fundingTxIndex` to a new dedicated `fundingKeyPath`. As a nice side-effect, the resulting funding pubkey is constant across rbf attempts. Also, there is no change in the data model, since the base `fundingKeyPath` is constant and still belongs to `LocalParams`.
    
    ---------
    
    Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
    pm47 and t-bast committed Apr 13, 2023
  2. Update tx_signature witness codec (#2633)

    We treat each witness as a blob of bytes encoded using bitcoin
    serialization.
    t-bast committed Apr 13, 2023
  3. Add support for splices (#2584)

    Add support for both splice-in and splice-out in Eclair. Mixing concurrent local/remote splice-in/splice-out is wired, although not supported in the API.
    
    The implementation differs from the current wip BOLT proposal on at least the following points:
    - we use a poor man's _quiescence_ protocol which just rejects the splice if the channel is not idle
    - splice txs always _spend_ the previous funding/splice tx, even if it isn't confirmed yet and could theoretically be RBFed. This is done to be compatible with zero-conf splices
    - the persistence/reconnection follows the logic described in https://gist.github.com/t-bast/1ac31f4e27734a10c5b9847d06db8d86.
    
    We add a new `fundingTxIndex` to `Commitment`, which has two nice advantages:
    - making debug much easier compared to dealing with txid:
      `splice=1 is now active, removed=0 remaining=2,1`
    - allowing to discriminate between initial funding, splices, rbf, and
      combinations thereof.
    
    We closely mimick RBFing the initial funding tx (e.g. `RbfStatus` vs `SpliceStatus`).
    
    ---------
    
    Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
    pm47 and t-bast committed Apr 13, 2023

Commits on Apr 5, 2023

  1. Allow negative contributions in InteractiveTxBuilder (#2619)

    * Allow negative contributions in InteractiveTxBuilder
    
    When splicing over an existing channel, it is simpler to specify the amount
    we will add or remove from the channel, rather than the resulting amount
    that takes the previous balance into account. It removes the need for
    truncating msat balances and trivially carries over those balances to
    the new commitment.
    
    * Update RBF contributions to allow negative amounts
    
    When RBF-ing a splice, we will need to be consistent with the
    `splice_init` and `splice_ack` messages and specify the funds we're
    adding or removing from the channel instead of the absolute value.
    
    We thus change the `tx_init_rbf` and `tx_ack_rbf` messages to use signed
    amounts.
    t-bast committed Apr 5, 2023
  2. Remove max-funding-satoshis config (#2624)

    * Remove `max-funding-satoshis` config
    
    This configuration parameter doesn't provide any meaningful guarantees
    since there are no limits on the number of channels remote peers can open
    to us. It's better to remove this check from eclair and let plugins decide
    whether to accept channels or not, based on whatever metric makes sense
    for their usecase.
    
    * Remove wumbo from permanent channel features
    
    We've never been really convinced that this feature made sense to keep in
    the channel features. It becomes especially weird with splicing, since a
    channel may initially be larger than the wumbo size, but could then shrink
    and become smaller than that threshold. Similarly, a channel that is
    initially below the wumbo size may exceed the wumbo size after a splice-in.
    t-bast committed Apr 5, 2023
  3. Store channel state after sending commit_sig (#2614)

    We must store the channel state after sending our `tx_signatures`,
    because our peer may broadcast the transaction at that point.
    But it's useful to store it earlier than that, to allow resuming the
    signatures exchange if we get disconnected, otherwise we could
    end up in a state where one peer has forgotten the channel while
    the other has sent `tx_signatures` and must thus wait for the
    channel to be spent or double-spent.
    
    With that change, we can cleanly handle any disconnection:
    
    - if we get disconnected before any peer sent `commitment_signed`,
      the channel is forgotten by both peers
    - if we get disconnected after one peer send `commitment_signed`
      but the other peer didn't, the channel will be forgotten when
      reconnecting (this is safe because the peer that sent
      `commitment_signed` did *not* send `tx_signatures` since the
      other peer didn't send `commitment_signed`)
    - if we get disconnected after both peers sent `commitment_signed`,
      we simply resume the signatures exchange on reconnection
    
    We introduce a new TLV field to `channel_reestablish` that contains
    the `txid` of the funding transaction that is partially signed: this lets
    peers figure out which messages to send back on reconnection.
    t-bast committed Apr 5, 2023

Commits on Apr 4, 2023

  1. Add listreceivedpayments RPC call (#2607)

    Add a new RPC to list payments received by the node.
    rorp committed Apr 4, 2023

Commits on Mar 31, 2023

  1. Rework responses to channel open and rbf (#2608)

    Main behavior changes (see commit messages for details):
    - channel opening errors are returned with a 200/OK status from the api
    - we return a success in the case of dual-funding or rbf, if the interactive tx has completed, even if the publish fails
    - for rbf, we send the success response later in the flow: only when the rbf flow is successful, as opposed to when we initiate it
    
    This is a prerequisite to splices, but also a first step towards reworking the channel request/response mechanism.
    
    Co-authored-by: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
    pm47 and t-bast committed Mar 31, 2023

Commits on Mar 27, 2023

  1. Add offer manager (#2566)

    Because offers are a very generic mechanism, handling them can require interacting with an inventory system (do we actually have the quantity that the payer is requesting) or other such systems which do not have their place inside eclair. For this reason offer handlers must be implemented as plugins that communicate with the offer manager.
    On startup, the offer handlers must register their offers with the offer manager, the offer manager will then forward the invoice requests and blinded payments to the relevant offer handler for approval.
    thomash-acinq committed Mar 27, 2023

Commits on Mar 23, 2023

  1. Fix opportunistic zero-conf (#2616)

    If we didn't plan on using zero-conf, but our peer sends us an early
    channel_ready, we can opportunistically switch to zero-conf.
    
    But we can only do that if we're sure that our peer cannot double-spend
    the funding transaction. We previously checked their contribution to the
    funding output, but that's not enough: they may add inputs to the funding
    transaction even if they don't contribute to the funding output.
    
    We were also setting duplicate `WatchPublished` in case we were already
    using zero-conf, which is now fixed.
    
    When our peer sends us channel_ready while we're still waiting for
    confirmations, we may opportunistically switch to zero-conf, in which
    case we have both a WatchPublished and a WatchConfirmed pending.
    But it may not actually be a real switch to zero-conf: maybe the
    transaction is confirmed, and they simply received the block slightly
    before us. In that case, the WatchConfirmed may trigger first, and it
    would be inefficient to let the WatchPublished override our funding
    status: it will make us set a new WatchConfirmed that will instantly
    trigger and rewrite the funding status again.
    t-bast committed Mar 23, 2023

Commits on Mar 16, 2023

  1. Use bitcoin-lib 0.27 (#2612)

    sstone committed Mar 16, 2023

Commits on Feb 28, 2023

  1. Update Bolt 3 tests (#2605)

    Add latest changes from lightning/bolts#1018
    Add latest fixes from lightning/bolts#1056
    t-bast committed Feb 28, 2023

Commits on Feb 20, 2023

  1. Make updateLocalFundingStatus method return Either (#2602)

    After calling this method, we perform actions at several places that
    only make sense if the correct behavior happened. Instead of assuming
    things went ok, we use proper typing and make the result explicit.
    pm47 committed Feb 20, 2023

Commits on Feb 17, 2023

  1. Limit number of RBF attempts during dual funding (#2596)

    Each RBF attempt adds more data that we need to store and process,
    so we want to limit our peers to a reasonable use of RBF.
    
    We send a warning to let them know that they are close to reaching the
    limits.
    t-bast committed Feb 17, 2023
Older