Merge commit '992ec8cc0dcb8437684cb3fc162b8be04f78170a' into blip18

Author: rorp

.github/workflows/latest-bitcoind.yml

@@ -48,5 +48,5 @@ jobs:
         run: echo "fs.file-max = 1024000" | sudo tee -a /etc/sysctl.conf
 
       - name: Run eclair tests
-        run: BITCOIND_DIR=$GITHUB_WORKSPACE/bitcoin/build/src ./mvnw test
+        run: BITCOIND_DIR=$GITHUB_WORKSPACE/bitcoin/build/bin ./mvnw test
         working-directory: ./eclair

.mvn/checksums/checksums-central.sha256

@@ -0,0 +1,10 @@
+# trusted checksum source setup
+-Daether.trustedChecksumsSource.summaryFile=true
+-Daether.trustedChecksumsSource.summaryFile.basedir=${session.rootDirectory}/.mvn/checksums/
+# post processor: trusted checksums
+-Daether.artifactResolver.postProcessor.trustedChecksums=false
+-Daether.artifactResolver.postProcessor.trustedChecksums.checksumAlgorithms=SHA-256
+-Daether.artifactResolver.postProcessor.trustedChecksums.failIfMissing=true
+-Daether.artifactResolver.postProcessor.trustedChecksums.snapshots=false
+# Uncomment the following line to generate checksums
+# -Daether.artifactResolver.postProcessor.trustedChecksums.record=true

.mvn/maven.config

@@ -95,5 +95,5 @@ To re-create the trusted checksums file, run:
 
 ```shell
 $ rm ~/.m2/wrapper ~/.sbt -rf
-$ ./mvnw clean install scoverage:report -DskipTests -Daether.artifactResolver.postProcessor.trustedChecksums.record
+$ ./mvnw clean install -DskipTests -Daether.artifactResolver.postProcessor.trustedChecksums.record
 ```

BUILD.md

@@ -284,11 +284,12 @@ eclair.chain = "regtest"
 eclair.bitcoind.rpcport=18443
 ```
 
-For signet, add `signet=1` in `bitcoin.conf` or start with `-signet`, and modify `eclair.conf`:
+For signet, add `signet=1` in `bitcoin.conf` or start with `-signet`, and modify `eclair.conf` as follows. The `signet-check-tx` config parameter should be the txid of a transaction that exists in your signet, "" to skip this check, or if not specified, the default signet txid value will be used.
 
 ```conf
 eclair.chain = "signet"
 eclair.bitcoind.rpcport=38332
