💬 pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1214502463)
We won't attempt an anchor connection to a host that doesn't have services:
https://github.com/bitcoin/bitcoin/blob/b22408df162a224d94ac54e8443b57ef3fd2ca72/src/net.cpp#L1813
In the test we don't actually bother setting up a listening node at the onion address we connect to with `block-relay-only` so the services remain null, even though we do still write the host information to anchors.dat
I use this hack to ensure that we attempt a connection, and the last assertion in the test will f
...
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1214502463)
We won't attempt an anchor connection to a host that doesn't have services:
https://github.com/bitcoin/bitcoin/blob/b22408df162a224d94ac54e8443b57ef3fd2ca72/src/net.cpp#L1813
In the test we don't actually bother setting up a listening node at the onion address we connect to with `block-relay-only` so the services remain null, even though we do still write the host information to anchors.dat
I use this hack to ensure that we attempt a connection, and the last assertion in the test will f
...
💬 pinheadmz commented on issue "Processing of new blocks slower than necessary due to overly selective peer selection":
(https://github.com/bitcoin/bitcoin/issues/21803#issuecomment-1573896728)
Sweet thanks. @rebroad feel free to comment if you think this is still an issue on master now, we can reopen if need be.
(https://github.com/bitcoin/bitcoin/issues/21803#issuecomment-1573896728)
Sweet thanks. @rebroad feel free to comment if you think this is still an issue on master now, we can reopen if need be.
✅ pinheadmz closed an issue: "Processing of new blocks slower than necessary due to overly selective peer selection"
(https://github.com/bitcoin/bitcoin/issues/21803)
(https://github.com/bitcoin/bitcoin/issues/21803)
💬 pinheadmz commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1214507584)
thanks, fixed.
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1214507584)
thanks, fixed.
🚀 fanquake merged a pull request: "refactor: rpc: Remove unnecessary uses of ParseNonRFCJSONValue() and rename it"
(https://github.com/bitcoin/bitcoin/pull/27256)
(https://github.com/bitcoin/bitcoin/pull/27256)
💬 pinheadmz commented on pull request "Support JSON-RPC 2.0 when requested by client":
(https://github.com/bitcoin/bitcoin/pull/27101#issuecomment-1573916898)
> 🐙 This pull request conflicts with the target branch and [needs rebase](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes).
done, very easy with scripted diff!
(https://github.com/bitcoin/bitcoin/pull/27101#issuecomment-1573916898)
> 🐙 This pull request conflicts with the target branch and [needs rebase](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes).
done, very easy with scripted diff!
💬 fanquake commented on pull request "Updated the installation instructions for macOS":
(https://github.com/bitcoin/bitcoin/pull/27525#issuecomment-1573922184)
Thanks, however we are going to leave this as-is for now. Generic changes to build docs are better suited if PR'd against all platforms, not sure we need to make the other additions.
(https://github.com/bitcoin/bitcoin/pull/27525#issuecomment-1573922184)
Thanks, however we are going to leave this as-is for now. Generic changes to build docs are better suited if PR'd against all platforms, not sure we need to make the other additions.
✅ fanquake closed a pull request: "Updated the installation instructions for macOS"
(https://github.com/bitcoin/bitcoin/pull/27525)
(https://github.com/bitcoin/bitcoin/pull/27525)
💬 petertodd commented on pull request "Remove -mempoolfullrbf option":
(https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1573923355)
FYI it appears that in addition to Luxor, AntPool and possibly one or two other pools are mining full-rbf replacements now with at least some of their hashing power. Wasabi also recently had a [double-spend](https://twitter.com/Turbolay/status/1654517651862065152) that would have been resolved with full-rbf, exactly as I and others have been arguing. Binance also appears to be [doing full-rbf replacements](https://twitter.com/mononautical/status/1664412056227921920) to bump-fees on their consoli
...
(https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1573923355)
FYI it appears that in addition to Luxor, AntPool and possibly one or two other pools are mining full-rbf replacements now with at least some of their hashing power. Wasabi also recently had a [double-spend](https://twitter.com/Turbolay/status/1654517651862065152) that would have been resolved with full-rbf, exactly as I and others have been arguing. Binance also appears to be [doing full-rbf replacements](https://twitter.com/mononautical/status/1664412056227921920) to bump-fees on their consoli
...
👍 fanquake approved a pull request: "doc: document json rpc endpoints"
(https://github.com/bitcoin/bitcoin/pull/27225#pullrequestreview-1457807717)
ACK 65e3abcbf2b9e818f3b9f1ba35f3cfe7df5e3811 - Seems fine. Can be improved if need be.
(https://github.com/bitcoin/bitcoin/pull/27225#pullrequestreview-1457807717)
ACK 65e3abcbf2b9e818f3b9f1ba35f3cfe7df5e3811 - Seems fine. Can be improved if need be.
✅ fanquake closed an issue: "Document JSON-RPC wallet endpoints"
(https://github.com/bitcoin/bitcoin/issues/20246)
(https://github.com/bitcoin/bitcoin/issues/20246)
🚀 fanquake merged a pull request: "doc: document json rpc endpoints"
(https://github.com/bitcoin/bitcoin/pull/27225)
(https://github.com/bitcoin/bitcoin/pull/27225)
💬 fanquake commented on pull request "guix: remove cURL from build env":
(https://github.com/bitcoin/bitcoin/pull/27779#issuecomment-1573938880)
> is the optimal shortcut.
I think I'd rather remove all the dead code. The option confusion comes from the fact that these flags seem to just fail silently if the relevant libraries haven't been compiled/installed with CMake, which I was look at for 2.6.
(https://github.com/bitcoin/bitcoin/pull/27779#issuecomment-1573938880)
> is the optimal shortcut.
I think I'd rather remove all the dead code. The option confusion comes from the fact that these flags seem to just fail silently if the relevant libraries haven't been compiled/installed with CMake, which I was look at for 2.6.
💬 ryanofsky commented on pull request "kernel: Remove shutdown from kernel library":
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214538307)
'> Thank you for your comprehensive answer. I think it boils down to: A fatal error should not necessarily have to trigger an interrupt for all kernel operations.
Yes, this is definitely a goal. Libbitcoinkernel should try to be a library, not an application or application framework. It should have a convenient way of cancelling operations and not force everything to use one shutdown variable.
But both the current PR and my branch do already support this. The main difference between the PR
...
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214538307)
'> Thank you for your comprehensive answer. I think it boils down to: A fatal error should not necessarily have to trigger an interrupt for all kernel operations.
Yes, this is definitely a goal. Libbitcoinkernel should try to be a library, not an application or application framework. It should have a convenient way of cancelling operations and not force everything to use one shutdown variable.
But both the current PR and my branch do already support this. The main difference between the PR
...
💬 virtu commented on issue "Intermittent failures in interface_usdt_mempool.py":
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1573950719)
@0xB10C and I had a look at this today. Here's what we found so far:
1. We believe the issue is caused by [one or more of the assertions](https://github.com/bitcoin/bitcoin/blob/b22408df162a224d94ac54e8443b57ef3fd2ca72/test/functional/interface_usdt_mempool.py#L306-L307) failing in the `handle_rejected_event` callback (although we are not sure why they fail).
2. The test framework's `assert_equal()` communicates failed assertions via exceptions. Unfortunately exceptions raised in bcc callback
...
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1573950719)
@0xB10C and I had a look at this today. Here's what we found so far:
1. We believe the issue is caused by [one or more of the assertions](https://github.com/bitcoin/bitcoin/blob/b22408df162a224d94ac54e8443b57ef3fd2ca72/test/functional/interface_usdt_mempool.py#L306-L307) failing in the `handle_rejected_event` callback (although we are not sure why they fail).
2. The test framework's `assert_equal()` communicates failed assertions via exceptions. Unfortunately exceptions raised in bcc callback
...
💬 TheCharlatan commented on pull request "kernel: Remove shutdown from kernel library":
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214545050)
> Also in both cases, it would be better if the kernel wasn't deciding itself whether to return early, but instead asked the application through std::function callbacks. I.e. there could be a std::function callbacks for "I just a new chain tip, should I keep processing or return early?" that would be more general than having hardcoded -stopatheight logic in the kernel.
How about making `startShutdown` return a boolean then that can be interpreted by calling code to either terminate the funct
...
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214545050)
> Also in both cases, it would be better if the kernel wasn't deciding itself whether to return early, but instead asked the application through std::function callbacks. I.e. there could be a std::function callbacks for "I just a new chain tip, should I keep processing or return early?" that would be more general than having hardcoded -stopatheight logic in the kernel.
How about making `startShutdown` return a boolean then that can be interpreted by calling code to either terminate the funct
...
💬 ryanofsky commented on pull request "init: Error if ignored bitcoin.conf file is found":
(https://github.com/bitcoin/bitcoin/pull/27302#issuecomment-1573955807)
No I still need to figure out what the last message https://github.com/bitcoin/bitcoin/issues/27246#issuecomment-1558537251 means, and finish #27409 to fix the ["Unfortunately the behavior for bitcoin-qt is stupider than bitcoind..."](https://github.com/bitcoin/bitcoin/issues/27246#issuecomment-1470284856) issue
(https://github.com/bitcoin/bitcoin/pull/27302#issuecomment-1573955807)
No I still need to figure out what the last message https://github.com/bitcoin/bitcoin/issues/27246#issuecomment-1558537251 means, and finish #27409 to fix the ["Unfortunately the behavior for bitcoin-qt is stupider than bitcoind..."](https://github.com/bitcoin/bitcoin/issues/27246#issuecomment-1470284856) issue
💬 pinheadmz commented on pull request "wallet: Add wallet method to detect if a key is "active"":
(https://github.com/bitcoin/bitcoin/pull/27216#discussion_r1214557458)
Thanks, both comments addressed with rebase
(https://github.com/bitcoin/bitcoin/pull/27216#discussion_r1214557458)
Thanks, both comments addressed with rebase
🚀 fanquake merged a pull request: "walletdb: Add PrefixCursor"
(https://github.com/bitcoin/bitcoin/pull/27790)
(https://github.com/bitcoin/bitcoin/pull/27790)
💬 ryanofsky commented on pull request "kernel: Remove shutdown from kernel library":
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214568318)
> How about making `startShutdown` return a boolean then that can be interpreted by calling code to either terminate the function or continue?
I think it's best if the notification interfaces just streamed notifications in one direction to the application, to update its UI, or trigger tasks like starting other services, saving state, freeing up disk space, or shutting down.
The notifications interface seems like an awkward way to send information the other direction from the application t
...
(https://github.com/bitcoin/bitcoin/pull/27711#discussion_r1214568318)
> How about making `startShutdown` return a boolean then that can be interpreted by calling code to either terminate the function or continue?
I think it's best if the notification interfaces just streamed notifications in one direction to the application, to update its UI, or trigger tasks like starting other services, saving state, freeing up disk space, or shutting down.
The notifications interface seems like an awkward way to send information the other direction from the application t
...