p2p: Use legacy relaying to download blocks in blocks-only mode #22340

dergoegge · 2021-06-25T13:49:49Z

A blocks-only node does not participate in transaction relay to reduce its own bandwidth usage and therefore does not have a mempool. The use of compact blocks is not beneficial to such a node since it will always have to download full blocks.

In both high- and low-bandwidth relaying the cmpctblock message is sent. This represent a bandwidth overhead for blocks-only nodes because the cmpctblock message is several times larger in the average case than the equivalent headers or inv announcement.

Example:
A block with 2000 txs results in a cmpctblock with 2000*6 bytes in short ids. This is several times larger than the equivalent 82 bytes for a headers message or 37 bytes for an inv.

Approach

This PR makes blocks-only nodes always use the legacy relaying to download new blocks.
It does so by making blocks-only nodes never initiate a high-bandwidth block relay connection by disabling the sending of sendcmpct(1). Additionally a blocks-only node will never request a compact block using getdata(CMPCT).

A blocks-only node will continue to serve compact blocks to its peers in both high- and low-bandwidth mode.

dergoegge · 2021-06-26T15:12:51Z

Over the last 24h i ran a blocks-only node that saw 106 blocks and downloaded 3.8MB in cmpctblock messages. Thats an average of 12KB bytes per cmpctblock message received from three high-bandwidth peers. Only 26KB would have been downloaded if headers messages would have been used instead.
Assuming an average block size of 1.38MB the cmpctblock messages represented 2.5% of downloaded block data.

fanquake · 2021-07-01T02:46:44Z

@jnewbery @amitiuttarwar @sipa @ajtowns Any thoughts?

ajtowns · 2021-07-02T05:20:06Z

Seems workable? Compact blocks should be seeing:

12kB for short tx ids per cmpctblock message announcing a new block (for each high bw peer per block)
2kB per getblocktxn message asking for the tx data (per block)
~0 overhead for blocktxn message providing the block txns

Which should be ~38kB per block or about 5MB per day/144 blocks. Legacy block relay should just be:

~0 overhead for headers message
~0 overhead for GETDATA MSG_BLOCK request
~0 ovehead for BLOCK message

So this makes sense to me.

jnewbery

Concept ACK. Requesting HB mode or sending GETDATA(MSG_CMPCT_BLOCK) is wasteful (for both sender and reciever) if the node can't reconstruct compact blocks.

src/net_processing.cpp

jnewbery · 2021-07-02T12:58:27Z

utACK 6dfee13

naumenkogs · 2021-07-07T11:57:46Z

Is this true for transactions received via sendrawtransaction? What if some node, for whatever reason, receives all transactions, while having blocks-only mode? For them, compact blocks are going to be beneficial, but this PR will disable it?

dergoegge · 2021-07-08T18:14:02Z

For them, compact blocks are going to be beneficial, but this PR will disable it?

@naumenkogs yes this PR would disable compact blocks even if txs were received through sendrawtransaction and i think overall that's ok since that seems like an edge case to me. I would presume most blocks-only nodes don't submit enough txs through sendrawtransaction for this to matter, especially not continuously so that most blocks contain many of those txs. Or if a node is broadcasting that many txs it might not care about the additional bandwidth?

[1] Technically it would be possible for a blocks-only node to ask for compact blocks if its mempool size (significantly) exceeds the overhead of compact blocks.
[2] A config option enabling compact blocks for those individual blocks-only nodes that heavily use sendrawtransaction could also help.

Do you think adding [1] or [2] to this PR would be worth it?

naumenkogs · 2021-07-09T05:46:09Z

I think [2] is better than [1].

Whether we want to add a new config option for this use case or just implement what you suggested originally — my personal choice would be to ask for thoughts at the #bitcoin-core-dev meeting.

jnewbery · 2021-07-09T08:36:04Z

yes this PR would disable compact blocks even if txs were received through sendrawtransaction and i think overall that's ok since that seems like an edge case to me.

