💬 janb84 commented on pull request "doc: bump the template macOS version since 14 is now the minimum supported version":
(https://github.com/bitcoin/bitcoin/pull/33573#issuecomment-3382760187)
> > The v30 has still support for 13+. see [https://github.com/bitcoin/bitcoin/pull/33559#discussion_r2414194987`](https://github.com/bitcoin/bitcoin/pull/33559#discussion_r2414194987%60)
> > Think it's still to early to change this if v30 has still full support for that version.
>
> Note that this PR is against master, not 30.x
I get it. but it's changing .github issue templates. Github uses master as a base for the templates right ?
So V30 or not at merge it will use this template as
...
(https://github.com/bitcoin/bitcoin/pull/33573#issuecomment-3382760187)
> > The v30 has still support for 13+. see [https://github.com/bitcoin/bitcoin/pull/33559#discussion_r2414194987`](https://github.com/bitcoin/bitcoin/pull/33559#discussion_r2414194987%60)
> > Think it's still to early to change this if v30 has still full support for that version.
>
> Note that this PR is against master, not 30.x
I get it. but it's changing .github issue templates. Github uses master as a base for the templates right ?
So V30 or not at merge it will use this template as
...
💬 Crypt-iQ commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2414740159)
Answered in the review club, also posting here:
Without this commit, leveldb's `MemTable` is non-deterministic since it depends on insert order. If we sort `vBlocks` right before calling `WriteBatchSync`, then the leveldb non-determinism is solved, but the number of times we call the comparison function varies since the initial ordering before sorting varies across runs of the same input. That means we need to sort when we insert into `m_dirty_blockindex` as the insert order _is_ deterministi
...
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2414740159)
Answered in the review club, also posting here:
Without this commit, leveldb's `MemTable` is non-deterministic since it depends on insert order. If we sort `vBlocks` right before calling `WriteBatchSync`, then the leveldb non-determinism is solved, but the number of times we call the comparison function varies since the initial ordering before sorting varies across runs of the same input. That means we need to sort when we insert into `m_dirty_blockindex` as the insert order _is_ deterministi
...
💬 davidgumberg commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2414749363)
Thanks for this suggestion, I've taken it.
(https://github.com/bitcoin/bitcoin/pull/32606#discussion_r2414749363)
Thanks for this suggestion, I've taken it.
💬 davidgumberg commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3382814452)
Force-pushed to address merge conflict and @hodlinator's feedback to log IP's.
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3382814452)
Force-pushed to address merge conflict and @hodlinator's feedback to log IP's.
💬 glozow commented on pull request "doc: bump the template macOS version since 14 is now the minimum supported version":
(https://github.com/bitcoin/bitcoin/pull/33573#issuecomment-3382815837)
> I get it. but it's changing .github issue templates. Github uses master as a base for the templates right ?
Oh sorry I misunderstood, you're absolutely right. I think it's more likely for people to use v30 on something more modern though.
(https://github.com/bitcoin/bitcoin/pull/33573#issuecomment-3382815837)
> I get it. but it's changing .github issue templates. Github uses master as a base for the templates right ?
Oh sorry I misunderstood, you're absolutely right. I think it's more likely for people to use v30 on something more modern though.
💬 Crypt-iQ commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2414764467)
Will compare the coverage from increasing to 4 vs increasing to 8.
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2414764467)
Will compare the coverage from increasing to 4 vs increasing to 8.
💬 glozow commented on issue "Mempool Expiry eviction might remove txs that could be mined in the next block":
(https://github.com/bitcoin/bitcoin/issues/33510#issuecomment-3382890614)
> Also thanks for digging up the history for expiration; I was wondering if it predated RBF, eviction, and CPFP, but it looks like all those things were added roughly around the same time. I can imagine one other reason for expiration, which probably didn't exist at the time it was added: allowing transactions to be replaced for free (e.g. without the incremental relay fee, as a counter to the pinning that's caused by that).
I'll add that, back in the day, expiry would have been the only way to
...
(https://github.com/bitcoin/bitcoin/issues/33510#issuecomment-3382890614)
> Also thanks for digging up the history for expiration; I was wondering if it predated RBF, eviction, and CPFP, but it looks like all those things were added roughly around the same time. I can imagine one other reason for expiration, which probably didn't exist at the time it was added: allowing transactions to be replaced for free (e.g. without the incremental relay fee, as a counter to the pinning that's caused by that).
I'll add that, back in the day, expiry would have been the only way to
...
💬 theuni commented on pull request "depends: Update URL for `qrencode` package source tarball":
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382904047)
I don't understand how this was ever intended to work. A depends source has a single hash.. that's pretty fundamental to the way it was designed. And a filename with a new hash is exactly the kind of thing it was intended to catch and disallow.
The filename was changed upstream, and rightly so. Why did we not just adopt the new filename/hash and let that be the end of it?
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382904047)
I don't understand how this was ever intended to work. A depends source has a single hash.. that's pretty fundamental to the way it was designed. And a filename with a new hash is exactly the kind of thing it was intended to catch and disallow.
The filename was changed upstream, and rightly so. Why did we not just adopt the new filename/hash and let that be the end of it?
💬 hebasto commented on pull request "depends: Update URL for `qrencode` package source tarball":
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382931665)
> I don't understand how this was ever intended to work. A depends source has a single hash.. that's pretty fundamental to the way it was designed. And a filename with a new hash is exactly the kind of thing it was intended to catch and disallow.
>
>
>
> The filename was changed upstream, and rightly so. Why did we not just adopt the new filename/hash and let that be the end of it?
>
That was the initial approach in https://github.com/bitcoin/bitcoin/commit/980e4987db0450cabb8761433001841f7e
...
(https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382931665)
> I don't understand how this was ever intended to work. A depends source has a single hash.. that's pretty fundamental to the way it was designed. And a filename with a new hash is exactly the kind of thing it was intended to catch and disallow.
>
>
>
> The filename was changed upstream, and rightly so. Why did we not just adopt the new filename/hash and let that be the end of it?
>
That was the initial approach in https://github.com/bitcoin/bitcoin/commit/980e4987db0450cabb8761433001841f7e
...
⚠️ Crypt-iQ opened an issue: "CanDirectFetch degrades HB compact block relay if blocks are rare"
(https://github.com/bitcoin/bitcoin/issues/33578)
[`CanDirectFetch`](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/net_processing.cpp#L1324) returns true when a node's local time is within 200 minutes of that node's tip time. When receiving a `CMPCTBLOCK` message from a peer, the node will [first check](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/net_processing.cpp#L4428) if there is an in-flight block request for the block hash. If the block is not already requeste
...
(https://github.com/bitcoin/bitcoin/issues/33578)
[`CanDirectFetch`](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/net_processing.cpp#L1324) returns true when a node's local time is within 200 minutes of that node's tip time. When receiving a `CMPCTBLOCK` message from a peer, the node will [first check](https://github.com/bitcoin/bitcoin/blob/b510893d00760083ac36948747aa6ebd84656192/src/net_processing.cpp#L4428) if there is an in-flight block request for the block hash. If the block is not already requeste
...
💬 plebhash commented on issue "[`v30.0rc3`]`bitcoin-node` aborts with mining IPC interface usage":
(https://github.com/bitcoin/bitcoin/issues/33554#issuecomment-3382951196)
> Indirectly, yes. The server threads will destroy themselves as soon as they are no longer referenced, either by the client or an ongoing IPC call that is using them. So as long as the client is not holding references to threads it is not using, they will be cleaned up.
ok I had AI tell me the same thing but didn't want to blindly trust it, so that's why I went out of my want o confirm that. Good to know.
then also what I said about unbounded resource consumption above is not true, since thre
...
(https://github.com/bitcoin/bitcoin/issues/33554#issuecomment-3382951196)
> Indirectly, yes. The server threads will destroy themselves as soon as they are no longer referenced, either by the client or an ongoing IPC call that is using them. So as long as the client is not holding references to threads it is not using, they will be cleaned up.
ok I had AI tell me the same thing but didn't want to blindly trust it, so that's why I went out of my want o confirm that. Good to know.
then also what I said about unbounded resource consumption above is not true, since thre
...
💬 plebhash commented on issue "RFC: Cancelling waitNext calls in the IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3383006863)
tbh option 3 feels like the lowest hanging fruit on our side, because it would require basically no changes from the current implementation (aside from the instantiation of new server threads, which is only a temporary workaround for the issues we're trying to mitigate here).
basically the arrival of `CoinbaseOutputConstraints` triggers the following:
- breaking the loop that monitors for `waitNext` responses
- instantiating a `BlockTemplate` via `Mining::createNewBlock()` under new coinbase co
...
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3383006863)
tbh option 3 feels like the lowest hanging fruit on our side, because it would require basically no changes from the current implementation (aside from the instantiation of new server threads, which is only a temporary workaround for the issues we're trying to mitigate here).
basically the arrival of `CoinbaseOutputConstraints` triggers the following:
- breaking the loop that monitors for `waitNext` responses
- instantiating a `BlockTemplate` via `Mining::createNewBlock()` under new coinbase co
...
💬 achow101 commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383051033)
Added a revert of 6de80512632afe612a3427463c94ac51f90f5203. as well since we should be preserving the filename to hash invariant, as discussed in https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382904047
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383051033)
Added a revert of 6de80512632afe612a3427463c94ac51f90f5203. as well since we should be preserving the filename to hash invariant, as discussed in https://github.com/bitcoin/bitcoin/pull/33494#issuecomment-3382904047
⚠️ rock9701 opened an issue: "rng"
(https://github.com/bitcoin/bitcoin/issues/33579)
### Motivation
# Hello, Enthusiasts 👋
I'm building a community dedicated to exploring the process of *private key generation* — specifically, the logic and inner workings of *RNG (Random Number Generators)* and the algorithms that power modern cryptographic systems.
The goal is to understand how different RNG implementations work, how they affect security, and how we can improve the quality of randomness in key generation.
If you're interested in topics like:
- entropy generation and crypto
...
(https://github.com/bitcoin/bitcoin/issues/33579)
### Motivation
# Hello, Enthusiasts 👋
I'm building a community dedicated to exploring the process of *private key generation* — specifically, the logic and inner workings of *RNG (Random Number Generators)* and the algorithms that power modern cryptographic systems.
The goal is to understand how different RNG implementations work, how they affect security, and how we can improve the quality of randomness in key generation.
If you're interested in topics like:
- entropy generation and crypto
...
✅ rock9701 closed an issue: "rng"
(https://github.com/bitcoin/bitcoin/issues/33579)
(https://github.com/bitcoin/bitcoin/issues/33579)
📝 achow101 opened a pull request: "depends: Use $(package)_file_name when downloading from the fallback"
(https://github.com/bitcoin/bitcoin/pull/33580)
The server hosting the fallbacks uses `make download` so the files are only available with their overridden names rather than the original name on the upstream source. We should therefore also use the overridden name when downloading from the fallback.
Fixes https://github.com/bitcoin-core/bitcoincore.org/issues/1168
(https://github.com/bitcoin/bitcoin/pull/33580)
The server hosting the fallbacks uses `make download` so the files are only available with their overridden names rather than the original name on the upstream source. We should therefore also use the overridden name when downloading from the fallback.
Fixes https://github.com/bitcoin-core/bitcoincore.org/issues/1168
💬 theuni commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383131374)
@hebasto Could you explain the need for 46135d90ea9002e273f2a75283444afd080b81b1 as well? Since its justification was supporting behavior that we really don't want to be supported, is it necessary now that we're reverting that behavior?
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383131374)
@hebasto Could you explain the need for 46135d90ea9002e273f2a75283444afd080b81b1 as well? Since its justification was supporting behavior that we really don't want to be supported, is it necessary now that we're reverting that behavior?
💬 plebhash commented on issue "RFC: Cancelling waitNext calls in the IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3383146351)
oh sorry, just saw the remark saying that option 3 could have undesired consequences, I overlooked that on my first reading!
so yeah option 3 is not necessarily my go-to
option 2 would slightly increase complexity on rust side, but it seems perfectly doable
and also after contemplating option 4, it also seems like a low hanging fruit on our side (even though it seems more complex to implement on C++ side)
that's because we already drop the `waitNext` promise once a `CoinbaseOutputConstraints
...
(https://github.com/bitcoin/bitcoin/issues/33575#issuecomment-3383146351)
oh sorry, just saw the remark saying that option 3 could have undesired consequences, I overlooked that on my first reading!
so yeah option 3 is not necessarily my go-to
option 2 would slightly increase complexity on rust side, but it seems perfectly doable
and also after contemplating option 4, it also seems like a low hanging fruit on our side (even though it seems more complex to implement on C++ side)
that's because we already drop the `waitNext` promise once a `CoinbaseOutputConstraints
...
👍 theuni approved a pull request: "depends: Use $(package)_file_name when downloading from the fallback"
(https://github.com/bitcoin/bitcoin/pull/33580#pullrequestreview-3316448485)
utACK 671b774d1b58c491b53f2b2f6ee42fb6b65a0e71. I was going to PR the same change.
For more context: Our sources server runs `make download` and makes those sources available as a backup host.
We can't control upstream filenames, so sometimes we rename them for local storage in depends. For ex "v0.1.tar.gz" may become "libfoo-v0.1.tar.gz".
But when we try to fetch "v0.1.tar.gz" from our backup, it doesn't exist, because it's been renamed to "libfoo-v0.1.tar.gz" there.
So instead of r
...
(https://github.com/bitcoin/bitcoin/pull/33580#pullrequestreview-3316448485)
utACK 671b774d1b58c491b53f2b2f6ee42fb6b65a0e71. I was going to PR the same change.
For more context: Our sources server runs `make download` and makes those sources available as a backup host.
We can't control upstream filenames, so sometimes we rename them for local storage in depends. For ex "v0.1.tar.gz" may become "libfoo-v0.1.tar.gz".
But when we try to fetch "v0.1.tar.gz" from our backup, it doesn't exist, because it's been renamed to "libfoo-v0.1.tar.gz" there.
So instead of r
...
💬 theuni commented on pull request "Revert "depends: Update URL for `qrencode` package source tarball"":
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383202945)
Additionally, I think we want to go ahead and change the source and filename in order to disambiguate any builders who are currently in limbo. As suggested on the previous PR, I suggest:
```Makefile
$(package)_download_path=https://github.com/fukuchi/libqrencode/archive/refs/tags/
$(package)_download_file=v$($(package)_version).tar.gz
$(package)_file_name=$(package)-$($(package)_version)-v2.tar.gz
$(package)_sha256_hash=5385bc1b8c2f20f3b91d258bf8ccc8cf62023935df2d2676b5b67049f31a049c
```
...
(https://github.com/bitcoin/bitcoin/pull/33577#issuecomment-3383202945)
Additionally, I think we want to go ahead and change the source and filename in order to disambiguate any builders who are currently in limbo. As suggested on the previous PR, I suggest:
```Makefile
$(package)_download_path=https://github.com/fukuchi/libqrencode/archive/refs/tags/
$(package)_download_file=v$($(package)_version).tar.gz
$(package)_file_name=$(package)-$($(package)_version)-v2.tar.gz
$(package)_sha256_hash=5385bc1b8c2f20f3b91d258bf8ccc8cf62023935df2d2676b5b67049f31a049c
```
...