mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 01:50:03 +01:00
stylesheet update and apply to BOLT 2,3
This commit is contained in:
parent
d600f07163
commit
641c6ab7b1
@ -9,6 +9,7 @@ temporarily included here for reference purposes.
|
||||
- dangling, misplaced modifiers
|
||||
- consistent paragraph tense (e.g. past, present, future)
|
||||
- passive voice (e.g. avoid 'we')
|
||||
- use 'local/remote' terminology rather than 'us/them' or 'we/they'
|
||||
- exception: `Introduction` section
|
||||
- capitalization
|
||||
- table of contents
|
||||
|
@ -110,7 +110,7 @@ across many distinct blockchains as well as have channels within multiple
|
||||
blockchains opened to the same peer (if it supports the target chains).
|
||||
|
||||
The `temporary_channel_id` is used to identify this channel until the
|
||||
funding transaction is established.
|
||||
funding transaction is established.
|
||||
|
||||
`funding_satoshis` is the amount the sender is putting into the
|
||||
channel. `push_msat` is an amount of initial funds that the sender is
|
||||
@ -119,7 +119,7 @@ threshold below which outputs should not be generated for this node's
|
||||
commitment or HTLC transactions (i.e. HTLCs below this amount plus
|
||||
HTLC transaction fees are not enforceable on-chain). This reflects the
|
||||
reality that tiny outputs are not considered standard transactions and
|
||||
will not propagate through the Bitcoin network. `channel_reserve_satoshis`
|
||||
will not propagate through the Bitcoin network. `channel_reserve_satoshis`
|
||||
is the minimum amount that the other node is to keep as a direct
|
||||
payment. `htlc_minimum_msat` indicates the smallest value HTLC this
|
||||
node will accept.
|
||||
@ -127,13 +127,13 @@ node will accept.
|
||||
`max_htlc_value_in_flight_msat` is a cap on total value of outstanding
|
||||
HTLCs, which allows a node to limit its exposure to HTLCs; similarly,
|
||||
`max_accepted_htlcs` limits the number of outstanding HTLCs the other
|
||||
node can offer.
|
||||
node can offer.
|
||||
|
||||
`feerate_per_kw` indicates the initial fee rate by 1000-weight
|
||||
(i.e. 1/4 the more normally-used 'fee rate per kilobyte') that this
|
||||
side will pay for commitment and HTLC transactions, as described in
|
||||
[BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted
|
||||
later with an `update_fee` message).
|
||||
later with an `update_fee` message).
|
||||
|
||||
`to_self_delay` is the number of blocks that the other node's to-self
|
||||
outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this
|
||||
@ -775,7 +775,7 @@ Invalid amounts are a clear protocol violation and indicate a breakdown.
|
||||
|
||||
If a node did not accept multiple HTLCs with the same payment hash, an
|
||||
attacker could probe to see if a node had an existing HTLC. This
|
||||
requirement, to deal with duplicates, leads us to use a separate
|
||||
requirement, to deal with duplicates, leads to the use of a separate
|
||||
identifier; its assumed a 64-bit counter never wraps.
|
||||
|
||||
Retransmissions of unacknowledged updates are explicitly allowed for
|
||||
|
@ -304,7 +304,7 @@ Thus, a simplified formula for *expected weight* is used, which assumes:
|
||||
* There are a small number of outputs (thus 1 byte to count them).
|
||||
* There are always both a `to_local` output and a `to_remote` output.
|
||||
|
||||
This gives us the following *expected weights* (details of the computation in [Appendix A](#appendix-a-expected-weights)):
|
||||
This yields the following *expected weights* (details of the computation in [Appendix A](#appendix-a-expected-weights)):
|
||||
|
||||
Commitment weight: 724 + 172 * num-untrimmed-htlc-outputs
|
||||
HTLC-timeout weight: 663
|
||||
@ -518,9 +518,9 @@ In binary, it's helpful to think of any index in terms of a *prefix*,
|
||||
followed by some trailing 0s. You can derive the secret for any
|
||||
index which matches this *prefix*.
|
||||
|
||||
For example, secret `0xFFFFFFFFFFF0` allows us to derive secrets for
|
||||
`0xFFFFFFFFFFF1` through `0xFFFFFFFFFFFF` inclusive. Secret `0xFFFFFFFFFF08`
|
||||
allows us to derive secrets `0xFFFFFFFFFF09` through `0xFFFFFFFFFF0F`
|
||||
For example, secret `0xFFFFFFFFFFF0` allows the secrets to be derived for
|
||||
`0xFFFFFFFFFFF1` through `0xFFFFFFFFFFFF`, inclusive; and secret `0xFFFFFFFFFF08`
|
||||
allows the secrets to be derive for `0xFFFFFFFFFF09` through `0xFFFFFFFFFF0F`,
|
||||
inclusive.
|
||||
|
||||
This is done using a slight generalization of `generate_from_seed` above:
|
||||
|
Loading…
Reference in New Issue
Block a user