💬 fanquake commented on pull request "doc: add alpine build instructions":
(https://github.com/bitcoin/bitcoin/pull/32559#discussion_r2126217083)
#32568 landed.
(https://github.com/bitcoin/bitcoin/pull/32559#discussion_r2126217083)
#32568 landed.
💬 willcl-ark commented on pull request "doc: add alpine build instructions":
(https://github.com/bitcoin/bitcoin/pull/32559#discussion_r2126226110)
Dropped in 64986e1a44e108628b245ca977d2b8eb69ed5580
(https://github.com/bitcoin/bitcoin/pull/32559#discussion_r2126226110)
Dropped in 64986e1a44e108628b245ca977d2b8eb69ed5580
👋 willcl-ark's pull request is ready for review: "doc: add alpine build instructions"
(https://github.com/bitcoin/bitcoin/pull/32559)
(https://github.com/bitcoin/bitcoin/pull/32559)
💬 Sjors commented on issue "wallet: render BIP388 wallet policies":
(https://github.com/bitcoin/bitcoin/issues/32659#issuecomment-2939449631)
One caveat is that a wallet policy typically uses `/**` to indicate a combined receive and change descriptor `<0;1>`. Although we can import such combined descriptors, we store them seperately and forget about the unified original. So the `listdescriptors` command would return a useless policy value.
We could make `listdescriptors` smart, but it's perhaps better if don't give it a `policy` and `keys` field and instead introduce a new `listwalletpolicies` RPC that _is_ smart (and only considers
...
(https://github.com/bitcoin/bitcoin/issues/32659#issuecomment-2939449631)
One caveat is that a wallet policy typically uses `/**` to indicate a combined receive and change descriptor `<0;1>`. Although we can import such combined descriptors, we store them seperately and forget about the unified original. So the `listdescriptors` command would return a useless policy value.
We could make `listdescriptors` smart, but it's perhaps better if don't give it a `policy` and `keys` field and instead introduce a new `listwalletpolicies` RPC that _is_ smart (and only considers
...
💬 petertodd commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939451159)
ACK a189d636184b1c28fa4a325b56c1fab8f44527b1
Nits in things like the exact wording of the release notes can be handled in a followup pull-req if necessary. The basic functionality clearly works.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939451159)
ACK a189d636184b1c28fa4a325b56c1fab8f44527b1
Nits in things like the exact wording of the release notes can be handled in a followup pull-req if necessary. The basic functionality clearly works.
💬 l0rinc commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2939458958)
I've run the command on a `Raspberry Pi 4 Model B - Cortex-A72 4-Core ARM with SanDisk SSD PLUS 1TB (USB 3.0)` with to have data about lower-end hardware as well.
<details>
<summary>full command</summary>
```bash
git remote add sipa https://github.com/sipa/bitcoin.git || true && git fetch sipa bench_sfl_css && git switch -C bench_sfl_css sipa/bench_sfl_css && \
git clean -fxd && git reset --hard && \
cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release && cmake --build build -j"
...
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2939458958)
I've run the command on a `Raspberry Pi 4 Model B - Cortex-A72 4-Core ARM with SanDisk SSD PLUS 1TB (USB 3.0)` with to have data about lower-end hardware as well.
<details>
<summary>full command</summary>
```bash
git remote add sipa https://github.com/sipa/bitcoin.git || true && git fetch sipa bench_sfl_css && git switch -C bench_sfl_css sipa/bench_sfl_css && \
git clean -fxd && git reset --hard && \
cmake -B build -DBUILD_BENCH=ON -DCMAKE_BUILD_TYPE=Release && cmake --build build -j"
...
💬 petertodd commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939461753)
@AMoynahan89
> Why is this pr still open?
>
> "It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone." -Achow101
>
> [](https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878853896)
Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way. Segwit, for example,
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939461753)
@AMoynahan89
> Why is this pr still open?
>
> "It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone." -Achow101
>
> [](https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878853896)
Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way. Segwit, for example,
...
💬 fjahr commented on pull request "index: Fix coinstats overflow and introduce index versioning":
(https://github.com/bitcoin/bitcoin/pull/30469#discussion_r2126292213)
No, it wasn't deleting it because it sounded like it should be kept around but yeah, deleting makes sense startin from a future version. I will just go with >=31 for now, if this gets backported the version check can be adapted accordingly.
(https://github.com/bitcoin/bitcoin/pull/30469#discussion_r2126292213)
No, it wasn't deleting it because it sounded like it should be kept around but yeah, deleting makes sense startin from a future version. I will just go with >=31 for now, if this gets backported the version check can be adapted accordingly.
💬 fjahr commented on pull request "index: Fix coinstats overflow and introduce index versioning":
(https://github.com/bitcoin/bitcoin/pull/30469#issuecomment-2939541299)
I have pushed a new version with a simplified approach as suggested by @maflcko. This puts the fixed version into a new path and removes the old version after a grace period. This makes downgrading possible and uses less code. I think this approach isn't too far off from the migration since syncing the index and running the migration are both processes that take some time.
(https://github.com/bitcoin/bitcoin/pull/30469#issuecomment-2939541299)
I have pushed a new version with a simplified approach as suggested by @maflcko. This puts the fixed version into a new path and removes the old version after a grace period. This makes downgrading possible and uses less code. I think this approach isn't too far off from the migration since syncing the index and running the migration are both processes that take some time.
💬 maluquices commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939590089)
> Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way.
Statement that's "technically" true but leaves out critical context. This PR is the reason Core dropped from 97% to below 90% adoption. It's not trivial disagreement, far from it.
> Controversy needs to be weighed against the reasonableness of that controversy, and where the controversy is coming from. Here,
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939590089)
> Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way.
Statement that's "technically" true but leaves out critical context. This PR is the reason Core dropped from 97% to below 90% adoption. It's not trivial disagreement, far from it.
> Controversy needs to be weighed against the reasonableness of that controversy, and where the controversy is coming from. Here,
...
💬 pinheadmz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939644399)
> dropped from 97% to below 90% adoption
> flies directly in the face of open-source development principles.
@maluquices this is a contradiction. Open source means anyone can fork the code, change it, release it, and use it. Bitcoin Core has been discussed, reviewed and maintained by hundreds of experts for over a decade and turned an idea into a two trillion dollar asset. Everyone is free to use Bitcoin Core, or to use software reviewed and maintained by any other group of people of any
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939644399)
> dropped from 97% to below 90% adoption
> flies directly in the face of open-source development principles.
@maluquices this is a contradiction. Open source means anyone can fork the code, change it, release it, and use it. Bitcoin Core has been discussed, reviewed and maintained by hundreds of experts for over a decade and turned an idea into a two trillion dollar asset. Everyone is free to use Bitcoin Core, or to use software reviewed and maintained by any other group of people of any
...
💬 theStack commented on pull request "refactor: Convert GenTxid to `std::variant`":
(https://github.com/bitcoin/bitcoin/pull/32631#issuecomment-2939644770)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/32631#issuecomment-2939644770)
Concept ACK
📝 willcl-ark opened a pull request: "guix: warn and abort when SOURCE_DATE_EPOCH is set"
(https://github.com/bitcoin/bitcoin/pull/32678)
Fixes: #29935
Current behaviour will by-default use SOURCE_DATE_EPOCH from the environment without warning. This breaks the default reproducibility from a guix build.
Warn when and exit when this variable is set, and
FORCE_SOURCE_DATE_EPOCH is unset.
(https://github.com/bitcoin/bitcoin/pull/32678)
Fixes: #29935
Current behaviour will by-default use SOURCE_DATE_EPOCH from the environment without warning. This breaks the default reproducibility from a guix build.
Warn when and exit when this variable is set, and
FORCE_SOURCE_DATE_EPOCH is unset.
💬 maluquices commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939708994)
@pinheadmz a "technically" accurate gotcha attempt that ignores the deeper issue. The adoption drop signals a real erosion of trust, not just a casual exercise of open-source freedom. When a change pushes away a substantial portion of the user base, dismissing it as "just fork it" ignores a practical reality. Open-source principles are a little more evolved than "the code is public" and require transparent decision-making that respects diverse input. When "reasonable" is defined by the few and d
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939708994)
@pinheadmz a "technically" accurate gotcha attempt that ignores the deeper issue. The adoption drop signals a real erosion of trust, not just a casual exercise of open-source freedom. When a change pushes away a substantial portion of the user base, dismissing it as "just fork it" ignores a practical reality. Open-source principles are a little more evolved than "the code is public" and require transparent decision-making that respects diverse input. When "reasonable" is defined by the few and d
...
💬 pinheadmz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939767822)
@maluquices all I'm trying to say is, don't drag "open source" into this conversation. Every single word has been open, as well as years of historical merit of the author and reviewers.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939767822)
@maluquices all I'm trying to say is, don't drag "open source" into this conversation. Every single word has been open, as well as years of historical merit of the author and reviewers.
💬 maflcko commented on pull request "wallet, rpc: Change `OutputType` items from `string` into compile-time constants `string_view`":
(https://github.com/bitcoin/bitcoin/pull/32432#issuecomment-2939811207)
Are you still working on this?
(https://github.com/bitcoin/bitcoin/pull/32432#issuecomment-2939811207)
Are you still working on this?
💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2939857873)
I ran a few reindexes with to try reproducing your issue. Since we don't have compact block announcements during ibd/reindexes (like in your example), after discussing this with @andrewtoth, I've tried `reindex-chainstate` until 888,888 blocks with `-debug=bench -debug=leveldb` to plot the block connect times, comparing 32MiB (master @ 370c5926) with 2MiB (master with lower leveldb file size, v28-like setup @ c9417a59).
----
A differential flame graph comparing the two leveldb file sizes sugg
...
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2939857873)
I ran a few reindexes with to try reproducing your issue. Since we don't have compact block announcements during ibd/reindexes (like in your example), after discussing this with @andrewtoth, I've tried `reindex-chainstate` until 888,888 blocks with `-debug=bench -debug=leveldb` to plot the block connect times, comparing 32MiB (master @ 370c5926) with 2MiB (master with lower leveldb file size, v28-like setup @ c9417a59).
----
A differential flame graph comparing the two leveldb file sizes sugg
...
💬 brunoerg commented on pull request "test: wallet: cover wallet passphrase with a null char":
(https://github.com/bitcoin/bitcoin/pull/32675#discussion_r2126494684)
Yes, going to add it.
(https://github.com/bitcoin/bitcoin/pull/32675#discussion_r2126494684)
Yes, going to add it.
💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2939904739)
I've created a repo for benchmark data, and added my results plus @l0rinc's: https://github.com/sipa/lin-benches/tree/main/data
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2939904739)
I've created a repo for benchmark data, and added my results plus @l0rinc's: https://github.com/sipa/lin-benches/tree/main/data
💬 0xB10C commented on issue "Coin Selection tracepoint overreports use of APS":
(https://github.com/bitcoin/bitcoin/issues/25150#issuecomment-2939916998)
> @0xB10C do you think anything should be done with this tracepoint?
I'm not familiar familiar enough with coin selection to comment on if the tracepoint is broken or how to best fix it.
If it's still useful and being used, would be good to fix it, if not, I'd be happy to remove it. Can always be patched back in for coinselection measurements if needed in an adhoc basis.
AFAIK @murchandamus and @achow101 were the main users when it was added.
(https://github.com/bitcoin/bitcoin/issues/25150#issuecomment-2939916998)
> @0xB10C do you think anything should be done with this tracepoint?
I'm not familiar familiar enough with coin selection to comment on if the tracepoint is broken or how to best fix it.
If it's still useful and being used, would be good to fix it, if not, I'd be happy to remove it. Can always be patched back in for coinselection measurements if needed in an adhoc basis.
AFAIK @murchandamus and @achow101 were the main users when it was added.