RFC: net: Pass best block known height into net #8542

pull theuni wants to merge 1 commits into bitcoin:master from theuni:pass-in-height changing 5 files +28 −25
  1. theuni commented at 11:00 pm on August 18, 2016: member

    This looks somewhat awkward as-is, but it’s a part of the CConnman refactor. I’ve broken it out and PR’d separately because it’s a change of behavior that requires some scrutiny. As part of #8085, the height will be passed into CConnman instead. For reference, it will end up looking more like this: https://github.com/bitcoin/bitcoin/pull/8085/commits/148163c9b1ce04ec9fa9c8ff9a4289520bd92127.

    Even without that, though, I think this is an improvement, as it eliminates a dependency on main from net.

    Push block height changes from main into net, and pass the current height into CNode at creation time, rather than pulling from main each time (and locking cs_main). Now CNode has no dependency on main for height.

    Note that It may also be handy to know later what our original height was for a given node.

    This also helps to prevent identity leakage a tiny bit. Before this change, an attacker could theoretically make 2 connections on different interfaces. They would connect fully on one, and only establish the initial connection on the other. Once they receive a new block, they would relay it to your first connection, and immediately commence the version handshake on the second. Since the new block height was reflected immediately, they could attempt to learn whether the two connections were correlated.

    This is, of course, incredibly unlikely to work due to the small timings involved and receipt from other senders. But it doesn’t hurt to lock-in nBestHeight at the time of connection, rather than letting the remote choose the time.

  2. net: Pass best block known height into net
    Then pass the current best height into CNode at creation time.
    
    This way CNode has no dependency on main for height, and the signals only move
    in one direction.
    
    This also helps to prevent identity leakage a tiny bit. Before this change, an
    attacker could theoretically make 2 connections on different interfaces. They
    would connect fully on one, and only establish the initial connection on the
    other. Once they receive a new block, they would relay it to your first
    connection, and immediately commence the version handshake on the second. Since
    the new block height is reflected immediately, they could attempt to learn
    whether the two connections were correlated.
    
    This is, of course, incredibly unlikely to work due to the small timings
    involved and receipt from other senders. But it doesn't hurt to lock-in
    nBestHeight at the time of connection, rather than letting the remote choose
    the time.
    a9535bc566
  3. jonasschnelli added the label P2P on Aug 19, 2016
  4. jonasschnelli commented at 6:27 am on August 19, 2016: contributor
    Concept ACK
  5. in src/init.cpp: in a9535bc566
    1502@@ -1503,6 +1503,7 @@ bool AppInit2(boost::thread_group& threadGroup, CScheduler& scheduler)
    1503     if (GetBoolArg("-listenonion", DEFAULT_LISTEN_ONION))
    1504         StartTorControl(threadGroup, scheduler);
    1505 
    1506+    SetNodeStartHeight(chainActive.Height());
    


    laanwj commented at 12:00 pm on August 24, 2016:

    Should IMO be prefixed Net in some way, otherwise it’s not clear that this is a net function. I also think the name “StartHeight” is a bit deceptive - nodes send each other their current height, not their starting height.

    Also: this creates a closely-coupled binding between Main and Net - just the other way around - my proposal would be to add a node notification signal on changed height that gets passed the height (if such doesn’t exist yet), and bind that to SetNetNodeHeight().


    theuni commented at 8:48 pm on August 24, 2016:

    Agreed that the name is unclear, will fix.

    After some thought, I also agree with using a signal. This will eventually connect to a connman instance, which shouldn’t be a problem. I’ll update with those suggestions and drop the RFC tag.

  6. sipa commented at 10:30 am on August 25, 2016: member
    Concept ACK, and agree with using a signal.
  7. theuni commented at 6:19 pm on August 31, 2016: member
    Included in #8085, though with the suggestions above not yet integrated.
  8. theuni closed this on Aug 31, 2016

  9. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-18 21:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me