profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/laanwj/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
W. J. van der Laan laanwj The Netherlands

bitcoin-core/bitcoin-maintainer-tools 60

External repository for Bitcoin Core related maintenance tools

laanwj/bitcoin-submittx 50

Stand-alone Bitcoin transaction submission tool

laanwj/bitcoin-qt 45

Original Bitcoin-Qt repository. No longer used, Bitcoin-Qt was merged upstream.

gcwnow/linux 44

Linux kernel for GCW Zero (Ingenic JZ4770)

laanwj/bitcoin 30

Laanwj's Bitcoin Core fork - see README.md on "readme" branch

bitcoinmeetups/bitcoinmeetups.github.com 14

Bitcoin Challenges, Meetups and Services, Exchange, Giveaways, Tipping, Ethereum, Counterparty, Dogeparty, ChangeTip, Tokens, Skype Groups, Lists, Projects, Sidechains, Maidsafe, CoinFactory, Git, Open Source, Incubator, Mastercoin, DAC, DAO, Bitshares, BitcoinX, Open-Transactions, Ripple, Bitcoin, Litecoin, Altcoins

laanwj/ast_pickler 4

Proof of concept serialization library that generates the Python code to construct objects.

laanwj/blockdb-troubleshoot 3

Bitcoin block database troubleshooting tools

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

Not sure if I understand your question in part "producing GitHub review"...

In Github web interface, we can go to "Files changed" tab, check "Viewed" checkboxes on the files, and click "Review changes" -> "Submit review", which produces sort of "special" kind of "comment". Maybe it's "better" for maintainers to check for these kind of "reviews", instead of "just" a comment?

hebasto

comment created time in 3 minutes

issue commentbitcoin-core/gui

bitcoinbuilds.org macOS CI is broken

It should adopt https://github.com/bitcoin/bitcoin/pull/19817 changes.

Sjors

comment created time in 10 minutes

pull request commentbitcoin-core/gui

WIP qt: mempool stats chart

I would prefer MB over count too if it's not too difficult. I might take a look a later to see how...

Can you split this PR a bit? E.g. one commit for the src/interfaces changes, one for mempoolstats.cpp (which probably should mostly be moved out of the GUI code), one for the UI change, etc.

RandyMcMillan