I agree that this seems like an edge case that wouldn't actually be used. Compact blocks exist to improve propagation speed/efficiency when a node is participating in tx relay. I'd prefer not to add a configuration option that we don't expect to be used, or to increase the complexity of this PR.

naumenkogs · 2021-07-09T08:55:42Z

I agree that this seems like an edge case that wouldn't actually be used. Compact blocks exist to improve propagation speed/efficiency when a node is participating in tx relay. I'd prefer not to add a configuration option that we don't expect to be used, or to increase the complexity of this PR.

To be clear, my worry is that some miners use the following setting:
A node in blocks-only mode with low-latency requirements (hence mining) is constantly fed with transactions via sendrawtransaction, for whatever reason (e.g., they consider p2p tx relay insecure and disable it).

I don't have any evidence of someone using this, just wanted to point out we are going to break this use case here, so I thought asking around makes sense.

sipa · 2021-07-19T15:59:53Z

@naumenkogs That seems very unlikely to me.

DrahtBot · 2021-07-23T01:16:23Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

#20799 (net processing: Only support version 2 compact blocks by jnewbery)

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.

theStack · 2021-08-04T14:23:09Z

Concept ACK

willcl-ark · 2021-08-04T16:39:21Z

utACK.

Perhaps a new test case in p2p_compactblocks.py or p2p_compactblocks_hb.py might be a good addition here, or in a follow-up? This changes behaviour but doesn't fail any tests.

LarryRuane · 2021-08-04T18:06:21Z

utACK 6dfee13
but (as others have said) a test would be nice

rajarshimaitra

Concept ACK.

As others have mentioned a functional test covering this behaviour would be nice.

I just have the following nits.

src/net_processing.cpp

theStack

utACK 6dfee13

jnewbery

A few small suggestions on the new test.

test/functional/p2p_compactblocks_blocksonly.py

dergoegge · 2021-08-09T20:45:59Z

Thanks for the review @jnewbery! I took all your suggestions.

I also added two new test cases:
One to test that on regular low bandwidth connections (no blocksonly nodes involved) getdata(CMPCT) is still sent. 8b1b308
And one to test that blocksonly nodes still serve compact blocks in hb and lb mode. 8c4159a

jnewbery

utACK 8c4159a

Thanks for being so responsive to review. I have a few more comments for your consideration inline. Nothing blocking.

test/functional/p2p_compactblocks_blocksonly.py

jonatack · 2021-08-10T17:13:48Z

Started looking at this PR. Rebased to current master, debug build is clean, ~~but the new test times out for me locally on every run (out of five).~~

test output

$ test/functional/p2p_compactblocks_blocksonly.py 
2021-08-10T15:36:10.388000Z TestFramework (INFO): Initializing test directory /tmp/bitcoin_func_test_ypwy_8d2
2021-08-10T15:36:11.582000Z TestFramework (INFO): Test that blocksonly nodes do not request high bandwidth mode.
2021-08-10T15:37:11.677000Z TestFramework.utils (ERROR): wait_until() failed. Predicate: ''''
        def test_function():
            if check_connected:
                assert self.is_connected
            return test_function_in()
'''
2021-08-10T15:37:11.677000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
  File "/home/jon/projects/bitcoin/bitcoin/test/functional/test_framework/test_framework.py", line 131, in main
    self.run_test()
  File "/home/jon/projects/bitcoin/bitcoin/test/functional/p2p_compactblocks_blocksonly.py", line 79, in run_test
    p2p_conn_blocksonly.wait_until(lambda: p2p_conn_blocksonly.message_count['sendcmpct'] == 2)
  File "/home/jon/projects/bitcoin/bitcoin/test/functional/test_framework/p2p.py", line 451, in wait_until
    wait_until_helper(test_function, timeout=timeout, lock=p2p_lock, timeout_factor=self.timeout_factor)
  File "/home/jon/projects/bitcoin/bitcoin/test/functional/test_framework/util.py", line 256, in wait_until_helper
    raise AssertionError("Predicate {} not true after {} seconds".format(predicate_source, timeout))
