net: Remove g_relay_txes #20217

pull jnewbery wants to merge 5 commits into bitcoin:master from jnewbery:2020-10-remove-grelaytxes changing 8 files +66 −47
  1. jnewbery commented at 11:19 AM on October 22, 2020: member

    g_relay_txes is only required inside net_processing and is set only once at startup. Instead of having a global, move it to be a const member of PeerManager.

    This requires moving PushNodeVersion() into PeerManager, which also allows us to remove the connman argument.

  2. fanquake added the label P2P on Oct 22, 2020
  3. MarcoFalke added the label Refactoring on Oct 22, 2020
  4. in src/init.cpp:1408 in 45e81e1eb2 outdated 
    1403 | @@ -1404,7 +1404,10 @@ bool AppInitMain(const util::Ref& context, NodeContext& node, interfaces::BlockA
1404 |      node.chainman = &g_chainman;
1405 |      ChainstateManager& chainman = *Assert(node.chainman);
1406 |  
1407 | -    node.peerman.reset(new PeerManager(chainparams, *node.connman, node.banman.get(), *node.scheduler, chainman, *node.mempool));
1408 | +    assert(!node.peerman);
1409 | +    const bool blocks_only = args.GetBoolArg("-blocksonly", DEFAULT_BLOCKSONLY);
    MarcoFalke commented at 11:53 AM on October 22, 2020:

    Any reason to change the name from relay_txes to blocks_only? With block-relay-only connections, I'd prefer to stick to the old name to avoid confusion.

    The purpose is to ignore incoming inv and tx messages, so another name suggestion could be ignore_incoming_tx_relay, as outgoing tx relay is unaffected.

    jnewbery commented at 12:35 PM on October 22, 2020:

    Done

  5. in src/net_processing.h:98 in 45e81e1eb2 outdated 
      94 | @@ -94,6 +95,9 @@ class PeerManager final : public CValidationInterface, public NetEventsInterface
  95 |       */
  96 |      void Misbehaving(const NodeId pnode, const int howmuch, const std::string& message);
  97 |  
  98 | +    /** Whether this node is in blocks only mode */
    MarcoFalke commented at 12:15 PM on October 22, 2020: 
        /** Whether to ignore incoming tx relay traffic */
    jnewbery commented at 12:35 PM on October 22, 2020:

    Done

  6. MarcoFalke commented at 12:16 PM on October 22, 2020: member

    Left some style questions. Feel free to ignore, obviously.

    Concept ACK on the change.

  7. jnewbery force-pushed on Oct 22, 2020
  8. jnewbery commented at 12:36 PM on October 22, 2020: member

    Thanks for the review @MarcoFalke. I've taken your suggested name change.

  9. practicalswift commented at 6:53 PM on October 22, 2020: contributor

    Concept ACK: globals going down is good!

  10. DrahtBot commented at 10:42 PM on October 22, 2020: member

    <!--e57a25ab6845829454e8d69fc972939a-->

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    <!--174a7506f384e20aa4161008e828411d-->

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #20541 (Move special CAddress-without-nTime logic to net_processing by sipa)
    • #20228 (addrman: Make addrman a top-level component by jnewbery)
    • #19858 (Periodically make block-relay connections and sync headers by sdaftuar)

    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.

  11. fanquake commented at 2:57 AM on October 23, 2020: member

    Concept ACK

  12. ervanipank88 commented at 1:22 AM on October 29, 2020: none

    .

  13. DrahtBot added the label Needs rebase on Nov 4, 2020
  14. jnewbery commented at 2:51 PM on November 4, 2020: member

    Rebased

  15. jnewbery force-pushed on Nov 4, 2020
  16. DrahtBot removed the label Needs rebase on Nov 4, 2020
  17. sipa commented at 2:11 AM on November 5, 2020: member

    utACK 179616f8211883739df6e06852bd976dcdd0c3c9

  18. narula commented at 11:07 PM on November 14, 2020: contributor

    code review ACK.

    I was confused about the relationship between g_relay_txes (now m_ignore_incoming_txs) and m_tx_relay. I think it's if m_tx_relay is null, this is a blocks-only peer, and if m_ignore_incoming_txs is true, I am a blocks-only peer. Is that right? I think unifying everything under names with "blocks-only" would be clearer but is out of scope for this change.

  19. jnewbery commented at 10:08 AM on November 16, 2020: member

    Yes, this has been confusing for people, which is why I think it's important to be precise with terminology:

    • a block-relay-only connection is a type of connection to a peer where we only send and process blocks. We do not send or process transactions or addresses to/from that peer. We'll request that the peer not send us transactions by setting relay to 0 in the version message that we send to them. We also won't initialize the m_tx_relay data structure for that peer, since we're not doing tx relay with them.
    • -blocksonly mode is a configuration option where we don't process transactions from any of our peers. We'll set relay to 0 in all of our version messages. It's mostly used to reduce bandwidth usage for people who don't need a mempool.

    think unifying everything under names with "blocks-only" would be clearer

    I think that's probably less clear since it would confuse those two concepts.

  20. narula commented at 5:09 PM on November 16, 2020: contributor
    • a block-relay-only connection is a type of connection to a peer where we only send and process blocks. We do not send or process transactions or addresses to/from that peer. We'll request that the peer not send us transactions by setting relay to 0 in the version message that we send to them. We also won't initialize the m_tx_relay data structure for that peer, since we're not doing tx relay with them.
    • -blocksonly mode is a configuration option where we don't process transactions from any of our peers. We'll set relay to 0 in all of our version messages. It's mostly used to reduce bandwidth usage for people who don't need a mempool.

    Hmm, these still seem like the same concept to me but I'm probably missing something; let me ask the question in a different way: What is the difference between me being a -blocksonly node and me setting all of my connections to block-relay-only (let's hypothetically say you could)? Is it how the node addresses incoming transactions? If there is no difference, I would say they are the same concept?

  21. jnewbery commented at 5:52 PM on November 16, 2020: member

    What is the difference between me being a -blocksonly node and me setting all of my connections to block-relay-only (let's hypothetically say you could)?

    Some differences:

    • block-relay-only isn't a configuration option. The user has no control over how many block-relay-only connections the node makes, or to which addresses.
    • in -blocksonly mode, we still participate in address relay (we send getaddr messages to our peers, process the addr messages in response, and gossip new incoming addresses). block-relay-only connections do not participate in address relay, to preserve the privacy of those connections.
    • in -blocksonly mode, we could theoretically turn off other components, such as the fee estimator (which relies on participating in p2p transaction relay). #18766 does that.
    • block-relay-only connections are persisted across restart as 'anchor connections'.

    There may be others.

  22. narula commented at 7:29 PM on November 16, 2020: contributor

    What is the difference between me being a -blocksonly node and me setting all of my connections to block-relay-only (let's hypothetically say you could)?

    Some differences:

    • block-relay-only isn't a configuration option. The user has no control over how many block-relay-only connections the node makes, or to which addresses.
    • in -blocksonly mode, we still participate in address relay (we send getaddr messages to our peers, process the addr messages in response, and gossip new incoming addresses). block-relay-only connections do not participate in address relay, to preserve the privacy of those connections.
    • in -blocksonly mode, we could theoretically turn off other components, such as the fee estimator (which relies on participating in p2p transaction relay). #18766 does that.
    • block-relay-only connections are persisted across restart as 'anchor connections'.

    There may be others.

    Thank you, that's very helpful! Just to wrap up, it sounds like in my thought experiment (a hypothetical node with all block-relay-only connections vs. a node with -blocksonly) the applicable differences are bullet points 2 and 4, in that the -blocksonly node would still send around and process addrs and its connections would not be persisted across restart.

    This makes sense because in -blocksonly mode a node still needs to learn about other nodes, so processing addrs is important. block-relay-only connections were never designed to be all of the connections, so it's fine for them not to process addrs because the node can rely on the other connections to do that.

    We wouldn't want to persist all connections across a restart (https://github.com/bitcoin/bitcoin/issues/17326#issuecomment-550521262), but because block-relay-only connections are more privacy-preserving and they are extra connections (we can rely on the other connections cycling) it's fine for them to be persisted. And persisting them sort of helps with eclipse attacks (https://github.com/bitcoin/bitcoin/issues/17326).

    I think I'm confused because the check for block-relay-only connections in the code is sometimes to see if m_tx_relay exists, which is non-intuitive because block-relay-only also implies that addrs are not gossiped with this peer either, not just transactions, and sometimes to call IsBlockOnlyConn().

    I think the new name for !g_relay_txes, m_ignore_incoming_txs, is much clearer.

  23. jnewbery commented at 11:20 AM on November 19, 2020: member

    I think I'm confused because the check for block-relay-only connections in the code is sometimes to see if m_tx_relay exists, which is non-intuitive because block-relay-only also implies that addrs are not gossiped with this peer either, not just transactions, and sometimes to call IsBlockOnlyConn().

    IsBlockOnlyConn() was added later, and I think is much clearer since it's instantly obvious what the test is for, rather than if (m_tx_relay), which might just be defensive code to ensure that a null ptr isn't dererenced. I'd support a PR that made changes like:

    diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index a69efa4fc0..3ea2c1a1f9 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -1657,7 +1657,7 @@ void static ProcessGetData(CNode& pfrom, Peer& peer, const CChainParams& chainpa
 
         const CInv &inv = *it++;
 
-        if (pfrom.m_tx_relay == nullptr) {
+        if (peer.IsBlockOnlyConn()) {
             // Ignore GETDATA requests for transactions from blocks-only peers.
             continue;
         }

    That's out of scope for this PR.

    I think the new name for !g_relay_txes, m_ignore_incoming_txs, is much clearer.

    Great. @MarcoFalke gets credit for that!

  24. in src/net_processing.cpp:2353 in 3b81ec59d1 outdated 
    2350 | @@ -2351,7 +2351,7 @@ void PeerManager::ProcessMessage(CNode& pfrom, const std::string& msg_type, CDat
2351 |  
2352 |          // Be shy and don't send version until we hear
2353 |          if (pfrom.IsInboundConn())
    MarcoFalke commented at 1:06 PM on November 19, 2020:

    style-nit in commit 3b81ec59d15c17bb1c39eeb044c113117c41071d:

    Could add {

    jnewbery commented at 6:09 PM on December 7, 2020:

    I joined the lines since the if block is one line.

  25. in src/net_processing.h:98 in 2ebb63696b outdated 
      93 | @@ -94,6 +94,9 @@ class PeerManager final : public CValidationInterface, public NetEventsInterface
  94 |       */
  95 |      void Misbehaving(const NodeId pnode, const int howmuch, const std::string& message);
  96 |  
  97 | +    /** Whether this node ignores txs received over p2p  */
    MarcoFalke commented at 1:06 PM on November 19, 2020:

    style-nit in 2ebb63696b0bac6dd627551d44aa935b769d8bde: double space

    jnewbery commented at 6:11 PM on December 7, 2020:

    Fixed

  26. in src/init.cpp:1408 in 10182aaa5b outdated 
    1403 | @@ -1404,7 +1404,8 @@ bool AppInitMain(const util::Ref& context, NodeContext& node, interfaces::BlockA
1404 |      node.chainman = &g_chainman;
1405 |      ChainstateManager& chainman = *Assert(node.chainman);
1406 |  
1407 | -    node.peerman.reset(new PeerManager(chainparams, *node.connman, node.banman.get(), *node.scheduler, chainman, *node.mempool));
1408 | +    assert(!node.peerman);
1409 | +    node.peerman = MakeUnique<PeerManager>(chainparams, *node.connman, node.banman.get(), *node.scheduler, chainman, *node.mempool);
    MarcoFalke commented at 1:07 PM on November 19, 2020:

    style nit in 10182aaa5bb2521ef6836d9984806968d3f46b24: When changing this, I'd prefer to use std::make_unique, not the deprecated wrapper.

    MarcoFalke commented at 2:56 PM on December 7, 2020:

    has this been addressed?

    jnewbery commented at 6:17 PM on December 7, 2020:

    Done

  27. MarcoFalke approved
  28. MarcoFalke commented at 1:15 PM on November 19, 2020: member

    review ACK 179616f8211883739df6e06852bd976dcdd0c3c9 nice cleanup! 🚔

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

review ACK 179616f8211883739df6e06852bd976dcdd0c3c9 nice cleanup! 🚔
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhgiwv8DdUGvchEGZlcyNFDb/+qNnq3WawkfpGWNb6Ncw1UhyOpoKtyLHCU8YtX
8KFBToEOqMSQw9vljAJx9oRYEd/ugMBJgCxpdlLMuFeOpw9q7DIxGCUxJdtte3sU
HQUPMduUvIb3PD6AXZC0uiTJk7S2DtZ7GhdPiVC1MK9prUZv/t17EA4o2daYFYZQ
2kz5vsvRXk2I5oh56sk0IlXr2Wid0+m6XDLj1Nf1CKZntg1DrR7+FeF9KN+pDuu5
FV6hUE7Enqnv67MY8L2qDegLAxdHGhCoS6wWwZIciahEtXbUHPLexERdE7Mm38pp
nHyidWXW1BVpYPIu8EssHboMreNxiX2BN4kyA2YPlKwmsmQjprBil+SnYaIVAWD4
8B5hxjH+f+DIxDliIphn3ABiLvJmXXh7GVG1XKKGdoBv5Po+YXh0UezPli6Fon49
gqWmaqYeRfD1gxFAdMaM0Bl1bbFUuDKarN1knvU99h87t7u4op6PcxDl52r2mb93
ePmRESnn
=hNL8
-----END PGP SIGNATURE-----

    python: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

    </details>

  29. jnewbery commented at 2:50 PM on November 19, 2020: member

    Thanks @MarcoFalke. All good suggestions. I'll take them all if I need to rebase this.

  30. DrahtBot added the label Needs rebase on Dec 7, 2020
  31. jnewbery commented at 1:55 PM on December 7, 2020: member

    rebased

  32. jnewbery force-pushed on Dec 7, 2020
  33. in src/init.cpp:1376 in ceedf230fd outdated 
    1375 | @@ -1376,7 +1376,7 @@ bool AppInitMain(const util::Ref& context, NodeContext& node, interfaces::BlockA
1376 |      // see Step 2: parameter interactions for more information about these
    MarcoFalke commented at 2:51 PM on December 7, 2020:

    unrelated: Not sure what this comment is trying to say. Could remove in this pull?

    jnewbery commented at 2:59 PM on December 7, 2020:

    done

  34. MarcoFalke commented at 2:56 PM on December 7, 2020: member

    re-ACK ceedf230fd only change is rebase 🏑

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK ceedf230fd only change is rebase 🏑
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUgCvAv+K3VviMunaCVXNAeZ/hZH34QUHITi3yW5mVjRux8HD/eTowDKtm+kMo/p
t2+ADIT+xufMOh4xBjJ/tk18daxL7IHceABiNuAP/uDUVOn+QeCYbfueVj0UBepS
G1mBS750Cy/frouSFD2Gn35H/8fNBtSTyAggKAveJ27cSK9h/nk2pp7xiyo+pG27
8+KoEt//u44zMRlLKFiEkMG6O60/RtxIndpLuU0t+T3qUv8CFyJYaWVjMng8ZA5B
2CvEI/7reaSWzyvfLakbkPdUtX6YqMixGSphq2U0AjcKShOSGF6wRnpo3bspsHXy
aBo8OOp/E3X74Ui8DaAEnXP7VQj6wYLZsCKAsv/f0Dn3AohEawRPkiNG/4pgArbH
iN746lD/VpJIABh3LdgY2FsyQ+lvf0mwol7WpNzMzIpy3qzvs8mixN+2HAuDWo02
/XNDqfOP2sb22+leSeiujZTm0YmkLdBfJbjSpVeLWBmEbHZ8aUY4GTewFe0CvULf
GcvKddFt
=+MY6
-----END PGP SIGNATURE-----

    Timestamp of file with hash c72658247447f9b3ea4dd216ccb2048076b4de79b559adad9feea0a1f8001eea -

    </details>

  35. jnewbery force-pushed on Dec 7, 2020
  36. DrahtBot removed the label Needs rebase on Dec 7, 2020
  37. MarcoFalke commented at 3:49 PM on December 7, 2020: member

    Would be nice if the previous feedback about MakeUnique was addressed, but looks fine already.

    re-ACK 4fdca52007 🎞

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 4fdca52007 🎞
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUjHMAv/ZPMhJbZefHl6UIHBCAxBD64CT2DiBLoPw/GmGmgxq1vBr8LIPR1RYfvB
tr8VcMtrqa+WaMszsEE3f+WAC86C49rbGn4r1MIEkFMiBZWn4N1nno5thhtCv9h8
mfnFpJUqlgeFv+5ZXh63Y0mA1PbA4B7KQ1V1hc9WXK+tTzTN06B7wKJGf9/PJWUl
sCWYpN5KBr4KGjlw6eJB9C141aIyUOgXzzep7waYeQqA4kUaJ6h7xk2g/1pLRA2f
v5Ds/DrHY5wHfdLEv82Jdpmi+GC2DZ+buiuo+CpHMli3VdclrOtPLEVkAwPJTSMu
UMOLzgZ9cOm0B9yCm2DtgRh1bVLJfAN3lzKpv2NObVZgW1sUQYHg1AFBJDMtj7dA
0zssUKJWLkbwKrND5LAocCHWlu0hBoYeM2wycWNRNvTUJlO8b9tzwrh2jpFlmVBK
AjM40R1MbjIl3SirWjbB7a4DD0ubl9KPCYCm6eGEZryT5VuIvOAfDz7IeC6iKjrq
uQVHH7b8
=1TZV
-----END PGP SIGNATURE-----

    Timestamp of file with hash 7771d7eb2920b1e3060dc2d3e986607c8393b9886bc4213c99ec34be0994af1c -

    </details>

  38. jnewbery commented at 6:17 PM on December 7, 2020: member

    @MarcoFalke addressed your review comments. Sorry for dropping them earlier.

  39. jnewbery force-pushed on Dec 7, 2020
  40. MarcoFalke commented at 6:40 PM on December 7, 2020: member

    re-ACK a21667ace8 🖱

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK a21667ace8 🖱
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhcBAwAqm9wdxwAE32mOhS0kcpLhVxGPmTuZ3Xwxca3DJNo20MX3qzUkmfG+izj
0it+s6TycxiPR0EXKDutg3qWxUcu0Js2pAcYnYrNAbUx91SwcT31kQ/VCSU/5MNj
xrrMKZLJ5nVeKSMnF76jvpc8yoQO6wJpbWCnt5w38noa9BhwDU2pvHQF9vhVA7V1
wZsqtr8z3gR54Ov7fQbN1DQ7eX/K8MjAjuUZvWTuEWVZPLUp5ewbm4r1iFQzskBJ
JhjwoIfg/dxAscOQzrXhwlt1aVHQPygQAICNw06W41jxZpVyGVsIOOd6h7nWc5O4
uSMF6W1HWuS12JhfCLl6W6HCRFt6/vt1pHu5sdTCpyFZPy66nTlDpbJBT7XnBh3T
3JGJTq+h5EP/p8A4Fh3bBnWmSqTGX4b3vCTcejO6nq4Knn2BGVjy4irYirXAkR//
ReIsxEwclRLo0iCl9LgmOGV25MUASd1BKlGl4NknohG3LoIra7ZJeuQW6ZnoWqhZ
GvvZqsbN
=mv04
-----END PGP SIGNATURE-----

    Timestamp of file with hash 0174d24f81d7b43cdafd8412778651b9496d8a3add89e495cf7fddb037bd18f1 -

    </details>

  41. DrahtBot added the label Needs rebase on Dec 9, 2020
  42. jnewbery force-pushed on Dec 9, 2020
  43. jnewbery commented at 11:37 AM on December 9, 2020: member

    rebased

  44. jnewbery commented at 11:38 AM on December 9, 2020: member

    At different times, this PR has had ACKs from @sipa @narula and @MarcoFalke. There have only been minor changes and rebases since those ACKs. Some reACKs at the same commit hash would be very appreciated!

  45. MarcoFalke commented at 11:50 AM on December 9, 2020: member

    re-ACK 22d960b124 🥃

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 22d960b124 🥃
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUjh9wv9GVZefOvKGq4C4k3P+5QHVrXbC5F9CYF6K/n+QKgIole9iTT5rRNT0C+o
WHb2Q3I3cdyo8WirtL/pBytgn3wBKu1Ap2v4Wygzb1p9+KbM/e2lcQLhGH7hfrKo
yt30H+V+mnAqiln7iPc9BtskrIcL/hMvgkyU01p7UguvPzKzfo+2wVNkJFialPqe
VrdpDO2cHbIexxD7Fjr12Q3Gdo2SRR66qo0poHNZkLZ1FRhzlRFsaixAwJTdDz9j
YG3qZl7QuZtEIwqlDDZSoGiplqA7zvNSxxlcEGCPHvHuPkHnv2Fc51iu+q0VduQA
H0hBpIVHeezSZpCAKbPz2f1dBPvRgw2H3Y5dReAuP8AFnJQmEqSmqIKMct7cqYR0
eUJCauczOLfaNCB6iiEP6aUXgzIv9GWcumx0LSh46JHuMUk690lj3uwMrqOFNjbv
WXEMx9a318Mu/nZNIkxItEJ579qhRyt7L/blV+hhUfupezceehR57UKP6oZVXJWq
yDQK6uHW
=altt
-----END PGP SIGNATURE-----

    Timestamp of file with hash 63b2a105ac69ff10887f137cd6a439977e3e14920cb1b46d6faaf934b73581b9 -

    </details>

  46. DrahtBot removed the label Needs rebase on Dec 9, 2020
  47. MarcoFalke added the label Needs rebase on Dec 9, 2020
  48. MarcoFalke commented at 2:39 PM on December 9, 2020: member

    needs rebase :dagger:

  49. [net processing] Move PushNodeVersion into PeerManager 5805b8299f
  50. [net processing] Add IgnoresIncomingTxs() function to PeerManager f3f61d0eb9
  51. [init] Use MakeUnique<> to construct peerman 4d510aa055
  52. [net processing] Add m_ignores_incoming_txs to PeerManager and use internally 68334b3944
  53. Remove g_relay_txes
    Also remove vestigial commend in init.cpp
    34e33ab859
  54. jnewbery force-pushed on Dec 9, 2020
  55. jnewbery commented at 6:23 PM on December 9, 2020: member

    rebased

  56. narula commented at 7:00 PM on December 9, 2020: contributor

    utACK 34e33ab8592d757b3acfe812c20d235029bbc319

  57. DrahtBot removed the label Needs rebase on Dec 9, 2020
  58. MarcoFalke commented at 6:28 AM on December 10, 2020: member

    re-ACK 34e33ab85 💐

    <details><summary>Show signature and timestamp</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

re-ACK 34e33ab85 💐
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUjrNwwAhgjzJwknztCmt65CG19czsI/ftTRBzjJQ2dkkxI/DpPNtVRdzMyiDX7C
kG7nZI+4PS2/DmzD46EwllFvndY3vLqVuGvr4I7/JIwAA49caGSABfY+5dW95BNp
sc3N0/w8TpM/HEsW71xoz2ebRMG7tV0WoY4rYuQm3ynQltQ51uk+DYB997QKqI4/
WRPyK0tXb0rG8nLj3zUBHBB4V1+4Qsjn22KS1O0MhSJh8/zrmooHcL4d1Z+GC3At
BkcyzLRWbAq5uVnqHgJyQcZsakWR/fUAx4LMjw4D4n7WV/ja2BOL3NlCtMKarqvO
88Ts9JcuI03rDfagB1K7JzpoSVDwpzP2E/7eE7fyB3Bo8mzNZ9OrwyoHDu957ydp
rUvZj7jzyg4LBFxwxvVEf0AvGCID4rYMDxdqjYNs5dLKee2UaqNaB6VY76lrj7fJ
szECMByBUJmqj0uZJNGVlzd3KcrfySW9KRAT+EoRPDSByehI6hfJtzJS/phOQ1Je
ngdR9Lq0
=kxdj
-----END PGP SIGNATURE-----

    Timestamp of file with hash 50413236396d5df336002d2266fca66543a43dc9ee2cb2ba69a71db2cca5df6a -

    </details>

  59. MarcoFalke merged this on Dec 10, 2020
  60. MarcoFalke closed this on Dec 10, 2020
  61. jnewbery deleted the branch on Dec 10, 2020
  62. sidhujag referenced this in commit 91c8703918 on Dec 10, 2020
  63. Fabcien referenced this in commit 042e6fa41e on Jan 25, 2022
  64. DrahtBot locked this on Feb 15, 2022
Contributors
jnewberyMarcoFalkepracticalswiftDrahtBotfanquakeervanipank88sipanarula
Labels
RefactoringP2P
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: 2026-04-22 09:14 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me