💬 hebasto commented on issue "`bitcoin.exe` is not included in Windows installer":
(https://github.com/bitcoin/bitcoin/issues/33418#issuecomment-3303414350)
nm
(https://github.com/bitcoin/bitcoin/issues/33418#issuecomment-3303414350)
nm
💬 sipa commented on pull request "txgraph: randomize order of same-feerate distinct-cluster transactions":
(https://github.com/bitcoin/bitcoin/pull/33335#issuecomment-3303438667)
Rebased on top of #33157, as there are some conflicts, and I expect the other one will go in first.
(https://github.com/bitcoin/bitcoin/pull/33335#issuecomment-3303438667)
Rebased on top of #33157, as there are some conflicts, and I expect the other one will go in first.
💬 hebasto commented on pull request "build: Remove bitness suffix from Windows installer":
(https://github.com/bitcoin/bitcoin/pull/32132#issuecomment-3303467007)
This needs to be elaborated in Release Notes.
When upgrading to v30.0, it appears necessary to uninstall first in order to remove the "... (64-bit)" Start Menu entries. Otherwise, they remain lingering.
(https://github.com/bitcoin/bitcoin/pull/32132#issuecomment-3303467007)
This needs to be elaborated in Release Notes.
When upgrading to v30.0, it appears necessary to uninstall first in order to remove the "... (64-bit)" Start Menu entries. Otherwise, they remain lingering.
💬 ryanofsky commented on issue "Test interface_ipc.py fails with Duplicate ID error when libmultiprocess is installed system-wide":
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303596365)
I wonder if changing order of import directories to put the local include path first would fix this:
```diff
- imports = [str(capnp_dir), str(src_dir), str(mp_dir)]
+ imports = [str(mp_dir), str(capnp_dir), str(src_dir)]
```
So far I'm not able to reproduce it on nixos since there's no global include directory. But I think the problem might be the line [`capnp.load(str(mp_dir / "mp" / "proxy.capnp"), imports=imports)`](https://github.com/bitcoin/bitcoin/blob/1444ed855f438f1270104
...
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303596365)
I wonder if changing order of import directories to put the local include path first would fix this:
```diff
- imports = [str(capnp_dir), str(src_dir), str(mp_dir)]
+ imports = [str(mp_dir), str(capnp_dir), str(src_dir)]
```
So far I'm not able to reproduce it on nixos since there's no global include directory. But I think the problem might be the line [`capnp.load(str(mp_dir / "mp" / "proxy.capnp"), imports=imports)`](https://github.com/bitcoin/bitcoin/blob/1444ed855f438f1270104
...
💬 00w1 commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3303649039)
> As far as I can tell, around 10% of nodes that report a minfeefilter are already using 0.1 sats/vB or less at this point, so it should improve rapidly.
96% nodes are using 1sat/vB: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/
Mining pools that are **not** using 0.1 sat/vB for `blockcmintxfee`: ViaBTC, F2Pool, MARA, Ocean and SBI Crypto
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3303649039)
> As far as I can tell, around 10% of nodes that report a minfeefilter are already using 0.1 sats/vB or less at this point, so it should improve rapidly.
96% nodes are using 1sat/vB: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/
Mining pools that are **not** using 0.1 sat/vB for `blockcmintxfee`: ViaBTC, F2Pool, MARA, Ocean and SBI Crypto
💬 Sjors commented on pull request "Silent Payments: Receiving":
(https://github.com/bitcoin/bitcoin/pull/32966#issuecomment-3303689146)
Lightly tested cc0b97b7879a73b9341bf88391312799be91439a by creating a fresh wallet in the GUI, importing my earlier silent payment descriptor and rescanning to find my funds. I managed to send some coin and checked that the change went back to the descriptor (there are no other descriptors in the wallet).
When I tried to import it into a fresh watch-only wallet I got:
> Cannot import silent payment descriptor into a wallet with silent-payments disabled
It would be nicer if it just toggl
...
(https://github.com/bitcoin/bitcoin/pull/32966#issuecomment-3303689146)
Lightly tested cc0b97b7879a73b9341bf88391312799be91439a by creating a fresh wallet in the GUI, importing my earlier silent payment descriptor and rescanning to find my funds. I managed to send some coin and checked that the change went back to the descriptor (there are no other descriptors in the wallet).
When I tried to import it into a fresh watch-only wallet I got:
> Cannot import silent payment descriptor into a wallet with silent-payments disabled
It would be nicer if it just toggl
...
💬 l0rinc commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2356043011)
that's what the previous check does on line 23, this validates that it's in a reasonable range, e.g. we're not returning number of bits or something
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2356043011)
that's what the previous check does on line 23, this validates that it's in a reasonable range, e.g. we're not returning number of bits or something
💬 Sjors commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#issuecomment-3303715446)
re-ACK 453b0fa286e5dce0af682b7b73684dd6415a50de
Just a rebase. Briefly retested on macOS that `build/bin/bitcoin node -ipcbind=unix` launches `bitcoin-node`.
(https://github.com/bitcoin/bitcoin/pull/33229#issuecomment-3303715446)
re-ACK 453b0fa286e5dce0af682b7b73684dd6415a50de
Just a rebase. Briefly retested on macOS that `build/bin/bitcoin node -ipcbind=unix` launches `bitcoin-node`.
💬 l0rinc commented on pull request "coinstats: avoid unnecessary Coin copy in ApplyHash":
(https://github.com/bitcoin/bitcoin/pull/33410#discussion_r2356055506)
given the above warning, can you create a godbolt reproducer to check if the compiler can already deduce this or not?
(https://github.com/bitcoin/bitcoin/pull/33410#discussion_r2356055506)
given the above warning, can you create a godbolt reproducer to check if the compiler can already deduce this or not?
⚠️ yancyribbens opened an issue: "coin-grinder missing test for TOTAL_TRIES"
(https://github.com/bitcoin/bitcoin/issues/33419)
The following (mutation) code can be remove from coin-grinder [here](https://github.com/bitcoin/bitcoin/blob/1444ed855f438f1270104fca259ce61b99ed5cdb/src/wallet/coinselection.cpp#L466) without encountering a test failure
```
if (curr_try >= TOTAL_TRIES) {
// Solution is not guaranteed to be optimal if `curr_try` hit TOTAL_TRIES
result.SetAlgoCompleted(false);
break;
}
```
This ought to be a similar test to [Test BnB attempt limit (`TOTAL_TRIES`)](https://github.com/bitcoin/bitcoin/b
...
(https://github.com/bitcoin/bitcoin/issues/33419)
The following (mutation) code can be remove from coin-grinder [here](https://github.com/bitcoin/bitcoin/blob/1444ed855f438f1270104fca259ce61b99ed5cdb/src/wallet/coinselection.cpp#L466) without encountering a test failure
```
if (curr_try >= TOTAL_TRIES) {
// Solution is not guaranteed to be optimal if `curr_try` hit TOTAL_TRIES
result.SetAlgoCompleted(false);
break;
}
```
This ought to be a similar test to [Test BnB attempt limit (`TOTAL_TRIES`)](https://github.com/bitcoin/bitcoin/b
...
💬 yancyribbens commented on issue "coin-grinder missing test for TOTAL_TRIES":
(https://github.com/bitcoin/bitcoin/issues/33419#issuecomment-3303748477)
cc @murchandamus
(https://github.com/bitcoin/bitcoin/issues/33419#issuecomment-3303748477)
cc @murchandamus
📝 ryanofsky opened a pull request: "test: Avoid interface_ipc.py Duplicate ID errors"
(https://github.com/bitcoin/bitcoin/pull/33420)
This change should fix issue https://github.com/bitcoin/bitcoin/issues/33417 reported by zaidmstrr. It's possible to reproduce the `mp/proxy.capnp:0: failed: Duplicate ID @0xcc316e3f71a040fb` error by installing libmultiprocess system-wide, or to one of the locations listed in the python test's `imports` list before the local libmultiprocess subtree, and then running the test.
(https://github.com/bitcoin/bitcoin/pull/33420)
This change should fix issue https://github.com/bitcoin/bitcoin/issues/33417 reported by zaidmstrr. It's possible to reproduce the `mp/proxy.capnp:0: failed: Duplicate ID @0xcc316e3f71a040fb` error by installing libmultiprocess system-wide, or to one of the locations listed in the python test's `imports` list before the local libmultiprocess subtree, and then running the test.
💬 ryanofsky commented on issue "Test interface_ipc.py fails with Duplicate ID error when libmultiprocess is installed system-wide":
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303794531)
I was able to reproduce the error by modifying the test to point at an external libmultiprocess installation and I think #33420 should fix it
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303794531)
I was able to reproduce the error by modifying the test to point at an external libmultiprocess installation and I think #33420 should fix it
💬 zaidmstrr commented on issue "Test interface_ipc.py fails with Duplicate ID error when libmultiprocess is installed system-wide":
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303796570)
I tested with your suggested change `imports = [str(mp_dir), str(capnp_dir), str(src_dir)]` and this fixes the issue. As now `mp_dir` was in the first place of the `imports` list so when `capnp.load()` parses the `imports` it finds `proxy.capnp` early, so no further lookups in the global directory were taken.
(https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303796570)
I tested with your suggested change `imports = [str(mp_dir), str(capnp_dir), str(src_dir)]` and this fixes the issue. As now `mp_dir` was in the first place of the `imports` list so when `capnp.load()` parses the `imports` it finds `proxy.capnp` early, so no further lookups in the global directory were taken.
🤔 zaidmstrr reviewed a pull request: "test: Avoid interface_ipc.py Duplicate ID errors"
(https://github.com/bitcoin/bitcoin/pull/33420#pullrequestreview-3235350017)
Tested ACK [e9c5227](https://github.com/bitcoin/bitcoin/pull/33420/commits/e9c52272ebd78d01882ac9b32b1aee8e12d87bec)
This fixes the issue and is also mentioned [here](https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303796570).
(https://github.com/bitcoin/bitcoin/pull/33420#pullrequestreview-3235350017)
Tested ACK [e9c5227](https://github.com/bitcoin/bitcoin/pull/33420/commits/e9c52272ebd78d01882ac9b32b1aee8e12d87bec)
This fixes the issue and is also mentioned [here](https://github.com/bitcoin/bitcoin/issues/33417#issuecomment-3303796570).
💬 ArmchairCryptologist commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3303852998)
> 96% nodes are using 1sat/vB: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/
Not saying their numbers do not have better coverage, but I'm basing my stats off nodes that connect to my public nodes, where as of right now, 79 out of 794 connected nodes that report a feefilter have it set to 0.1 sat/vB or less, which is just about 10%. The ratio is pretty similar across all nodes, but I suppose it could be skewed by nodes that are specifically trying to connect
...
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3303852998)
> 96% nodes are using 1sat/vB: https://delvingbitcoin.org/t/measuring-minrelaytxfee-across-the-bitcoin-network/
Not saying their numbers do not have better coverage, but I'm basing my stats off nodes that connect to my public nodes, where as of right now, 79 out of 794 connected nodes that report a feefilter have it set to 0.1 sat/vB or less, which is just about 10%. The ratio is pretty similar across all nodes, but I suppose it could be skewed by nodes that are specifically trying to connect
...
💬 sdaftuar commented on pull request "Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2356170332)
Hmm, so there is a sort-of dependency between this invocation of `CheckMemPoolPolicyLimits()` and `ReplacementChecks()` -- the cluster size limit check won't be correct if we invoke it before we've added potential conflicts for removal to the changeset as well. However, if there are conflicts for removal, then cluster size limits are checked within `ReplacementChecks()` anyway, so there's not really an issue, except that this slightly confusing and perhaps this relationship could be overlooked
...
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2356170332)
Hmm, so there is a sort-of dependency between this invocation of `CheckMemPoolPolicyLimits()` and `ReplacementChecks()` -- the cluster size limit check won't be correct if we invoke it before we've added potential conflicts for removal to the changeset as well. However, if there are conflicts for removal, then cluster size limits are checked within `ReplacementChecks()` anyway, so there's not really an issue, except that this slightly confusing and perhaps this relationship could be overlooked
...
💬 Sjors commented on pull request "test: Avoid interface_ipc.py Duplicate ID errors":
(https://github.com/bitcoin/bitcoin/pull/33420#issuecomment-3303876135)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/33420#issuecomment-3303876135)
Concept ACK
💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2356183335)
The order is intentional, we want to always fill in data that we know about first.
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2356183335)
The order is intentional, we want to always fill in data that we know about first.
💬 achow101 commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2356190597)
No, signing does not log.
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2356190597)
No, signing does not log.