AssertionError: Predicate ''''
        def test_function():
            if check_connected:
                assert self.is_connected
            return test_function_in()
''' not true after 60.0 seconds
2021-08-10T15:37:11.729000Z TestFramework (INFO): Stopping nodes
2021-08-10T15:37:11.891000Z TestFramework (WARNING): Not cleaning up dir /tmp/bitcoin_func_test_ypwy_8d2
2021-08-10T15:37:11.892000Z TestFramework (ERROR): Test failed. Test logging available at /tmp/bitcoin_func_test_ypwy_8d2/test_framework.log
2021-08-10T15:37:11.894000Z TestFramework (ERROR): 
2021-08-10T15:37:11.896000Z TestFramework (ERROR): Hint: Call /home/jon/projects/bitcoin/bitcoin/test/functional/combine_logs.py '/tmp/bitcoin_func_test_ypwy_8d2' to consolidate all logs
2021-08-10T15:37:11.896000Z TestFramework (ERROR): 
2021-08-10T15:37:11.897000Z TestFramework (ERROR): If this failure happened unexpectedly or intermittently, please file a bug and provide a link or upload of the combined log.
2021-08-10T15:37:11.897000Z TestFramework (ERROR): https://github.com/bitcoin/bitcoin/issues
2021-08-10T15:37:11.897000Z TestFramework (ERROR):

amitiuttarwar · 2021-08-10T20:01:47Z

@jonatack that's odd. I tried rebasing on master & the tests are passing 🤔

And based on the logs you posted, I don't see why rebasing would cause a difference. The test file introduced is new, and I don't believe anything has changed recently around compact block p2p messages. Do you have any more info you can offer?

jonatack · 2021-08-10T20:13:34Z

It's late but I'll try again tomorrow (and do a review, looks like an interesting PR). I rebased and did a debug build with clang 13 on debian before running the test. Maybe it was spurious.

jonatack · 2021-08-10T21:06:18Z

Ok, the test runs fine. Here is what happened: I forgot about the footgun on master that currently doesn't build when DEBUG_ADDRMAN is defined. I built with my bash alias that does a debug build with that, the build failed, I didn't notice, and so I was running the test on the wrong build. I just verified that the failure I reported occurs on master. Apologies for the noise! Will review tomorrow.

jonatack

Code review re-ACK ae54485 per git diff e21f2e4 ae54485, only changes since last review are minor (mostly documentation) improvements in the functional test; rebased to master, debug build clean, ran test a few times, including with vagrind

test/functional/p2p_compactblocks_blocksonly.py --valgrind failed for me locally on the first run (AssertionError: [node 0] Unable to connect to bitcoind after 60s) during test setup, but succeeded on the second and third runs.

Thanks for updating!

test/functional/p2p_compactblocks_blocksonly.py

jonatack · 2021-08-16T10:43:04Z

I did not modify 6dfee13 because i don't want to invalidate the utACKs that this commit has already gotten

Your mileage may vary. In review feedback a year ago it was suggested to me to not worry too much about invalidating ACKs and I ended up "invalidating" 7 ACKs on that pull, which was subsequently merged. Since then I no longer worry about it and AFAICT doing so doesn't seem to have slowed anything down. (Sharing a thought in general, not for this case!)

jnewbery · 2021-08-16T13:38:11Z

ACK ae54485

rajarshimaitra

tACK ae54485

Stepped through the test, verified expected behaviors.

Below are few comments inline, nothing blocking.

Aside

Taking this opportunity to mention some generic approaches I took for functional test reviews. Could be helpful for new review club folks:

