Reply channel range simplification #737
Conversation
…onale This was confusing: the flag name made implementers *think* they knew what it was for. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The current loose constraints causes confusion (and now all major implementations meet the stricter requirements anyway). You are allowed to provide more blocks than requested, but you have to be complete and in order, and each reply has to have some overlap with the requested range. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
force-pushed
the
reply_channel_range-simplification
branch
from
a769e08
to
c950d4e
Compare
|
@wpaulino could you take a look at this? And share your thoughts on the fact that this PR disallows splitting a block's content over two replies? |
There was a problem hiding this comment.
@wpaulino could you take a look at this? And share your thoughts on the fact that this PR disallows splitting a block's content over two replies?
I agree with @rustyrussell that we can't detect the last reply properly if we allow overlapping heights. There may be a future where the number of channels created in a block exceed the size of a single uncompressed reply message, but we also have the compressed option which is more than enough.
| - SHOULD set `complete` to 1. | ||
| - SHOULD set `full_information` to 1. | ||
| - the first `reply_channel_range` message: | ||
| - MUST set `first_blocknum` less than or equal to the `first_blocknum` in `query_channel_range` |
There was a problem hiding this comment.
I believe the rationale between this "less than or equal" is to allow pre-generated responses that may start a few blocks before the first_blocknum.
Imagine for example that blocks 3, 4, 5 and 6 fit in a pre-generated response. If you ask for first_blocknum = 5 instead of generating a response that matches exactly that, I can give you my pre-generated response that contains blocks 3, 4, 5 and 6 and save some computing power. And you have the results you wanted so you should be happy with that.
This is extra flexibility that doesn't cost much, so it's worth having IMHO.
|
Merging as agreed during yesterday's meeting: http://www.erisian.com.au/meetbot/lightning-dev/2020/lightning-dev.2020-03-30-19.06.log.html |
First a trivial renaming of the confusing
completefield.Then, we insist that query_channel_range replies be in order (everyone now does this anyway) and non-overlapping (ditto: c-lightning had strict enforcement on this, which was overzealous but means everyone now does it that way). Currently c-lightning maintains a bitmap for every block it requested, but it's much simpler to assume ordered replies, and simply check if we received the final one.