Move channel parameters to their own conf section (#2149)

For consistency with existing sections: `router`, `relay`, `peer-connection`, etc.

Author: pm47

eclair-core/src/main/resources/reference.conf

@@ -16,8 +16,6 @@ eclair {
     password = "" // password for basic auth, must be non empty if json-rpc api is enabled
   }
 
-  watch-spent-window = 1 minute // at startup watches will be put back within that window to reduce herd effect; must be > 0s
-
   bitcoind {
     host = "localhost"
     rpcport = 8332
@@ -74,45 +72,49 @@ eclair {
     channel-flags {
       announce-channel = true
     }
-  }
 
-  dust-limit-satoshis = 546
-  max-remote-dust-limit-satoshis = 600
-  htlc-minimum-msat = 1
-  // The following parameters apply to each HTLC direction (incoming or outgoing), which means that the total HTLC limits will be twice what is set here
-  max-htlc-value-in-flight-msat = 5000000000 // 50 mBTC
-  max-accepted-htlcs = 30
-
-  reserve-to-funding-ratio = 0.01 // recommended by BOLT #2
-  max-reserve-to-funding-ratio = 0.05 // channel reserve can't be more than 5% of the funding amount (recommended: 1%)
+    dust-limit-satoshis = 546
+    max-remote-dust-limit-satoshis = 600
+    htlc-minimum-msat = 1
+    // The following parameters apply to each HTLC direction (incoming or outgoing), which means that the total HTLC limits will be twice what is set here
+    max-htlc-value-in-flight-msat = 5000000000 // 50 mBTC
+    max-accepted-htlcs = 30
+
+    reserve-to-funding-ratio = 0.01 // recommended by BOLT #2
+    max-reserve-to-funding-ratio = 0.05 // channel reserve can't be more than 5% of the funding amount (recommended: 1%)
+    min-funding-satoshis = 100000
+    max-funding-satoshis = 16777215 // to open channels larger than 16777215 you must enable the large_channel_support feature in 'eclair.features'
+
+    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)
+    mindepth-blocks = 3
+    expiry-delta-blocks = 144
+    // When we receive the preimage for an HTLC and want to fulfill it but the upstream peer stops responding, we want to
+    // avoid letting its HTLC-timeout transaction become enforceable on-chain (otherwise there is a race condition between
+    // our HTLC-success and their HTLC-timeout).
+    // We will close the channel when the HTLC-timeout will happen in less than this number.
+    // NB: this number effectively reduces the expiry-delta-blocks, so you may want to take that into account and increase
+    // expiry-delta-blocks.
+    fulfill-safety-before-timeout-blocks = 24
+    min-final-expiry-delta-blocks = 30 // Bolt 11 invoice's min_final_cltv_expiry; must be strictly greater than fulfill-safety-before-timeout-blocks
+    max-block-processing-delay = 30 seconds // we add a random delay before processing blocks, capped at this value, to prevent herd effect
+    max-tx-publish-retry-delay = 60 seconds // we add a random delay before retrying failed transaction publication
+
+    // The default strategy, when we encounter an unhandled exception or internal error, is to locally force-close the
+    // channel. Not only is there a delay before the channel balance gets refunded, but if the exception was due to some
+    // misconfiguration or bug in eclair that affects all channels, we risk force-closing all channels.
+    // This is why an alternative behavior is to simply log an error and stop the node. Note that if you don't closely
+    // monitor your node, there is a risk that your peers take advantage of the downtime to try and cheat by publishing a
+    // revoked commitment. Additionally, while there is no known way of triggering an internal error in eclair from the
+    // outside, there may very well be a bug that allows just that, which could be used as a way to remotely stop the node
+    // (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
+  }
 
   balance-check-interval = 1 hour
 
-  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)
-  mindepth-blocks = 3
-  expiry-delta-blocks = 144
-  // When we receive the preimage for an HTLC and want to fulfill it but the upstream peer stops responding, we want to
-  // avoid letting its HTLC-timeout transaction become enforceable on-chain (otherwise there is a race condition between
-  // our HTLC-success and their HTLC-timeout).
-  // We will close the channel when the HTLC-timeout will happen in less than this number.
-  // NB: this number effectively reduces the expiry-delta-blocks, so you may want to take that into account and increase
-  // expiry-delta-blocks.
-  fulfill-safety-before-timeout-blocks = 24
-  min-final-expiry-delta-blocks = 30 // Bolt 11 invoice's min_final_cltv_expiry; must be strictly greater than fulfill-safety-before-timeout-blocks
-  max-block-processing-delay = 30 seconds // we add a random delay before processing blocks, capped at this value, to prevent herd effect
-  max-tx-publish-retry-delay = 60 seconds // we add a random delay before retrying failed transaction publication
-
-  // The default strategy, when we encounter an unhandled exception or internal error, is to locally force-close the
-  // channel. Not only is there a delay before the channel balance gets refunded, but if the exception was due to some
-  // misconfiguration or bug in eclair that affects all channels, we risk force-closing all channels.
-  // This is why an alternative behavior is to simply log an error and stop the node. Note that if you don't closely
-  // monitor your node, there is a risk that your peers take advantage of the downtime to try and cheat by publishing a
-  // revoked commitment. Additionally, while there is no known way of triggering an internal error in eclair from the
-  // outside, there may very well be a bug that allows just that, which could be used as a way to remotely stop the node
-  // (with the default behavior, it would "only" cause a local force-close of the channel).
-  unhandled-exception-strategy = "local-close" // local-close or stop
-
   relay {
     fees {
       // Fees for public channels
@@ -197,8 +199,6 @@ eclair {
     update-fee-min-diff-ratio = 0.1
   }
 
-  revocation-timeout = 20 seconds // after sending a commit_sig, we will wait for at most that duration before disconnecting
-
   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
@@ -213,13 +213,13 @@ eclair {
 
   payment-request-expiry = 1 hour // default expiry for payment requests generated by this node
   multi-part-payment-expiry = 60 seconds // default expiry for receiving all parts of a multi-part payment
-  min-funding-satoshis = 100000
-  max-funding-satoshis = 16777215 // to open channels larger than 16777215 you must enable the large_channel_support feature in 'eclair.features'
   max-payment-attempts = 5
 
   autoprobe-count = 0 // number of parallel tasks that send test payments to detect invalid channels
 
   router {
+    watch-spent-window = 1 minute // at startup watches will be put back within that window to reduce herd effect; must be > 0s
+
     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
     init-timeout = 5 minutes