I don't think any reviewer should have a responsibility to justify in detail why they're not accepting a PR, or why they're choosing to spend more time to review one and not another.

I mean, heck, it's going to happen right - a PR from sipa vs a PR from Joe Bloggs.

I think your point about the analogy isn't as clear as all that; the analogy would be more with setting policy and less with what constitutes a valid transaction (that's more, does the syntax of the document even satisfy the definition of a BIP).

If the problem with AI drafts were *only* volume we wouldn't be having the same discussion, nor using terms like slop.

uncomfortable truth? : i feel like the debate on the mailing list about AI authorship for BIPs is reminiscent of the filtering debate for Bitcoin. In both cases, people arguing for prevention (not just dissuasion) are essentially pissing in the wind. Using "automated tools to detect AI usage in documents" is doomed to fail over time, with terrible false +ve rates; just think about it. In both cases, the technological reality just does not support the prevention argument.

As for dissuasion, even that's problematic. It's hard to argue these tools are not useful, and the nuance of "don't misuse it" is too difficult to capture imo. In short, just like spam on-chain, I'm not saying there isn't a problem, but it's hard to define and the cure is worse than the disease.

Bitcoin is going to zero if this fork activates.

A few devs deciding it’s okay to seize people’s money just because they use the same feature as some spammers use isn’t even remotely bitcoin.

nostr:note1u5w7w37tfj076v8llw4435hwyhxetxjcezjfurfxc6g44qxhwpyqq94sty

GCC does compile-time checks too, but they're both valid, and both print a string of the given width, but %*.s is weird and should probably elicit a warning. The man page suggests this will print padding (* specifies the minimum width, . specifies zero precision, so no chars from string are printed) and that the string need not be nul terminated, but it printed something and valgrind complained (string was *not* nul terminated), so I suspect the man page or implementation are wrong.

But it's really a "did you mean %*." warning because I expect no code deliberately does this...

I think finding a bug where printf("%*.s") was used instead of printf(".*s") was the point at which I realized that some C issues cannot be mitigated with better tooling...

Yes, this is a single commit! Should have mentioned...

I hate price talk, but if you're going to do it, please understand that "market cap" is a very rough *ceiling* on current value.

It's neither the amount of money which has gone in, nor the amount of money which can come out.

So the order of magnitude is useful to compare against other assets. But abusing it in terms of profits and losses is a category error, and I assume done mainly because it's so easy to measure.

Grump over.

Assuming usage of OP_RETURN as the garbage can for non-financial data that would otherwise go into the UTXO set is naive.

First, it's more expensive than inscriptions, control block embedding and other techniques.

Second, you're expecting developers of ordinals, inscriptions, stamps, brc-20, etc to *change* their protocol to accommodate. There's zero evidence this is going to happen.

Third, you're assuming that these are people that want to act as good stewards of the Bitcoin protocol. They spam specifically to hurt Bitcoin. They've demonstrated this by spamming in the first place. That's like asking malicious spray painting vandals to paint a particular wall that's easy to wash off. Again, no evidence that this is going to happen.

The logic is misguided and makes unfounded assumptions.

Don't suggest a developer resign unless you're the one who will shoulder the load.

And if any bitcoin developer is thinking of stepping down over the current drama, *please * reach out to me: I've been a FOSS dev full time for over 25 years and I've been there! I'm not going to judge, but I may have a useful perspective. ❤️

Half of me is like "I can say whatever I want on nostr!" And the other half of me is like "do I really want a cryptographically signed message of me saying that"

The constant insinuation that Bitcoin Core devs don't have "the same skin in the game node runners do", is annoying me. Just maybe there is a good reason for the group to not loudly asvertise this and keep a low profile?

yay! Thanks for the feedback!

> a) if the selector is meant to be scriptnum compatible, would be good to make that clear (ie 513 on the stack is interpreted as outputscript+collate not as 0x0102 and tested as outputamount+version.

This builds on the previous BIP, which changes this, but I agree it needs to be explicit.

> b) please use hex for the selector values...

Done.

c) you might consider two separate functions [op_tx and op_txcollate] instead of using a bit selector; makes it slightly easier to statically validate expected stack depth, though still not great.

Understandable, but since we have a bit selector anyway, I prefer this approach.

> d) not sure the ordering of collate-vs-noncollate makes sense - should "output" just always put the new data at the start of the buffer or the end of the stack do you consistently get the last output thing first?

Good catch!

I've switched the definition around to the order I think of it, i.e. txid order. But it means the definition of "output" for the non-collate case is a bit awkward: `"output" means "push a new element on the stack under the previous output elements" (i.e. the last output will be the top stack element).`

> e) input(num)witness seems like a bad idea to me, constraining how other inputs are spent just seems like asking for complexity and bugs.

I agree, so don't do that. However, it's possibly useful too, so it's allowed. Not like you're going to do this "accidentally".

> f) having a way to pull info from other inputs' annex (and your own) would be a win though, but maybe that should be an op_annex getter.

I was tempted to use separate bits for WITNESS_STACK, WITNESS_TAPSCRIPT and WITNESS_ANNEX for this reason, but the entire witness is more robust against future SegWit output types: I don't have to worry too hard about how to interpret those fields.

Note that getting the ANNEX is awkard, due to lack of DROPN. See the very-unfleshed-out OP_MULTI which would make this tenable.

> g) personally I don't think upgradability is a win here, better to upgrade by defining a new opcode than have weird semantics that people will forget to check.

Perhaps, but this argument seems very weak. Who will forget to check? The only possibility is someone who allows arbitrary selection_vectors in their script, and they're already kinda messed up.

> h) the ctv comparison at the end is inaccurate - ctv also commits to scriptSigs.

