For context, Bitcoin Core has something like 240'000 lines of c++ code.

I don't intend to take the time to go through someone of that magnitude, but if you want to take a look, here's the diff: https://github.com/bitcoin/bitcoin/compare/28.x...bitcoinknots:bitcoin:28.x-knots

Hey Leon,

thanks for your reply. Given the many points you raised, I will quote for context what I’m replying to.

> Leon wrote:

> What I don't understand is why the limit for op_return is being changed when filters are actually working. Yes they don't filter out everything but they do filter out most of it.

I am puzzled how you arrive at the conclusion that they "filter out most of it". 53% of transactions over the past year had OP_RETURN outputs or inscriptions. Could you perhaps explain further what effect you perceive filters to have had?

> Leon wrote:

> Then you have a couple of folks claiming that filters are useless and we should give up on them entirely because spammers could use out of bound transactions via services as slipstream by MARA to circumvent filters (which is right but also proves that filters are working pretty well since they wouldn't need to go out of bound otherwise).

Some miners appear to be running Libre Relay or have otherwise loosened their mempool policy. These miners accept transactions considered non-standard by default Bitcoin Core configurations in-band. They appear to track them normally in their mempools, and include them in their blocks whenever those transaction’s feerates put them in the block. The myth that non-standard transactions need to pay a multiple of other transactions appears to be based on the OP_RETURN_BOT service charging a premium and sending at a higher feerate, but if you are willing to wait, non-standard transactions appear to be getting confirmed at the same feerates as any other txs.

> What puzzles me as well is the statement that transaction fees are enough to filter out spam. You might be right with this claim but I am not sold on it entirely.

Given limited blockspace, it is obvious that transaction uses that can afford to pay more for blockspace will price out transactions that can only afford to pay little for blockspace. This means especially that large value transfers have a much bigger budget to pay for blockspace than small transfers (if you are sending 10 ₿, you don’t care about paying 10'000 sats in fees, but if you’re trying to send 10'000 sats, paying 10'000 sats is prohibitive). This isn’t a new observation, I wrote in 2016: "Transaction fees are not in relation to the amount of value transferred, but in relation to the amount of block space they'll take. Therefore, it is relatively cheap to send large amounts of value in Bitcoin but uneconomical to send micro-payments." (via https://bitcoin.stackexchange.com/a/48422/5406). I’m not sure what your expectation is, but any form of Bitcoin succeeding will mean that small payments will be economically infeasible on chain. In the past couple years, we saw the third hype wave of people using Bitcoin for publishing data. Just like the prior two times, the excitement eventually subsided and as the premium came down, the cost curbed the transaction volume. Even at the peak of the hype, large transfers easily price out this sort of use. If you are upset that small payments were priced out, I’m afraid that’s the expected outcome either way. I don’t see the point in lying to Bitcoin users by trying to keep transaction fees low artificially.

> Leon wrote:

> As long as bitcoin evolves the way as projected and increases in global significance a lot more folks might want to spam the chain even though fees would be higher at that point the incentive for spamming and using more resources to do so would grow similarly.

> In general I think spam is harmful and might lead to unintended consequences so I don't think we should give non monetary transactions more room and easier ways to use the protocol.

OP_RETURN outputs do not grow the UTXO set, because they do not get added to the UTXO set. They are easier to validate than payment outputs, because they don’t contain signature operations. Since OP_RETURN data is in output scripts, it has no witness data that would be discounted. As far as I can tell, besides competing for blockspace, they use less resources in every way than other transactions per byte.

Inscriptions also do not increase the UTXO set per se, because it takes creating an output and spending an output to publish the Inscription in the input’s witness stack. Witness data is validated once and retained with a full copy of the blockchain or discarded by pruned nodes as any other blockchain data.

It seems to me that most of the UTXO set increase is due to Ordinals—the notion that satoshis have a serial number and some of those serial numbers are more valuable than others—and users splitting up UTXOs to isolate satoshis with certain Ordinals. Sometimes inscriptions are attached to Ordinals, but I’d still blame that on Ordinals more than on Inscriptions. The transactions that split UTXO amounts to isolate certain Ordinals are indistinguishable from payment transactions without out-of-band information about Ordinals, so the main UTXO set bloat is not easy to filter.

So, overall I see UTXO bloat from Ordinals and blockspace demand by transactions that offer to pay more for blockspace. I don’t see a practical way of preventing Ordinals, and don’t perceive Inscriptions or OP_RETURN outputs as particularly harmful (dumb sure, but not harmful). Perhaps you could elaborate how spam is harmful, if you disagree, because I don’t see it.

> Leon wrote:

> I said core seems compromised because they would not ship many "controversial" implementations in the past but this time when controversy is obvious as you can tell from the debate they don't care and ship anyways.

I don’t know which examples of controversial changes that did not get shipped you are referring to, but the ones I recall were sunk by convincing technical arguments against them. I have yet to see a convincing technical argument against raising the OP_RETURN limit.

P2TR keypath inputs weigh 230 Wu (57.5 vB), so P2TR outputs with 1000 sats are economically spendable at feerates up to 17.3 sats/vB.

Would you like to share your concrete concerns, so I can address them?

I have not received any money or other incentives to have a specific position in this matter, not am I aware of any other participants in this discussion being paid to represent a specific position.

To me the arguments for lifting the limit make sense by themselves. My skepticism to the viability of filtering transactions with significant demand aren't exactly new, I pretty much write the same thing on last year's pull request for "match more data carrying" which I found to be similarly poorly motivated.

New major versions are only released twice a year, in April and October. Even if the PR were merged, which it has not yet, it would not be released until Bitcoin Core 30.0 is released in October.

If a pull request doesn't pass review, the reviewers leave feedback on what to improve until it becomes ready for merge or work on it is discontinued. When pull requests run into well-reasoned opposition they tend to get closed to curb review time spent on things that are unlikely to be merged.

No, I did not conflate contributors and maintainers. In Bitcoin Core nothing gets merged until it has been reviewed by several regular contributors, usually several times. Sure, one of the five maintainers (who are part of the regular contributors) is usually the last reviewer and will merge a PR if it has had enough review and they're satisfied, but they don't merge things that haven't been reviewed by other knowledgeable developers, mostly from those 40 regulars.

It might make more sense when you consider that neither Peter nor myself is speaking for Bitcoin Core, but that birth of us are just presenting our own opinions.

Murch didn't talk about the OP_RETURN limit at all in that post, he was addressing claims that Bitcoin Knots has more developers than Bitcoin Core.

If you want to know my thoughts on the policy change, I've left a comment on the PR.

About 28,000 differing lines of code across 550 files and 1400 commits

Okay, what for? For informing people about the options they're choosing from?

You're welcome, and that's what I think mostly as well: (high-value)monetary transactions will have the highest bidding power in the long run and that's what will curb the data transactions. Thanks for being open to hearing various sources.

Stop wondering whether that was a joke

Is that a gut feeling, wishful thinking, or did you see anything specific in that repository that indicated review activity?

Yeah it isn't much, just about 28,000 lines of code difference across 550 files and 1400 commits.

See https://njump.me/nevent1qqsqgqshlvle5f0ud0xvaadcytfest4mv47hr2j9fsrlpf67c7mwprspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsf2ds69dp2ympzhtpmdd46f3w2cnfkjphtpnaesf5xs8z95vqu2xqrqsqqqqqplc5wt9

Witness data is discounted by a factor four not three, but yeah, OP_RETURN data takes more blockspace and is more expensive to the same degree. Either way the sender pays for whatever blockspace they win the bid on.

That's where we disagree. We should make the benign way of writing data easier so they stop using the malign one.

Yes, that's correct. Small data payloads get slightly cheaper. It just seems that people are much more concerned about big amounts of data and those are significantly more expensive with OP_RETURN. Either way, data occupies whatever blockspace the transaction bids the premium for.

It's not a bug. Dropping the script size limit is an intentional design decision. As BIP 342 says:

"Why is a limit on script size no longer needed? Since there is no scriptCode directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed."

You could always put data in the block chain by paying for the block space. The DoS protection was always the block size limit and blockspace market: it's expensive and people stop doing it whenever the hype has jumped the shark.

Could you elaborate how "inscriptions are more onerous for the data hoarders to inscribe and reconstruct in order to access their data"? Serialization and deserialization of data is a standard exercise that gets designed once and then used per a library. Why would they care which function they call on a library?

Could you tell me more about the concern you have when you say "if we let them put data on the Blockchain in its raw form that could be inviting even more problems than it solves"?

Theoretically you could have done the same reveal truck with p2sh, but the redeem script had to fit into a single 520 byte push. Segwit introduced the witness section and witness discount, Taproot removed the 520 byte limit for witness stack items. Altogether, you could then do big scripts for less in the witness.

The main reason to do it is the same reason as 2013: it's preferable for people to write into op_return outputs than into unspendable payment outputs. Dropping the limit makes OP_RETURN a reliable replacement for the latter which is currently standard and essentially unpreventable.

Data in OP_RETURN is significantly more expensive than data in inscriptions, so I have a hard time understanding the concern that the overall block space occupied by data transactions would increase.

Whether more should have been done about inscriptions seems like a separate debate that mostly muddies the water here.

Biometrics are user IDs, not passwords.

Bitcoin Core currently estimates feerates based on the time transactions of various feerates spend in the mempool before they appear in blocks. We ignore any transactions that we have not seen in the mempool.

We also have work in progress to estimate feerates based on the transactions in the mempool. https://github.com/bitcoin/bitcoin/issues/30392

1. I don't understand why people think Peter Todd is a regular contributor to Bitcoin Core. I don't think I've seen him make that claim, I've certainly not seen other contributors make that claim, and as far as I can tell, he has made three commits since 2016.

2. You will have to ask Peter why he said that and how he meant it.