💬 ukml commented on issue "Link":
(https://github.com/bitcoin/bitcoin/issues/33739#issuecomment-3464792014)
This link does not work
(https://github.com/bitcoin/bitcoin/issues/33739#issuecomment-3464792014)
This link does not work
✅ pinheadmz closed an issue: "Link"
(https://github.com/bitcoin/bitcoin/issues/33739)
(https://github.com/bitcoin/bitcoin/issues/33739)
📝 fjahr opened a pull request: "RFC: bench: Add multi thread benchmarking"
(https://github.com/bitcoin/bitcoin/pull/33740)
This adds a rough way to run specific benchmarks with different numbers of worker threads to see how these impact performance. This is useful for me in the batch validation context and for potential refactorings of checkqueue but I am not sure if this is useful in many other contexts so I am leaving this as a RFC draft for now to see if there is any interest in merging something like this.
Example output:
```
$ build/bin/bench_bitcoin -filter=ConnectBlockAllSchnorr -min-time=1000 -scale-t
...
(https://github.com/bitcoin/bitcoin/pull/33740)
This adds a rough way to run specific benchmarks with different numbers of worker threads to see how these impact performance. This is useful for me in the batch validation context and for potential refactorings of checkqueue but I am not sure if this is useful in many other contexts so I am leaving this as a RFC draft for now to see if there is any interest in merging something like this.
Example output:
```
$ build/bin/bench_bitcoin -filter=ConnectBlockAllSchnorr -min-time=1000 -scale-t
...
💬 fjahr commented on pull request "checkqueue: set MAX_SCRIPTCHECK_THREADS to nCores - 1":
(https://github.com/bitcoin/bitcoin/pull/32692#issuecomment-3465177675)
> The reason for the existing limit of 15 is because benchmarks showed that even on an otherwise unloaded machine with more cores than that, adding more script validation threads was net slower after about that many. That benchmark dates from 2013, so there is no reason to assume it still holds, as both hardware and typical blockchain script usage has changed significantly, as well as other parts of the codebase. But it would still be worth investigating if there isn't just some number above whi
...
(https://github.com/bitcoin/bitcoin/pull/32692#issuecomment-3465177675)
> The reason for the existing limit of 15 is because benchmarks showed that even on an otherwise unloaded machine with more cores than that, adding more script validation threads was net slower after about that many. That benchmark dates from 2013, so there is no reason to assume it still holds, as both hardware and typical blockchain script usage has changed significantly, as well as other parts of the codebase. But it would still be worth investigating if there isn't just some number above whi
...
💬 fjahr commented on pull request "RFC: bench: Add multi thread benchmarking":
(https://github.com/bitcoin/bitcoin/pull/33740#issuecomment-3465206321)
I people could test the exact command as above it might be interesting to post the results here. For me at least, 13 worker threads are consistently delivering a better result than 15 worker threads.
(https://github.com/bitcoin/bitcoin/pull/33740#issuecomment-3465206321)
I people could test the exact command as above it might be interesting to post the results here. For me at least, 13 worker threads are consistently delivering a better result than 15 worker threads.
💬 Frenchanfry commented on issue "Limit "Bulk Dust" with a default filter or consensus..":
(https://github.com/bitcoin/bitcoin/issues/33737#issuecomment-3465272210)
I love this idea to keep spammers away; it also is fundamental when bitcoins value isn't compared relatively to the $. to keep the network clean and efficient.
1 satoshi = 1 satoshi.
(https://github.com/bitcoin/bitcoin/issues/33737#issuecomment-3465272210)
I love this idea to keep spammers away; it also is fundamental when bitcoins value isn't compared relatively to the $. to keep the network clean and efficient.
1 satoshi = 1 satoshi.
✅ pinheadmz closed an issue: "Limit "Bulk Dust" with a default filter or consensus.."
(https://github.com/bitcoin/bitcoin/issues/33737)
(https://github.com/bitcoin/bitcoin/issues/33737)
💬 pinheadmz commented on issue "Limit "Bulk Dust" with a default filter or consensus..":
(https://github.com/bitcoin/bitcoin/issues/33737#issuecomment-3465288829)
This should be posted on the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev), the [Delving Bitcoin forum](https://delvingbitcoin.org/) or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on [Stack Exchange](https://bitcoin.stackexchange.com/). The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.
(https://github.com/bitcoin/bitcoin/issues/33737#issuecomment-3465288829)
This should be posted on the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev), the [Delving Bitcoin forum](https://delvingbitcoin.org/) or some other platform where broad, protocol-level concepts are discussed. Conceptual questions and most usage questions can be posted on [Stack Exchange](https://bitcoin.stackexchange.com/). The Bitcoin Core issue tracker is reserved for discussion about this specific software project only, its implementation and usage.
🤔 fjahr reviewed a pull request: "[Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2"
(https://github.com/bitcoin/bitcoin/pull/32617#pullrequestreview-3396562602)
Just skimmed a bit to start. Before spending significant time on reviewing this, I think it would be great if this could be cleaned up to the point that it can be taken out of draft status. Potentially also consider splitting it into multiple commits.
(https://github.com/bitcoin/bitcoin/pull/32617#pullrequestreview-3396562602)
Just skimmed a bit to start. Before spending significant time on reviewing this, I think it would be great if this could be cleaned up to the point that it can be taken out of draft status. Potentially also consider splitting it into multiple commits.
💬 fjahr commented on pull request "[Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2":
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475742295)
There is a 2.5 but no 3?
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475742295)
There is a 2.5 but no 3?
💬 fjahr commented on pull request "[Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2":
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475743528)
There are two 2s here
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475743528)
There are two 2s here
💬 fjahr commented on pull request "[Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2":
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475734567)
2018?
(https://github.com/bitcoin/bitcoin/pull/32617#discussion_r2475734567)
2018?
💬 w0xlt commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2476033021)
Should the height be validated here ?
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2476033021)
Should the height be validated here ?
💬 davidgumberg commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3465392926)
Rebased to address reviewer feedback.
@ajtowns I'm thinking of this now less as a mitigation for the fingerprinting vector, and more just defense-in-depth / closing off attack surface for compact blocks. E.g. [CVE-2024-35202](https://bitcoincore.org/en/2024/10/08/disclose-blocktxn-crash/) and [CVE-2024-52921](https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/) are more trivial to exploit because you don't need an HB slot.
An HB slot might be a low bar for
...
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3465392926)
Rebased to address reviewer feedback.
@ajtowns I'm thinking of this now less as a mitigation for the fingerprinting vector, and more just defense-in-depth / closing off attack surface for compact blocks. E.g. [CVE-2024-35202](https://bitcoincore.org/en/2024/10/08/disclose-blocktxn-crash/) and [CVE-2024-52921](https://bitcoincore.org/en/2024/10/08/disclose-mutated-blocks-hindering-propagation/) are more trivial to exploit because you don't need an HB slot.
An HB slot might be a low bar for
...
💬 w0xlt commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2476043001)
Out of curiosity, why return a reference instead of an owned copy? It would avoid lifetime ambiguity
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2476043001)
Out of curiosity, why return a reference instead of an owned copy? It would avoid lifetime ambiguity
🤔 w0xlt reviewed a pull request: "kernel: Introduce C header API"
(https://github.com/bitcoin/bitcoin/pull/30595#pullrequestreview-3396973870)
Are the `assert` statements in `src/kernel/bitcoinkernel.cpp` really necessary, or could they be replaced with runtime validation?
Using `assert` makes the project incompatible with some constrained TEEs, such as SGX.
(https://github.com/bitcoin/bitcoin/pull/30595#pullrequestreview-3396973870)
Are the `assert` statements in `src/kernel/bitcoinkernel.cpp` really necessary, or could they be replaced with runtime validation?
Using `assert` makes the project incompatible with some constrained TEEs, such as SGX.
📝 polespinasa opened a pull request: "rpc: [PoC] Optionally print feerates in sat/vb"
(https://github.com/bitcoin/bitcoin/pull/33741)
Part of https://github.com/bitcoin/bitcoin/issues/32093
Returning feerates in BTC/kvB it can be very burdensome and is not good practice, as the most widely adopted units are sat/vB. This PR aims to show a PoC of how we could migrate to sat/vb in a backwards compatible manner.
The RPC affectd by this PR are `getmempoolinfo`, `getnetworkinfo`, `getwalletinfo`, `estimatesmartfee` and `estimaterawfee`.
Because of sub 1sat/vB environment we cannot rely on GetFee() because it internally uses
...
(https://github.com/bitcoin/bitcoin/pull/33741)
Part of https://github.com/bitcoin/bitcoin/issues/32093
Returning feerates in BTC/kvB it can be very burdensome and is not good practice, as the most widely adopted units are sat/vB. This PR aims to show a PoC of how we could migrate to sat/vb in a backwards compatible manner.
The RPC affectd by this PR are `getmempoolinfo`, `getnetworkinfo`, `getwalletinfo`, `estimatesmartfee` and `estimaterawfee`.
Because of sub 1sat/vB environment we cannot rely on GetFee() because it internally uses
...
💬 polespinasa commented on issue "Migrate from BTC/kvB to sat/vB on RPC and startup options":
(https://github.com/bitcoin/bitcoin/issues/32093#issuecomment-3465697269)
https://github.com/bitcoin/bitcoin/pull/33741 implements a PoC on how we can print feerates using sat/vB in a backwards compatible way.
Some similar approach could be used for the arguments, where the user can set feerates in sat/vB and it will be interpreted as it only if he also sets satvb flag to true.
That would create inconsistencies with the approach already taken by `fundrawtransaction`. But being honest I don't like the two arguments approach I think the UX is horrible and it can lead
...
(https://github.com/bitcoin/bitcoin/issues/32093#issuecomment-3465697269)
https://github.com/bitcoin/bitcoin/pull/33741 implements a PoC on how we can print feerates using sat/vB in a backwards compatible way.
Some similar approach could be used for the arguments, where the user can set feerates in sat/vB and it will be interpreted as it only if he also sets satvb flag to true.
That would create inconsistencies with the approach already taken by `fundrawtransaction`. But being honest I don't like the two arguments approach I think the UX is horrible and it can lead
...
🤔 w0xlt reviewed a pull request: "rpc: Optionally print feerates in sat/vb"
(https://github.com/bitcoin/bitcoin/pull/33741#pullrequestreview-3397062784)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/33741#pullrequestreview-3397062784)
Concept ACK
💬 furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#issuecomment-3465766818)
> Can you run the commits through clang-format-diff.py? There are a bunch of formatting issues in the first two commits.
Pushed.
(https://github.com/bitcoin/bitcoin/pull/33689#issuecomment-3465766818)
> Can you run the commits through clang-format-diff.py? There are a bunch of formatting issues in the first two commits.
Pushed.