💬 willcl-ark commented on issue "Stop shipping ARM32 builds for releases?":
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841444915)
I think I heard that that the Pi 5 ARM chips are _unable_ to boot a 32bit kernel (although you can still hack about in a 32 bit userspace if you really want), so it seems that the day is definitely getting nearer.
If I am correct above the question then perhaps becomes "how long do we want to ship release builds for Pi 3's and 4's".
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841444915)
I think I heard that that the Pi 5 ARM chips are _unable_ to boot a 32bit kernel (although you can still hack about in a 32 bit userspace if you really want), so it seems that the day is definitely getting nearer.
If I am correct above the question then perhaps becomes "how long do we want to ship release builds for Pi 3's and 4's".
💬 AiJunki commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841448223)
Fuck you petertodd. stay off bitcoin. you cunts.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841448223)
Fuck you petertodd. stay off bitcoin. you cunts.
💬 moth-oss commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2841523683)
Concept NACK
Removing op_return output limit will be ineffective in making a dent in the UTXO bloat because of the segwit discount vs cost of putting data in op_return. We should focus on addressing the UTXO bloat issue head on vs hoping that people will pay more just to store data "the right way".
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2841523683)
Concept NACK
Removing op_return output limit will be ineffective in making a dent in the UTXO bloat because of the segwit discount vs cost of putting data in op_return. We should focus on addressing the UTXO bloat issue head on vs hoping that people will pay more just to store data "the right way".
💬 i5hi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841539259)
humble concept NACK
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841539259)
humble concept NACK
💬 i5hi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841541157)
opens up a worse attack vector. there are more creative ways to solve utxo bloat.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841541157)
opens up a worse attack vector. there are more creative ways to solve utxo bloat.
💬 ajtowns commented on pull request "RFC: Accept non-std transactions in Testnet4 by default again":
(https://github.com/bitcoin/bitcoin/pull/32133#issuecomment-2841546065)
> I didn't mean that they setup this connection to a miner on purpose, I meant that they just happened to be connect to a miner by chance (which I think is much more likely to happend on testnet than on mainnet).
Even in that case, they've manually modified their own node to accept non standard transactions so they should have some chance of being aware that something weird is going on. Also, if it is the case that randomly connecting to nodes finds you a testnet miner that accepts non standa
...
(https://github.com/bitcoin/bitcoin/pull/32133#issuecomment-2841546065)
> I didn't mean that they setup this connection to a miner on purpose, I meant that they just happened to be connect to a miner by chance (which I think is much more likely to happend on testnet than on mainnet).
Even in that case, they've manually modified their own node to accept non standard transactions so they should have some chance of being aware that something weird is going on. Also, if it is the case that randomly connecting to nodes finds you a testnet miner that accepts non standa
...
💬 i5hi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841551520)
opens up a worse attack vector. we should be exploring more creative ways to solve utxo bloat.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841551520)
opens up a worse attack vector. we should be exploring more creative ways to solve utxo bloat.
💬 maflcko commented on pull request "RFC: Accept non-std transactions in Testnet4 by default again":
(https://github.com/bitcoin/bitcoin/pull/32133#issuecomment-2841588172)
Tend toward -0. As mentioned above in my first comment, it is not sufficient to achieve the goal you are trying to achieve, so it mostly brings the downsides mentioned above with questionable benefits.
Going forward, one could say the only way for developers to inject non-standard transactions into testnet_N is to ask a miner or rent some hashrate to do it.
However, injecting test-only non-standard transactions into a test network comes with its own downsides, like requiring more exception
...
(https://github.com/bitcoin/bitcoin/pull/32133#issuecomment-2841588172)
Tend toward -0. As mentioned above in my first comment, it is not sufficient to achieve the goal you are trying to achieve, so it mostly brings the downsides mentioned above with questionable benefits.
Going forward, one could say the only way for developers to inject non-standard transactions into testnet_N is to ask a miner or rent some hashrate to do it.
However, injecting test-only non-standard transactions into a test network comes with its own downsides, like requiring more exception
...
💬 maflcko commented on issue "Stop shipping ARM32 builds for releases?":
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841608459)
If this is dropped in the future, I guess we'll wholesale drop support for 32-bit architectures? If there is no release 32-bit build that we feel like is worth keeping, then I wonder if it is worth it to check and support it in CI.
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841608459)
If this is dropped in the future, I guess we'll wholesale drop support for 32-bit architectures? If there is no release 32-bit build that we feel like is worth keeping, then I wonder if it is worth it to check and support it in CI.
💬 maflcko commented on pull request "util: Remove `fsbridge::get_filesystem_error_message()`":
(https://github.com/bitcoin/bitcoin/pull/32383#issuecomment-2841616263)
lgtm re-ACK 97eaadc3bf9f621ba397e29bb1c0cd99af55f2e3
Only change are some minor format cleanups for the error messages.
(https://github.com/bitcoin/bitcoin/pull/32383#issuecomment-2841616263)
lgtm re-ACK 97eaadc3bf9f621ba397e29bb1c0cd99af55f2e3
Only change are some minor format cleanups for the error messages.
💬 stickies-v commented on pull request "refactor: validation: mark CheckBlockIndex as const":
(https://github.com/bitcoin/bitcoin/pull/32364#issuecomment-2841672078)
Force-pushed to deduplicate the `GetAll()` overloads by adding a `GetAllImpl()` templated helper, addressing @mzumsande's [comment](https://github.com/bitcoin/bitcoin/pull/32364#pullrequestreview-2804523333).
> I wrote this simpler approach here [TheCharlatan@fe13fa0](https://github.com/TheCharlatan/bitcoin/commit/fe13fa082e3d6befa6d5332428584570ead608ab) after seeing you mentioning it last week. I think making sure that all block indexes are declared const in the method might be beneficial t
...
(https://github.com/bitcoin/bitcoin/pull/32364#issuecomment-2841672078)
Force-pushed to deduplicate the `GetAll()` overloads by adding a `GetAllImpl()` templated helper, addressing @mzumsande's [comment](https://github.com/bitcoin/bitcoin/pull/32364#pullrequestreview-2804523333).
> I wrote this simpler approach here [TheCharlatan@fe13fa0](https://github.com/TheCharlatan/bitcoin/commit/fe13fa082e3d6befa6d5332428584570ead608ab) after seeing you mentioning it last week. I think making sure that all block indexes are declared const in the method might be beneficial t
...
💬 snakezhu commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841722467)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841722467)
Concept ACK.
💬 LaurentMT commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841723105)
@Sjors
> There is no difference in actual resource consumption, block weight is just an accounting trick.
I have to disagree here. The weight of data stored in blocks has a direct impact on the throughput of the system, a property that is as critical for the operations of the system, if not more, than others properties like the size of the UTXO set.
A given quantity of data stored in a op_return output has a far larger negative externality on the throughput than the same data stored in
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841723105)
@Sjors
> There is no difference in actual resource consumption, block weight is just an accounting trick.
I have to disagree here. The weight of data stored in blocks has a direct impact on the throughput of the system, a property that is as critical for the operations of the system, if not more, than others properties like the size of the UTXO set.
A given quantity of data stored in a op_return output has a far larger negative externality on the throughput than the same data stored in
...
💬 l0rinc commented on issue "Stop shipping ARM32 builds for releases?":
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841724415)
As mentioned before, 32 bit support isn't tested as thoroughly as 64 (e.g. https://github.com/bitcoin/bitcoin/pull/28531/files#r2036954366), it would simplify a few scenarios if we didn't have walk on eggshells when doing storage size calculations (e.g. https://github.com/bitcoin/bitcoin/blob/master/src/util/byte_units.h#L15)
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2841724415)
As mentioned before, 32 bit support isn't tested as thoroughly as 64 (e.g. https://github.com/bitcoin/bitcoin/pull/28531/files#r2036954366), it would simplify a few scenarios if we didn't have walk on eggshells when doing storage size calculations (e.g. https://github.com/bitcoin/bitcoin/blob/master/src/util/byte_units.h#L15)
💬 scgbckbone commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841741416)
Concept ACK
Better to just increase default size and keep config ops. If some people'd like to pretend that it is not already happenig - so be it
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841741416)
Concept ACK
Better to just increase default size and keep config ops. If some people'd like to pretend that it is not already happenig - so be it
📝 Sjors opened a pull request: "mining: rename gbt_force and gbt_force_name"
(https://github.com/bitcoin/bitcoin/pull/32386)
The term "force" is ambiguous and not used in [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate-changes) where there ! rule prefix is introduced.
E.g. this code is hard to read:
```cpp
if (!gbt_force) {
s.insert(s.begin(), '!');
```
Additionally, #29039 renamed `gbt_vb_name` to `gbt_force_name` which might, at least for me, further increased the confusion.
This is a pure (variable rename) refactor and does not change behavior.
(https://github.com/bitcoin/bitcoin/pull/32386)
The term "force" is ambiguous and not used in [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate-changes) where there ! rule prefix is introduced.
E.g. this code is hard to read:
```cpp
if (!gbt_force) {
s.insert(s.begin(), '!');
```
Additionally, #29039 renamed `gbt_vb_name` to `gbt_force_name` which might, at least for me, further increased the confusion.
This is a pure (variable rename) refactor and does not change behavior.
💬 willcl-ark commented on issue "test: interface_usdt_net.py failure under --valgrind":
(https://github.com/bitcoin/bitcoin/issues/32374#issuecomment-2841768158)
I am able to replicate this on NixOS
<details>
<summary>Details</summary>
```log
bitcoin on master [$?⇡] via △ v3.30.5 via 🐍 v3.12.7 via ❄️ impure (nix-shell-env)
❯ just build -DWITH_USDT=ON
configure running
configure complete
build running
build complete
bitcoin on master [$?⇡] via △ v3.30.5 via 🐍 v3.12.7 via ❄️ impure (nix-shell-env) took 41s
❯ sudo -E PYTHONPATH="/nix/store/nql0w8in8bj1i3f0xgpxr40hx2gy2lgg-bcc-0.31.0/lib/python3.12/site-packages:/nix/store/bymayrdmvq8ahkhrlcw2akjs
...
(https://github.com/bitcoin/bitcoin/issues/32374#issuecomment-2841768158)
I am able to replicate this on NixOS
<details>
<summary>Details</summary>
```log
bitcoin on master [$?⇡] via △ v3.30.5 via 🐍 v3.12.7 via ❄️ impure (nix-shell-env)
❯ just build -DWITH_USDT=ON
configure running
configure complete
build running
build complete
bitcoin on master [$?⇡] via △ v3.30.5 via 🐍 v3.12.7 via ❄️ impure (nix-shell-env) took 41s
❯ sudo -E PYTHONPATH="/nix/store/nql0w8in8bj1i3f0xgpxr40hx2gy2lgg-bcc-0.31.0/lib/python3.12/site-packages:/nix/store/bymayrdmvq8ahkhrlcw2akjs
...
💬 stevenroose commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2841771631)
ACK
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2841771631)
ACK
💬 Ali2kCom commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841782583)
Concept NACK. Removing OP_RETURN makes it more difficult to run full nodes and, as a result, gradually centralizes the network. This is not an issue where a small group of developers can implement changes that affect Bitcoin's core assumptions.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841782583)
Concept NACK. Removing OP_RETURN makes it more difficult to run full nodes and, as a result, gradually centralizes the network. This is not an issue where a small group of developers can implement changes that affect Bitcoin's core assumptions.
💬 stevenroose commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841784481)
Concept ACK. Implementation looks ok, can't comment on functional test coverage.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841784481)
Concept ACK. Implementation looks ok, can't comment on functional test coverage.