📝 hebasto converted_to_draft a pull request: "Enable HW-accelerated implementations of SHA256 for MSVC builds"
(https://github.com/bitcoin/bitcoin/pull/24773)
This PR enables AVX2, SSE4.1 and x86 SHA-NI implementations of SHA256 instead of the "standard" one.
**NOTE about testing**. During runtime the SHA-NI implementation is available only if a CPU has the `sha_ni` flag set.
(https://github.com/bitcoin/bitcoin/pull/24773)
This PR enables AVX2, SSE4.1 and x86 SHA-NI implementations of SHA256 instead of the "standard" one.
**NOTE about testing**. During runtime the SHA-NI implementation is available only if a CPU has the `sha_ni` flag set.
💬 cshintov commented on issue "Slow memory leak in v22.0?":
(https://github.com/bitcoin/bitcoin/issues/24542#issuecomment-1535190060)
I'm running `24.0.1` and I tried with various `rpcthreads` values `50, 100, 150`.
I could solve the issue by setting the below env var.
By default, since glibc 2.10, the C library will create up to two heap
arenas per core. This is known to cause excessive memory usage in some
scenarios. To avoid this we have to set
```MALLOC_ARENA_MAX=1```
without this the usage grows beyond 36GB, with this it stays under 2GB
normally.
ref: https://github.com/bitcoin/bi
...
(https://github.com/bitcoin/bitcoin/issues/24542#issuecomment-1535190060)
I'm running `24.0.1` and I tried with various `rpcthreads` values `50, 100, 150`.
I could solve the issue by setting the below env var.
By default, since glibc 2.10, the C library will create up to two heap
arenas per core. This is known to cause excessive memory usage in some
scenarios. To avoid this we have to set
```MALLOC_ARENA_MAX=1```
without this the usage grows beyond 36GB, with this it stays under 2GB
normally.
ref: https://github.com/bitcoin/bi
...
🤔 instagibbs reviewed a pull request: "BIP324: ElligatorSwift integrations"
(https://github.com/bitcoin/bitcoin/pull/27479#pullrequestreview-1413629831)
Looking good, have not reviewed the secp PRs yet
(https://github.com/bitcoin/bitcoin/pull/27479#pullrequestreview-1413629831)
Looking good, have not reviewed the secp PRs yet
💬 instagibbs commented on pull request "BIP324: ElligatorSwift integrations":
(https://github.com/bitcoin/bitcoin/pull/27479#discussion_r1185343503)
throwing it out there: could also have the `initiating` match erroneously, and assert that the secret *should not match* unless both privkeys/ent32s match?
(https://github.com/bitcoin/bitcoin/pull/27479#discussion_r1185343503)
throwing it out there: could also have the `initiating` match erroneously, and assert that the secret *should not match* unless both privkeys/ent32s match?
💬 instagibbs commented on pull request "BIP324: ElligatorSwift integrations":
(https://github.com/bitcoin/bitcoin/pull/27479#discussion_r1185352230)
where is this used?
(https://github.com/bitcoin/bitcoin/pull/27479#discussion_r1185352230)
where is this used?
💬 willcl-ark commented on issue "Compiling a bitcoin core version that accepts transactions over 100vkb":
(https://github.com/bitcoin/bitcoin/issues/27490#issuecomment-1535224839)
I agree this should be closed here. @batriskaweb3 has already been given guidance on the procedure they can follow to propose changes to relay policy and also other more suitable avenues to ask questions like this:
> I think this issue should be closed, and discussion moved to stack exchange, note that a few similar questions have already been posted: [bitcoin.stackexchange.com/search?q=MAX_STANDARD_TX_WEIGHT](https://bitcoin.stackexchange.com/search?q=MAX_STANDARD_TX_WEIGHT)
>
> If you th
...
(https://github.com/bitcoin/bitcoin/issues/27490#issuecomment-1535224839)
I agree this should be closed here. @batriskaweb3 has already been given guidance on the procedure they can follow to propose changes to relay policy and also other more suitable avenues to ask questions like this:
> I think this issue should be closed, and discussion moved to stack exchange, note that a few similar questions have already been posted: [bitcoin.stackexchange.com/search?q=MAX_STANDARD_TX_WEIGHT](https://bitcoin.stackexchange.com/search?q=MAX_STANDARD_TX_WEIGHT)
>
> If you th
...
🤔 theuni requested changes to a pull request: "Introduce platform-agnostic `ALWAYS_INLINE` macro"
(https://github.com/bitcoin/bitcoin/pull/27575#pullrequestreview-1413752558)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/27575#pullrequestreview-1413752558)
Concept ACK.
💬 theuni commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
I think it'd be better to error in this case so that we can add another platform exception if necessary. IIRC for the places that we use it, inlining is critical and we might want to design functions differently for platforms where it's not possible.
Especially given the [gcc semantics](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html):
> Failure to inline such a function is diagnosed as an error.
As-is, I think this is currently a theoretical regression as we might no
...
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
I think it'd be better to error in this case so that we can add another platform exception if necessary. IIRC for the places that we use it, inlining is critical and we might want to design functions differently for platforms where it's not possible.
Especially given the [gcc semantics](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html):
> Failure to inline such a function is diagnosed as an error.
As-is, I think this is currently a theoretical regression as we might no
...
💬 hebasto commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185419080)
Mind suggesting an error wording?
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185419080)
Mind suggesting an error wording?
💬 sangaman commented on issue "Slow memory leak in v22.0?":
(https://github.com/bitcoin/bitcoin/issues/24542#issuecomment-1535282807)
Thank you @cshintov ! I'll try this env var out and see if it solves my issue without having to change my config.
(https://github.com/bitcoin/bitcoin/issues/24542#issuecomment-1535282807)
Thank you @cshintov ! I'll try this env var out and see if it solves my issue without having to change my config.
💬 theuni commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185451991)
How about: `#error No known always_inline attribute for this platform.`
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185451991)
How about: `#error No known always_inline attribute for this platform.`
💬 hebasto commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535335103)
Updated d66232f625a0781da2f4269cd8c5199ded2f43da -> a0d13e873be437260a79a62777560677c6a651b8 ([pr27575.01](https://github.com/hebasto/bitcoin/commits/pr27575.01) -> [pr27575.02](https://github.com/hebasto/bitcoin/commits/pr27575.02), [diff](https://github.com/hebasto/bitcoin/compare/pr27575.01..pr27575.02)):
- addressed @theuni's [comment](https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
(https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535335103)
Updated d66232f625a0781da2f4269cd8c5199ded2f43da -> a0d13e873be437260a79a62777560677c6a651b8 ([pr27575.01](https://github.com/hebasto/bitcoin/commits/pr27575.01) -> [pr27575.02](https://github.com/hebasto/bitcoin/commits/pr27575.02), [diff](https://github.com/hebasto/bitcoin/compare/pr27575.01..pr27575.02)):
- addressed @theuni's [comment](https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
💬 hebasto commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535337768)
Updated d66232f625a0781da2f4269cd8c5199ded2f43da -> 3f19875d667522412408d06873e87ff8150e49c4 ([pr27575.01](https://github.com/hebasto/bitcoin/commits/pr27575.01) -> [pr27575.03](https://github.com/hebasto/bitcoin/commits/pr27575.03), [diff](https://github.com/hebasto/bitcoin/compare/pr27575.01..pr27575.03)):
- addressed @theuni's [comment](https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
(https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535337768)
Updated d66232f625a0781da2f4269cd8c5199ded2f43da -> 3f19875d667522412408d06873e87ff8150e49c4 ([pr27575.01](https://github.com/hebasto/bitcoin/commits/pr27575.01) -> [pr27575.03](https://github.com/hebasto/bitcoin/commits/pr27575.03), [diff](https://github.com/hebasto/bitcoin/compare/pr27575.01..pr27575.03)):
- addressed @theuni's [comment](https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185412930)
💬 hebasto commented on pull request "Introduce platform-agnostic `ALWAYS_INLINE` macro":
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185458777)
Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535337768).
(https://github.com/bitcoin/bitcoin/pull/27575#discussion_r1185458777)
Thanks! [Updated](https://github.com/bitcoin/bitcoin/pull/27575#issuecomment-1535337768).
💬 instagibbs commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#issuecomment-1535354925)
@sdaftuar did you have Current Thoughts about this approach? Trying to bridge IRC discussions to the blocking PR
(https://github.com/bitcoin/bitcoin/pull/24008#issuecomment-1535354925)
@sdaftuar did you have Current Thoughts about this approach? Trying to bridge IRC discussions to the blocking PR
📝 TheCharlatan opened a pull request: "kernel: Remove args, chainparams, chainparamsbase from kernel library"
(https://github.com/bitcoin/bitcoin/pull/27576)
This pull request is part of the `libbitcoinkernel` project https://github.com/bitcoin/bitcoin/issues/24303 https://github.com/bitcoin/bitcoin/projects/18 and more specifically its "Step 2: Decouple most non-consensus code from libbitcoinkernel". It is based on #27491 and #27125. Commits of this change start after the commit titled "commits after this are non-base". It will remain on draft until the two pull requests it is based on are merged.
This completes the removal of the node's chainpar
...
(https://github.com/bitcoin/bitcoin/pull/27576)
This pull request is part of the `libbitcoinkernel` project https://github.com/bitcoin/bitcoin/issues/24303 https://github.com/bitcoin/bitcoin/projects/18 and more specifically its "Step 2: Decouple most non-consensus code from libbitcoinkernel". It is based on #27491 and #27125. Commits of this change start after the commit titled "commits after this are non-base". It will remain on draft until the two pull requests it is based on are merged.
This completes the removal of the node's chainpar
...
📝 mzumsande opened a pull request: "p2p: give seednodes time before falling back to fixed seeds"
(https://github.com/bitcoin/bitcoin/pull/27577)
`-seednode` is an alternative bootstrap mechanism - when choosing it, we make a `AddrFetch` connection to the specified peer, gather addresses from them, and then disconnect. Presumably, if users specify a seednode they prefer addresses from that node over fixed seeds.
However, when disabling dns seeds and specifiying `-seednode`, `CConnman::ProcessAddrFetch()` immediately removes the entry from `m_addr_fetches` (before the seednode could give us addresses) - and once `m_addr_fetches` is em
...
(https://github.com/bitcoin/bitcoin/pull/27577)
`-seednode` is an alternative bootstrap mechanism - when choosing it, we make a `AddrFetch` connection to the specified peer, gather addresses from them, and then disconnect. Presumably, if users specify a seednode they prefer addresses from that node over fixed seeds.
However, when disabling dns seeds and specifiying `-seednode`, `CConnman::ProcessAddrFetch()` immediately removes the entry from `m_addr_fetches` (before the seednode could give us addresses) - and once `m_addr_fetches` is em
...
📝 benthecarman opened a pull request: "Allow accepting non-standard transactions on mainnet"
(https://github.com/bitcoin/bitcoin/pull/27578)
There are many projects today that have part of their workflow "email a miner this transaction" (inscriptions, https://github.com/supertestnet/breaker-of-jpegs, etc). This is a problem and will eventually cause a mempool divergence between nodes and miners. To help mitigate this we should have an option for users to accept non standard transactions on mainnet. There is already a setting for test networks, this PR just allows it to be set for mainnet.
(https://github.com/bitcoin/bitcoin/pull/27578)
There are many projects today that have part of their workflow "email a miner this transaction" (inscriptions, https://github.com/supertestnet/breaker-of-jpegs, etc). This is a problem and will eventually cause a mempool divergence between nodes and miners. To help mitigate this we should have an option for users to accept non standard transactions on mainnet. There is already a setting for test networks, this PR just allows it to be set for mainnet.
💬 theuni commented on pull request "Enable HW-accelerated implementations of SHA256 for MSVC builds":
(https://github.com/bitcoin/bitcoin/pull/24773#discussion_r1185598352)
I'm so confused.
Was `GetCPUID` not compiling already? If not, what was guarding it?
And I don't understand the comment about MSVC and assembly. It seems to deal with the randomness example ok?
(https://github.com/bitcoin/bitcoin/pull/24773#discussion_r1185598352)
I'm so confused.
Was `GetCPUID` not compiling already? If not, what was guarding it?
And I don't understand the comment about MSVC and assembly. It seems to deal with the randomness example ok?
💬 sdaftuar commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1535568784)
Concept NACK.
If there's a standardness rule that is interfering with someone's use case, we should discuss it and figure out whether the rule can be relaxed to accommodate the use case, or whether the use case can be adapted to comply with the standardness rules. Generally speaking, our policy rules are designed to prevent various kinds of denial-of-service attacks, or to help make sure the network runs smoothly -- so if users are trying to bypass them, there's a good chance that there's in
...
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1535568784)
Concept NACK.
If there's a standardness rule that is interfering with someone's use case, we should discuss it and figure out whether the rule can be relaxed to accommodate the use case, or whether the use case can be adapted to comply with the standardness rules. Generally speaking, our policy rules are designed to prevent various kinds of denial-of-service attacks, or to help make sure the network runs smoothly -- so if users are trying to bypass them, there's a good chance that there's in
...
💬 jamesob commented on pull request "assumeutxo":
(https://github.com/bitcoin/bitcoin/pull/15606#issuecomment-1535622786)
Alright! This is fully rebased and passing CI. Copy/pasteable testing instructions follow.
I'm pretty sure these are the complete changes necessary to enable use of assumeutxo (via `loadtxoutset`), including pruning and index use. It's worth noting that 200 of these lines are an elaborate demo shell script and another good chunk of this is airy RPC code, so this 1200 line diff is maybe more approachable than it appears.
### Recent changes
- [x] I've segmented blockfile storage into "ass
...
(https://github.com/bitcoin/bitcoin/pull/15606#issuecomment-1535622786)
Alright! This is fully rebased and passing CI. Copy/pasteable testing instructions follow.
I'm pretty sure these are the complete changes necessary to enable use of assumeutxo (via `loadtxoutset`), including pruning and index use. It's worth noting that 200 of these lines are an elaborate demo shell script and another good chunk of this is airy RPC code, so this 1200 line diff is maybe more approachable than it appears.
### Recent changes
- [x] I've segmented blockfile storage into "ass
...