comment created time in 14 minutes

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::SelectCoinsMinConf(const CAmount& nTargetValue, const CoinEligibil     if (coin_selection_params.use_bnb) {         std::vector<OutputGroup> positive_groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, effective_feerate, coin_selection_params.m_long_term_feerate, eligibility_filter, true /* positive_only */);         bnb_used = true;-        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet, not_input_fees);+        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet);     } else {         // The knapsack solver has some legacy behavior where it will spend dust outputs. We retain this behavior, so don't filter for positive only here.         // The knapsack solver currently does not use effective values, so we give GroupOutputs feerates of 0 so it sets the effective values to be the same as the real value.         std::vector<OutputGroup> groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, CFeeRate(0), CFeeRate(0), eligibility_filter, false /* positive_only */);          bnb_used = false;-        return KnapsackSolver(nTargetValue, groups, setCoinsRet, nValueRet);+        return KnapsackSolver(nTargetValue + coin_selection_params.m_change_fee, groups, setCoinsRet, nValueRet);

In commit "Roll not_input_fees into nValueToSelect instead of having it be separate" (534917d11c12a713b39708290f51f495f370a66d)

Thanks for new code comments, very helpful. IIUC. I'm still a little surprised to see this change here in this commit, instead of in it's own commit or in the "Have KnapsackSolver actually use effective values" commit. Everything else in this commit is not a change in behavior, but this one change passing a higher target to KnapsackSolver is a change in behavior? If this is the case, it would be nice to split this up into two commits, or alternately say how the two different parts of this change are dependent in the commit message.

I'm also curious about tradeoffs with the new behavior. This is probably just my ignorance, but I don't know if it is strictly better to target the change cost, or if there are there expected cases where targeting no-change cost would be better. Would be nice to be able to understand more of this background thinking from the code comment or commit message.

achow101

comment created time in 29 minutes

Pull request review commentbitcoin/bitcoin

Add prune blockers to BlockManager

 int BlockManager::GetSpendHeight(const CCoinsViewCache& inputs)     return pindexPrev->nHeight + 1; } +const CBlockIndex* BlockManager::GetLastPruneBlock(const CBlockIndex* start_block) {+    const CBlockIndex* block = start_block;+    CHECK_NONFATAL(block);

Thanks! I made the changes as suggested.

fjahr

comment created time in 20 minutes

Pull request review commentbitcoin/bitcoin

wallet: Fix issues when `walletdir` is root directory(Windows)

 std::vector<fs::path> ListDatabases(const fs::path& wallet_dir)         try {             // Get wallet path relative to walletdir by removing walletdir from the wallet path.             // This can be replaced by boost::filesystem::lexically_relative once boost is bumped to 1.60.-            const fs::path path = it->path().string().substr(offset);+            fs::path path = wallet_dir.string();

You could still keep path const as before, by utilizing immediately-invoked lambda, as suggested in ES.28: Use lambdas for complex initialization, especially of const variables guideline, with something like this (also avoiding re-initializing path variable):

            const fs::path path = [&wallet_dir, &it, offset]() {

                if (wallet_dir == wallet_dir.root_path()) {
                   return it->path().string().substr(offset - 1);
                }

                return it->path().string().substr(offset);
            }();

Not sure if this is the best way to do that overall, as I don't have basically any experience with boost/stl filesystem...

prayank23

comment created time in 25 minutes

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

That's indeed the main reason I wrote this, though I can see how it's useful for redownloading pruned blocks too.

I'm using this for ForkMonitor to fetch stale blocks and compare the transactions, to see if there was a double-spend: https://forkmonitor.info/stale/btc/679823

Sjors

comment created time in 27 minutes

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

Oh, I see. I missed that fetching non-main-chain blocks was a goal here.

Why would you want that?

Sjors

comment created time in 29 minutes

issue openedbitcoin-core/gui

bitcoinbuilds.org macOS CI is broken

See e.g. https://github.com/bitcoin-core/gui/pull/325 build log: https://bitcoinbuilds.org/index.php?ansilog=be6bfe20-7e28-4344-9664-6ae1ff46dbb9.log

4643   In file included from ./boost/config.hpp:44:
L4644   ./boost/config/detail/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
L4645   #  include <cstddef>
L4646              ^~~~~~~~~
L4647   1 error generated.

cc @jonasschnelli

created time in 30 minutes

issue commentbitcoin/bitcoin

ci: ccache does not work for macOS cross-compiling builds

Urgh... That kinda sucks... I think the easiest solution is perhaps to wait until ccache 4.1 is available on all distros and set compiler_type/CCACHE_COMPILERTYPE?

hebasto

comment created time in 34 minutes

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::CreateTransactionInternal(                     return false;                 } -                nFeeNeeded = coin_selection_params.m_effective_feerate.GetFee(nBytes);-                if (nFeeRet >= nFeeNeeded) {-                    // Reduce fee to only the needed amount if possible. This-                    // prevents potential overpayment in fees if the coins-                    // selected to meet nFeeNeeded result in a transaction that-                    // requires less fee than the prior iteration.--                    // If we have no change and a big enough excess fee, then-                    // try to construct transaction again only without picking-                    // new inputs. We now know we only need the smaller fee-                    // (because of reduced tx size) and so we should add a-                    // change output. Only try this once.-                    if (nChangePosInOut == -1 && nSubtractFeeFromAmount == 0 && pick_new_inputs) {-                        unsigned int tx_size_with_change = nBytes + coin_selection_params.change_output_size + 2; // Add 2 as a buffer in case increasing # of outputs changes compact size-                        CAmount fee_needed_with_change = coin_selection_params.m_effective_feerate.GetFee(tx_size_with_change);-                        CAmount minimum_value_for_change = GetDustThreshold(change_prototype_txout, coin_selection_params.m_discard_feerate);-                        if (nFeeRet >= fee_needed_with_change + minimum_value_for_change) {-                            pick_new_inputs = false;-                            nFeeRet = fee_needed_with_change;-                            continue;-                        }-                    }

I think the key thing in understanding this code is that nChange (now named change_and_fee) was actually supposed to just be the change. nValueToSelect includes the nFeeRet from the previous iteration. So we could have nChange == 0 if we select exactly enough to cover the recipient amount + previous nFeeRet. That would cause this code to trigger.

achow101

comment created time in 40 minutes

pull request commentbitcoin/bitcoin

wallet: Fix issues when `walletdir` is root directory(Windows)

Welp, I did crazy thing and launched bitcoind as root, with:

sudo src/bitcoind -regtest -walletdir=/ -datadir=/tmp/datadir -server

Created wallet, and then listed:

{
  "wallets": [
    {
      "name": "est"
    },
    {
      "name": "ome/vincas/.bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-8198c6f7-2f0b-4394-a92a-d4d738994f33/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-9063e6a5-c013-4127-a7dd-a10a3874ed18/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-e9783f5b-51ab-458f-ab57-31976e38bff8/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-f1c34eba-d63e-4379-a315-75056bbcc162/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-d4096df3-5adb-40dd-9425-6f80fb6fd07b/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-e6a27da9-a78e-48a5-a272-38a950ddfd41/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/bitcoin/123-bitcoin-core-gui.git/test/functional/data/wallets/high_minversion"
    },
    {
      "name": "ome/vincas/code/bitcoin/149-bitcoin-core-gui.git/test/functional/data/wallets/high_minversion"
    }
  ]
}

Interesting to see bitcoind scan whole system for wallets :D (log even printed ListDatabases: Error scanning /sys/fs/bpf: boost::filesystem::status: Operation not permitted: "/sys/fs/bpf/wallet.dat").

Anyhow, issue is the same on Linux, and this PR did fix that too:

{
  "wallets": [
    {
      "name": "test"
    },
...same...
prayank23

comment created time in 41 minutes

Pull request review commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

 def test_rpc(self):         assert_equal(json0["vin"][0]["sequence"], 4294967293)         assert_equal(json1["vin"][0]["sequence"], 4294967294) +    def test_no_inherited_signaling(self):+        # Send tx from which to conflict outputs later+        base_txid = self.nodes[0].sendtoaddress(self.nodes[0].getnewaddress(), Decimal("10"))+        self.nodes[0].generate(1)+        self.sync_blocks()++        # Create a explicitly opting parent transaction+        optin_parent_tx = self.nodes[0].createrawtransaction([{+            'txid': base_txid,+            'vout': 0,+            "sequence": 0xfffffffd,+        }], {self.nodes[0].getnewaddress(): Decimal("9.99998")})++        optin_parent_tx = self.nodes[0].signrawtransactionwithwallet(optin_parent_tx)++        # Broadcast parent tx+        optin_parent_txid = self.nodes[0].sendrawtransaction(hexstring=optin_parent_tx["hex"], maxfeerate=0)+        assert optin_parent_txid in self.nodes[0].getrawmempool()++        replacement_parent_tx = self.nodes[0].createrawtransaction([{+            'txid': base_txid,+            'vout': 0,+            "sequence": 0xfffffffd,+        }], {self.nodes[0].getnewaddress(): Decimal("9.90000")})++        replacement_parent_tx = self.nodes[0].signrawtransactionwithwallet(replacement_parent_tx)++        # Test if parent tx can be replaced.+        res = self.nodes[0].testmempoolaccept(rawtxs=[replacement_parent_tx['hex']], maxfeerate=0)[0]++        # Parent can be replaced.+        assert_equal(res['allowed'], True)++        # Create a optout child tx spending opting parent+        optout_child_tx = self.nodes[0].createrawtransaction([{+            'txid': optin_parent_txid,+            'vout': 0,+            "sequence": 0xffffffff,+        }], {self.nodes[0].getnewaddress(): Decimal("9.99990")})++        optout_child_tx = self.nodes[0].signrawtransactionwithwallet(optout_child_tx)++        # Broadcast child tx+        optout_child_txid = self.nodes[0].sendrawtransaction(hexstring=optout_child_tx["hex"], maxfeerate=0)+        assert optout_child_txid in self.nodes[0].getrawmempool()++        replacement_child_tx = self.nodes[0].createrawtransaction([{+            'txid': optin_parent_txid,+            'vout': 0,+            "sequence": 0xffffffff,+        }], {self.nodes[0].getnewaddress(): Decimal("9.00000")})++        replacement_child_tx = self.nodes[0].signrawtransactionwithwallet(replacement_child_tx)++        # Broadcast replacement child tx+        # BIP 125 :+        # 1. The original transactions signal replaceability explicitly or through inheritance as described in the above+        # Summary section.

This is a good place to refer to the CVE so it's clear the behaviour here is not following BIP125.

ariard

comment created time in an hour

pull request commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

utACK fb2047b

ariard

comment created time in an hour

pull request commentbitcoin-core/secp256k1

VERIFY_CHECK precondition for secp256k1_fe_set_int.

@roconnor-blockstream Maybe cherry-pick https://github.com/bitcoin-core/secp256k1/pull/636/commits/b17a7df8145a6a86d49c354c7e7b59a432ea5346 (or just steal my improved comment for here.) and then add the VERIFY_CHECK here.

roconnor-blockstream

comment created time in an hour

pull request commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

Also, I had a look on the rest of RBF functional test coverage (i.e feature_rbf.py, mempool_accept.py, p2p_invalid_tx.py). AFAICT, the latest check on incremental relay fee increase doesn't seem to have coverage ?

ariard

comment created time in an hour

PR opened bitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

Contrary to BIP125 or other full-node implementation (e.g btcd), Bitcoin Core's mempool policy doesn't implement inherited signaling.

This PR documents our mempool behavior on it and add a test demonstrating the case.

+73 -4

0 comment

2 changed files

pr created time in an hour

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

@sipa we don't fetch a block if we already have one for that height. So if you're trying retrieve the losing block from a race, most likely your peers also saw it later and didn't fetch it.

Sjors

comment created time in an hour

pull request commentbitcoin-core/secp256k1

VERIFY_CHECK precondition for secp256k1_fe_set_int.

This PR overlaps with https://github.com/bitcoin-core/secp256k1/pull/636.

roconnor-blockstream

comment created time in an hour

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

@Talkless

Wait @hebasto, a bit off topic, should I have had to make actual GitHub review in this interface, or comment is enough? Maybe sticking to always checking all files and producing GitHub review would be "better"?

Not sure if I understand your question in part "producing GitHub review"...

Anyway, your https://github.com/bitcoin-core/gui/pull/123#issuecomment-840720795 is straightforward. While reviewing pulls after rebasing I do the same locally git range-diff master pr-before-rebase pr-after-rebase. If rebasing is not trivial it could be valuable re-check all changes.

hebasto

comment created time in an hour

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::CreateTransactionInternal(                     return false;                 } -                nFeeNeeded = coin_selection_params.m_effective_feerate.GetFee(nBytes);-                if (nFeeRet >= nFeeNeeded) {-                    // Reduce fee to only the needed amount if possible. This-                    // prevents potential overpayment in fees if the coins-                    // selected to meet nFeeNeeded result in a transaction that-                    // requires less fee than the prior iteration.--                    // If we have no change and a big enough excess fee, then-                    // try to construct transaction again only without picking-                    // new inputs. We now know we only need the smaller fee-                    // (because of reduced tx size) and so we should add a-                    // change output. Only try this once.-                    if (nChangePosInOut == -1 && nSubtractFeeFromAmount == 0 && pick_new_inputs) {-                        unsigned int tx_size_with_change = nBytes + coin_selection_params.change_output_size + 2; // Add 2 as a buffer in case increasing # of outputs changes compact size-                        CAmount fee_needed_with_change = coin_selection_params.m_effective_feerate.GetFee(tx_size_with_change);-                        CAmount minimum_value_for_change = GetDustThreshold(change_prototype_txout, coin_selection_params.m_discard_feerate);-                        if (nFeeRet >= fee_needed_with_change + minimum_value_for_change) {-                            pick_new_inputs = false;-                            nFeeRet = fee_needed_with_change;-                            continue;-                        }-                    }

It's change boosting but in the case where we don't have change.

It's the same scenario as change boosting, but instead of having selected more than enough to cover the fees from the previous iteration, we have selected exactly enough to cover those fees. But in this second iteration, there are fewer inputs, so fewer fees, so we need to add a change output because there is no existing change to boost.

I keep linking to line 2683: https://github.com/bitcoin/bitcoin/blob/0f402b9263b0579b29aa0f841fc64ad58d3efba6/src/wallet/wallet.cpp#L2683

Because in every case where the code below it (line 2766) would seemingly need to add a change output, it seems like this line would already have added it. This line happens after selecting coins in the same iteration of the while loop. My only understanding (which makes no sense) is that the code is selecting coins, seeing if a change output needs to be added, then adding it on line 2683. Then seeing if a change output needs to be added again on line 2766, but this code can never trigger because the change output should be already added.

If the code added in 0f402b9263b0579b29aa0f841fc64ad58d3efba6 is just nonsense that doesn't do anything, then it should be safe to drop. And it could be safe to drop anyway. Everything else in this PR looks good, just these CreateTransactionInternal changes are still pretty opaque to me.

achow101

comment created time in an hour

PR opened bitcoin-core/ctaes

Port to windows

This PR adds a couple changes to port this library to a Windows environment.

build system

Added a CMakeLists.txt for a simple portable build system across OS's. It has been carefully written and annotated with comments for easy consumption and portability. This lets a user using Windows and *nix-like environment to build this project with a variety of "generators"(Make, Ninja, Visual Studio) and compilers.

The directory structure created for install looks as follows assuming its installed to the default /usr/local:

/usr/local/ctaes/
    include/
        ctaes.h   // <-- our header
    lib/
        libctaes.a //   <--- our library
        cmake/
            ctaes/
                 ctaesConfig.cmake    // <--- config for other CMake projects to consume
    

The defaults provided by CMake are nearly always right and one could pass specific configs to the terminal on Windows10 with something like, provided you have clang in your path:

cmake . -DCMAKE_C_COMPILER=clang

Lines 35-43 are the "toughest" to digest, but they essentially describe how to install the library and header along with a config file for other CMake projects to consume this library.

bench.c

The function gettimeofday does not exist within the win32 environment and so to keep the same functionality, we just define an equivalent form of it.

README

Shows how to build with CMake.

How it looks on Ubuntu via WSL2 (but also tested on standalone ubuntu)
user@DESKTOP-VCPLNO0:/tmp/ctaes$ cmake . -B build/ -DCMAKE_BUILD_TYPE=MinSizeRel -DCMAKE_INSTALL_PREFIX=./build/output
-- C flags being used: -Wall -Wextra -Wundef -Wpointer-arith -Wconversion
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ctaes/build
user@DESKTOP-VCPLNO0:/tmp/ctaes$ cmake . -B build/ -DCMAKE_BUILD_TYPE=MinSizeRel
-- C flags being used: -Wall -Wextra -Wundef -Wpointer-arith -Wconversion
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ctaes/build
user@DESKTOP-VCPLNO0:/tmp/ctaes$ cmake --install build/
-- Install configuration: "MinSizeRel"
-- Installing: /tmp/ctaes/build/output/lib/libctaes.a
-- Installing: /tmp/ctaes/build/output/include/ctaes.h
-- Installing: /tmp/ctaes/build/output/lib/cmake/ctaes/ctaesConfig.cmake
-- Installing: /tmp/ctaes/build/output/lib/cmake/ctaes/ctaesConfig-minsizerel.cmake
How it looks on Windows10 using the "Windows Terminal" (a slick wrapper around PowerShell)
PS C:\Users\user\Downloads\ctaes> cmake . -B build/ -DCMAKE_BUILD_TYPE=MinSizeRel
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.21376.
-- C flags being used: /Wall /sdl /MP
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/william/Downloads/ctaes/build
PS C:\Users\user\Downloads\ctaes> cmake --build build/ --config MinSizeRel
Microsoft (R) Build Engine version 16.9.0+5e4b48a27 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

  Checking Build System
  Building Custom Rule C:/Users/user/Downloads/ctaes/CMakeLists.txt
  ctaes.vcxproj -> C:\Users\user\Downloads\ctaes\build\MinSizeRel\ctaes.lib
  Building Custom Rule C:/Users/user/Downloads/ctaes/CMakeLists.txt
  bench.vcxproj -> C:\Users\user \Downloads\ctaes\build\MinSizeRel\bench.exe
  Building Custom Rule C:/Users/user/Downloads/ctaes/CMakeLists.txt
  tests.vcxproj -> C:\Users\user\Downloads\ctaes\build\MinSizeRel\tests.exe
  Building Custom Rule C:/Users/user/Downloads/ctaes/CMakeLists.txt

For the windows user, they can perform the first step of generating the build files and then open up the "sln" file on their Visual Studio and go down that route as well.

+77 -2

0 comment

3 changed files

pr created time in an hour

PR opened bitcoin/bitcoin

test: add P2PK support to MiniWallet

This PR adds support for creating and spending transactions with raw pubkey (P2PK) outputs to MiniWallet, as suggested by MarcoFalke. Using that mode in the test feature_csv_activation.py, all txs submitted to the mempool follow the standard policy, i.e. -acceptnonstdtxn=1 can be removed.

Possible follow-ups:

  • Improve MiniWallet constructor Interface; an enum-like parameter instead of two booleans would probably be better
  • Look at other tests that could benefit from P2PK (e.g. feature_cltv.py?)
  • Check vsize also for P2PK txs (vsize varies due to signature, i.e. a range has to be asserted)
+44 -8

0 comment

2 changed files

pr created time in an hour

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

Wait @hebasto, a bit off topic, should I have had to make actual GitHub review in this interface, or comment is enough? Maybe sticking to always checking all files and producing GitHub review would be "better"?

hebasto

comment created time in an hour

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

re-utACK 716139584ddf7ef554962e0188ae8b8a74e310e4, range-diff does not show anything to actually review or test.

hebasto

comment created time in 2 hours

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

Yes, I imagine it'd use the "background' fetching logic in SendMessages, not the direct fetch in response to an announcement one.

Sjors

comment created time in 2 hours

pull request commentbitcoin/bitcoin

build: Fix undefined reference to __mulodi4

The steps to reproduce from https://github.com/bitcoin/bitcoin/pull/21920#issue-641280284 can be used here as well

hebasto

comment created time in 2 hours

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

In practice I'm already able to use this PR to fetch stale blocks by simply looping over my peers and "spamming" them all. I then disconnect if the block doesn't show up, connect to random new peers and then try again.

So although the current incarnation is not ideal, it's already useful. A revamp of ProcessHeadersMessage with a separate block download manager sounds doesn't sound easy to me. It also needs different timeout rules than IBD, because most of the time a peer won't have the block.

The use case of re-fetching pruned blocks is more similar to IBD, since you can expect every non-pruned node with sufficiently high pindexLastCommonBlock to have it.

Sjors

comment created time in 2 hours

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

@Sjors Sure, but that doesn't sound too hard to add. And doing it that way sounds a lot more useful.

Sjors

comment created time in 2 hours

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

@sipa the current block fetching logic is buried deep inside net_processing. A MSG_BLOCK is generated when processing received headers:

https://github.com/bitcoin/bitcoin/blob/4741aec1dd28829f45abcc529cddaa0ff04d07a0/src/net_processing.cpp#L2011-L2021

Or when receiving a block: https://github.com/bitcoin/bitcoin/blob/4741aec1dd28829f45abcc529cddaa0ff04d07a0/src/net_processing.cpp#L1733-L1739

There doesn't seem to be a queue of blocks to fetch that's distributed over peers and checked in a background process.

Sjors

comment created time in 2 hours