Start python debugging and step through the *.py file.
The output will show at the start of the test, the temp directory where regtest nodes are created. - You can talk to them while you pause the python file, with bitcoin-cli -datadir=/tmp-filepath/node0/ <command>.
You can tail -f their debug.log and only activate the required logging(net, rpc, etc depending on the test you are trying) using bitcoin-cli, to see communications happening in each nodes. Verify they are occurring as expected.
If you want to print something from src/*.cpp, use LogPrintf() to print in the debug.log file, that you were already tailing.
Use python debug console to work with the python objects, call functions, see object attributes are updated as expected.
Try to identify edge cases by changing test variables and observing failures.

test/functional/p2p_compactblocks_blocksonly.py

dergoegge · 2021-09-04T11:35:43Z

Thanks @rajarshimaitra and @jonatack for the reviews and advice!

nocmpct_blocksonly_2 -> nocmpct_blocksonly_3

git range-diff nocmpct_blocksonly_2...nocmpct_blocksonly_3

1:  1bd2f889c ! 1:  ac90610e1 [test] Test that -blocksonly nodes do not request high bandwidth mode.
    @@ test/functional/p2p_compactblocks_blocksonly.py (new)
     +
     +    def setup_network(self):
     +        self.setup_nodes()
    ++        # Start network with everyone disconnected
     +        self.sync_all()
     +
     +    def build_block_on_tip(self):
    @@ test/functional/p2p_compactblocks_blocksonly.py (new)
     +        # node2 produces blocks that are passed to the rest of the nodes
     +        # through the respective p2p connections.
     +
    -+        self.log.info("Test that -blocksonly nodes do not select peers for BIP 152 high bandwidth mode.")
    ++        self.log.info("Test that -blocksonly nodes do not select peers for BIP152 high bandwidth mode")
     +
     +        block0 = self.build_block_on_tip()
     +
     +        # A -blocksonly node should not request BIP152 high bandwidth mode upon
     +        # receiving a new valid block at the tip.
    -+        p2p_conn_blocksonly.send_and_ping(msg_block(block0))
    ++        p2p_conn_blocksonly.send_message(msg_block(block0))
    ++        p2p_conn_blocksonly.wait_until(lambda: p2p_conn_blocksonly.message_count['block'] == 1)
     +        assert_equal(int(self.nodes[0].getbestblockhash(), 16), block0.sha256)
    -+        p2p_conn_blocksonly.wait_until(lambda: p2p_conn_blocksonly.message_count['sendcmpct'] == 2)
    ++        assert_equal(p2p_conn_blocksonly.message_count['sendcmpct'], 2)
     +        assert_equal(p2p_conn_blocksonly.last_message['sendcmpct'].announce, False)
     +
     +        # A normal node participating in transaction relay should request BIP152
2:  abe3c5cf7 ! 2:  90776a869 [test] Test that -blocksonly nodes do not send getdata(CMPCT) on a low bandwidth connection.
    @@ test/functional/p2p_compactblocks_blocksonly.py: class P2PCompactBlocksBlocksOnl
              assert_equal(p2p_conn_high_bw.last_message['sendcmpct'].announce, True)
      
     +        self.log.info("Test that -blocksonly nodes send getdata(BLOCK) instead"
    -+                      " of getdata(CMPCT) in BIP152 low bandwidth mode.")
    ++                      " of getdata(CMPCT) in BIP152 low bandwidth mode")
     +
     +        block1 = self.build_block_on_tip()
     +
3:  c652e187e ! 3:  e38eb9288 [test] Test that getdata(CMPCT) is still sent on regular low bandwidth connections.
    @@ test/functional/p2p_compactblocks_blocksonly.py: class P2PCompactBlocksBlocksOnl
     +        self.nodes[3].submitblock(block0.serialize().hex())
     +
              self.log.info("Test that -blocksonly nodes send getdata(BLOCK) instead"
    -                       " of getdata(CMPCT) in BIP152 low bandwidth mode.")
    +                       " of getdata(CMPCT) in BIP152 low bandwidth mode")
      
     @@ test/functional/p2p_compactblocks_blocksonly.py: class P2PCompactBlocksBlocksOnly(BitcoinTestFramework):
              p2p_conn_high_bw.sync_send_with_ping()
              assert_equal(p2p_conn_high_bw.last_message['getdata'].inv, [CInv(MSG_CMPCT_BLOCK, block1.sha256)])
      
     +        self.log.info("Test that getdata(CMPCT) is still sent on BIP152 low bandwidth connections"
    -+                      " when no -blocksonly nodes are involved.")
    ++                      " when no -blocksonly nodes are involved")
     +
     +        p2p_conn_low_bw.send_and_ping(msg_headers(headers=[CBlockHeader(block1)]))
     +        p2p_conn_low_bw.sync_with_ping()
4:  ae54485c4 ! 4:  f30eb1fe4 [test] Test that -blocksonly nodes still serve compact blocks.
    @@ test/functional/p2p_compactblocks_blocksonly.py: class P2PCompactBlocksBlocksOnl
              p2p_conn_low_bw.sync_with_ping()
              assert_equal(p2p_conn_low_bw.last_message['getdata'].inv, [CInv(MSG_CMPCT_BLOCK, block1.sha256)])
      
    -+        self.log.info("Test that -blocksonly nodes still serve compact blocks.")
    ++        self.log.info("Test that -blocksonly nodes still serve compact blocks")
     +
     +        def test_for_cmpctblock(block):
     +            if 'cmpctblock' not in p2p_conn_blocksonly.last_message:

naumenkogs · 2021-09-22T07:15:42Z

ACK f30eb1f

test/functional/p2p_compactblocks_blocksonly.py

dergoegge · 2021-09-22T20:24:45Z

nocmpct_blocksonly_3 -> nocmpct_blocksonly_4

git range-diff nocmpct_blocksonly_3...nocmpct_blocksonly_4

1:  ac90610e1 ! 1:  df6794e80 [test] Test that -blocksonly nodes do not request high bandwidth mode.
    @@ test/functional/p2p_compactblocks_blocksonly.py (new)
     +class P2PCompactBlocksBlocksOnly(BitcoinTestFramework):
     +    def set_test_params(self):
     +        self.extra_args = [["-blocksonly"], [], []]
    -+        self.num_nodes = len(self.extra_args)
    ++        self.num_nodes = 3
     +
     +    def setup_network(self):
     +        self.setup_nodes()
    @@ test/functional/p2p_compactblocks_blocksonly.py (new)
     +
     +        # A -blocksonly node should not request BIP152 high bandwidth mode upon
     +        # receiving a new valid block at the tip.
    -+        p2p_conn_blocksonly.send_message(msg_block(block0))
    -+        p2p_conn_blocksonly.wait_until(lambda: p2p_conn_blocksonly.message_count['block'] == 1)
    ++        p2p_conn_blocksonly.send_and_ping(msg_block(block0))
     +        assert_equal(int(self.nodes[0].getbestblockhash(), 16), block0.sha256)
     +        assert_equal(p2p_conn_blocksonly.message_count['sendcmpct'], 2)
     +        assert_equal(p2p_conn_blocksonly.last_message['sendcmpct'].announce, False)
2:  90776a869 = 2:  548115650 [test] Test that -blocksonly nodes do not send getdata(CMPCT) on a low bandwidth connection.
3:  e38eb9288 ! 3:  01db031b5 [test] Test that getdata(CMPCT) is still sent on regular low bandwidth connections.
    @@ test/functional/p2p_compactblocks_blocksonly.py: from test_framework.util import
      class P2PCompactBlocksBlocksOnly(BitcoinTestFramework):
          def set_test_params(self):
     -        self.extra_args = [["-blocksonly"], [], []]
    +-        self.num_nodes = 3
     +        self.extra_args = [["-blocksonly"], [], [], []]
    -         self.num_nodes = len(self.extra_args)
    ++        self.num_nodes = 4

          def setup_network(self):
    +         self.setup_nodes()
     @@ test/functional/p2p_compactblocks_blocksonly.py: class P2PCompactBlocksBlocksOnly(BitcoinTestFramework):

              p2p_conn_blocksonly = self.nodes[0].add_p2p_connection(P2PInterface())
4:  f30eb1fe4 = 4:  c24c52d51 [test] Test that -blocksonly nodes still serve compact blocks.

jnewbery · 2021-09-23T10:13:06Z

Code review ACK c24c52d

naumenkogs · 2021-09-24T12:00:43Z

ACK c24c52d

Co-authored-by: Amiti Uttarwar <[email protected]>

…w bandwidth connection. Co-authored-by: Amiti Uttarwar <[email protected]>

…h connections. Co-authored-by: Amiti Uttarwar <[email protected]>

dergoegge · 2021-09-29T08:55:55Z

Rebased on latest master.

@jnewbery @theStack @jonatack @naumenkogs @rajarshimaitra I would appreciate it if you folks could have another look and re-ACK since i think this is pretty close to being ready :)

naumenkogs · 2021-09-29T10:52:05Z

ACK 18c5b23

rajarshimaitra · 2021-09-29T16:06:00Z

tACK 18c5b23

jnewbery · 2021-09-29T16:18:29Z

reACK 18c5b23

Did the rebase myself and verified the same result.

theStack

re-ACK 18c5b23 🥛

After my previous ACK (on a single commit with the changes in net_processing), the PR has been rebased and tests have been added. Those LGTM, the only place I found confusing is the assertion checking that the number of received sendcmpct messages on a peer from node after handshake is 2 initially, and not 1. I had to dig in the code to find out why:

bitcoin/src/net_processing.cpp

Lines 2721 to 2730 in 571bb94

    
           // Tell our peer we are willing to provide version 1 or 2 cmpctblocks 
        
           // However, we do not request new block announcements using 
        
           // cmpctblock messages. 
        
           // We send this to non-NODE NETWORK peers as well, because 
        
           // they may wish to request compact blocks from us 
        
           bool fAnnounceUsingCMPCTBLOCK = false; 
        
           uint64_t nCMPCTBLOCKVersion = 2; 
        
           m_connman.PushMessage(&pfrom, msgMaker.Make(NetMsgType::SENDCMPCT, fAnnounceUsingCMPCTBLOCK, nCMPCTBLOCKVersion)); 
        
           nCMPCTBLOCKVersion = 1; 
        
           m_connman.PushMessage(&pfrom, msgMaker.Make(NetMsgType::SENDCMPCT, fAnnounceUsingCMPCTBLOCK, nCMPCTBLOCKVersion));

Not a big deal, but if a follow-up PR is planned, probably a small comment could be added to the test explaining why 2 messages are expected (sendcmpct(0, 2) and sendcmpct(0, 1)).

…cks in blocks-only mode 18c5b23 [test] Test that -blocksonly nodes still serve compact blocks. (Niklas Gögge) a79ad65 [test] Test that getdata(CMPCT) is still sent on regular low bandwidth connections. (Niklas Gögge) 5e231c1 [test] Test that -blocksonly nodes do not send getdata(CMPCT) on a low bandwidth connection. (Niklas Gögge) 5bf6587 [test] Test that -blocksonly nodes do not request high bandwidth mode. (Niklas Gögge) 0dc8bf5 [net processing] Dont request compact blocks in blocks-only mode (Niklas Gögge) Pull request description: A blocks-only node does not participate in transaction relay to reduce its own bandwidth usage and therefore does not have a mempool. The use of compact blocks is not beneficial to such a node since it will always have to download full blocks. In both high- and low-bandwidth relaying the `cmpctblock` message is sent. This represent a bandwidth overhead for blocks-only nodes because the `cmpctblock` message is several times larger in the average case than the equivalent `headers` or `inv` announcement. ![compact blocks](https://raw.githubusercontent.com/bitcoin/bips/master/bip-0152/protocol-flow.png) >**Example:** >A block with 2000 txs results in a `cmpctblock` with 2000*6 bytes in short ids. This is several times larger than the equivalent 82 bytes for a `headers` message or 37 bytes for an `inv`. ## Approach This PR makes blocks-only nodes always use the legacy relaying to download new blocks. It does so by making blocks-only nodes never initiate a high-bandwidth block relay connection by disabling the sending of `sendcmpct(1)`. Additionally a blocks-only node will never request a compact block using `getdata(CMPCT)`. A blocks-only node will continue to serve compact blocks to its peers in both high- and low-bandwidth mode. ACKs for top commit: naumenkogs: ACK 18c5b23 rajarshimaitra: tACK bitcoin/bitcoin@18c5b23 jnewbery: reACK 18c5b23 theStack: re-ACK 18c5b23 🥛 Tree-SHA512: 0c78804aa397513d41f97fe314efb815efcd852d452dd903df9d4749280cd3faaa010fa9b51d7d5168b8a77e08c8ab0a491ecdbdb3202f2e9cd5137cddc74624

fanquake · 2021-10-01T06:45:47Z

This has been merged.

…locks-o…

DrahtBot added the P2P label Jun 25, 2021

jnewbery reviewed Jul 2, 2021

View reviewed changes

src/net_processing.cpp Outdated Show resolved Hide resolved

src/net_processing.cpp Outdated Show resolved Hide resolved

dergoegge force-pushed the nocmpct_blocksonly branch from e599338 to 6dfee13 Compare July 2, 2021 12:03

maflcko changed the title ~~Use legacy relaying to download blocks in blocks-only mode~~ p2p: Use legacy relaying to download blocks in blocks-only mode Jul 2, 2021

DrahtBot mentioned this pull request Jul 23, 2021

net processing: Only support version 2 compact blocks #20799

Merged

rajarshimaitra reviewed Aug 4, 2021

View reviewed changes

src/net_processing.cpp Show resolved Hide resolved

src/net_processing.cpp Show resolved Hide resolved

theStack reviewed Aug 6, 2021

View reviewed changes

dergoegge force-pushed the nocmpct_blocksonly branch from 307e220 to 217a80d Compare August 8, 2021 08:42

jnewbery reviewed Aug 9, 2021

View reviewed changes

dergoegge force-pushed the nocmpct_blocksonly branch from 217a80d to 8c4159a Compare August 9, 2021 20:44

jnewbery reviewed Aug 10, 2021

View reviewed changes

jonatack reviewed Aug 16, 2021

View reviewed changes

test/functional/p2p_compactblocks_blocksonly.py Outdated Show resolved Hide resolved

rajarshimaitra reviewed Aug 17, 2021

View reviewed changes

test/functional/p2p_compactblocks_blocksonly.py Show resolved Hide resolved

test/functional/p2p_compactblocks_blocksonly.py Outdated Show resolved Hide resolved

DrahtBot mentioned this pull request Aug 31, 2021

net: Make m_mempool optional in PeerManager #22850

Closed

dergoegge force-pushed the nocmpct_blocksonly branch from ae54485 to f30eb1f Compare September 4, 2021 11:22

jnewbery reviewed Sep 22, 2021

View reviewed changes

test/functional/p2p_compactblocks_blocksonly.py Outdated Show resolved Hide resolved

test/functional/p2p_compactblocks_blocksonly.py Outdated Show resolved Hide resolved

dergoegge force-pushed the nocmpct_blocksonly branch from f30eb1f to c24c52d Compare September 22, 2021 20:19

dergoegge and others added 5 commits September 28, 2021 22:11

[net processing] Dont request compact blocks in blocks-only mode

0dc8bf5

[test] Test that -blocksonly nodes do not request high bandwidth mode.

5bf6587

Co-authored-by: Amiti Uttarwar <[email protected]>

[test] Test that -blocksonly nodes do not send getdata(CMPCT) on a lo…

5e231c1

…w bandwidth connection. Co-authored-by: Amiti Uttarwar <[email protected]>

[test] Test that getdata(CMPCT) is still sent on regular low bandwidt…

a79ad65

…h connections. Co-authored-by: Amiti Uttarwar <[email protected]>

[test] Test that -blocksonly nodes still serve compact blocks.

18c5b23

dergoegge force-pushed the nocmpct_blocksonly branch from c24c52d to 18c5b23 Compare September 28, 2021 20:28

theStack approved these changes Sep 30, 2021

View reviewed changes

fanquake closed this Oct 1, 2021

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Oct 1, 2021

Merge bitcoin#22340: p2p: Use legacy relaying to download blocks in b…

7bf3295

…locks-o…

dergoegge mentioned this pull request Oct 17, 2022

net: Set relay in version msg to peers with relay permission in -blocksonly mode #26248

Merged

bitcoin locked and limited conversation to collaborators Oct 30, 2022

	// Tell our peer we are willing to provide version 1 or 2 cmpctblocks
	// However, we do not request new block announcements using
	// cmpctblock messages.
	// We send this to non-NODE NETWORK peers as well, because
	// they may wish to request compact blocks from us
	bool fAnnounceUsingCMPCTBLOCK = false;
	uint64_t nCMPCTBLOCKVersion = 2;
	m_connman.PushMessage(&pfrom, msgMaker.Make(NetMsgType::SENDCMPCT, fAnnounceUsingCMPCTBLOCK, nCMPCTBLOCKVersion));
	nCMPCTBLOCKVersion = 1;
	m_connman.PushMessage(&pfrom, msgMaker.Make(NetMsgType::SENDCMPCT, fAnnounceUsingCMPCTBLOCK, nCMPCTBLOCKVersion));

p2p: Use legacy relaying to download blocks in blocks-only mode #22340

p2p: Use legacy relaying to download blocks in blocks-only mode #22340

Uh oh!

Conversation

dergoegge commented Jun 25, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Approach

Uh oh!

dergoegge commented Jun 26, 2021

Uh oh!

fanquake commented Jul 1, 2021

Uh oh!

ajtowns commented Jul 2, 2021

Uh oh!

jnewbery left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jnewbery commented Jul 2, 2021

Uh oh!

naumenkogs commented Jul 7, 2021

Uh oh!

dergoegge commented Jul 8, 2021

Uh oh!

naumenkogs commented Jul 9, 2021

Uh oh!

jnewbery commented Jul 9, 2021

Uh oh!

naumenkogs commented Jul 9, 2021

Uh oh!

sipa commented Jul 19, 2021

Uh oh!

DrahtBot commented Jul 23, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

Uh oh!

theStack commented Aug 4, 2021

Uh oh!

willcl-ark commented Aug 4, 2021

Uh oh!

LarryRuane commented Aug 4, 2021

Uh oh!

rajarshimaitra left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

theStack left a comment

Choose a reason for hiding this comment

Uh oh!

jnewbery left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dergoegge commented Aug 9, 2021

Uh oh!

jnewbery left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonatack commented Aug 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amitiuttarwar commented Aug 10, 2021

Uh oh!

jonatack commented Aug 10, 2021

Uh oh!

jonatack commented Aug 10, 2021

Uh oh!

jonatack left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

dergoegge commented Jun 25, 2021 •

edited

Loading

DrahtBot commented Jul 23, 2021 •

edited

Loading

jonatack commented Aug 10, 2021 •

edited

Loading

jonatack left a comment •

edited

Loading

rajarshimaitra left a comment •

edited

Loading