💬 hebasto commented on pull request "depends: Propagate native C compiler to `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3607392698)
My Guiz build:
```
x86_64
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu.tar.gz
fe143b6be
...
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3607392698)
My Guiz build:
```
x86_64
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu.tar.gz
fe143b6be
...
✅ hebasto closed a pull request: "depends, doc: Add `tcl` as build dependency for `sqlite` package"
(https://github.com/bitcoin/bitcoin/pull/33975)
(https://github.com/bitcoin/bitcoin/pull/33975)
💬 hebasto commented on pull request "depends, doc: Add `tcl` as build dependency for `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33975#issuecomment-3607395504)
> > Can we just pass the compiler through?
>
> See #33995.
Closing in favour of https://github.com/bitcoin/bitcoin/pull/33995.
(https://github.com/bitcoin/bitcoin/pull/33975#issuecomment-3607395504)
> > Can we just pass the compiler through?
>
> See #33995.
Closing in favour of https://github.com/bitcoin/bitcoin/pull/33995.
💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3607424994)
Rebased to resolve a conflict with merged bitcoin/bitcoin#33857.
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3607424994)
Rebased to resolve a conflict with merged bitcoin/bitcoin#33857.
💬 hebasto commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607449106)
Rebased on top of the merged bitcoin/bitcoin#33857.
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607449106)
Rebased on top of the merged bitcoin/bitcoin#33857.
💬 ryanofsky commented on issue "Memory leak when using IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3607454869)
> yes, that's also my understanding... the puzzling thing is that we're still having the memory leaks... so we're either missing some detail on this analysis, or the cause is related to something other than templates
I think at this point we've ruled out the obvious possible causes of leaks, and need to start debugging the issue more directly.
It would help to have some steps to reproduce. If someone can let me know what code to check out and build, and what commands to run that will show the
...
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3607454869)
> yes, that's also my understanding... the puzzling thing is that we're still having the memory leaks... so we're either missing some detail on this analysis, or the cause is related to something other than templates
I think at this point we've ruled out the obvious possible causes of leaks, and need to start debugging the issue more directly.
It would help to have some steps to reproduce. If someone can let me know what code to check out and build, and what commands to run that will show the
...
💬 JeremyRubin commented on pull request "ci: remove `doc/release-notes.md` from lint-spelling.py":
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607478808)
I guess it's _not_ a failure, as it only pops up when other issues flag, but it does get reported in CI as:
```
^---- ⚠️ Failure generated from lint-tests.py
doc/release-notes.md:379: Atack ==> Attack
```
which is sort of confusing
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607478808)
I guess it's _not_ a failure, as it only pops up when other issues flag, but it does get reported in CI as:
```
^---- ⚠️ Failure generated from lint-tests.py
doc/release-notes.md:379: Atack ==> Attack
```
which is sort of confusing
💬 fanquake commented on issue "build: use UCRT runtime for Windows (release) binaries":
(https://github.com/bitcoin/bitcoin/issues/30210#issuecomment-3607488174)
> Since https://github.com/bitcoin/bitcoin/pull/33764 has been merged, this checkbox can now be ticked.
As I mentioned in that PR, neither the headers, neither the compiler version, or headers used, match Guix, so its not exactly testing something similar to how we build releases. That will be improved by #33775.
(https://github.com/bitcoin/bitcoin/issues/30210#issuecomment-3607488174)
> Since https://github.com/bitcoin/bitcoin/pull/33764 has been merged, this checkbox can now be ticked.
As I mentioned in that PR, neither the headers, neither the compiler version, or headers used, match Guix, so its not exactly testing something similar to how we build releases. That will be improved by #33775.
💬 fanquake commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607495972)
Given it's dropping the other CI, I think this PR should be completing #30210, dropping workarounds, updating any docs, and completing the migration.
(https://github.com/bitcoin/bitcoin/pull/33593#issuecomment-3607495972)
Given it's dropping the other CI, I think this PR should be completing #30210, dropping workarounds, updating any docs, and completing the migration.
💬 maflcko commented on pull request "ci: remove `doc/release-notes.md` from lint-spelling.py":
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607571201)
That could be fixed by rewording, or changing the spacing, maybe something like:
```diff
diff --git a/test/lint/test_runner/src/main.rs b/test/lint/test_runner/src/main.rs
index 5c65fcad89..39ae9dc815 100644
--- a/test/lint/test_runner/src/main.rs
+++ b/test/lint/test_runner/src/main.rs
@@ -742,7 +742,7 @@ fn run_all_python_linters() -> LintResult {
.success()
{
good = false;
- println!("^---- ⚠️ Failure generated from {entry_fn}");
...
(https://github.com/bitcoin/bitcoin/pull/33968#issuecomment-3607571201)
That could be fixed by rewording, or changing the spacing, maybe something like:
```diff
diff --git a/test/lint/test_runner/src/main.rs b/test/lint/test_runner/src/main.rs
index 5c65fcad89..39ae9dc815 100644
--- a/test/lint/test_runner/src/main.rs
+++ b/test/lint/test_runner/src/main.rs
@@ -742,7 +742,7 @@ fn run_all_python_linters() -> LintResult {
.success()
{
good = false;
- println!("^---- ⚠️ Failure generated from {entry_fn}");
...
💬 ryanofsky commented on issue "should concurrent IPC requests directed to the same thread cause a crash?":
(https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3607727965)
re: https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3566852691
> my main question is whether there are there protection mechanisms in place in case we try to create too many threads at once?
There aren't any currently, and making a lot of threads is probably the easiest way an IPC client could DoS the node.
It wouldn't be hard to create a limit though, if there is a use-case.
I do think creating 5 threads for each client that needs to receive templates sounds like overkill, and
...
(https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3607727965)
re: https://github.com/bitcoin/bitcoin/issues/33923#issuecomment-3566852691
> my main question is whether there are there protection mechanisms in place in case we try to create too many threads at once?
There aren't any currently, and making a lot of threads is probably the easiest way an IPC client could DoS the node.
It wouldn't be hard to create a limit though, if there is a use-case.
I do think creating 5 threads for each client that needs to receive templates sounds like overkill, and
...
👍 sedited approved a pull request: "validation: Improve warnings in case of chain corruption"
(https://github.com/bitcoin/bitcoin/pull/33553#pullrequestreview-3535952294)
ACK 4b4711369880369729893ba7baef11ba2a36cf4b
(https://github.com/bitcoin/bitcoin/pull/33553#pullrequestreview-3535952294)
ACK 4b4711369880369729893ba7baef11ba2a36cf4b
💬 maflcko commented on pull request "refactor: replace manual promise with SyncWithValidationInterfaceQueue":
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2585968902)
@ANtutov are you still working on this?
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2585968902)
@ANtutov are you still working on this?
👍 ryanofsky approved a pull request: "mining: getCoinbase() returns struct instead of raw tx"
(https://github.com/bitcoin/bitcoin/pull/33819#pullrequestreview-3536150722)
Code review ACK 60f74dd315811db427797a606f4b5611a8c59993. New comments and renaming both seem great, and it is nice to get rid of the extract function. PR feels much more straightforward now.
(https://github.com/bitcoin/bitcoin/pull/33819#pullrequestreview-3536150722)
Code review ACK 60f74dd315811db427797a606f4b5611a8c59993. New comments and renaming both seem great, and it is nice to get rid of the extract function. PR feels much more straightforward now.
💬 ryanofsky commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2586011866)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)
Would be nice to avoid the move and treat `pblock` and `coinbase_tx_template` local variables more consistently. Would suggest defining `CoinbaseTxTemplate& coinbase_tx_template{pblocktemplate->m_coinbase_tx_template}` above similar to `pblock`.
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2586011866)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)
Would be nice to avoid the move and treat `pblock` and `coinbase_tx_template` local variables more consistently. Would suggest defining `CoinbaseTxTemplate& coinbase_tx_template{pblocktemplate->m_coinbase_tx_template}` above similar to `pblock`.
💬 ryanofsky commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2585999526)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)
Maybe good to assert witness_index is between 0 and the vout size. Obviously it should be, but good to check array bounds since the index is coming from a different place.
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2585999526)
In commit "mining: add new getCoinbaseTx() returning a struct" (60f74dd315811db427797a606f4b5611a8c59993)
Maybe good to assert witness_index is between 0 and the vout size. Obviously it should be, but good to check array bounds since the index is coming from a different place.
💬 fanquake commented on pull request "guix: use GCC 14.3.0 over 13.3.0":
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3608054699)
@laanwj nice! I've re-integrated this into Guix (to build with `./contrib/guix/guix-build`), and minified the flags further, see this branch: https://github.com/fanquake/bitcoin/tree/repro_33775_minimal. With the top commit, the diff is still the register swapping:
```diff
--- a.txt
+++ b.txt
@@ -1,9 +1,9 @@
-test.cpp.obj.aarch64: file format pe-x86-64
+test.cpp.obj.x86_64: file format pe-x86-64
Disassembly of section .text:
0000000000000000 <IsBDBFile(fs::path cons
...
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3608054699)
@laanwj nice! I've re-integrated this into Guix (to build with `./contrib/guix/guix-build`), and minified the flags further, see this branch: https://github.com/fanquake/bitcoin/tree/repro_33775_minimal. With the top commit, the diff is still the register swapping:
```diff
--- a.txt
+++ b.txt
@@ -1,9 +1,9 @@
-test.cpp.obj.aarch64: file format pe-x86-64
+test.cpp.obj.x86_64: file format pe-x86-64
Disassembly of section .text:
0000000000000000 <IsBDBFile(fs::path cons
...
💬 hebasto commented on pull request "depends: Switch from multilib to platform-specific toolchains":
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3608103648)
My Guix build:
```
x86_64
9077d4894e4f4a5baa4763f65a61cc48a352312c59480cb9bb9395002a37e499 guix-build-7c2489086914/output/aarch64-linux-gnu/SHA256SUMS.part
b2efe0ce73341388f1f9c72b67448b9b864f80b48886b836beb975eae0d7ef86 guix-build-7c2489086914/output/aarch64-linux-gnu/bitcoin-7c2489086914-aarch64-linux-gnu-debug.tar.gz
ed13ca6437ea2604cc77357758bb578887cb6381d0511248bed941dc77a476d4 guix-build-7c2489086914/output/aarch64-linux-gnu/bitcoin-7c2489086914-aarch64-linux-gnu.tar.gz
6945b4b48
...
(https://github.com/bitcoin/bitcoin/pull/32162#issuecomment-3608103648)
My Guix build:
```
x86_64
9077d4894e4f4a5baa4763f65a61cc48a352312c59480cb9bb9395002a37e499 guix-build-7c2489086914/output/aarch64-linux-gnu/SHA256SUMS.part
b2efe0ce73341388f1f9c72b67448b9b864f80b48886b836beb975eae0d7ef86 guix-build-7c2489086914/output/aarch64-linux-gnu/bitcoin-7c2489086914-aarch64-linux-gnu-debug.tar.gz
ed13ca6437ea2604cc77357758bb578887cb6381d0511248bed941dc77a476d4 guix-build-7c2489086914/output/aarch64-linux-gnu/bitcoin-7c2489086914-aarch64-linux-gnu.tar.gz
6945b4b48
...
📝 instagibbs opened a pull request: "test: fix test_limit_enforcement_package"
(https://github.com/bitcoin/bitcoin/pull/34001)
The current test has a couple issues:
1) the parent_tx_good is regenerating the exact same transaction that is already in the cluster, so it's resulting in no replacements on submission
2) once fixed, the additional fee needs to be allocated to the parent transaction in the package, not the child. If the RBF fees are allocated to the child, this triggers the package RBF logic, which requires no in-mempool ancestors to be present.
Fix the bug and add a few assertions to protect against reg
...
(https://github.com/bitcoin/bitcoin/pull/34001)
The current test has a couple issues:
1) the parent_tx_good is regenerating the exact same transaction that is already in the cluster, so it's resulting in no replacements on submission
2) once fixed, the additional fee needs to be allocated to the parent transaction in the package, not the child. If the RBF fees are allocated to the child, this triggers the package RBF logic, which requires no in-mempool ancestors to be present.
Fix the bug and add a few assertions to protect against reg
...
💬 instagibbs commented on pull request "test: fix test_limit_enforcement_package":
(https://github.com/bitcoin/bitcoin/pull/34001#issuecomment-3608128047)
cc @sdaftuar @glozow
(https://github.com/bitcoin/bitcoin/pull/34001#issuecomment-3608128047)
cc @sdaftuar @glozow