Test threadpool

.github/workflows/latest-bitcoind.yml

@@ -1,10 +1,10 @@
 name: Latest Bitcoin Core
 
 on:
-  workflow_dispatch: # Build can be triggered manually from github.com
-  schedule:
-    # Run at midnight on Sunday and Wednesday.
-    - cron: '0 0 * * 0,3'
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
 
 permissions:
   contents: read
@@ -18,11 +18,12 @@ jobs:
       - name: Checkout bitcoind master
         uses: actions/checkout@v3
         with:
-          repository: bitcoin/bitcoin
+          repository: furszy/bitcoin-core
+          ref: 2025_threadpool_http_server
           path: bitcoin
 
       - name: Install bitcoind dependencies
-        run: sudo apt-get install build-essential cmake pkg-config bsdmainutils python3 libevent-dev libboost-dev libminiupnpc-dev libnatpmp-dev libzmq3-dev libsqlite3-dev systemtap-sdt-dev
+        run: sudo apt-get install build-essential cmake pkg-config bsdmainutils python3 libevent-dev libboost-dev libminiupnpc-dev libnatpmp-dev libzmq3-dev libsqlite3-dev systemtap-sdt-dev libcapnp-dev capnproto
         working-directory: ./bitcoin
 
       - name: Init and configure cmake build
@@ -48,5 +49,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

.github/workflows/main.yml

@@ -1,10 +1,6 @@
 name: Build & Test
 
 on:
-  push:
-    branches: [ master ]
-  pull_request:
-    branches: [ master ]
 
 jobs:
 

.mvn/maven.config

@@ -6,3 +6,5 @@
 -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

BUILD.md

@@ -94,6 +94,6 @@ To make local development and testing easier, SNAPSHOT dependencies are not veri
 To re-create the trusted checksums file, run:
 
 ```shell
-$ rm ~/.m2/wrapper ~/.sbt -rf
+$ rm -Rf ~/.m2/wrapper ~/.sbt
 $ ./mvnw clean install -DskipTests -Daether.artifactResolver.postProcessor.trustedChecksums.record
 ```

README.md

@@ -62,7 +62,7 @@ This means that instead of re-implementing them, Eclair benefits from the verifi
 
 * Eclair needs a _synchronized_, _segwit-ready_, **_zeromq-enabled_**, _wallet-enabled_, _non-pruning_, _tx-indexing_ [Bitcoin Core](https://github.com/bitcoin/bitcoin) node.
 * You must configure your Bitcoin node to use `bech32` or `bech32m` (segwit) addresses. If your wallet has "non-segwit UTXOs" (outputs that are neither `p2sh-segwit`, `bech32` or `bech32m`), you must send them to a `bech32` or `bech32m` address before running Eclair.
-* Eclair requires Bitcoin Core 28.1 or higher. If you are upgrading an existing wallet, you may need to create a new address and send all your funds to that address.
+* Eclair requires Bitcoin Core 29 or higher. If you are upgrading an existing wallet, you may need to create a new address and send all your funds to that address.
 
 Run bitcoind with the following minimal `bitcoin.conf`:
 
@@ -71,8 +71,8 @@ server=1
 rpcuser=foo
 rpcpassword=bar
 txindex=1
-addresstype=bech32
-changetype=bech32
+addresstype=bech32m
+changetype=bech32m
 zmqpubhashblock=tcp://127.0.0.1:29000
 zmqpubrawtx=tcp://127.0.0.1:29000
 ```
@@ -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,

docs/Configure.md

@@ -261,32 +261,16 @@ eclair {
     path-finding {
       experiments {
         control = ${eclair.router.path-finding.default} {
-          percentage = 50
-        }
-
-        // alternative routing heuristics (replaces ratios)
-        test-failure-cost = ${eclair.router.path-finding.default} {
-          use-ratios = false
-
-          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
-          // Corresponds to how much you are willing to pay to get one less failed payment attempt
-          failure-cost {
-            fee-base-msat = 2000
-            fee-proportional-millionths = 500
-          }
-          percentage = 10
+          percentage = 70
         }
 
         // To optimize for fees only:
         test-fees-only = ${eclair.router.path-finding.default} {
-          ratios {
-            base = 1
-            cltv = 0
-            channel-age = 0
-            channel-capacity = 0
+          // By setting everything to zero, only fees will be taken into account.
+          locked-funds-risk = 0
+          failure-cost {
+            fee-base-msat = 0
+            fee-proportional-millionths = 0
           }
           hop-cost {
             fee-base-msat = 0
@@ -297,12 +281,6 @@ eclair {
 
         // To optimize for shorter paths:
         test-short-paths = ${eclair.router.path-finding.default} {
-          ratios {
-            base = 1
-            cltv = 0
-            channel-age = 0
-            channel-capacity = 0
-          }
           hop-cost {
             // High hop cost penalizes strongly longer paths
             fee-base-msat = 10000
@@ -313,30 +291,8 @@ eclair {
 
         // To optimize for successful payments:
         test-pay-safe = ${eclair.router.path-finding.default} {
-          ratios {
-            base = 0
-            cltv = 0
-            channel-age = 0.5 // Old channels should have less risk of failures
-            channel-capacity = 0.5 // High capacity channels are more likely to have enough liquidity to relay our payment
-          }
-          hop-cost {
-            // Less hops means less chances of failures
-            fee-base-msat = 1000
-            fee-proportional-millionths = 1000
-          }
-          percentage = 10
-        }
-
-        // To optimize for fast payments:
-        test-pay-fast = ${eclair.router.path-finding.default} {
-          ratios {
-            base = 0.2
-            cltv = 0.5 // In case of failure we want our funds back as fast as possible
-            channel-age = 0.3 // Older channels are more likely to run smoothly
-            channel-capacity = 0
-          }
-          hop-cost {
-            // Shorter paths should be faster
+          failure-cost {
+            // High failure cost will penalize paths that are less likely to succeed.
             fee-base-msat = 10000
             fee-proportional-millionths = 10000
           }

docs/FAQ.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.