minor: fixed hierarchy and added a table of content #7

pm47 · 2016-11-16T18:50:38Z

I spotted some inconsistencies in naming between channel establishment and channel closing.

I'd like to do:

shutdown -> close_channel
close_signature -> closing_signed

what do you think?

Roasbeef

Your suggested renaming SGTM. Curious to see what the others think!

Roasbeef · 2016-11-17T00:13:02Z

02-peer-protocol.md

-
-FIXME
-
+  * [Channel](#channel)


Nice addition with the table of contents! 👍

Hmm, there's shutdown, which is where we don't add anything new, and closing, which is where we're negotiation the final close tx. I used to call shutdown "clearing" but that has a specific finance meaning which was deeply sucky.

Ah, I see you reverted that AFAICT? I'll squash and merge.

Ah, I see you reverted that AFAICT? I'll squash and merge.

Yeah, I didn't want to mix two separate topics in the same PR. I am just OCDing on funding_signed vs close_signature 😵

…g-rfc into patch-2

rustyrussell · 2016-11-18T03:34:08Z

Squashed into three patches, and merged. Thanks!

Contents stolen from Christian's draft. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell · 2016-11-21T06:22:40Z

Pierre-Marie Padiou notifications@github.com writes:

pm47 commented on this pull request.

@@ -11,9 +11,25 @@ The messages described in this document are grouped logically into 4 groups by t

Routing (types 256-511): node and channel announcements, as well as any active route exploration.

# Table of Contents

-FIXME

* Channel

Ah, I see you reverted that AFAICT? I'll squash and merge.

Yeah, I didn't want to mix two separate topics in the same PR. I am just OCDing on funding_signed vs close_signature 😵

Agreed. Pick one to change and submit another PR :)

Thanks!
Rusty.

BOLT #7: More complex proposal, using three separate message types.

This commit modifies the “Normal Operation” summarization by including a link to BOLT #7 when mentioning the `announcement_signature` message. Previously a reader would need to search other documents to figure out what an `announcement_signature` was, and its purpose.

This commit modifies the glossary to add a new entry which defines the usage of `chain_hash` throughout the remainder of the documents. Additionally, we now also specify which chain hash we expect for Bitcoin within the glossary. This commit also modifies BOLT #2 and #7 to omit the definition of the expected `chain_hash` value for Bitcoin.

Fixed warnings: .copy-edit-stylesheet-checklist.md: 49: MD030/list-marker-space Spaces after list markers [Expected: 1; Actual: 0] .copy-edit-stylesheet-checklist.md: 1: MD041/first-line-h1 First line in file should be a top level header [Context: "Basic checklist/stylesheet use..."] 02-peer-protocol.md: 161: MD018/no-missing-space-atx No space after hash on atx style header [Context: "#7](07-routing-gossip.md#bolt-..."]

…ement/channel_update/node_announcement. This makes discussing them simpler for the next patch. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@sstone

Suggested-by: @sstone Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…ement/channel_update/node_announcement. This makes discussing them simpler for the next patch. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@sstone

Suggested-by: @sstone Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…ement/channel_update/node_announcement. This makes discussing them simpler for the next patch. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@Roasbeef

Reported-by: @Roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@Roasbeef

Reported-by: @Roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…r channel_update message While going through the BOLT lightning#7 I was confused by this receiving node requirement for `channel_update` message: "if the `timestamp` is equal to the last-received `channel_update` AND the fields (other than `signature`) differ: MAY blacklist this `node_id`; MAY forget all channels associated with it." On the outset it might read to "`timestamp` should be same, the `signature` should be same as previous but if the other data is different; then blacklist the `node_id`". However, if `signature` is same as previous update but data is different, then the `signature` would be rendered invalid. And since `signature` check is done prior to the `timestamp` check, this situation of checking may not arise. So this check seems to be redundant. However, Mark H corrected me on stackexchange (https://bitcoin.stackexchange.com/questions/88350/bolt-7-can-receiving-node-requirements-in-channel-update-message-give-rise-to) by saying that a valid signature must be provided for this update and timestamp to go through. This pull request corrects the language behind this check. While creating this pull request, I also noticed a slight typo in the same section. The sentence prior to the one I mentioned above says that if the timestamp is not greater than the previous message, the node should ignore the message. And the second sentence is about comparing if timestamp is equal. But again, this check might not be processed as the message will be discarded if it is not greater. I have changed that to "greater than or equal to".

