💬 ADAMSALAMA6667 commented on issue "Cannot import descriptors with label and internal:false":
(https://github.com/bitcoin/bitcoin/issues/32376#issuecomment-2843684526)
[]()****
(https://github.com/bitcoin/bitcoin/issues/32376#issuecomment-2843684526)
[]()****
💬 w0xlt commented on issue "An "output descriptor" should not have many different checksums":
(https://github.com/bitcoin/bitcoin/issues/30632#issuecomment-2843736550)
Can this issue be closed ?
(https://github.com/bitcoin/bitcoin/issues/30632#issuecomment-2843736550)
Can this issue be closed ?
✅ achow101 closed an issue: "An "output descriptor" should not have many different checksums"
(https://github.com/bitcoin/bitcoin/issues/30632)
(https://github.com/bitcoin/bitcoin/issues/30632)
💬 ajtowns commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2843801037)
> My intention with this PR was to have a first step that is consensual among regular contributors,
The minimal change would just be to bump the default value of datacarrier, afaics.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2843801037)
> My intention with this PR was to have a first step that is consensual among regular contributors,
The minimal change would just be to bump the default value of datacarrier, afaics.
💬 w0xlt commented on issue "`keypoolrefill` doesn't fill keypool to specified parameter":
(https://github.com/bitcoin/bitcoin/issues/29924#issuecomment-2843818428)
Yes, by default, descriptor wallets start with 4 `ScriptPubKeyManager` (WPKH, TR, PKH, and SH(WPKH())), each with a size of 1,000. Therefore, the initial value is 4,000.
Incrementing the key pool with 4,001 keys gives 4001 * 4 = 16,004.
(https://github.com/bitcoin/bitcoin/issues/29924#issuecomment-2843818428)
Yes, by default, descriptor wallets start with 4 `ScriptPubKeyManager` (WPKH, TR, PKH, and SH(WPKH())), each with a size of 1,000. Therefore, the initial value is 4,000.
Incrementing the key pool with 4,001 keys gives 4001 * 4 = 16,004.
💬 davidgumberg commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2843857723)
utACK https://github.com/bitcoin/bitcoin/commit/e976bd3045010ee217aa0f2dca4c962aabb789d5
This will likely slow down IBD by a small amount for those running large dbcache values close to or greater than the old maximum (~16GB) because we lose some write "cut-through"[^1] but I seriously doubt there are that many people allocating >16GB to their DBCache, and I don't think sparing those users ~10 minutes during IBD is worth having every node on the network have a medium sized stall to flush ever
...
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2843857723)
utACK https://github.com/bitcoin/bitcoin/commit/e976bd3045010ee217aa0f2dca4c962aabb789d5
This will likely slow down IBD by a small amount for those running large dbcache values close to or greater than the old maximum (~16GB) because we lose some write "cut-through"[^1] but I seriously doubt there are that many people allocating >16GB to their DBCache, and I don't think sparing those users ~10 minutes during IBD is worth having every node on the network have a medium sized stall to flush ever
...
💬 davidgumberg commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2843872570)
> Could you please try the following patch:
>
> [...]
It failed with this build command:
```
26.64 /AFLplusplus/afl-clang-fast++ -pipe -std=c++20 -O2 -g -fstack-protector-all -fcf-protection=full -fstack-clash-pro
tection -Wl,-z,relro -Wl,-z,now -Wl,-z,separate-code -fsanitize=address -fPIE -pie -fcf-protection=none CMakeFiles/bitco
ind.dir/bitcoind.cpp.o CMakeFiles/bitcoind.dir/init/bitcoind.cpp.o -o ../bin/bitcoind ../lib/libbitcoin_node.a ../lib/l
ibbitcoin_wallet.a libleveldb.a libcrc32c
...
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2843872570)
> Could you please try the following patch:
>
> [...]
It failed with this build command:
```
26.64 /AFLplusplus/afl-clang-fast++ -pipe -std=c++20 -O2 -g -fstack-protector-all -fcf-protection=full -fstack-clash-pro
tection -Wl,-z,relro -Wl,-z,now -Wl,-z,separate-code -fsanitize=address -fPIE -pie -fcf-protection=none CMakeFiles/bitco
ind.dir/bitcoind.cpp.o CMakeFiles/bitcoind.dir/init/bitcoind.cpp.o -o ../bin/bitcoind ../lib/libbitcoin_node.a ../lib/l
ibbitcoin_wallet.a libleveldb.a libcrc32c
...
🤔 monlovesmango reviewed a pull request: "Refactor BnB tests"
(https://github.com/bitcoin/bitcoin/pull/29532#pullrequestreview-2809059556)
ACK dbf1f2663b1afbe03d6b1855f83db604bc79979e
I like how it now covers a variety of fee rates.
(https://github.com/bitcoin/bitcoin/pull/29532#pullrequestreview-2809059556)
ACK dbf1f2663b1afbe03d6b1855f83db604bc79979e
I like how it now covers a variety of fee rates.
💬 monlovesmango commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2069787909)
Nit: this also seems to be checking for a match
```suggestion
BOOST_CHECK_MESSAGE(result->GetSelectedValue() == expected_amount, strprintf("Selected amount match in BnB-Success: %s. Expected %d, and got %d", test_title, expected_amount, result->GetSelectedValue()));
```
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2069787909)
Nit: this also seems to be checking for a match
```suggestion
BOOST_CHECK_MESSAGE(result->GetSelectedValue() == expected_amount, strprintf("Selected amount match in BnB-Success: %s. Expected %d, and got %d", test_title, expected_amount, result->GetSelectedValue()));
```
💬 monlovesmango commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2069786399)
Nit: this seems to be checking for a match, not a mismatch
```suggestion
BOOST_CHECK_MESSAGE(HaveEquivalentValues(expected_result, *result), strprintf("Result match in BnB-Success: %s. Expected %s, and got %s", test_title, InputAmountsToString(expected_result), InputAmountsToString(*result)));
```
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2069786399)
Nit: this seems to be checking for a match, not a mismatch
```suggestion
BOOST_CHECK_MESSAGE(HaveEquivalentValues(expected_result, *result), strprintf("Result match in BnB-Success: %s. Expected %s, and got %s", test_title, InputAmountsToString(expected_result), InputAmountsToString(*result)));
```
📝 monlovesmango opened a pull request: "doc: Fix test_bitcoin path"
(https://github.com/bitcoin/bitcoin/pull/32389)
This commit fixes a couple command paths for interacting with the test_bitcoin binary within the Unit Test documentation.
If the commands are run as is a `command not found` error is returned.
```bash
❯ test_bitcoin --list_content
bash: test_bitcoin: command not found
```
```bash
❯ test_bitcoin --help
bash: test_bitcoin: command not found
```
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be
...
(https://github.com/bitcoin/bitcoin/pull/32389)
This commit fixes a couple command paths for interacting with the test_bitcoin binary within the Unit Test documentation.
If the commands are run as is a `command not found` error is returned.
```bash
❯ test_bitcoin --list_content
bash: test_bitcoin: command not found
```
```bash
❯ test_bitcoin --help
bash: test_bitcoin: command not found
```
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be
...
💬 monlovesmango commented on pull request "doc: Fix fuzz test_runner.py path":
(https://github.com/bitcoin/bitcoin/pull/32353#issuecomment-2843997945)
For anyone interested, I just opened another PR for this same type of documentation fix in the Unit Test README.md, https://github.com/bitcoin/bitcoin/pull/32389
(https://github.com/bitcoin/bitcoin/pull/32353#issuecomment-2843997945)
For anyone interested, I just opened another PR for this same type of documentation fix in the Unit Test README.md, https://github.com/bitcoin/bitcoin/pull/32389
💬 davidgumberg commented on pull request "crypto: Use secure_allocator for `AES256_ctx`":
(https://github.com/bitcoin/bitcoin/pull/31774#issuecomment-2844095843)
Rebased to address merge conflict.
(https://github.com/bitcoin/bitcoin/pull/31774#issuecomment-2844095843)
Rebased to address merge conflict.
⚠️ eth opened an issue: "Please add evm support"
(https://github.com/bitcoin/bitcoin/issues/32390)
### Please describe the feature you'd like to see added.
Bitcoin will surely die if it doesn't copy Ethereum (as you can see by the eth/btc chart)
### Is your feature related to a problem, if so please describe it.
_No response_
### Describe the solution you'd like
_No response_
### Describe any alternatives you've considered
_No response_
### Please leave any additional context
_No response_
(https://github.com/bitcoin/bitcoin/issues/32390)
### Please describe the feature you'd like to see added.
Bitcoin will surely die if it doesn't copy Ethereum (as you can see by the eth/btc chart)
### Is your feature related to a problem, if so please describe it.
_No response_
### Describe the solution you'd like
_No response_
### Describe any alternatives you've considered
_No response_
### Please leave any additional context
_No response_
💬 davidgumberg commented on pull request "crypto: Use secure_allocator for `AES256_ctx`":
(https://github.com/bitcoin/bitcoin/pull/31774#issuecomment-2844149953)
Rebased to address merge conflict, dropped legacy wallet encryption benchmark, and reduced number of keys since the benchmark was taking an unreasonably long time.
(https://github.com/bitcoin/bitcoin/pull/31774#issuecomment-2844149953)
Rebased to address merge conflict, dropped legacy wallet encryption benchmark, and reduced number of keys since the benchmark was taking an unreasonably long time.
💬 davidgumberg commented on pull request "doc: Fix test_bitcoin path":
(https://github.com/bitcoin/bitcoin/pull/32389#issuecomment-2844153778)
ACK https://github.com/bitcoin/bitcoin/pull/32389/commits/6cbc28b8dd629062950f195facc009fd8ba86310
(https://github.com/bitcoin/bitcoin/pull/32389#issuecomment-2844153778)
ACK https://github.com/bitcoin/bitcoin/pull/32389/commits/6cbc28b8dd629062950f195facc009fd8ba86310
✅ achow101 closed an issue: "Please add evm support"
(https://github.com/bitcoin/bitcoin/issues/32390)
(https://github.com/bitcoin/bitcoin/issues/32390)
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2069908553)
Thinking about it, doing the copy here is definitely fine for now (we can optimize it in a following PR).
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2069908553)
Thinking about it, doing the copy here is definitely fine for now (we can optimize it in a following PR).
💬 laanwj commented on pull request "[PoC] Modernize use of UTF-8 in Windows code":
(https://github.com/bitcoin/bitcoin/pull/32380#issuecomment-2844227744)
After this we should revert our custom [leveldb unicode patch](f8ae182c1e5176d12e816fb2217ae33a5472fdd7). This would make the `env_windows` backend go back to using the `A` functions, which already take UTF-8 as-is.
(https://github.com/bitcoin/bitcoin/pull/32380#issuecomment-2844227744)
After this we should revert our custom [leveldb unicode patch](f8ae182c1e5176d12e816fb2217ae33a5472fdd7). This would make the `env_windows` backend go back to using the `A` functions, which already take UTF-8 as-is.
💬 rebroad commented on pull request "Policy: Enforce witness script size limit for tapscript":
(https://github.com/bitcoin/bitcoin/pull/29769#issuecomment-2844242309)
I'm finding it hard to understand the nuance that is potentially being missed in the arguments in either direction. I think node operators ought to have a say in the transactions they want to support or not support, so as long as the filters are optional (and Bitcoin Core developers choose the defaults), then I'm in favour of including filters that have at least 33% support of node operators.
(https://github.com/bitcoin/bitcoin/pull/29769#issuecomment-2844242309)
I'm finding it hard to understand the nuance that is potentially being missed in the arguments in either direction. I think node operators ought to have a say in the transactions they want to support or not support, so as long as the filters are optional (and Bitcoin Core developers choose the defaults), then I'm in favour of including filters that have at least 33% support of node operators.