💬 dani69654 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2836782764)
How a P2P money network became a file storage system will make a great case study in the future.

🚀 achow101 merged a pull request: "test: Add missing check for empty stderr in util tester"
(https://github.com/bitcoin/bitcoin/pull/32327)

📝 achow101 opened a pull request: "test: Use the correct node for doubled keypath test"
(https://github.com/bitcoin/bitcoin/pull/32369)
#29124 had a silent merge conflict with #32350 which resulted in it using the wrong node. Fix the test to use the correct v22 node.

💬 andrewtoth commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2836929583)
> An entire file can be serialized directly after an OP_RETURN as-is. So later, when a Bitcoin user goes to do data recovery, or has their system seized by a government and they do a cursory analysis of its contents, both will have to contend with the now completely plaintext arbitrary data that any anonymous person has now effectively forced them to store and/or process on their system in order to participate in the Bitcoin network.

Luckily, blocks and mempool data are stored obfuscated on d
...

💬 cmdruid commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2837019460)
The limitation to a single OP_RETURN output per tx is indeed dumb and should be removed, but I don't see why you would remove filtering rules if people actively use them and build clients around them.

There's always going to be a difference in policy between mempool and onchain. Just because you can bribe a miner to side-step mempool consensus isn't really an argument to remove filtering rules, you may as well remove the dust limit while you're at it.

🤔 Turtlecute33 reviewed a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2801335235)
NACK

Removing the limits on OP_RETURN does not mean that people minting ordinals will stop using Taproot outputs, so it will not prevent the continued growth of the UTXO set.

Any non-definitive restriction on mempool policy is essentially useless, as it can be easily circumvented via slipstream techniques and accelerator services. Meanwhile, removing arbitrary limits on data carrier outputs does not guarantee any meaningful improvement or change in the behavior of ordinal minters.

Given
...

🤔 danielabrozzoni reviewed a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2801386763)
While there are valid arguments on both sides of this discussion, I am leaning towards a NACK

It is true that mempool policy filters have not been completely successful at preventing transaction spam, and they will never be. However, they do provide a form of friction if enough people use them; for example, if all mempools refuse transactions with OP_RETURNs above the current limit, spammers have no choice but to use mempool accelerators and pay higher fees for their transactions.

I also a
...

💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2837164692)
I want to remind people that you should actually read the mailing list discussion first, and understand what exactly lead to this pull-req: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2065255362)
I had forgotten why I did it that way, but when I tried that, testing the first commit results in warnings that the helper functions are unused.

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2065270057)
Taken, thanks

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#discussion_r2065274288)
I did that on purpose to illustrate that the function now needs the custom weight for the new test

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#issuecomment-2837277525)
> nit: Perhaps the commit descriptions ("BnB rate sensitivity tests", "simple BnB failure tests", and "BnB iteration exhaustion test", for example) could become functions for clarity (not necessarily new test cases).

I’m not sure I understand what you mean. Do you mean that I introduce helper functions like "TestBnBSuccess" for the new tests instead of making them their own test cases?

📝 LEGENDZENT opened a pull request: "4 million lost bitcoin"
(https://github.com/bitcoin/bitcoin/pull/32370)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

✅ achow101 closed a pull request: "4 million lost bitcoin"
(https://github.com/bitcoin/bitcoin/pull/32370)

📝 achow101 locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/32370)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

💬 wizkid057 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2837312049)
> Luckily, blocks and mempool data are stored obfuscated on disk by XOR-ing with a random per-node key. See #28052, #28207.

This, admittedly, partly mitigates one objection of mine (out of dozens, to be clear). I recall this was discussed _many_ years ago in #bitcoin-dev, but I didn't know it actually finally martialized. Thanks.

However, unless I'm missing something, it seems regular upgrade paths don't have a mechanism to make any use of this obfuscation. Only new nodes seem to benefit.
...

💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2837355636)
@wizkid057 I need to remind people that Bitcoin Core is not the only implementation out there. It is already quite easy to get arbitrarily sized OP_Returns mined, and even Bitcoin Core's standardness rules already allow long byte sequences to get mined and thus included in block*.dat files.

Anyway, I just checked, and Google Chromium v135 at least appears to store cached data on your hard drive verbatim (plus a file header). If even they aren't concerned about unobfuscated random cached data
...

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#issuecomment-2837376769)
> nit: Some commits can be squashed to avoid warnings like "unused function".

@w0xlt: I ran each commit, and I did not receive this warning. Could you let me know which commit resulted in that warning for you?



> As discussed during Bitcoin Core Review Club, at least one test with 0 fee rate should probably be added to avoid test coverage regression.

@monlovesmango: I added another commit to run the simple tests at various feerates, including the feerates 0 sat/kvB, 1 sat/kvB, and 1,
...

💬 wizkid057 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2837460876)
> @wizkid057 I need to remind people that Bitcoin Core is not the only implementation out there. It is already quite easy to get arbitrarily sized OP_Returns mined, and even Bitcoin Core's standardness rules already allow long byte sequences to get mined and thus included in block*.dat files.

By "long byte sequences", I don't know of any way to get more than few hundred bytes in a sequence without a miner's involvement.

I'm talking about entire real world files without breaks.

It's alre
...

💬 murchandamus commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#issuecomment-2837465545)
Rebased due to strange CI failures