While going through the BOLT lightning#7 I was confused by this receiving node requirement for `channel_update` message: "if the `timestamp` is equal to the last-received `channel_update` AND the fields (other than `signature`) differ: MAY blacklist this `node_id`; MAY forget all channels associated with it." On the outset it might read to "`timestamp` should be same, the `signature` should be same as previous but if the other data is different; then blacklist the `node_id`". However, if `signature` is same as previous update but data is different, then the `signature` would be rendered invalid. And since `signature` check is done prior to the `timestamp` check, this situation of checking may not arise. So this check seems to be redundant. However, Mark H corrected me on stackexchange (https://bitcoin.stackexchange.com/questions/88350/bolt-7-can-receiving-node-requirements-in-channel-update-message-give-rise-to) by saying that a valid signature must be provided for this update and timestamp to go through. This pull request corrects the language behind this check. While creating this pull request, I also noticed a slight typo in the same section. The sentence prior to the one I mentioned above says that if the timestamp is not greater than the previous message, the node should ignore the message. And the second sentence is about comparing if timestamp is equal. But again, this check might not be processed as the message will be discarded if it is not greater. I have changed that to "greater than or equal to".

…or channel_update message While going through the BOLT lightning#7 I was confused by this receiving node requirement for `channel_update` message: "if the `timestamp` is equal to the last-received `channel_update` AND the fields (other than `signature`) differ: MAY blacklist this `node_id`; MAY forget all channels associated with it." On the outset it might read to "`timestamp` should be same, the `signature` should be same as previous but if the other data is different; then blacklist the `node_id`". However, if `signature` is same as previous update but data is different, then the `signature` would be rendered invalid. And since `signature` check is done prior to the `timestamp` check, this situation of checking may not arise. So this check seems to be redundant. However, Mark H corrected me on stackexchange (https://bitcoin.stackexchange.com/questions/88350/bolt-7-can-receiving-node-requirements-in-channel-update-message-give-rise-to) by saying that a valid signature must be provided for this update and timestamp to go through. This pull slightly corrects the language behind this check and adds a paragraph in the rationale to explain that point. While creating this pull request, I also noticed a slight typo in the same section. The sentence prior to the one I mentioned above says that if the timestamp is not greater than the previous message, the node should ignore the message. And the second sentence is about comparing if timestamp is equal. But again, the equal to check might not be processed as the message will be discarded if it is not greater. I have changed that to "greater than or equal to".

BOLT lightning#7 : Receiving node requirements related to timestamp for channel_update message

