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

BOLT 2, BOLT 5: restrict to ASCII characters.

Browse source 
’ -> '

LANG=C python3 complains otherwise.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-01-25 10:40:10 +10:30
parent de8be3072d
commit 40b747806e
2 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
02-peer-protocol.md
View file

@ -95,7 +95,7 @@ desire to set up a new channel.
* [33:first-per-commitment-point] * [33:first-per-commitment-point]
The `temporary-channel-id` is used to identify this channel until the funding transaction is established. `funding-satoshis` is the amount the sender is putting into the channel. `dust-limit-satoshis` is the threshold below which output should be generated for this node’s commitment or HTLC transaction; ie. 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. The `temporary-channel-id` is used to identify this channel until the funding transaction is established. `funding-satoshis` is the amount the sender is putting into the channel. `dust-limit-satoshis` is the threshold below which output should be generated for this node's commitment or HTLC transaction; ie. 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.
`max-htlc-value-in-inflight-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. `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. `max-htlc-value-in-inflight-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. `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.
@ -356,7 +356,7 @@ and indicating the scriptpubkey it wants to be paid to.
#### Requirements #### Requirements
A node MUST NOT send a `shutdown` if there are updates pending A node MUST NOT send a `shutdown` if there are updates pending
on the receiving node's commitment transaction which are not yet added to the sender’s commitment. on the receiving node's commitment transaction which are not yet added to the sender's commitment.
A node MUST NOT send an `update_add_htlc` after a `shutdown`, A node MUST NOT send an `update_add_htlc` after a `shutdown`,
and MUST NOT send more than one `shutdown`. A sending node and MUST NOT send more than one `shutdown`. A sending node

2
05-onchain.md
View file

@ -290,7 +290,7 @@ A node MUST resolve all unresolved outputs as follows:
This output is considered *resolved* by the *commitment transaction*. This output is considered *resolved* by the *commitment transaction*.
2. _B's main output_: The node MUST *resolve* this by spending using the 2. _B's main output_: The node MUST *resolve* this by spending using the
revocation key. revocation key.
3. _A's offered HTLCs_: The node MUST *resolve* this in one of two ways: either by spending using the payment preimage if known, or spending using B’s HTLC-timeout transaction. 3. _A's offered HTLCs_: The node MUST *resolve* this in one of two ways: either by spending using the payment preimage if known, or spending using B's HTLC-timeout transaction.
4. _B's offered HTLCs_: The node MUST *resolve* this by spending once the HTLC timeout has passed. 4. _B's offered HTLCs_: The node MUST *resolve* this by spending once the HTLC timeout has passed.
5. _B's HTLC-timeout transaction_: The node MUST *resolve* this by 5. _B's HTLC-timeout transaction_: The node MUST *resolve* this by
spending using the revocation key. spending using the revocation key.