Bitcoincore copy blocks for new synchronization. Tell me friends

[LoyceV]

The gain is not big compared with the total time, but it is still a gain.

You make me want to test this

[Cricktor]

I think this means it only keeps mempool empty, and I don't think that matters much during IBD.

I disagree somewhat for the second half of your sentence.

Not having to care about mempool and incoming transactions and their validation for moderately low memory devices (not more than 16GB of RAM) means less I/O concerning the UTXO set to check and verify that incoming transactions indeed only spend existing UTXOs. Current chainstate directory is about 12GiB large. You can't really hold that in memory having not more than 16GB and OS and other running processes need RAM space, too.

Being trustless your node can't blindly believe transactions served to it are valid per se and the transmitting connected other node complies to all rules as if that's a given. On the other hand now that I think about it, how can a node in the process of IBD even try to validate a new transaction's inputs when its UTXO set isn't yet fully built. Now I'm a bit confused...

You make me want to test this

Go ahead, there's this itching feeling...

[LoyceV]

I think this means it only keeps mempool empty, and I don't think that matters much during IBD.

I disagree somewhat for the second half of your sentence.

Not having to care about mempool and incoming transactions and their validation for moderately low memory devices (not more than 16GB of RAM) means less I/O concerning the UTXO set to check and verify that incoming transactions indeed only spend existing UTXOs. Current chainstate directory is about 12GiB large. You can't really hold that in memory having not more than 16GB and OS and other running processes need RAM space, too.

I thought it would only ignore mempool. If blocksonly=1 ignores chainstate, then I expect a significant increase in speed and even 4 GB RAM should be enough.

Being trustless your node can't blindly believe transactions served to it are valid per se and the transmitting connected other node complies to all rules as if that's a given. On the other hand now that I think about it, how can a node in the process of IBD even try to validate a new transaction's inputs when its UTXO set isn't yet fully built. Now I'm a bit confused...

During IBD, your UTXO set always contains all inputs that existed when the block you're currently verifying was found. So the fact that you don't have a full UTXO set yet is irrelevant at that moment.

You make me want to test this

Go ahead, there's this itching feeling...

I'll need a high-bandwidth high-CPU system with little RAM for this test.

[Cricktor]

I thought it would only ignore mempool. If blocksonly=1 ignores chainstate, then I expect a significant increase in speed and even 4 GB RAM should be enough.

I don't understand what you mean with "ignores chainstate". chainstate is built during IBD, it's an important task during IBD to build the current UTXO set.

blocksonly=1 lets the node only fetch and relay block data, no transactions. The node doesn't ask to get new transactions and doesn't relay any, because it doesn't have any unconfirmed transactions. When new transactions traffic is ignored the node can't reasonably maintain an own mempool. So, yes it has to ignore entertaining an own mempool, it should only update chainstate aka the UTXO set while it processes blocks sequentially until reaching chaintip.

Being trustless your node can't blindly believe transactions served to it are valid per se and the transmitting connected other node complies to all rules as if that's a given. On the other hand now that I think about it, how can a node in the process of IBD even try to validate a new transaction's inputs when its UTXO set isn't yet fully built. Now I'm a bit confused...

During IBD, your UTXO set always contains all inputs that existed when the block you're currently verifying was found. So the fact that you don't have a full UTXO set yet is irrelevant at that moment.

What I meant is the following (we assume blocksonly=0 for a moment):
IBD is at block 800,000, chainstate updated to this point. Every transaction contained in up to block 800,000 can and has been verified (we ignore assumevalid stuff for a moment). Any UTXO created up to block 800,000 is known to be a valid. But the node can't yet know if any of the UTXOs so far has been spent in a block later.

I struggle to understand why a node in the process of IBD would care about new unconfirmed transactions when it can't verify if the inputs of the new transaction are valid UTXO when our example node has no clue yet what happened in blocks 800,001 until current chaintip.
When a new transaction relayed by some connected node has an input which transaction outpoint is contained in a block less than 800,000 our mighty node knows it's at least valid for this outpoint, but it can't yet know if this transaction outpoint hasn't been spent in some blocks which it hasn't yet seen.

Hm, maybe we're already drifting a bit into off-topic land? I hope not, but I don't want to hijack the thread with my struggles.

I'll need a high-bandwidth high-CPU system with little RAM for this test.

Isn't there a way to tell a Linux kernel to use only a defined amount of RAM? I've foggy memory about this. Another way would be to setup a VM with desired resource restrictions on an otherwise too "large" host.

[LoyceV]

I don't understand what you mean with "ignores chainstate".

I misunderstood, and removed it.

What I meant is the following (we assume blocksonly=0 for a moment):
IBD is at block 800,000, chainstate updated to this point. Every transaction contained in up to block 800,000 can and has been verified (we ignore assumevalid stuff for a moment). Any UTXO created up to block 800,000 is known to be a valid. But the node can't yet know if any of the UTXOs so far has been spent in a block later.

I struggle to understand why a node in the process of IBD would care about new unconfirmed transactions when it can't verify if the inputs of the new transaction are valid UTXO when our example node has no clue yet what happened in blocks 800,001 until current chaintip.

I think it's more of a "why not" thing: chances of other nodes broadcasting fake transactions are small, and your own node doesn't do anything with them until it's fully synced. If it wouldn't do this during IBD, it would have to start after downloading the last block. The same thing can happen at each new block: if there's a conflict with a transaction in mempool, the transaction becomes invalid. Some block explorers show those transactions with the one that replaced it.

I'll need a high-bandwidth high-CPU system with little RAM for this test.

Isn't there a way to tell a Linux kernel to use only a defined amount of RAM? I've foggy memory about this. Another way would be to setup a VM with desired resource restrictions on an otherwise too "large" host.

The easiest would be to turn of swap, and fill /dev/shm with data to reduce available memory. But I don't have enough laptops laying around to really test this, and I don't really want to write may TB of data again to the tiny SSD in my spare laptop.
The only VDS I can rent by the hour comes costs $50 per month, and still has 8 GB RAM. Other servers will start throttling CPU so the result is inaccurate. I don't think it's worth it just for this little experiment.