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

BOLT #2, #5: derive maximum HTLC limit based on penalty size.

Browse source 
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.

The number is 600, comfortably under the 626 theoretical limit.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-11-15 13:51:09 +10:30
parent 3c612dd229
commit 9b7a2922b1
2 changed files with 30 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
02-peer-protocol.md
View file

@ -106,8 +106,9 @@ immediately included in a block.
The sender SHOULD set `dust-limit-satoshis` to sufficient value to
allow commitment transactions to propagate through the bitcoin
network. It MUST set `max-num-htlcs` to less than or equal to 300
[FIXME:LAOLU recalc?]. It SHOULD set `htlc-minimum-msat` to the minimum
network. It MUST set `max-num-htlcs` to less than or equal to 600
<sup>[BOLT #5](05-onchain.md#penalty-transaction-weight-calculation)</sup>.
It SHOULD set `htlc-minimum-msat` to the minimum
amount HTLC it is willing to accept from this peer.
@ -116,7 +117,7 @@ unreasonably large. The receiver MAY fail the channel if
`funding-satoshis` is too small, and MUST fail the channel if
`push-msat` is greater than `funding-amount` * 1000.
The receiving node MAY fail the channel if it considers
`htlc-minimum-msat` too large, `max-htlc-value-in-flight` too small, `channel-reserve-satoshis` too large, or `max-num-htlcs` too small. It MUST fail the channel if `max-num-htlcs` is greater than 300 [FIXME:LAOLU recalc?]
`htlc-minimum-msat` too large, `max-htlc-value-in-flight` too small, `channel-reserve-satoshis` too large, or `max-num-htlcs` too small. It MUST fail the channel if `max-num-htlcs` is greater than 600.
The receiver MUST fail the channel if

26
05-onchain.md
View file

@ -316,6 +316,32 @@ broadcasts HTLC-timeout and HTLC-success transactions, but the
requirement that we persist until all outputs are irrevocably resolved
should cover this. [FIXME: May have to divide and conquer here, since they may be able to delay us long enough to avoid successful penalty spend? ]
## Penalty Transaction Weight Calculation
As described in [BOLT #3](03-transactions.md), the witness script for
a penalty transaction is:
<sig> 1 { OP_IF <key> OP_ELSE to-self-delay OP_CSV OP_DROP <key> OP_ENDIF OP_CHECKSIG }
Which takes 1 byte to indicate the number of stack elements, plus one
byte for the size of each element (+3), 73 bytes worst-case for
`<sig>` (+73), one byte for the `1` (+1), nine bytes for the script
instructions (+9), 33 bytes for each of the keys (+66), and two bytes
for `to-self-delay` (+2).
This gives 1+3+73+1+9+66+2=155 bytes of witness data, weight 155.
The penalty txinput itself takes 41 bytes, thus has a weight of 164,
meaning each input adds 319 weight.
The rest of the penalty transaction takes 4+3+1+8+1+34+4=55 bytes
assuming it has a pay-to-witness-script-hash (the largest standard
output script), thus a base weight of 220.
With a maximum standard weight of 400000, this means a standard
penalty transaction can have up to 1253 inputs. Thus we could allow
626 HTLCs in each direction (with one output to-self) and still
resolve it with a single penalty transaction.
# General Requirements