aljaz/lightning
1
0
Fork 0
mirror of https://github.com/aljazceru/lightning.git synced 2025-12-19 23:24:27 +01:00
Code Issues Packages Projects Releases Wiki Activity

bcli: become less aggressive with onchain fee levels.

Browse Source 
Users are more upset recently with the cost of unilateral closes
than they are the risk of being cheated.  While we complete our
anchor implementation so we can use low fees there, let's
get less aggressive (we already have 34 or 18 blocks to close
in the worst case).

The changes are:

- Commit transactions were "2 CONSERVATIVE" now "6 ECONOMICAL".
- HTLC resolution txs were "3 CONSERVATIVE" now "6 ECONOMICAL".
- Penalty txs were "3 CONSERVATIVE" now "12 ECONOMICAL".
- Normal txs were "4 ECONOMICAL" now "12 ECONOMICAL".

There can be no perfect levels, but we have had understandable
complaints recently about how high our default fee levels are.

Changelog-Changed: Protocol: channel feerates reduced to bitcoind's "6 block ECONOMICAL" rate.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
2021-05-04 20:06:11 +09:30
parent 9a22e7b3a1
commit d8e68893f5
6 changed files with 29 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
plugins/bcli.c
View File

@@ -410,7 +410,7 @@ static struct command_result *process_getblockchaininfo(struct bitcoin_cli *bcli
}
enum feerate_levels {
FEERATE_VERY_URGENT,
FEERATE_HIGHEST,
FEERATE_URGENT,
FEERATE_NORMAL,
FEERATE_SLOW,
@@ -604,19 +604,15 @@ static struct command_result *getchaininfo(struct command *cmd,
/* Mutual recursion. */
static struct command_result *estimatefees_done(struct bitcoin_cli *bcli);
/*
* Calls `estimatesmartfee` with targets 2/CONSERVATIVE (very urgent),
* 3/CONSERVATIVE (urgent), 4/ECONOMICAL (normal), and 100/ECONOMICAL (slow)
*/
struct estimatefee_params {
u32 blocks;
const char *style;
};
static const struct estimatefee_params estimatefee_params[] = {
[FEERATE_VERY_URGENT] = { 2, "CONSERVATIVE" },
[FEERATE_URGENT] = { 3, "CONSERVATIVE" },
[FEERATE_NORMAL] = { 4, "ECONOMICAL" },
[FEERATE_HIGHEST] = { 2, "CONSERVATIVE" },
[FEERATE_URGENT] = { 6, "ECONOMICAL" },
[FEERATE_NORMAL] = { 12, "ECONOMICAL" },
[FEERATE_SLOW] = { 100, "ECONOMICAL" },
};
@@ -640,10 +636,10 @@ static struct command_result *estimatefees_next(struct command *cmd,
json_add_u64(response, "opening", stash->perkb[FEERATE_NORMAL]);
json_add_u64(response, "mutual_close", stash->perkb[FEERATE_SLOW]);
json_add_u64(response, "unilateral_close",
stash->perkb[FEERATE_VERY_URGENT] * bitcoind->commit_fee_percent / 100);
stash->perkb[FEERATE_URGENT] * bitcoind->commit_fee_percent / 100);
json_add_u64(response, "delayed_to_us", stash->perkb[FEERATE_NORMAL]);
json_add_u64(response, "htlc_resolution", stash->perkb[FEERATE_URGENT]);
json_add_u64(response, "penalty", stash->perkb[FEERATE_URGENT]);
json_add_u64(response, "penalty", stash->perkb[FEERATE_NORMAL]);
/* We divide the slow feerate for the minimum acceptable, lightningd
* will use floor if it's hit, though. */
json_add_u64(response, "min_acceptable",
@@ -655,7 +651,7 @@ static struct command_result *estimatefees_next(struct command *cmd,
* margin (say 5x the expected fee requirement)
*/
json_add_u64(response, "max_acceptable",
stash->perkb[FEERATE_VERY_URGENT]
stash->perkb[FEERATE_HIGHEST]
* bitcoind->max_fee_multiplier);
return command_finished(cmd, response);
}