Oh, good catch! Fixed.

> i) automatically hashing it as you go rather than pushing the whole thing to the stack then hashing it seems worth considering

That seems like a regression to me. People have been proposing combo opcodes precisely because they haven't a decent costing model.

1. OP_SHA256 is a single opcode.

2. You can also now easily append/prepend/insert data that you want to commit to.

3. You have 4MB of stack, which is hard to exhaust (you can, using metadata, but it's difficult).

4. Hashing directly would reduce the cost from 12 varops per byte to 10, and you get 5200 varops (!) for every tx byte.

To reflect the depth of my gratitute for your feedback, I shall now review your lisp approach. Seems the least I can do! 💜

Do not try to stop the train. That's impossible.

Instead, only try to realize the truth....

Then you will see that it is not the train that stops, it is only yourself.

It is, as far as I can tell, impossible to tell the difference between "making an inane comment on your post to be supportive" and "llm bot spamming".

If I don't learn anything from what you're saying, why say it?

Perhaps I need a client which doesn't show comments more than two hops away in my social graph? Probably too quiet though; I would need many more friends.

Can't tellwhether this is an allusion to scifi or ancient fortifications.

Morale is low.

If I knew how to materially increase the cost of spamming the chain I totally would advocate for that. I do not.

> What's your goal that makes you opposed to spam, rather than being willing to merely ignore it? Or what's the success condition that would let you happily move on from this issue?

My goal is to make Bitcoin a monetary network and not anything else. I'm convinced this PR has a good chance of going in, so I'll move on from this issue regardless. I will make some predictions, though, and show the receipts when something like this comes up again.

If the removal of the datacarriersize default PR goes through in the next release of Bitcoin Core:

* There will be at least 100x more OP_RETURN outputs greater than 83 total bytes in 2026 than 2024.

* The cost of those transactions will generally be cheaper with respect to the median block fee than they were.

* There will be at least 30% more hashrate mining OP_RETURN outputs greater than 83 total bytes in 2026 than 2024.

Does someone want to explain to me how OP_RETURNs increase the blockchain growth, hardware requirements, or otherwise increase the cost of running a node? I keep seeing that concern, and that seems completely counter my expectations. I'd love to see a detailed explanation of how that follows.

"You can reduce spam by discouraging it" is a question of incentives, not one of fundamentals. I don't think we've finished the fundamental debate that you wanted yet.

Do you agree that core devs in general are trying to make bitcon work as a monetary network with a similar/compatible definitively to yours? That is, that we are actually on the same side here, even if we have different thoughts on how best to achieve that goal?

Do you accept that reasonable people can disagree on what constitutes "spam"? Both in thinking things you think aren't spam actually are, and in thinking stuff you think is spam is fine?

Do you accept that bitcoin is not your network, to rule as you wish, but that rule changes require near unanimous consent, even from the reasonable people who disagree with you, and potentially even from people doing the spamming?

Are you trying to ban spamming from bitcoin entirely?

Are you merely trying to discourage spammers? Are you aware that that might have no effect, or the opposite ("how dare you tell me what to do, I'll do it to spite you")?

Do you believe that going into technical details on this topic, to work out how best to make bitcoin sustainable as a monetary network in the long term is a valuable thing to do, or is that just a way for experts to attempt to close down the discussion and exclude non-experts?

I notice you're gong straight back to personal attacks ("would you rather people question your competence rather than your intent") and justifying it with fairly specific thoughts about current approaches, rather than sticking with the fundamental principles you claimed to want to discuss.

> I realise it's not pleasant to put something you hate (data spam) and something you like (other people using bitcoin as a MoE) into the same category, but as far as technical impact on your node's operation, they really are fundamentally the same, affecting your node in the same way, subject to the same global limits, impacting the same global marketplace in the same way (ie the blockspace fee market), having the same solution (move the substance off chain so you're mostly not subject to the limits or fees; eg via lightning).

I agree with everything until that last clause. You can reduce spam by discouraging it. That's what we've been doing with non-standard OP_RETURNs and non-standard scripts and below-dust-limit outputs, which you don't have to do with legitimate transactions. I actually really like your analysis and the commonality in reducing on-chain transactions is some sort of layer two which settles at layer 1. That's a useful insight.

Where I think the reasoning goes wrong is that spammers don't have the same goal as you, to reduce their on-chain footprint and use off-chain protocols to make things efficient. The spammers specifically *want* to spam the chain and have been shown to be malicious in that regard, purposefully trolling Bitcoiners (like the stamps protocol, for example). So in a sense, thinking about making their protocols efficient is a waste of time. I really don't think they're interested because they could do the same stuff for way cheaper on almost every altcoin.

> Ceasing to forbid/discourage something isn't the same as encouraging it, and the continued implication that this is all about devs wanting to encourage spam continues to be unappreciated, unfair and incorrect.

That is the end effect, though, isn't it? Whatever your intentions may be, the end result is that more spam comes onto the network. Or maybe you'll deny this, in which case, we'll devolve into discussions about what might happen. But ultimately, I'm not inside your head and can't determine what your intentions are, I can only judge the practical effect this has. You said that you're prioritizing Bitcoin as a monetary network. The PR deprioritizes Bitcoin as a monetary network and your response seems to be that your intentions aren't to do that. OK, I guess? Would you rather have people question your competence instead of intent? Because the result is as clear as day that we'll see more spam and not less as a result of the PR. And when people like me say that, we get a lot of anger, insults and eventually, speculations about boogeymen that will do something worse if we don't agree to this PR.

The strategy of the day seems to be, "Let's explain harder."

What if the people that disagree with you already understand? Maybe it's not a matter of explaining, but genuine fundamental disagreement?