mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-09 15:52:43 +01:00
Code Issues Projects Releases Wiki Activity

Add section about liquidity griefing

Browse source 
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.
This commit is contained in:
t-bast 2023-02-10 10:59:02 +01:00 • committed by neil saitug
parent 03a0eab139
commit 1e48543ff1
2 changed files with 23 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.aspell.en.pws
View file

@ -424,3 +424,4 @@ prevtx
ints
replaceability
disincentivize
UTXOs

24
02-peer-protocol.md
View file

@ -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)