peer: always send latest block header as part of ping messages #5621
Conversation
|
what do you do if you find out you are behind for significant time? call addpeer? |
|
bitcoind has stale block detect logic, and will connect out to Peers if stale. I'm not sure how this could be used with bitcoind -- not sure that you can feed it headers. I like extra headers relay sources but not sure how this can be used atm |
Just added another commit to expose it over the call to We can also use this new return value to write an integration test on our end tighten things up a bit. Def some more work needed on a higher level, but this is an easy win to get the ball rolling. One other enhancement here would be to always send back our current header in the pong message as well. |
There was a problem hiding this comment.
Cool PR! Really enjoyed diving into the chainntfns package a bit!
Left some spec related questions.
Also, similar to @Crypt-iQ's question: would this purely be for application (or neutrino) logic? ie, Should LND ever react in a certain way if it sees that it's peers are getting blocks that it itself isnt?
rn, it's setup mainly for interpretation by a higher level application/system, the first step is just to make the data available before attempting to act on it in an automated fashion. |
Roasbeef
force-pushed
the
ping-pong-headers
branch
from
516c334 to
bfc87fb
Compare
In this commit, we implement a long discussed mechanism to use the Lightning Network as a redundant block header source. By sending our latest block header with each ping message, we give peers another source (outside of the Bitcoin P2P network) they can use to spot check their chain state. Peers can also use this information to detect if they've been eclipsed from the traditional Bitcoin P2P network itself. As is, we only send this data in Ping messages (which are periodically sent), in the future we could also move to send them as the partial payload for our pong messages, and also randomize the payload size requested as well.
Roasbeef
force-pushed
the
ping-pong-headers
branch
from
bfc87fb to
8fd14bc
Compare
peer/brontide.go
Outdated
| @@ -1368,8 +1375,14 @@ out: | |||
| atomic.StoreInt64(&p.pingTime, delay) | |||
|
|
|||
| case *lnwire.Ping: | |||
| // TODO(roasbeef): get from buffer pool somewhere? ends | |||
| // up w/ lots of small allocations | |||
There was a problem hiding this comment.
Don't need to include this in an earlier commit if it gets deleted?
| /* | ||
| The last ping payload the peer has sent to us. | ||
| */ | ||
| bytes last_ping_payload = 15; |
There was a problem hiding this comment.
Does this get encoded as hex?
You can send an individual header to bitcoind over p2p using the |
Thanks - I wasn't aware of the |
In this commit, we implement a long discussed mechanism to use the
Lightning Network as a redundant block header source. By sending our
latest block header with each ping message, we give peers another source
(outside of the Bitcoin P2P network) they can use to spot check their
chain state. Peers can also use this information to detect if they've
been eclipsed from the traditional Bitcoin P2P network itself.
As is, we only send this data in Ping messages (which are periodically
sent), in the future we could also move to send them as the partial
payload for our pong messages, and also randomize the payload size
requested as well.