💬 ryanofsky commented on pull request "Multiprocess bitcoin":
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-2737514540)
> From comments, it sounds like 19461 is closest, and provides the most functionality for the feature; would it make any sense to maybe change release order, putting 19461 (and a more complete #19460?) ahead of #31740 and #31741?
There isn't really a predefined order between #19461 and #31741 and the changes do not overlap so they they could be reviewed, tested, and merged in either order. The merge order will just depend on where people want to spend effort reviewing and testing. I expect #3
...
(https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-2737514540)
> From comments, it sounds like 19461 is closest, and provides the most functionality for the feature; would it make any sense to maybe change release order, putting 19461 (and a more complete #19460?) ahead of #31740 and #31741?
There isn't really a predefined order between #19461 and #31741 and the changes do not overlap so they they could be reviewed, tested, and merged in either order. The merge order will just depend on where people want to spend effort reviewing and testing. I expect #3
...
💬 Chand-ra commented on issue "test: No unit test covers BIP342 tapscript signatures":
(https://github.com/bitcoin/bitcoin/issues/32012#issuecomment-2737545631)
> Hi, [@jirijakes](https://github.com/jirijakes). I've tried to reproduce it but the unit test fails when running it with this mutation.
Hmm, I seem to be able to reproduce the bug with the following:
```
$ git diff
diff --git a/src/script/interpreter.cpp b/src/script/interpreter.cpp
index a35306b693..d9c119ae77 100644
--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -1484,7 +1484,7 @@ bool SignatureHashSchnorr(uint256& hash_out, ScriptExecutionData& execdata, cons
...
(https://github.com/bitcoin/bitcoin/issues/32012#issuecomment-2737545631)
> Hi, [@jirijakes](https://github.com/jirijakes). I've tried to reproduce it but the unit test fails when running it with this mutation.
Hmm, I seem to be able to reproduce the bug with the following:
```
$ git diff
diff --git a/src/script/interpreter.cpp b/src/script/interpreter.cpp
index a35306b693..d9c119ae77 100644
--- a/src/script/interpreter.cpp
+++ b/src/script/interpreter.cpp
@@ -1484,7 +1484,7 @@ bool SignatureHashSchnorr(uint256& hash_out, ScriptExecutionData& execdata, cons
...
💬 yancyribbens commented on pull request "multiprocess: Add bitcoin wrapper executable":
(https://github.com/bitcoin/bitcoin/pull/31375#issuecomment-2737580772)
Couldn't much of this be done by using a `just` file? I saw a PR a while that tried to add something about a `justfile` which is a way to wrap command to make them easier and more discoverable.
(https://github.com/bitcoin/bitcoin/pull/31375#issuecomment-2737580772)
Couldn't much of this be done by using a `just` file? I saw a PR a while that tried to add something about a `justfile` which is a way to wrap command to make them easier and more discoverable.
💬 Emzy commented on issue "29.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2737590259)
I tested the PCP functionality with v29.0rc2.
Started it like this on am3 mac ```/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net```
Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
First I got this for ipv4:
```
2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
2025-03-19T17:13:52Z [net] pcp: Receiv
...
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2737590259)
I tested the PCP functionality with v29.0rc2.
Started it like this on am3 mac ```/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net```
Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
First I got this for ipv4:
```
2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
2025-03-19T17:13:52Z [net] pcp: Receiv
...
💬 janb84 commented on issue "29.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2737599427)
> I tested the PCP functionality with v29.0rc2.
>
> Started it like this on my m3 mac `/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net`
>
> Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
>
> First I got this for ipv4:
>
> ```
> 2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
> 2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
> 2025-03-19T17:13:
...
(https://github.com/bitcoin/bitcoin/issues/32026#issuecomment-2737599427)
> I tested the PCP functionality with v29.0rc2.
>
> Started it like this on my m3 mac `/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net`
>
> Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
>
> First I got this for ipv4:
>
> ```
> 2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
> 2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
> 2025-03-19T17:13:
...
💬 Emzy commented on issue "Enable PCP by default?":
(https://github.com/bitcoin/bitcoin/issues/31663#issuecomment-2737605657)
I tested the PCP functionality with v29.0rc2.
Started it like this on my m3 mac ```/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net```
Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
First I got this for ipv4:
```
2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
2025-03-19T17:13:52Z [net] pcp: Rece
...
(https://github.com/bitcoin/bitcoin/issues/31663#issuecomment-2737605657)
I tested the PCP functionality with v29.0rc2.
Started it like this on my m3 mac ```/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -signet -natpmp=1 -debug=net```
Router is a FRITZ!Box 7530 AX with up to date firmware version 8.02.
First I got this for ipv4:
```
2025-03-19T17:13:52Z [net] pcp: Requesting port mapping for addr 0.0.0.0 port 38333 from gateway 192.168.99.1
2025-03-19T17:13:52Z [net] pcp: Internal address after connect: 192.168.99.114
2025-03-19T17:13:52Z [net] pcp: Rece
...
💬 zzzi2p commented on pull request "i2p: make a time gap between creating transient sessions and using them":
(https://github.com/bitcoin/bitcoin/pull/32065#issuecomment-2737607630)
Tunnels get built when the SAM session is opened, and are automatically rebuilt when they expire, the router does that for you as long as the SAM session stays open. A session is just a pool of inbound and outbound tunnels. I assume that's what you are trying to do here, have the session open and ready before it's needed.
(https://github.com/bitcoin/bitcoin/pull/32065#issuecomment-2737607630)
Tunnels get built when the SAM session is opened, and are automatically rebuilt when they expire, the router does that for you as long as the SAM session stays open. A session is just a pool of inbound and outbound tunnels. I assume that's what you are trying to do here, have the session open and ready before it's needed.
💬 ryanofsky commented on pull request "multiprocess: Add bitcoin wrapper executable":
(https://github.com/bitcoin/bitcoin/pull/31375#issuecomment-2737612354)
> Couldn't much of this be done by using a `just` file? I saw a PR a while that tried to add something about a `justfile` which is a way to wrap command to make them easier and more discoverable.
Yes it could also be done as a shell script or python script. If we could count on a justfile interpreter, or a portable shell, or python being installed on all platforms which bitcoin runs on, the changes in the two commits here a47cf680619cae5892d72355f56f5c5051fd5434 and cbc0bdd73ed0fd672307cf0f80
...
(https://github.com/bitcoin/bitcoin/pull/31375#issuecomment-2737612354)
> Couldn't much of this be done by using a `just` file? I saw a PR a while that tried to add something about a `justfile` which is a way to wrap command to make them easier and more discoverable.
Yes it could also be done as a shell script or python script. If we could count on a justfile interpreter, or a portable shell, or python being installed on all platforms which bitcoin runs on, the changes in the two commits here a47cf680619cae5892d72355f56f5c5051fd5434 and cbc0bdd73ed0fd672307cf0f80
...
💬 darosior commented on issue "Enable PCP by default?":
(https://github.com/bitcoin/bitcoin/issues/31663#issuecomment-2737618918)
Thanks for testing!
(https://github.com/bitcoin/bitcoin/issues/31663#issuecomment-2737618918)
Thanks for testing!
💬 yancyribbens commented on issue "BnB untested/unused condition in UTXO exclusion optimization":
(https://github.com/bitcoin/bitcoin/issues/32047#issuecomment-2737655586)
> This is not accurate. You could have two UTXOs of different output types that have the same effective value but differing fees. Counterexample:
Yes, I redacted that comment later in the thread as my understand of the problem improved. As I posted last, there's even a test [here](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L427) that tests two UTXOs with the same effective_value yet different fees.
> However, since [CoinGrinder got merged](https://gi
...
(https://github.com/bitcoin/bitcoin/issues/32047#issuecomment-2737655586)
> This is not accurate. You could have two UTXOs of different output types that have the same effective value but differing fees. Counterexample:
Yes, I redacted that comment later in the thread as my understand of the problem improved. As I posted last, there's even a test [here](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L427) that tests two UTXOs with the same effective_value yet different fees.
> However, since [CoinGrinder got merged](https://gi
...
💬 yancyribbens commented on issue "BnB untested/unused condition in UTXO exclusion optimization":
(https://github.com/bitcoin/bitcoin/issues/32047#issuecomment-2737675105)
However, doesn't the waste score account for long_term_fee_rate as well as fee_rate? In other-words, just comparing `fee` amounts and not `long_term_fee_rate` would not be enough to know if comparing two UTXOs have different was scores..
(https://github.com/bitcoin/bitcoin/issues/32047#issuecomment-2737675105)
However, doesn't the waste score account for long_term_fee_rate as well as fee_rate? In other-words, just comparing `fee` amounts and not `long_term_fee_rate` would not be enough to know if comparing two UTXOs have different was scores..
⚠️ luisschwab opened an issue: "Incorrect balance when dealing with coinbase UTXOs that will be mature on _h_ + 1"
(https://github.com/bitcoin/bitcoin/issues/32098)
Bitcoin Core is reporting the wrong balance when dealing with coinbase UTXOs that will become mature on the next block.
Scenario:
On regtest, I mine 101 blocks. Since coinbase maturity height is 100 blocks, I have 1 mature UTXO (50 BTC) at height 101. However, at height 102, another coinbase UTXO (50 BTC) will have matured and will be accepted by the mempool as an input to a transaction. Therefore, my _**spendable**_ balance at height 102 will be 50+50 BTC (2 UTXOs available for selection).
Cu
...
(https://github.com/bitcoin/bitcoin/issues/32098)
Bitcoin Core is reporting the wrong balance when dealing with coinbase UTXOs that will become mature on the next block.
Scenario:
On regtest, I mine 101 blocks. Since coinbase maturity height is 100 blocks, I have 1 mature UTXO (50 BTC) at height 101. However, at height 102, another coinbase UTXO (50 BTC) will have matured and will be accepted by the mempool as an input to a transaction. Therefore, my _**spendable**_ balance at height 102 will be 50+50 BTC (2 UTXOs available for selection).
Cu
...
💬 luisschwab commented on issue "Incorrect balance when dealing with coinbase UTXOs that will be mature on `h + 1`":
(https://github.com/bitcoin/bitcoin/issues/32098#issuecomment-2737775525)
Apparently this is a simple fix:
```diff
scr/wallet/wallet.cpp
int CWallet::GetTxBlocksToMaturity(const CWalletTx& wtx) const
{
AssertLockHeld(cs_wallet);
if (!wtx.IsCoinBase()) {
return 0;
}
int chain_depth = GetTxDepthInMainChain(wtx);
assert(chain_depth >= 0); // coinbase tx should not be conflicted
- return std::max(0, (COINBASE_MATURITY+1) - chain_depth);
+ return std::max(0, COINBASE_MATURITY - chain_depth);
}
```
(https://github.com/bitcoin/bitcoin/issues/32098#issuecomment-2737775525)
Apparently this is a simple fix:
```diff
scr/wallet/wallet.cpp
int CWallet::GetTxBlocksToMaturity(const CWalletTx& wtx) const
{
AssertLockHeld(cs_wallet);
if (!wtx.IsCoinBase()) {
return 0;
}
int chain_depth = GetTxDepthInMainChain(wtx);
assert(chain_depth >= 0); // coinbase tx should not be conflicted
- return std::max(0, (COINBASE_MATURITY+1) - chain_depth);
+ return std::max(0, COINBASE_MATURITY - chain_depth);
}
```
💬 maflcko commented on pull request "test: Fix intermittent issue in p2p_orphan_handling.py":
(https://github.com/bitcoin/bitcoin/pull/32092#discussion_r2004125240)
thx, done
(https://github.com/bitcoin/bitcoin/pull/32092#discussion_r2004125240)
thx, done
💬 maflcko commented on issue "Incorrect balance when dealing with coinbase UTXOs that will be mature on `h + 1`":
(https://github.com/bitcoin/bitcoin/issues/32098#issuecomment-2737798747)
I presume this was last touched in commit bf3a20a6e8cafdf723ef101af078df303ea06fec, which explains that there may be a race condition where the transaction is rejected, because the 100th block has not been relayed yet to the peer when the transaction is sent.
(https://github.com/bitcoin/bitcoin/issues/32098#issuecomment-2737798747)
I presume this was last touched in commit bf3a20a6e8cafdf723ef101af078df303ea06fec, which explains that there may be a race condition where the transaction is rejected, because the 100th block has not been relayed yet to the peer when the transaction is sent.
💬 maflcko commented on issue "Failure to run Fuzz tests when running with corpus":
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2737863589)
> libc++abi: terminating due to uncaught exception of type std::__1::ios_base::failure: DataStream::read(): end of data: unspecified iostream_category error
This looks like an upstream packaging bug or asan bug on your platform, given that it passes fine when asan is disabled on your platform.
(https://github.com/bitcoin/bitcoin/issues/32089#issuecomment-2737863589)
> libc++abi: terminating due to uncaught exception of type std::__1::ios_base::failure: DataStream::read(): end of data: unspecified iostream_category error
This looks like an upstream packaging bug or asan bug on your platform, given that it passes fine when asan is disabled on your platform.
💬 hebasto commented on issue "[rfc] build: Reject unclean configure?":
(https://github.com/bitcoin/bitcoin/issues/31942#issuecomment-2737914378)
FWIW, at the end of configuration, Qt 6 prints:
```
If reconfiguration fails for some reason, try removing 'CMakeCache.txt' from the build directory
Alternatively, you can add the --fresh flag to your CMake flags.
```
(https://github.com/bitcoin/bitcoin/issues/31942#issuecomment-2737914378)
FWIW, at the end of configuration, Qt 6 prints:
```
If reconfiguration fails for some reason, try removing 'CMakeCache.txt' from the build directory
Alternatively, you can add the --fresh flag to your CMake flags.
```
🤔 maflcko reviewed a pull request: "contrib: Make deterministic-coverage error messages more readable"
(https://github.com/bitcoin/bitcoin/pull/32074#pullrequestreview-2700009626)
rebased with a move-only change, and replied to all feedback
(https://github.com/bitcoin/bitcoin/pull/32074#pullrequestreview-2700009626)
rebased with a move-only change, and replied to all feedback
💬 maflcko commented on pull request "contrib: Make deterministic-coverage error messages more readable":
(https://github.com/bitcoin/bitcoin/pull/32074#discussion_r2004192240)
I found `Err(...)?` nicer as an early-return statement, but no strong opinion
(https://github.com/bitcoin/bitcoin/pull/32074#discussion_r2004192240)
I found `Err(...)?` nicer as an early-return statement, but no strong opinion
💬 maflcko commented on pull request "contrib: Make deterministic-coverage error messages more readable":
(https://github.com/bitcoin/bitcoin/pull/32074#discussion_r2004194037)
In Rust shadowing is a feature, but happy to change, no strong opinion.
(https://github.com/bitcoin/bitcoin/pull/32074#discussion_r2004194037)
In Rust shadowing is a feature, but happy to change, no strong opinion.