👍 theuni approved a pull request: "Update leveldb subtree to latest upstream"
(https://github.com/bitcoin/bitcoin/pull/31671#pullrequestreview-2565178887)
utACK 910a11fa66305f90b0f3a8aa9d2055b58a2d8d80
(https://github.com/bitcoin/bitcoin/pull/31671#pullrequestreview-2565178887)
utACK 910a11fa66305f90b0f3a8aa9d2055b58a2d8d80
👍 ryanofsky approved a pull request: "Add multiprocess binaries to release build (except Windows, OpenBSD)"
(https://github.com/bitcoin/bitcoin/pull/30975#pullrequestreview-2565181290)
Code review ACK 4b5b8d4f63a9f9154ac8e37861c2b3781bb7fd2d. Since last review, this was rebased and a new commit was added to run symbol-check and security-check on bitcoin-node and bitcoin-gui binaries.
I'm not sure how frequently `rpc_misc.py` CI errors that are reported https://github.com/chaincodelabs/libmultiprocess/issues/128 happen, but if I understand correctly if this PR is merged we would expect these errors to happen more because more multiprocess tests will be run more? This might b
...
(https://github.com/bitcoin/bitcoin/pull/30975#pullrequestreview-2565181290)
Code review ACK 4b5b8d4f63a9f9154ac8e37861c2b3781bb7fd2d. Since last review, this was rebased and a new commit was added to run symbol-check and security-check on bitcoin-node and bitcoin-gui binaries.
I'm not sure how frequently `rpc_misc.py` CI errors that are reported https://github.com/chaincodelabs/libmultiprocess/issues/128 happen, but if I understand correctly if this PR is merged we would expect these errors to happen more because more multiprocess tests will be run more? This might b
...
💬 l0rinc commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924059948)
> Picking a random block is just as arbitrary
Absolutely, nobody recommended that.
> I'm sure there has been a block in past that had exactly 50% schnorr sigs
My point is that I'd appreciate putting in the work and actually testing that assumption. And I'm not recommending getting any block, but create one that is based on measured values, not guessed ones.
> Like over the last year it's probably going to be something around 40%.
Great, can we back that by actual measurements?
...
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924059948)
> Picking a random block is just as arbitrary
Absolutely, nobody recommended that.
> I'm sure there has been a block in past that had exactly 50% schnorr sigs
My point is that I'd appreciate putting in the work and actually testing that assumption. And I'm not recommending getting any block, but create one that is based on measured values, not guessed ones.
> Like over the last year it's probably going to be something around 40%.
Great, can we back that by actual measurements?
...
💬 l0rinc commented on pull request "optimization: `CheckBlock` input duplicate detection":
(https://github.com/bitcoin/bitcoin/pull/31682#discussion_r1924065290)
Thanks for the context!
Do you think it makes sense to update that here, or should I just close the PR and leave https://github.com/bitcoin/bitcoin/pull/31699 as a follow-up?
(https://github.com/bitcoin/bitcoin/pull/31682#discussion_r1924065290)
Thanks for the context!
Do you think it makes sense to update that here, or should I just close the PR and leave https://github.com/bitcoin/bitcoin/pull/31699 as a follow-up?
🚀 fanquake merged a pull request: "test: Bump sync_mempools timeout in p2p_1p1c_network.py"
(https://github.com/bitcoin/bitcoin/pull/31701)
(https://github.com/bitcoin/bitcoin/pull/31701)
⚠️ PaddyFlueckiger opened an issue: "Wrong/missing package content for unsigned macOS, ARM based packages"
(https://github.com/bitcoin/bitcoin/issues/31702)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
I believe the following two files have the same content (Bitcoin-Qt.app):
- bitcoin-28.1-arm64-apple-darwin-unsigned.tar.gz
- bitcoin-28.1-arm64-apple-darwin-unsigned.zip
I think they ought to contain:
- Bitcoin-Qt.app (bitcoin-28.1-arm64-apple-darwin-unsigned.zip)
- bitcoind, bitcoin-cli, etc. (bitcoin-28.1-arm64-apple-darwin-unsigned.tar.gz)
... but they both do not contain the bitcoin
...
(https://github.com/bitcoin/bitcoin/issues/31702)
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Current behaviour
I believe the following two files have the same content (Bitcoin-Qt.app):
- bitcoin-28.1-arm64-apple-darwin-unsigned.tar.gz
- bitcoin-28.1-arm64-apple-darwin-unsigned.zip
I think they ought to contain:
- Bitcoin-Qt.app (bitcoin-28.1-arm64-apple-darwin-unsigned.zip)
- bitcoind, bitcoin-cli, etc. (bitcoin-28.1-arm64-apple-darwin-unsigned.tar.gz)
... but they both do not contain the bitcoin
...
💬 theuni commented on pull request "init: Lock blocksdir in addition to datadir":
(https://github.com/bitcoin/bitcoin/pull/31674#issuecomment-2605264866)
> > It's not likely to happen currently, but may be more relevant in the future with applications using the kernel. Note that the kernel does not currently do any dir locking, but it should.
>
> I think if we want directory locking in the kernel library, we should do that here before we introduce and ossify new assumptions on when exactly the lock is taken. As an alternative, how about taking the lock in the `BlockManager` constructor, like done here https://github.com/TheCharlatan/bitcoin/tr
...
(https://github.com/bitcoin/bitcoin/pull/31674#issuecomment-2605264866)
> > It's not likely to happen currently, but may be more relevant in the future with applications using the kernel. Note that the kernel does not currently do any dir locking, but it should.
>
> I think if we want directory locking in the kernel library, we should do that here before we introduce and ossify new assumptions on when exactly the lock is taken. As an alternative, how about taking the lock in the `BlockManager` constructor, like done here https://github.com/TheCharlatan/bitcoin/tr
...
🚀 fanquake merged a pull request: "Update leveldb subtree to latest upstream"
(https://github.com/bitcoin/bitcoin/pull/31671)
(https://github.com/bitcoin/bitcoin/pull/31671)
👍 fanquake approved a pull request: "depends: Override default build type for `libevent`"
(https://github.com/bitcoin/bitcoin/pull/31661#pullrequestreview-2565227676)
ACK d44626a9c2eb95b434edc7a22a70f2cce63c9d84
(https://github.com/bitcoin/bitcoin/pull/31661#pullrequestreview-2565227676)
ACK d44626a9c2eb95b434edc7a22a70f2cce63c9d84
💬 TheCharlatan commented on pull request "init: Lock blocksdir in addition to datadir":
(https://github.com/bitcoin/bitcoin/pull/31674#issuecomment-2605281926)
> I like this better, yes. Ok if I take that as a starting point and refactor it a bit?
Sure!
(https://github.com/bitcoin/bitcoin/pull/31674#issuecomment-2605281926)
> I like this better, yes. Ok if I take that as a starting point and refactor it a bit?
Sure!
🚀 fanquake merged a pull request: "depends: Override default build type for `libevent`"
(https://github.com/bitcoin/bitcoin/pull/31661)
(https://github.com/bitcoin/bitcoin/pull/31661)
💬 fanquake commented on pull request "refactor: Use std::span over Span":
(https://github.com/bitcoin/bitcoin/pull/31519#issuecomment-2605305226)
Rebase now that we've got leveldb + the sha changes in?
(https://github.com/bitcoin/bitcoin/pull/31519#issuecomment-2605305226)
Rebase now that we've got leveldb + the sha changes in?
💬 l0rinc commented on pull request "refactor: Use std::span over Span":
(https://github.com/bitcoin/bitcoin/pull/31519#issuecomment-2605307972)
+ the `UCharCast` ones
(https://github.com/bitcoin/bitcoin/pull/31519#issuecomment-2605307972)
+ the `UCharCast` ones
💬 fjahr commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924113469)
> Absolutely, nobody recommended that.
You literally [suggested it one day ago](https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1922316363) and when @Eunovo said [he was going to follow through with it](https://github.com/bitcoin/bitcoin/pull/31689#issuecomment-2604687152) you gave him a thumbs up. That's what started this whole argument.
> Great, can we back that by actual measurements?
As I said, I think 50/50 is fine so I won't do those measurements. Unless @Eunovo wants to
...
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924113469)
> Absolutely, nobody recommended that.
You literally [suggested it one day ago](https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1922316363) and when @Eunovo said [he was going to follow through with it](https://github.com/bitcoin/bitcoin/pull/31689#issuecomment-2604687152) you gave him a thumbs up. That's what started this whole argument.
> Great, can we back that by actual measurements?
As I said, I think 50/50 is fine so I won't do those measurements. Unless @Eunovo wants to
...
💬 l0rinc commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924120812)
> You literally https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1922316363
Read it again, there was no randomness suggested, rather the opposite, a well thought out investigation.
> likely than not that we will see more taproot adoption rather than less
Exactly, so why 50/50 and not 80/20?
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924120812)
> You literally https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1922316363
Read it again, there was no randomness suggested, rather the opposite, a well thought out investigation.
> likely than not that we will see more taproot adoption rather than less
Exactly, so why 50/50 and not 80/20?
💬 fjahr commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924125286)
> Exactly, so why 50/50 and not 80/20?
Why 80/20?
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924125286)
> Exactly, so why 50/50 and not 80/20?
Why 80/20?
💬 l0rinc commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924126425)
Exactly!
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924126425)
Exactly!
💬 fjahr commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924128794)
> Read it again, there was no randomness suggested
What investigation? You suggested to pick a random block from mainnet and @Eunovo followed up with this saying "Block 861848 for example".
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924128794)
> Read it again, there was no randomness suggested
What investigation? You suggested to pick a random block from mainnet and @Eunovo followed up with this saying "Block 861848 for example".
💬 fjahr commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924131171)
> > Exactly, so why 50/50 and not 80/20?
>
> Why 80/20?
I hope you get the point. I can ask you why why why for anything you suggest too (why do you want to look at the past? Why do you want to look at the past year/6 months etc) and this PR will not go anywhere which would be a shame. This is a pointless debate.
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924131171)
> > Exactly, so why 50/50 and not 80/20?
>
> Why 80/20?
I hope you get the point. I can ask you why why why for anything you suggest too (why do you want to look at the past? Why do you want to look at the past year/6 months etc) and this PR will not go anywhere which would be a shame. This is a pointless debate.
💬 l0rinc commented on pull request "Benchmark Chainstate::ConnectBlock duration":
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924131994)
Please read what I wrote, there was no random block suggestion.
All I'm saying is let's back up our choices by data instead of random values guided by feelings.
Did not expect that to be a controversial statement...
(https://github.com/bitcoin/bitcoin/pull/31689#discussion_r1924131994)
Please read what I wrote, there was no random block suggestion.
All I'm saying is let's back up our choices by data instead of random values guided by feelings.
Did not expect that to be a controversial statement...