…_update message (#621) Clarify timestamp requirements for channel_update messages.

Related to pull lightning#621 Corrected the indentation in the otherwise section in the `timestamp` check of the `channel_update` message. Both the if appeared at the same level of otherwise.

'three gossip messages' should refer to node and channel discovery messages, not just channel discovery messages.

The introductory paragraph describes node discovery and channel discovery, but changes the ordering. Keep the same ordering throughout the paragraph for readability.

'three gossip messages' should refer to node and channel discovery messages, not just channel discovery messages.

The introductory paragraph describes node discovery and channel discovery, but changes the ordering. Keep the same ordering throughout the paragraph for readability.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@t-bast

Suggested-by: @t-bast Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pm47 added 5 commits November 16, 2016 19:24

Update 02-peer-protocol.md

8cfb189

Update 02-peer-protocol.md

7259b8d

added ToC

21656c9

fixed paragraph hierarchy

a7d8989

reverted close_signature->closing_signed

1e9f5cd

Roasbeef reviewed Nov 17, 2016

View reviewed changes

pm47 and others added 2 commits November 17, 2016 11:41

fixed toc

0c35d91

Merge branch 'master' of https://github.com/lightningnetwork/lightnin…

ee986d1

…g-rfc into patch-2

rustyrussell closed this Nov 18, 2016

pm47 deleted the patch-2 branch November 18, 2016 09:26

rustyrussell referenced this pull request in rustyrussell/bolts Nov 21, 2016

BOLT #7: More complex proposal, using three separate message types.

2e93a41

Contents stolen from Christian's draft. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

pm47 mentioned this pull request Nov 21, 2016

minor: close_signature -> closing_signed #12

Merged

BitfuryLightning added a commit that referenced this pull request Nov 22, 2016

Merge pull request #11 from rustyrussell/more-complex-gossip

25db643

BOLT #7: More complex proposal, using three separate message types.

rustyrussell mentioned this pull request Aug 21, 2017

Route discovery? #222

Closed

shannona mentioned this pull request Dec 8, 2017

BOLT 7,8,11: Add table-of-contents #310

Closed

rustyrussell referenced this pull request in rustyrussell/bolts Mar 20, 2018

BOLT #7: rename gossip_timestamp_range to gossip_timestamp_filter.

5712125

Suggested-by: @sstone Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell referenced this pull request in rustyrussell/bolts Jun 18, 2018

BOLT #7: rename gossip_timestamp_range to gossip_timestamp_filter.

e9b07c5

Suggested-by: @sstone Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell referenced this pull request in rustyrussell/bolts Nov 20, 2018

BOLT #7: don't accidentially wumbo the channel_update.

347c9f4

Reported-by: @Roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell added a commit that referenced this pull request Nov 29, 2018

BOLT #7: don't accidentially wumbo the channel_update.

4c12ae8

Reported-by: @Roasbeef Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

fjahr pushed a commit to fjahr/lightning-mw that referenced this pull request Dec 25, 2018

BMW lightning#7: Edit for MW context

08fdc30

This was referenced Jun 16, 2019

BOLT #7 : Receiving node requirements related to timestamp for channel_update message ugamkamat/lightning-rfc#1

Merged

BOLT #7: receiving node requirements related to timestamp for channel_update message #621

Merged

ugamkamat added a commit to ugamkamat/lightning-rfc that referenced this pull request Jun 16, 2019

Merge pull request #1 from ugamkamat/ugamkamat-patch-2

4c422ce

BOLT lightning#7 : Receiving node requirements related to timestamp for channel_update message

t-bast pushed a commit that referenced this pull request Jul 16, 2019

BOLT #7: receiving node requirements related to timestamp for channel…

1db481f

…_update message (#621) Clarify timestamp requirements for channel_update messages.

t-bast pushed a commit that referenced this pull request Jul 23, 2019

BOLT #7: Correct indentation typo in channel_update message (#649)

1810eaf

jnewbery added a commit to jnewbery/lightning-rfc that referenced this pull request Mar 24, 2020

Bolt lightning#7: Update introduction text

ba0040b

'three gossip messages' should refer to node and channel discovery messages, not just channel discovery messages.

cdecker pushed a commit that referenced this pull request May 11, 2020

Bolt #7: Update introduction text

f49fb44

'three gossip messages' should refer to node and channel discovery messages, not just channel discovery messages.

rustyrussell added a commit that referenced this pull request May 31, 2022

BOLT #7: Make channel_update always have htlc_maximum_msat.

466317a

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rustyrussell added a commit that referenced this pull request Jun 1, 2022

BOLT #7: rename message_flags to must_be_one.

f99b549

Suggested-by: @t-bast Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

ifuensan added a commit to ifuensan/bolts that referenced this pull request May 9, 2023

BOLT lightning#7: Corregidos los saltos de líneas

fe959ca

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

minor: fixed hierarchy and added a table of content #7

minor: fixed hierarchy and added a table of content #7

pm47 commented Nov 16, 2016

Roasbeef left a comment

Roasbeef Nov 17, 2016

rustyrussell Nov 18, 2016

pm47 Nov 18, 2016

rustyrussell commented Nov 18, 2016

rustyrussell commented Nov 21, 2016

# Table of Contents

-FIXME


		FIXME

		* [Channel](#channel)

minor: fixed hierarchy and added a table of content #7

minor: fixed hierarchy and added a table of content #7

Conversation

pm47 commented Nov 16, 2016

Roasbeef left a comment

Choose a reason for hiding this comment

Roasbeef Nov 17, 2016

Choose a reason for hiding this comment

rustyrussell Nov 18, 2016

Choose a reason for hiding this comment

pm47 Nov 18, 2016

Choose a reason for hiding this comment

rustyrussell commented Nov 18, 2016

rustyrussell commented Nov 21, 2016

# Table of Contents

-FIXME