💬 leCheeseRoyale commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840803515)
Also peter todd, eric wall, and udi are all bad actors. homos
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840803515)
Also peter todd, eric wall, and udi are all bad actors. homos
💬 Bue-von-hon commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2840828249)
@luke-jr @instagibbs @maflcko @rkrux @glozow @adamandrews1 @w0xlt @1440000bytes
gentle ping.
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2840828249)
@luke-jr @instagibbs @maflcko @rkrux @glozow @adamandrews1 @w0xlt @1440000bytes
gentle ping.
🤔 shahsb reviewed a pull request: "common: Close non-std fds before exec in RunCommandJSON"
(https://github.com/bitcoin/bitcoin/pull/32343#pullrequestreview-2805771996)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/32343#pullrequestreview-2805771996)
Concept ACK
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067899705)
> Would it make more sense if m_recv_buffer was a std::deque or something where we can truncate the structure without copying/moving/shifting left?
Sounds good :)
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067899705)
> Would it make more sense if m_recv_buffer was a std::deque or something where we can truncate the structure without copying/moving/shifting left?
Sounds good :)
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067900213)
Sure, thanks :)
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067900213)
Sure, thanks :)
💬 romanz commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067902920)
I suggest considering a similar approach to `libevent`'s evbuffers:
> evbuffers are represented using a linked list of memory chunks, with pointers to the first and last chunk in the chain.
https://libevent.org/doc/buffer_8h.html
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2067902920)
I suggest considering a similar approach to `libevent`'s evbuffers:
> evbuffers are represented using a linked list of memory chunks, with pointers to the first and last chunk in the chain.
https://libevent.org/doc/buffer_8h.html
📝 w0xlt opened a pull request: "Make `cs_db` mutex non-recursive"
(https://github.com/bitcoin/bitcoin/pull/32384)
Make `cs_db` mutex non-recursive (related to https://github.com/bitcoin/bitcoin/issues/19303).
(https://github.com/bitcoin/bitcoin/pull/32384)
Make `cs_db` mutex non-recursive (related to https://github.com/bitcoin/bitcoin/issues/19303).
💬 captCovalent commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840978179)
Concept NACK
- First, it’s a security mess.
- Second, bigger transactions would bloat the blockchain, slowing things down and making it tougher for regular folks to run nodes, which could centralize Bitcoin.
- Third, Bitcoin’s about money, not storing random data. Opening this up feels like a step away from its core purpose. Plus, there’s no clear agreement among devs or the community, and there are better ways to handle data needs without going all-in like this. I mean what does this PR ac
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840978179)
Concept NACK
- First, it’s a security mess.
- Second, bigger transactions would bloat the blockchain, slowing things down and making it tougher for regular folks to run nodes, which could centralize Bitcoin.
- Third, Bitcoin’s about money, not storing random data. Opening this up feels like a step away from its core purpose. Plus, there’s no clear agreement among devs or the community, and there are better ways to handle data needs without going all-in like this. I mean what does this PR ac
...
💬 l0rinc commented on pull request "coins: fix `cachedCoinsUsage` accounting in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2068100317)
They were introduced in https://github.com/bitcoin/bitcoin/pull/28865/files#diff-bca63b54ad7fcc2df12f3237fd8775810c1b849c49110f702920655778fcc248R45-R49, I don't see any concrete explanation for what the problem was - and couldn't reproduce any fuzzing problem when I've removed these.
@fanquake, can you help us out here, do you remember why these were added?
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2068100317)
They were introduced in https://github.com/bitcoin/bitcoin/pull/28865/files#diff-bca63b54ad7fcc2df12f3237fd8775810c1b849c49110f702920655778fcc248R45-R49, I don't see any concrete explanation for what the problem was - and couldn't reproduce any fuzzing problem when I've removed these.
@fanquake, can you help us out here, do you remember why these were added?
💬 nud3l commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841137030)
Concept ACK
There should be a canonical way to include data to Bitcoin that is most efficient for the network. OP_RETURN is a much more efficient way than using taproot tricks.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841137030)
Concept ACK
There should be a canonical way to include data to Bitcoin that is most efficient for the network. OP_RETURN is a much more efficient way than using taproot tricks.
💬 letscagefdn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841138801)
Please remove this PR, this will crash the price
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841138801)
Please remove this PR, this will crash the price
💬 mrberlinorg commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841153004)
Concept NACK
This PR introduces a fundamental shift in Bitcoin's networking model by encrypting peer-to-peer transport via BIP324. While the goals of improving privacy and censorship resistance may seem beneficial, the trade-offs involved are deeply concerning from both a philosophical and technical standpoint.
Loss of network transparency
Bitcoin's peer-to-peer layer has always been observable, enabling traffic analysis, censorship detection, and independent verification of network behav
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841153004)
Concept NACK
This PR introduces a fundamental shift in Bitcoin's networking model by encrypting peer-to-peer transport via BIP324. While the goals of improving privacy and censorship resistance may seem beneficial, the trade-offs involved are deeply concerning from both a philosophical and technical standpoint.
Loss of network transparency
Bitcoin's peer-to-peer layer has always been observable, enabling traffic analysis, censorship detection, and independent verification of network behav
...
💬 monlovesmango commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841163721)
>The proposed Bitcoin Core change could pose risks to Bitcoin's usability and decentralization by allowing more non-financial data, potentially bloating the blockchain and making it harder for regular users to run nodes.
>Second, bigger transactions would bloat the blockchain, slowing things down and making it tougher for regular folks to run nodes, which could centralize Bitcoin.
As https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840479090 states, this PR does not increase no
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841163721)
>The proposed Bitcoin Core change could pose risks to Bitcoin's usability and decentralization by allowing more non-financial data, potentially bloating the blockchain and making it harder for regular users to run nodes.
>Second, bigger transactions would bloat the blockchain, slowing things down and making it tougher for regular folks to run nodes, which could centralize Bitcoin.
As https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840479090 states, this PR does not increase no
...
💬 hebasto commented on pull request "Make `cs_db` mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32384#issuecomment-2841170159)
It might be better to focus on reviewing https://github.com/bitcoin/bitcoin/pull/28710 instead.
(https://github.com/bitcoin/bitcoin/pull/32384#issuecomment-2841170159)
It might be better to focus on reviewing https://github.com/bitcoin/bitcoin/pull/28710 instead.
📝 stratospher opened a pull request: "test: add test for malleated transaction with valid witness"
(https://github.com/bitcoin/bitcoin/pull/32385)
- [`create_malleated_version()`](https://github.com/bitcoin/bitcoin/blob/d62c2d82e14d27307d8790fd9d921b740b784668/test/functional/p2p_orphan_handling.py#L141) function in the functional tests currently creates transactions with same txid, different wtxid but the witness is invalid.
- it is useful to have transactions with same txid, different wtxid and valid witness for better coverage
and to test how these transactions are relayed over different kinds of P2P connections
(ex: see https://
...
(https://github.com/bitcoin/bitcoin/pull/32385)
- [`create_malleated_version()`](https://github.com/bitcoin/bitcoin/blob/d62c2d82e14d27307d8790fd9d921b740b784668/test/functional/p2p_orphan_handling.py#L141) function in the functional tests currently creates transactions with same txid, different wtxid but the witness is invalid.
- it is useful to have transactions with same txid, different wtxid and valid witness for better coverage
and to test how these transactions are relayed over different kinds of P2P connections
(ex: see https://
...
💬 stratospher commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2068135636)
Here's something we can play with in this PR - https://github.com/stratospher/bitcoin/commit/dace16b34f31f6ad97ab21c66f3e65274cdace8c
It's not a pretty and compact method of generating like `malleate_tx()` but it works.
I've also opened #32385 to discuss how this could be done better!
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2068135636)
Here's something we can play with in this PR - https://github.com/stratospher/bitcoin/commit/dace16b34f31f6ad97ab21c66f3e65274cdace8c
It's not a pretty and compact method of generating like `malleate_tx()` but it works.
I've also opened #32385 to discuss how this could be done better!
💬 francisco-alonso commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841183765)
Concept NACK !
This affects node costs, increases pressure on fees, and slowly centralizes the network. These are not side effects, for me they are fundamental design tradeoffs. Bitcoin's value comes from being simple, predictable, and hard to change (and should be like this forever). Core fundamentals like minimizing blockchain bloat and protecting decentralization should not be addressed without consensus.
At the end of the day, this is not just about `OP_RETURN`. The real issue is wheth
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841183765)
Concept NACK !
This affects node costs, increases pressure on fees, and slowly centralizes the network. These are not side effects, for me they are fundamental design tradeoffs. Bitcoin's value comes from being simple, predictable, and hard to change (and should be like this forever). Core fundamentals like minimizing blockchain bloat and protecting decentralization should not be addressed without consensus.
At the end of the day, this is not just about `OP_RETURN`. The real issue is wheth
...
💬 stratospher commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2068145404)
> stale_tx came from the private broadcast storage, is the original transaction, not the malleated one.
ohh missed that, will check it again.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2068145404)
> stale_tx came from the private broadcast storage, is the original transaction, not the malleated one.
ohh missed that, will check it again.
💬 mrberlinorg commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#discussion_r2068154281)
Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:
Non-standard transactions: Multiple OP_RETURN outputs in a transaction are considered non-standard. Allowing them could lead to network inconsistencies, as some nodes might not be able to properly process or relay these transactions.
Network congestion: More OP_RETURN outputs would increase
...
(https://github.com/bitcoin/bitcoin/pull/32359#discussion_r2068154281)
Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:
Non-standard transactions: Multiple OP_RETURN outputs in a transaction are considered non-standard. Allowing them could lead to network inconsistencies, as some nodes might not be able to properly process or relay these transactions.
Network congestion: More OP_RETURN outputs would increase
...
💬 Sjors commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841239327)
> You could consider leaving the options in and just increasing the default to max block size. I don't feel strongly about doing this - the config option would just be a footgun long term - but we did do `-mempoolfullrbf` removal in separate stages. It might make this less controversial.
At this point I think the controversy is sunk cost, and staging the removal just means another round of all this.
---
Things that should be discussed on the mailinglist, but I'll respond to them here an
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2841239327)
> You could consider leaving the options in and just increasing the default to max block size. I don't feel strongly about doing this - the config option would just be a footgun long term - but we did do `-mempoolfullrbf` removal in separate stages. It might make this less controversial.
At this point I think the controversy is sunk cost, and staging the removal just means another round of all this.
---
Things that should be discussed on the mailinglist, but I'll respond to them here an
...