💬 fanquake commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389692101)
cc @theStack
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389692101)
cc @theStack
🤔 glozow reviewed a pull request: "mempool: Persist with XOR"
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1725266416)
reACK fa6b053b5c964fb35935fa994cb782c0731a56f8
(https://github.com/bitcoin/bitcoin/pull/28207#pullrequestreview-1725266416)
reACK fa6b053b5c964fb35935fa994cb782c0731a56f8
💬 theStack commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389710284)
Good catch @kashifs. Do you want to open a PR for the fix? If not (for whatever reason), I'm happy to do it and add the commit with your authorship.
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389710284)
Good catch @kashifs. Do you want to open a PR for the fix? If not (for whatever reason), I'm happy to do it and add the commit with your authorship.
💬 instagibbs commented on pull request "fuzz: Minor improvements to tx_package_eval target":
(https://github.com/bitcoin/bitcoin/pull/28825#discussion_r1389748737)
yes, with the idea that the fuzzer won't be able to generate the preimage to all genuinely create null uint256/prevout
(https://github.com/bitcoin/bitcoin/pull/28825#discussion_r1389748737)
yes, with the idea that the fuzzer won't be able to generate the preimage to all genuinely create null uint256/prevout
💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1389838929)
I agree that would be nice, in particular so that we can enable `p2p_dos_header_tree.py` (which uses testnet instead of regtest) in combination with v2 transport. One possibility would be to move the `MAGIC_BYTES` constants from `p2p.py` into another file (e.g. `test_framework/messages.py`), change all includes, pass `net` to `EncryptedP2PState`, and change `V1_PREFIX` into a local variable using it)
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1389838929)
I agree that would be nice, in particular so that we can enable `p2p_dos_header_tree.py` (which uses testnet instead of regtest) in combination with v2 transport. One possibility would be to move the `MAGIC_BYTES` constants from `p2p.py` into another file (e.g. `test_framework/messages.py`), change all includes, pass `net` to `EncryptedP2PState`, and change `V1_PREFIX` into a local variable using it)
⚠️ lasermind opened an issue: "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`"
(https://github.com/bitcoin/bitcoin/issues/28847)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Although the blockchain is synced, after some minutes, `bitcoin-cli -getinfo` does not display `verification progress: 100.0000%` any more, but drops to `99.9999%` and even below.
New block arrived:
After two minutes:
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
Although the blockchain is synced, after some minutes, `bitcoin-cli -getinfo` does not display `verification progress: 100.0000%` any more, but drops to `99.9999%` and even below.
New block arrived:
After two minutes:
![verification-999999-hl](https://github.com/bitcoin
...
💬 pinheadmz commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806420963)
You'll find this question on stack exchange:
https://bitcoin.stackexchange.com/search?q=Progress
It can happen if the most recent block was mined too long ago. Essentially the node can only estimate how many blocks "should be" in the chain given the time. Your node doesn't know if there is a longer chain out there than what it already has, and so "progress" is just a guess.
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806420963)
You'll find this question on stack exchange:
https://bitcoin.stackexchange.com/search?q=Progress
It can happen if the most recent block was mined too long ago. Essentially the node can only estimate how many blocks "should be" in the chain given the time. Your node doesn't know if there is a longer chain out there than what it already has, and so "progress" is just a guess.
📝 instagibbs opened a pull request: "Change up submitpackage results"
(https://github.com/bitcoin/bitcoin/pull/28848)
This was prompted by errors being returned that didn't "make any sense" to me, because it would for example return a "fee too low" error, when the "real" error was the child had something invalid, which disallowed CPFP evaluation. Rather than make judgment calls on what error is important, we simply return all errors and let the callers determine what's best.
I'm not sure this is the best format, in that maybe we want to make failure cases more obvious. Maybe failures into its own top-level o
...
(https://github.com/bitcoin/bitcoin/pull/28848)
This was prompted by errors being returned that didn't "make any sense" to me, because it would for example return a "fee too low" error, when the "real" error was the child had something invalid, which disallowed CPFP evaluation. Rather than make judgment calls on what error is important, we simply return all errors and let the callers determine what's best.
I'm not sure this is the best format, in that maybe we want to make failure cases more obvious. Maybe failures into its own top-level o
...
💬 lasermind commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806447019)
I'm inclined to agree, that such a "probabilistic decrease" could be done when really the most recent block was mined "too long ago". But it happens regularly even after two minutes. This can't be "too long ago" when it is to assume that a new block happens every 10 minutes.
Also note: I'm **not** talking about the `progress` from the log file, which seems to sit happily at `1.000000`. I'm talking about the `verification progress` value, output by the command `bitcoin-cli -getinfo`, which sta
...
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806447019)
I'm inclined to agree, that such a "probabilistic decrease" could be done when really the most recent block was mined "too long ago". But it happens regularly even after two minutes. This can't be "too long ago" when it is to assume that a new block happens every 10 minutes.
Also note: I'm **not** talking about the `progress` from the log file, which seems to sit happily at `1.000000`. I'm talking about the `verification progress` value, output by the command `bitcoin-cli -getinfo`, which sta
...
💬 sipa commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806450388)
@lasermind A node is *always* synchronizing. It is never "done", because it cannot know whether a later block was already mined. So the number is just a ratio between the number of blocks it has divided by a guess for how many blocks should exist, on average. Even briefly after a block, it will be less than 100%.
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806450388)
@lasermind A node is *always* synchronizing. It is never "done", because it cannot know whether a later block was already mined. So the number is just a ratio between the number of blocks it has divided by a guess for how many blocks should exist, on average. Even briefly after a block, it will be less than 100%.
📝 kashifs opened a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849)
fix node index bug when comparing peerinfo in test/functional/p2p_v2_transport.py
(https://github.com/bitcoin/bitcoin/pull/28849)
fix node index bug when comparing peerinfo in test/functional/p2p_v2_transport.py
💬 kashifs commented on pull request "BIP324 integration":
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389939970)
I've opened a PR. Please let me know if it's done correctly and if there is more that I should do.
(https://github.com/bitcoin/bitcoin/pull/28331#discussion_r1389939970)
I've opened a PR. Please let me know if it's done correctly and if there is more that I should do.
💬 TheCharlatan commented on pull request "depends: remove `PYTHONPATH` from config.site":
(https://github.com/bitcoin/bitcoin/pull/28845#issuecomment-1806474583)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28845#issuecomment-1806474583)
Concept ACK
💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389968548)
`depth > 0 || (depth == 0 && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or: must not be (block) conflicted, and it must not be abandoned, for the corresponding output to be considered spent.
`mit->second.isConfirmed() || mit->second.InMempool() || (mit->second.isInactive() && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or in the mempool, or: must be inactive and not abandoned for the corresponding
...
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389968548)
`depth > 0 || (depth == 0 && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or: must not be (block) conflicted, and it must not be abandoned, for the corresponding output to be considered spent.
`mit->second.isConfirmed() || mit->second.InMempool() || (mit->second.isInactive() && !mit->second.isAbandoned())` is saying that the spending transaction should be confirmed, or in the mempool, or: must be inactive and not abandoned for the corresponding
...
👍 theStack approved a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725729898)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725729898)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180
🤔 mzumsande reviewed a pull request: "test: fix node index bug when comparing peerinfo"
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725745992)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180, good find!
(https://github.com/bitcoin/bitcoin/pull/28849#pullrequestreview-1725745992)
ACK 22e38080ea75c9efb1cb7d4643a1c79fdafa6180, good find!
👍 TheCharlatan approved a pull request: "depends: remove `PYTHONPATH` from config.site"
(https://github.com/bitcoin/bitcoin/pull/28845#pullrequestreview-1725750947)
ACK 95aab1f02784e5d92572ccfcd4ce27107e4b2888
There is nothing in that path anymore.
Guix builds (x86_64)
```
92c922498b9d7e68742355653cc84317d0f0947e8fdd012488c9875e8b54e03c guix-build-95aab1f02784/output/aarch64-linux-gnu/SHA256SUMS.part
634a6a7a82efcb86eb7e875aa4534bd5646e80ee21e951d9624ca7ff78fc82f5 guix-build-95aab1f02784/output/aarch64-linux-gnu/bitcoin-95aab1f02784-aarch64-linux-gnu-debug.tar.gz
2dd4305e325723cac4b0b8e1803d48f3d7eb6fa2fd49c0a980ff907bb3e5da2b guix-build-95aab1
...
(https://github.com/bitcoin/bitcoin/pull/28845#pullrequestreview-1725750947)
ACK 95aab1f02784e5d92572ccfcd4ce27107e4b2888
There is nothing in that path anymore.
Guix builds (x86_64)
```
92c922498b9d7e68742355653cc84317d0f0947e8fdd012488c9875e8b54e03c guix-build-95aab1f02784/output/aarch64-linux-gnu/SHA256SUMS.part
634a6a7a82efcb86eb7e875aa4534bd5646e80ee21e951d9624ca7ff78fc82f5 guix-build-95aab1f02784/output/aarch64-linux-gnu/bitcoin-95aab1f02784-aarch64-linux-gnu-debug.tar.gz
2dd4305e325723cac4b0b8e1803d48f3d7eb6fa2fd49c0a980ff907bb3e5da2b guix-build-95aab1
...
💬 ishaanam commented on pull request "wallet: track mempool conflicts with wallet transactions":
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389995261)
Because `tx3` replaced `tx2`, so `tx1` is now `TxStateInactive` instead of `TxStateMempoolConflicted`, making `unspents[0]` spent.
(https://github.com/bitcoin/bitcoin/pull/27307#discussion_r1389995261)
Because `tx3` replaced `tx2`, so `tx1` is now `TxStateInactive` instead of `TxStateMempoolConflicted`, making `unspents[0]` spent.
⚠️ luke-jr opened an issue: "Manpage for `-par` bolds lower bound"
(https://github.com/bitcoin/bitcoin/issues/28850)
```
\fB\-par=\fR<n>
.IP
Set the number of script verification threads (\fB\-10\fR to 15, 0 = auto, <0 =
leave that many cores free, default: 0)
```
`\fB` makes the `-10` bold, as if it were a parameter rather than a value.
(Additionally, the `-10` comes from the system of whoever ran the gen-manpages script, and should probably be generated deterministically here...)
(https://github.com/bitcoin/bitcoin/issues/28850)
```
\fB\-par=\fR<n>
.IP
Set the number of script verification threads (\fB\-10\fR to 15, 0 = auto, <0 =
leave that many cores free, default: 0)
```
`\fB` makes the `-10` bold, as if it were a parameter rather than a value.
(Additionally, the `-10` comes from the system of whoever ran the gen-manpages script, and should probably be generated deterministically here...)
💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390030476)
Hmm, that will only happen when the node is close to the tip, because of the 1024 block download window. More precisely, when the node is within 1312 blocks from the tip (window + limited peers threshold). Nice observation!.
Will modify it and add coverage for it.
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1390030476)
Hmm, that will only happen when the node is close to the tip, because of the 1024 block download window. More precisely, when the node is within 1312 blocks from the tip (window + limited peers threshold). Nice observation!.
Will modify it and add coverage for it.