💬 glozow commented on pull request "[NO MERGE] BIP331 Ancestor Package Relay":
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214497418)
Basically arbitrary. The relevance is basically which peer's message processing is blocked to process this, and would get a misbehaving score if the tx is invalid. Anyone who announced it is equally deserving of this burden imo. I suppose a more fair way to pick is uniformly randomly.
(https://github.com/bitcoin/bitcoin/pull/27742#discussion_r1214497418)
Basically arbitrary. The relevance is basically which peer's message processing is blocked to process this, and would get a misbehaving score if the tx is invalid. Anyone who announced it is equally deserving of this burden imo. I suppose a more fair way to pick is uniformly randomly.
💬 instagibbs commented on issue "Processing of new blocks slower than necessary due to overly selective peer selection":
(https://github.com/bitcoin/bitcoin/issues/21803#issuecomment-1573888486)
I believe so. A headers peer announcing first doesn't preclude follow-on compact block messages anymore, within some limits of peer type.
(https://github.com/bitcoin/bitcoin/issues/21803#issuecomment-1573888486)
I believe so. A headers peer announcing first doesn't preclude follow-on compact block messages anymore, within some limits of peer type.
💬 Harshil-Jani commented on issue "Log which peer sent us a header (first)":
(https://github.com/bitcoin/bitcoin/issues/27744#issuecomment-1573894340)
Hey !! I am new into bitcoin developement and if no one is already working to do this change, I am willing to do this.
(https://github.com/bitcoin/bitcoin/issues/27744#issuecomment-1573894340)
Hey !! I am new into bitcoin developement and if no one is already working to do this change, I am willing to do this.
💬 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