+eclair.bitcoind.signet-check-tx=<txid of signet tx>
 ```
 
 You may also want to take advantage of the new configuration sections in `bitcoin.conf` to manage parameters that are network specific,

README.md

@@ -1,6 +1,6 @@
 # FAQ
 
-## What does it mean for a channel to be "enabled" or "disabled" ?
+## What does it mean for a channel to be "enabled" or "disabled"?
 
 A channel is disabled if a `channel_update` message has been broadcast for that channel with the `disable` bit set (see [BOLT 7](https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message)). It means that the channel still exists but cannot be used to route payments, until it has been re-enabled.
 
@@ -13,6 +13,16 @@ There are other cases when a channel becomes disabled, for example when its bala
 
 Note that you can have multiple channels between the same nodes, and that some of them can be enabled while others are disabled (i.e. enable/disable is channel-specific, not node-specific).
 
-## How should you stop an Eclair node ?
+## How do I make my closing transactions confirm faster?
+
+When channels are unilaterally closed, there is a delay before which closing transactions can be published: you must wait for this delay before you can get your funds back.
+
+Once published, transactions will be automatically RBF-ed by `eclair` based on your configuration values for the [`eclair.on-chain-fees` section](../eclair-core/src/main/resources/reference.conf).
+
+Note that there is an upper bound on the feerate that will be used, configured by the `eclair.on-chain-fees.max-closing-feerate` parameter.
+If the current feerate is higher than this value, your transactions will not confirm.
+You should update `eclair.on-chain-fees.max-closing-feerate` in your `eclair.conf` and restart your node: your transactions will automatically be RBF-ed using the new feerate.
+
+## How should you stop an Eclair node?
 
 To stop your node you just need to kill its process, there is no API command to do this. The JVM handles the quit signal and notifies the node to perform clean-up. For example, there is a hook to cleanly free DB locks when using Postgres.

docs/FAQ.md

@@ -21,7 +21,7 @@
     <parent>
         <groupId>fr.acinq.eclair</groupId>
         <artifactId>eclair_2.13</artifactId>
-        <version>0.12.0</version>
+        <version>0.13.0</version>
     </parent>
 
     <artifactId>eclair-core_2.13</artifactId>

docs/release-notes/eclair-v0.13.0.md

@@ -42,6 +42,8 @@ eclair {
     final-pubkey-refresh-delay = 3 seconds
     // If true, eclair will poll bitcoind for 30 seconds at start-up before giving up.
     wait-for-bitcoind-up = true
+    // The txid of a transaction that exists in your custom signet network or "" to skip this check.
+    signet-check-tx = "ff1027486b628b2d160859205a3401fb2ee379b43527153b0b50a92c17ee7955" // coinbase of block #5000 of default signet
   }
 
   node-alias = "eclair"
@@ -72,11 +74,12 @@ eclair {
     option_shutdown_anysegwit = optional
     option_dual_fund = optional
     option_quiesce = optional
+    option_attribution_data = optional
     option_onion_messages = optional
     // This feature should only be enabled when acting as an LSP for mobile wallets.
     // When activating this feature, the peer-storage section should be customized to match desired SLAs.
     option_provide_storage = disabled
-    option_channel_type = optional
+    option_channel_type = mandatory
     option_scid_alias = optional
     option_payment_metadata = optional
     // By enabling option_zeroconf, you will be trusting your peer as fundee. You will lose funds if they double spend
@@ -133,7 +136,7 @@ eclair {
 
     to-remote-delay-blocks = 720 // number of blocks that the other node's to-self outputs must be delayed (720 ~ 5 days)
     max-to-local-delay-blocks = 2016 // maximum number of blocks that we are ready to accept for our own delayed outputs (2016 ~ 2 weeks)
-    min-depth-blocks = 6 // minimum number of confirmations for channel transactions, which we will additionally scale based on the amount at stake
+    min-depth-blocks = 8 // minimum number of confirmations for channel transactions to be safe from reorgs
     expiry-delta-blocks = 144
     max-expiry-delta-blocks = 2016 // we won't forward HTLCs with timeouts greater than this delta
     // When we receive the preimage for an HTLC and want to fulfill it but the upstream peer stops responding, we want to
@@ -166,7 +169,7 @@ eclair {
     // (with the default behavior, it would "only" cause a local force-close of the channel).
     unhandled-exception-strategy = "local-close" // local-close or stop
 
-    revocation-timeout = 20 seconds // after sending a commit_sig, we will wait for at most that duration before disconnecting
+    revocation-timeout = 60 seconds // after sending a commit_sig, we will wait for at most that duration before disconnecting
 
     channel-open-limits {
       max-pending-channels-per-peer = 3 // maximum number of pending channels we will accept from a given peer
@@ -248,6 +251,18 @@ eclair {
       // Number of blocks before the incoming HTLC expires that an async payment must be triggered by the receiver
       cancel-safety-before-timeout-blocks = 144
     }
+
+    // We assign reputation to our peers to prioritize payments during congestion.
+    // The reputation is computed as fees paid divided by what should have been paid if all payments were successful.
+    peer-reputation {
+      // Set this parameter to false to disable the reputation algorithm and simply relay the incoming endorsement
+      // value, as described by https://github.com/lightning/blips/blob/master/blip-0004.md,
+      enabled = true
+      // Reputation decays with the following half life to emphasize recent behavior.
+      half-life = 30 days
+      // Payments that stay pending for longer than this get penalized.
+      max-relay-duration = 5 minutes
+    }
   }
 
   on-chain-fees {
@@ -268,9 +283,17 @@ eclair {
       closing = medium
     }
 
+    // Maximum feerate that will be used when closing channels for outputs that aren't at risk (main balance and HTLC 3rd-stage transactions).
+    // Using a low value here ensures that you won't be paying high fees when the mempool is congested and you're not in
+    // a hurry to get your channel funds back.
+    // If closing transactions don't confirm and you need to get the funds back quickly, you should increase this value
+    // and restart your node: closing transactions will automatically be RBF-ed to match the current feerate.
+    // This value is in satoshis per byte.
+    max-closing-feerate = 10
+
     feerate-tolerance {
-      ratio-low = 0.5 // will allow remote fee rates as low as half our local feerate when not using anchor outputs
-      ratio-high = 10.0 // will allow remote fee rates as high as 10 times our local feerate when not using anchor outputs
+      ratio-low = 0.5 // will allow remote fee rates as low as half our local feerate (only enforced when not using anchor outputs)
+      ratio-high = 10.0 // will allow remote fee rates as high as 10 times our local feerate (for all commitment formats)
       // when using anchor outputs, we only need to use a commitment feerate that allows the tx to propagate: we will use CPFP to speed up confirmation if needed.
       // the following value is the maximum feerate we'll use for our commit tx (in sat/byte)
       anchor-output-max-commit-feerate = 10
@@ -374,10 +397,10 @@ eclair {
   }
 
   peer-connection {
-    auth-timeout = 15 seconds // will disconnect if connection authentication doesn't happen within that timeframe
-    init-timeout = 15 seconds // will disconnect if initialization doesn't happen within that timeframe
+    auth-timeout = 30 seconds // will disconnect if connection authentication doesn't happen within that timeframe
+    init-timeout = 30 seconds // will disconnect if initialization doesn't happen within that timeframe
     ping-interval = 30 seconds
-    ping-timeout = 20 seconds // will disconnect if peer takes longer than that to respond
+    ping-timeout = 60 seconds // will disconnect if peer takes longer than that to respond
     ping-disconnect = true // disconnect if no answer to our pings
     // When enabled, if we receive an incoming connection, we will echo the source IP address in our init message.
     // This should be disabled if your node is behind a load balancer that doesn't preserve source IP addresses.
@@ -404,6 +427,9 @@ eclair {
 
   router {
     watch-spent-window = 60 minutes // at startup watches on public channels will be put back within that window to reduce herd effect; must be > 0s
+    // when we detect that a remote channel has been spent on-chain, we wait for 72 blocks before removing it from the graph
+    // if this was a splice instead of a close, we will be able to simply update the channel in our graph and keep its reputation
+    channel-spent-splice-delay = 72
 
     channel-exclude-duration = 60 seconds // when a temporary channel failure is returned, we exclude the channel from our payment routes for this duration
     broadcast-interval = 60 seconds // see BOLT #7
@@ -434,6 +460,11 @@ eclair {
       default {
         randomize-route-selection = true // when computing a route for a payment we randomize the final selection
 
+        mpp {
+          min-amount-satoshis = 15000 // minimum amount sent via partial HTLCs
+          max-parts = 5 // maximum number of HTLCs sent per payment: increasing this value will impact performance
+        }
+
         boundaries {
           max-route-length = 6         // max route length for the 'first pass', if none is found then a second pass is made with no limit
           max-cltv = 2016              // max acceptable cltv expiry for the payment (2016 ~ 2 weeks)
@@ -442,7 +473,14 @@ eclair {
           max-fee-proportional-percent = 3 // that's 3%
         }
 
-        use-ratios = true // if false, will use failure-cost
+        hop-cost {
+          // virtual fee for additional hops: how much you are willing to pay to get one less hop in the payment path
+          fee-base-msat = 500
+          fee-proportional-millionths = 200
+        }
+
+        use-ratios = true // if true, will use `ratios`, if false, will use `failure-cost`, `locked-funds-risk`, `use-log-probability`, `use-past-relay-data`.
+
         // channel 'weight' is computed with the following formula: (channelFee + hop-cost) * (ratio-base + cltvDelta * ratio-cltv + channelAge * ratio-channel-age + channelCapacity * ratio-channel-capacity)
         // the following parameters can be used to ask the router to use heuristics to find i.e: 'cltv-optimized' routes, **the sum of the four ratios must be 1**
         ratios {
@@ -452,17 +490,12 @@ eclair {
           channel-capacity = 0.55 // when computing the weight for a channel, consider its CAPACITY in this proportion
         }
 
-        hop-cost {
-          // virtual fee for additional hops: how much you are willing to pay to get one less hop in the payment path
-          fee-base-msat = 500
-          fee-proportional-millionths = 200
-        }
+        // Everything below is ignored if use-ratio = true.
 
         locked-funds-risk = 1e-8 // msat per msat locked per block. It should be your expected interest rate per block multiplied by the probability that something goes wrong and your funds stay locked.
         // 1e-8 corresponds to an interest rate of ~5% per year (1e-6 per block) and a probability of 1% that the channel will fail and our funds will be locked.
 
         // virtual fee for failed payments: how much you are willing to pay to get one less failed payment attempt
-        // ignored if use-ratio = true
         failure-cost {
           fee-base-msat = 2000
           fee-proportional-millionths = 500
@@ -473,10 +506,10 @@ eclair {
         // probability of success, however is penalizes less the paths with a low probability of success.
         use-log-probability = false
 
-        mpp {
-          min-amount-satoshis = 15000 // minimum amount sent via partial HTLCs
-          max-parts = 5 // maximum number of HTLCs sent per payment: increasing this value will impact performance
-        }
+        // When set to false, we assume that the balances of channels are uniformly distributed. That means the
+        // probability that we can send an amount X through a channel of capacity C is 1 - X / C.
+        // When set to true, past payments attempts will be used to compute a better estimate.
+        use-past-relay-data = false
       }
 
       // The path-finding algo uses one or more sets of parameters named experiments. Each experiment has a percentage

eclair-core/pom.xml

@@ -32,7 +32,11 @@ object DBChecker extends Logging {
     Try(nodeParams.db.channels.listLocalChannels()) match {
       case Success(channels) =>
         channels.foreach {
-          case data: ChannelDataWithCommitments if !data.commitments.validateSeed(nodeParams.channelKeyManager) => throw InvalidChannelSeedException(data.channelId)
+          case data: ChannelDataWithCommitments =>
+            val channelKeys = nodeParams.channelKeyManager.channelKeys(data.channelParams.channelConfig, data.channelParams.localParams.fundingKeyPath)
+            if (!data.commitments.validateSeed(channelKeys)) {
+              throw InvalidChannelSeedException(data.channelId)
+            }
           case _ => ()
         }
         channels