From 1e48543ff142341f9e6fbae4a2f77e86602a9124 Mon Sep 17 00:00:00 2001 From: t-bast Date: Fri, 10 Feb 2023 10:59:02 +0100 Subject: [PATCH] Add section about liquidity griefing This issue is non-trivial and worth mentioning, otherwise implementations may forget to handle this which would result in an easy way of attacking node's on-chain liquidity, creating a large opportunity cost. --- .aspell.en.pws | 1 + 02-peer-protocol.md | 24 ++++++++++++++++++++++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/.aspell.en.pws b/.aspell.en.pws index a4d459d..6744cc2 100644 --- a/.aspell.en.pws +++ b/.aspell.en.pws @@ -424,3 +424,4 @@ prevtx ints replaceability disincentivize +UTXOs diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 6977475..58941b3 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -211,7 +211,6 @@ The sending node: - MUST send even `serial_id`s - if is the *non-initiator*: - MUST send odd `serial_id`s - - MUST provide a best estimate for the weight of the witness for this input The receiving node: - MUST add all received inputs to the transaction @@ -243,6 +242,28 @@ this input spends. Used to verify that the input is non-malleable. replaceability, and the same value should be used across implementations to avoid on-chain fingerprinting. +#### Liquidity griefing + +When sending `tx_add_input`, senders have no guarantee that the remote node +will complete the protocol in a timely manner. Malicious remote nodes could +delay messages or stop responding, which can result in a partially created +transaction that cannot be broadcast by the honest node. If the honest node +is locking the corresponding UTXO exclusively for this remote node, this can +be exploited to lock up the honest node's liquidity. + +It is thus recommended that implementations keep UTXOs unlocked and actively +reuse them in concurrent sessions, which guarantees that transactions created +with honest nodes double-spend pending transactions with malicious nodes at +no additional cost for the honest node. + +Unfortunately, this will also create conflicts between concurrent sessions +with honest nodes. This is a reasonable trade-off though because: + +* on-chain funding attempts are relatively infrequent operations +* honest nodes should complete the protocol quickly, reducing the risk of + conflicts +* failed attempts can simply be retried at no cost + ### The `tx_add_output` Message This message adds a transaction output. @@ -539,7 +560,6 @@ Echoing back `tx_abort` allows the peer to ack that they've seen the abort messa permitting the originating peer to terminate the in-flight process without worrying about stale messages. - ## Channel Establishment v1 After authenticating and initializing a connection ([BOLT #8](08-transport.md)