💬 fjahr commented on issue "Mistake in `feature_pruning.py` functional test?":
(https://github.com/bitcoin/bitcoin/issues/32249#issuecomment-2816874110)
@EniRox001 If you want to you could also introduce a new node that is not involved in any other test, some might prefer this as cleaner since it avoids such issues. But that's up to you.
(https://github.com/bitcoin/bitcoin/issues/32249#issuecomment-2816874110)
@EniRox001 If you want to you could also introduce a new node that is not involved in any other test, some might prefer this as cleaner since it avoids such issues. But that's up to you.
💬 GYGY072H commented on issue "Mistake in `feature_pruning.py` functional test?":
(https://github.com/bitcoin/bitcoin/issues/32249#issuecomment-2816895006)
Look honestly I thought this was A computer class program I have no fkg
Idea wat is going on I don't even know the names of the bottom's this is
ridiculous I thought I need to take a class so am not embarrassed of not
knowing how to use a computer int life all I use is my phone even that is
difficult for me can you can you explain to me what is this? Am kinda
scared am not and American and this looks funny
On Sat, Apr 19, 2025, 5:37 PM Fabian Jahr ***@***.***> wrote:
> @EniRox001 <h
...
(https://github.com/bitcoin/bitcoin/issues/32249#issuecomment-2816895006)
Look honestly I thought this was A computer class program I have no fkg
Idea wat is going on I don't even know the names of the bottom's this is
ridiculous I thought I need to take a class so am not embarrassed of not
knowing how to use a computer int life all I use is my phone even that is
difficult for me can you can you explain to me what is this? Am kinda
scared am not and American and this looks funny
On Sat, Apr 19, 2025, 5:37 PM Fabian Jahr ***@***.***> wrote:
> @EniRox001 <h
...
👍 theStack approved a pull request: "descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey`"
(https://github.com/bitcoin/bitcoin/pull/31243#pullrequestreview-2780108332)
re-ACK acee5c59e68f31acba111bc4d1892b08243ea5e0
case-sensitivity yocto-nit: in commit subject for 6268bde0af0aa9cfb3df08d6b9b67fdffa2a1a12: s/BIP32PUbKeyProvider/BIP32PubkeyProvider/
(https://github.com/bitcoin/bitcoin/pull/31243#pullrequestreview-2780108332)
re-ACK acee5c59e68f31acba111bc4d1892b08243ea5e0
case-sensitivity yocto-nit: in commit subject for 6268bde0af0aa9cfb3df08d6b9b67fdffa2a1a12: s/BIP32PUbKeyProvider/BIP32PubkeyProvider/
💬 NicolaLS commented on pull request "doc: Improve `dependencies.md`":
(https://github.com/bitcoin/bitcoin/pull/31895#discussion_r2051609620)
ah yes messed up the rebase..fixed now.
(https://github.com/bitcoin/bitcoin/pull/31895#discussion_r2051609620)
ah yes messed up the rebase..fixed now.
💬 NicolaLS commented on pull request "doc: Improve `dependencies.md`":
(https://github.com/bitcoin/bitcoin/pull/31895#discussion_r2051609798)
good idea, changed it.
(https://github.com/bitcoin/bitcoin/pull/31895#discussion_r2051609798)
good idea, changed it.
💬 mzumsande commented on pull request "bench: close wallets after migration":
(https://github.com/bitcoin/bitcoin/pull/32309#issuecomment-2816951357)
Thanks, I didn't realize that there were multiple independent issues - makes sense now, Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32309#issuecomment-2816951357)
Thanks, I didn't realize that there were multiple independent issues - makes sense now, Concept ACK.
⚠️ vicortar opened an issue: "Critical Discrepancy: Bitcoin Core Node Sees UTXO via scantxoutset, BUT listunspent & Sparrow Wallet Fail; Address Undrivable from LND Key?"
(https://github.com/bitcoin/bitcoin/issues/32311)
Hello LND Developers and Community,
I'm facing a highly unusual and critical issue where on-chain funds associated with a past LND channel closure are inaccessible, despite my Bitcoin Core node (v29.0.0, RPi5, fully synced after fresh IBD, txindex=1) confirming the UTXO's existence via scantxoutset. However, both listunspent and external wallet software (Sparrow) fail to see this UTXO, and crucially, the address holding the funds cannot be derived from my LND root key using standard methods.
Sys
...
(https://github.com/bitcoin/bitcoin/issues/32311)
Hello LND Developers and Community,
I'm facing a highly unusual and critical issue where on-chain funds associated with a past LND channel closure are inaccessible, despite my Bitcoin Core node (v29.0.0, RPi5, fully synced after fresh IBD, txindex=1) confirming the UTXO's existence via scantxoutset. However, both listunspent and external wallet software (Sparrow) fail to see this UTXO, and crucially, the address holding the funds cannot be derived from my LND root key using standard methods.
Sys
...
💬 l0rinc commented on pull request "[IBD] prevector: store `P2WSH`/`P2TR`/`P2PK` scripts inline":
(https://github.com/bitcoin/bitcoin/pull/32279#issuecomment-2817037407)
Finished a full IBD with default dbcache=450 on HDD
<details>
<summary>Benchmark</summary>
```bash
COMMITS="156f9913a26598009c8356c34548002e6a6aba02 a2a3e0cfd8549e3be03fd81e75ebb7527e9345d7"; \
STOP_HEIGHT=888888; DBCACHE=450; \
CC=gcc; CXX=g++; \
BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \
(for c in $COMMITS; do git fetch origin $c -q && git log -1 --pretty=format:'%h %s' $c || exit 1; done) && \
hyperfine \
--sort 'command' \
--run
...
(https://github.com/bitcoin/bitcoin/pull/32279#issuecomment-2817037407)
Finished a full IBD with default dbcache=450 on HDD
<details>
<summary>Benchmark</summary>
```bash
COMMITS="156f9913a26598009c8356c34548002e6a6aba02 a2a3e0cfd8549e3be03fd81e75ebb7527e9345d7"; \
STOP_HEIGHT=888888; DBCACHE=450; \
CC=gcc; CXX=g++; \
BASE_DIR="/mnt/my_storage"; DATA_DIR="$BASE_DIR/BitcoinData"; LOG_DIR="$BASE_DIR/logs"; \
(for c in $COMMITS; do git fetch origin $c -q && git log -1 --pretty=format:'%h %s' $c || exit 1; done) && \
hyperfine \
--sort 'command' \
--run
...
🤔 i-am-yuvi reviewed a pull request: "build: Fix `macdeployqtplus` after switching to Qt 6"
(https://github.com/bitcoin/bitcoin/pull/32287#pullrequestreview-2780171994)
tACK b2f1c20d24ee6cae65e7bbff60091b39cc2694b4
```
...
...
+ Deploying plugins +
Processing plugin platforms/libqminimal.dylib ...
/Library/Developer/CommandLineTools/usr/bin/strip: warning: changes being made to the file will invalidate the code signature in: /Users/yuvrajchhetri/Desktop/bitcoin/build/dist/Bitcoin-Qt.app/Contents/PlugIns/platforms/libqminimal.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the
...
(https://github.com/bitcoin/bitcoin/pull/32287#pullrequestreview-2780171994)
tACK b2f1c20d24ee6cae65e7bbff60091b39cc2694b4
```
...
...
+ Deploying plugins +
Processing plugin platforms/libqminimal.dylib ...
/Library/Developer/CommandLineTools/usr/bin/strip: warning: changes being made to the file will invalidate the code signature in: /Users/yuvrajchhetri/Desktop/bitcoin/build/dist/Bitcoin-Qt.app/Contents/PlugIns/platforms/libqminimal.dylib
/Library/Developer/CommandLineTools/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the
...
💬 Bartek922 commented on issue "Critical Discrepancy: Bitcoin Core Node Sees UTXO via scantxoutset, BUT listunspent & Sparrow Wallet Fail; Address Undrivable from LND Key?":
(https://github.com/bitcoin/bitcoin/issues/32311#issuecomment-2817042723)
> Hello LND Developers and Community, I'm facing a highly unusual and critical issue where on-chain funds associated with a past LND channel closure are inaccessible, despite my Bitcoin Core node (v29.0.0, RPi5, fully synced after fresh IBD, txindex=1) confirming the UTXO's existence via scantxoutset. However, both listunspent and external wallet software (Sparrow) fail to see this UTXO, and crucially, the address holding the funds cannot be derived from my LND root key using standard methods. S
...
(https://github.com/bitcoin/bitcoin/issues/32311#issuecomment-2817042723)
> Hello LND Developers and Community, I'm facing a highly unusual and critical issue where on-chain funds associated with a past LND channel closure are inaccessible, despite my Bitcoin Core node (v29.0.0, RPi5, fully synced after fresh IBD, txindex=1) confirming the UTXO's existence via scantxoutset. However, both listunspent and external wallet software (Sparrow) fail to see this UTXO, and crucially, the address holding the funds cannot be derived from my LND root key using standard methods. S
...
✅ willcl-ark closed an issue: "Critical Discrepancy: Bitcoin Core Node Sees UTXO via scantxoutset, BUT listunspent & Sparrow Wallet Fail; Address Undrivable from LND Key?"
(https://github.com/bitcoin/bitcoin/issues/32311)
(https://github.com/bitcoin/bitcoin/issues/32311)
💬 willcl-ark commented on issue "Critical Discrepancy: Bitcoin Core Node Sees UTXO via scantxoutset, BUT listunspent & Sparrow Wallet Fail; Address Undrivable from LND Key?":
(https://github.com/bitcoin/bitcoin/issues/32311#issuecomment-2817048564)
Hi.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) or the `#bitcoin` IRC channel on the [Libera Chat](https://libera.chat/) network.
That said, it seems like this question should not even be posted there, and would be better posted in an LND help forum, as the fundamental problem (restoring and LND-derived key) is unrelated to Bitcoin Core?
> Why would listunspent (even with the correct wallet specified) a
...
(https://github.com/bitcoin/bitcoin/issues/32311#issuecomment-2817048564)
Hi.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) or the `#bitcoin` IRC channel on the [Libera Chat](https://libera.chat/) network.
That said, it seems like this question should not even be posted there, and would be better posted in an LND help forum, as the fundamental problem (restoring and LND-derived key) is unrelated to Bitcoin Core?
> Why would listunspent (even with the correct wallet specified) a
...
📝 EniRox001 opened a pull request: "test: Fix feature_pruning test after nTime typo fix"
(https://github.com/bitcoin/bitcoin/pull/32312)
The test_pruneheight_undo_presence test was failing after fixing a typo
in the mine_large_blocks.nTime variable (previously incorrectly written
as nTimes). The typo fix exposed an underlying issue where node 2, which
is involved in reorg testing, was being used for the undo presence test.
The problem occurred because node 2, being part of reorg testing, could
be on a different chain than other nodes. This caused failures when
attempting to fetch blocks from other nodes that didn't recogn
...
(https://github.com/bitcoin/bitcoin/pull/32312)
The test_pruneheight_undo_presence test was failing after fixing a typo
in the mine_large_blocks.nTime variable (previously incorrectly written
as nTimes). The typo fix exposed an underlying issue where node 2, which
is involved in reorg testing, was being used for the undo presence test.
The problem occurred because node 2, being part of reorg testing, could
be on a different chain than other nodes. This caused failures when
attempting to fetch blocks from other nodes that didn't recogn
...
🤔 theStack reviewed a pull request: "psbt: add non-default sighash types to PSBTs and unify sighash type match checking"
(https://github.com/bitcoin/bitcoin/pull/31622#pullrequestreview-2780244157)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/31622#pullrequestreview-2780244157)
Concept ACK
💬 theStack commented on pull request "psbt: add non-default sighash types to PSBTs and unify sighash type match checking":
(https://github.com/bitcoin/bitcoin/pull/31622#discussion_r2051723308)
nit: `CheckSignatureEncoding` already checks for empty sig, so the first check isn't needed
```suggestion
if (!CheckSignatureEncoding(sig, SCRIPT_VERIFY_DERSIG | SCRIPT_VERIFY_STRICTENC, nullptr)) {
```
any reason why the verification flags don't also include `SCRIPT_VERIFY_LOW_S`?
(https://github.com/bitcoin/bitcoin/pull/31622#discussion_r2051723308)
nit: `CheckSignatureEncoding` already checks for empty sig, so the first check isn't needed
```suggestion
if (!CheckSignatureEncoding(sig, SCRIPT_VERIFY_DERSIG | SCRIPT_VERIFY_STRICTENC, nullptr)) {
```
any reason why the verification flags don't also include `SCRIPT_VERIFY_LOW_S`?
💬 furszy commented on pull request "bench: close wallets after migration":
(https://github.com/bitcoin/bitcoin/pull/32309#issuecomment-2817260424)
> On Windows, benchmark runs sporadically hung because the descriptor wallet and its companion watch-only wallet were never unloaded, remaining registered in the global WalletContext. This prevented the test harness from cleaning up its temporary directory.
Hmm, haven't dug deeper but this does not seem to be accurate. The `WalletContext` is not global. It is created at the beginning of the benchmark, just after creating the test context (which is the one that calls to the `fs::removal_all` t
...
(https://github.com/bitcoin/bitcoin/pull/32309#issuecomment-2817260424)
> On Windows, benchmark runs sporadically hung because the descriptor wallet and its companion watch-only wallet were never unloaded, remaining registered in the global WalletContext. This prevented the test harness from cleaning up its temporary directory.
Hmm, haven't dug deeper but this does not seem to be accurate. The `WalletContext` is not global. It is created at the beginning of the benchmark, just after creating the test context (which is the one that calls to the `fs::removal_all` t
...
📝 l0rinc opened a pull request: "RFC: Fix `cachedCoinsUsage` usages in `CCoinsViewCache`"
(https://github.com/bitcoin/bitcoin/pull/32313)
Split out of https://github.com/bitcoin/bitcoin/pull/32296#issuecomment-2813590511 since this needed more complicated production code changes.
The changes ensure `cachedCoinsUsage` remains balanced throughout all coin operations and that the sanitizers will catch future violations.
The change was tested with the related fuzz test, and asserted before/after each `cachedCoinsUsage` change (in production code and fuzz) that the calculations are still correct by recalculating it from scratch:
...
(https://github.com/bitcoin/bitcoin/pull/32313)
Split out of https://github.com/bitcoin/bitcoin/pull/32296#issuecomment-2813590511 since this needed more complicated production code changes.
The changes ensure `cachedCoinsUsage` remains balanced throughout all coin operations and that the sanitizers will catch future violations.
The change was tested with the related fuzz test, and asserted before/after each `cachedCoinsUsage` change (in production code and fuzz) that the calculations are still correct by recalculating it from scratch:
...
💬 andrewtoth commented on pull request "RFC: Fix `cachedCoinsUsage` usages in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051775463)
I think this would be simpler if we kept the original behavior of moving the `coin` here as well, and then only increment the `cachedCoinsUsage` if the coin is inserted.
In practice it's not possible to get `!inserted` unless the assume utxo payload was generated incorrectly.
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051775463)
I think this would be simpler if we kept the original behavior of moving the `coin` here as well, and then only increment the `cachedCoinsUsage` if the coin is inserted.
In practice it's not possible to get `!inserted` unless the assume utxo payload was generated incorrectly.
💬 andrewtoth commented on pull request "RFC: Fix `cachedCoinsUsage` usages in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051774641)
Would it be simpler to just move this `if` block below the `if` block that throws, instead of pulling the throw out?
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051774641)
Would it be simpler to just move this `if` block below the `if` block that throws, instead of pulling the throw out?
💬 andrewtoth commented on pull request "RFC: Fix `cachedCoinsUsage` usages in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051775760)
The entry has an empty coin here, it was just created. So this is just subtracting zero.
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2051775760)
The entry has an empty coin here, it was just created. So this is just subtracting zero.