-
Notifications
You must be signed in to change notification settings - Fork 38.7k
Move special CAddress-without-nTime logic to net_processing #20541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move special CAddress-without-nTime logic to net_processing #20541
Conversation
5ce0928 to
ebe8db0
Compare
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
Concept ACK. Does this conflict with any backports we might want to do for 0.21? |
ebe8db0 to
158c0ec
Compare
|
@MarcoFalke I don't think so. It doesn't conflict with #20516 (either can be backported without affecting the other). Anything else you're thinking of? |
vasild
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 158c0ec1
It is somewhat worrying that all tests passed with the swapped services and address, but when I think about it - it is 8 bytes service flags + 16 bytes address + 2 bytes port. I guess we can't do any sanity check on those as any 26 random bytes could be valid.
Indeed. I think we should add unit test vectors for all message types with an example message and the expected deserialization? Assert that both are identical. Though, message format (deserialization) is handled in the same function that does the processing, so I am not sure how to test this in general without rewriting net_processing. |
It is, but that's at least partially explained by the fact that we barely use these values. One is ignored entirely, the other is used for statistics about our local IP. The nService fields are also ignored entirely.
That makes sense. |
|
Concept ACK |
|
ACK 158c0ec |
158c0ec to
775954a
Compare
|
Rebased. |
jnewbery
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concept ACK.
src/net_processing.cpp
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that references to version 31402 are very useful (beyond being a historical footnote). The version message contains {services, ipv6 addr, port} elements - the fact that that also used to be how address records used to be serialized in addr messages is not helpful in understanding the current protocol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they're useful for the time being, as I'd expect more descriptions and documentations of the protocol will keep referring to these fields as CAddresses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable
|
When we receive a
Perhaps in the next p2p version bump, we should explicitly document those fields as unused, since there's no purpose for them. |
vasild
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 775954ac5ffd2b0d6f89a5b35e4120f0d170c884
775954a to
79aa69c
Compare
Historically, the VERSION message contains an "addrMe" and an "addrYou". As these are sent before version negotiation is complete, the protocol version is INIT_PROTO_VERSION (209), and in that protocol, CAddress is serialized without nTime. This is in fact the only situation left where a CAddress is (de)serialized without nTime. As it's such a simple structure (CService for ip/port + uint64_t for nServices), just inline that structure in the few places where it occurs, and remove the logic for dealing with missing nTime from CAddress.
The us=... message in the debug log when sending a version message is always [::]:0, because we no longer send our own address there. Therefore, this information is entirely redundant. Remove it.
79aa69c to
75290ae
Compare
Zero-1729
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crACK 75290ae
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 75290ae
Tested on signet
$ ./src/bitcoind -signet -debug=net -logips
$ grep version ~/.bitcoin/signet/debug.log
...
2021-08-22T15:01:44Z received: version (103 bytes) peer=6
2021-08-22T15:01:44Z sending version (109 bytes) peer=6
2021-08-22T15:01:44Z send version message: version 70016, blocks=52221, them=[::]:0, txrelay=1, peer=6
2021-08-22T15:01:44Z receive version message: /Satoshi:22.99.0/: version 70016, blocks=52221, us=[::]:0, txrelay=1, peer=6, peeraddr=127.0.0.1:40326
2021-08-22T15:02:06Z sending version (109 bytes) peer=7
2021-08-22T15:02:06Z send version message: version 70016, blocks=52221, them=[::]:0, txrelay=1, peer=7
2021-08-22T15:02:07Z received: version (103 bytes) peer=7
2021-08-22T15:02:07Z receive version message: /Satoshi:22.99.0/: version 70016, blocks=52221, us=[::]:0, txrelay=1, peer=7, peeraddr=q3z526imdoo2pdujkfp5vslshni2niewlbxfokejfkddkezxutagezyd.onion:38333
2021-08-22T15:02:07Z New outbound peer connected: version: 70016, blocks=52221, peer=7, peeraddr=q3z526imdoo2pdujkfp5vslshni2niewlbxfokejfkddkezxutagezyd.onion:38333 (outbound-full-relay)
2021-08-22T15:02:11Z sending version (109 bytes) peer=8
2021-08-22T15:02:11Z send version message: version 70016, blocks=52221, them=[::]:0, txrelay=1, peer=8
2021-08-22T15:02:12Z received: version (103 bytes) peer=8
2021-08-22T15:02:12Z receive version message: /Satoshi:21.99.0/: version 70016, blocks=52221, us=[::]:0, txrelay=1, peer=8, peeraddr=uvj2uaxjztqtvmd5d27bgmfyfn6v3c2px2am2utbniuea55eblhid7qd.onion:38333
2021-08-22T15:02:12Z New outbound peer connected: version: 70016, blocks=52221, peer=8, peeraddr=uvj2uaxjztqtvmd5d27bgmfyfn6v3c2px2am2utbniuea55eblhid7qd.onion:38333 (outbound-full-relay)
2021-08-22T15:02:12Z sending version (109 bytes) peer=9
2021-08-22T15:02:12Z send version message: version 70016, blocks=52221, them=95.217.184.148:38333, txrelay=1, peer=9
2021-08-22T15:02:13Z received: version (102 bytes) peer=9
2021-08-22T15:02:13Z receive version message: /Satoshi:0.21.1/: version 70016, blocks=52221, us=184.75.221.35:38484, txrelay=1, peer=9, peeraddr=95.217.184.148:38333
2021-08-22T15:02:13Z New outbound peer connected: version: 70016, blocks=52221, peer=9, peeraddr=95.217.184.148:38333 (outbound-full-relay)
2021-08-22T15:02:20Z sending version (109 bytes) peer=10
2021-08-22T15:02:20Z send version message: version 70016, blocks=52221, them=[::]:0, txrelay=1, peer=10
2021-08-22T15:02:21Z received: version (102 bytes) peer=10
2021-08-22T15:02:21Z receive version message: /Satoshi:0.21.1/: version 70016, blocks=52221, us=[::]:0, txrelay=1, peer=10, peeraddr=s7fcvn5rblem7tiquhhr7acjdhu7wsawcph7ck44uxyd6sismumemcyd.onion:38333
2021-08-22T15:02:21Z New outbound peer connected: version: 70016, blocks=52221, peer=10, peeraddr=s7fcvn5rblem7tiquhhr7acjdhu7wsawcph7ck44uxyd6sismumemcyd.onion:38333 (outbound-full-relay)
| CAddress(CService(), addr.nServices); | ||
| CAddress addrMe = CAddress(CService(), nLocalNodeServices); | ||
| CService addr_you = addr.IsRoutable() && !IsProxy(addr) && addr.IsAddrV1Compatible() ? addr : CService(); | ||
| uint64_t your_services{addr.nServices}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, can be const
- uint64_t my_services{pnode.GetLocalServices()};
- uint64_t nonce = pnode.GetLocalNonce();
+ const uint64_t my_services{pnode.GetLocalServices()};
+ const uint64_t nonce{pnode.GetLocalNonce()};
const int nNodeStartingHeight{m_best_height};
- NodeId nodeid = pnode.GetId();
+ const NodeId nodeid{pnode.GetId()};
CAddress addr = pnode.addr;
- CService addr_you = addr.IsRoutable() && !IsProxy(addr) && addr.IsAddrV1Compatible() ? addr : CService();
- uint64_t your_services{addr.nServices};
+ const CService addr_you{addr.IsRoutable() && !IsProxy(addr) && addr.IsAddrV1Compatible() ? addr : CService()};
+ const uint64_t your_services{addr.nServices};There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will include this if I have to retouch for other reasons.
vasild
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 75290ae
|
crACK |
Historically, the VERSION message contains an "addrMe" and an "addrYou". As these are sent before version negotiation is complete, the protocol version is INIT_PROTO_VERSION (209), and in that protocol, CAddress is serialized without nTime.
This is in fact the only situation left where a CAddress is (de)serialized without nTime. As it's such a simple structure (CService for ip/port + uint64_t for nServices), just inline that structure in the few places where it occurs, and remove the logic for dealing with missing nTime from CAddress.