💬 21M4TW commented on issue "Allow sending untrusted utxos in the sendtoaddress api":
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2840543377)
If the utxo is coming from another wallet, you will need an external mechanism to sign it? Isn't the purpose of the createpsbt function?

💬 0ceanSlim commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840552186)
> That makes no difference and everyone knows this, making it easier is not a strategy. That's like saying its easy for someone to jump over my fence, thus why should i be allowed to put up a fence? The point is Im deciding whether or not i want a fence and when you push a change that removes the option, you're going to make people furious over nothing... and per you're own argument it wouldn't change anything. If it doesn't change anything then its clearly not needed for any reason. The only re
...

💬 portlandhodl commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840658744)
Concept Ack

Same code is already being applied to at least 3-5% of hashrate today at MARA.

💬 luke-jr commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679141)
Concept NACK. At a minimum, it would need to tally up the total length (including the sizes of additional amount + script size fields) and ensure it remains under the datacarriersize limit. But also, such "protocols" are abusive and should not exist. Even if they were to be tolerated, they could just as well divide the existing datacarrier space without having multiple outputs.

💬 chrisguida commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679803)
Concept NACK, same reason as on https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833932824.

The proper solution is to [filter inscriptions](https://github.com/bitcoin/bitcoin/pull/28408), not to keep appeasing the spammers. The more we appease them, the more "economic demand" there will be to create spam.

💬 sbddesign commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840700497)
Concept ACK

As long as there is hashrate willing to include a non-standard OP_RETURN in a block, then no one single node's policy is going to prevent that OP_RETURN from entering a block. And if users are going to try and store data on-chain, using an output that does add to the existing UTXO set seems preferable.

💬 SergioDemianLerner commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840716517)
Concept ACK.

OP_RETURN not only allows arbitrary data to be included, it allows data that can be consumed by Bitcoin smart contracts with ESSPI (https://arxiv.org/abs/2503.02772). This facilitates the creation of Bitcoin L2s that need more expressive Bitcoin contracts to work.

💬 albertoig commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840718366)
Concept NACK. This is a direct method of attack.

💬 abdelrahman543873 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840751279)
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. This might centralize control, as only those with significant resources could manage full nodes

💬 nolim1t commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840754876)
> > Moderation suggestion: close to non-contributors.
>
> This is far more than a small technical change, so the broader community should not be shut out of the discussion or shuffled off to the mailing list. This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety.
>
> * Merging this PR means Bitcoin is no longer a decentralized currency.
>
> * Merging this PR means Bitcoin is no longer money.
>
> * Merging this PR means Bitcoin is
...

💬 leCheeseRoyale commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840771858)
Additional Concerns – Concept NACK

While many critical points have already been raised, I’d like to highlight several underdiscussed but significant risks introduced by this PR:

1. Fee Market Distortion via “Cheap” OP_RETURNs

Removing all limits on OP_RETURNs creates a perverse incentive: transactions can now carry large, non-economic payloads while avoiding long-term storage costs (since OP_RETURNs don’t enter the UTXO set).This allows chain data to be subsidized at rates far below wh
...

💬 adamdecaf commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840792912)
Concept Nack

Other coins can and have implemented wasteful experiments. There's no reason or authority to make Bitcoin into a shitcoin. Leave the hardest money on the planet alone and let it fix the world.

💬 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

💬 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.

🤔 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

💬 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 :)

💬 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 :)

💬 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

📝 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).

💬 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
...