Limits on block construction that cross transactions make it harder to accurately estimate fees and greatly complicate optimal block construction--  the latter being important because smarter and more computer powered mining code generating higher profits is a pro centralization factor.

In terms of effectiveness the "spam" will just make itself indistinguishable from the most common transaction traffic from the perspective of such metrics--  and might well drive up "spam" levels because the higher embedding cost may make some of them use more transactions.  The competition for these buckets by other traffic could make it effectively a block size reduction even against very boring ordinary transactions.  ... which is probably not what most people want.

I think it's important to keep in mind that bitcoin fee levels even at 0.1s/vb are far beyond what other hosting services and other blockchains cost-- so anyone still embedding data in bitcoin *really* want to be there for some reason and aren't too fee sensitive or else they'd already be using something else... some are even in favor of higher costs since the high fees are what create the scarcity needed for their seigniorage.

But yeah I think your comments on priorities are correct.


On Sat, Oct 18, 2025 at 1:20 AM Antoine Riard <antoine.riard@gmail.com> wrote:
Hi list,

Thanks to the annex covered by the signature, I don't see how the concern about limiting
the extensibility of bitcoin script with future (post-quantum) cryptographic schemes.
Previous proposal of the annex were deliberately designed with variable-length fields
to flexibly accomodate a wide range of things.

I believe there is one thing that has not been proposed to limit unpredictable utterance
of spams on the blockchain, namely congestion control of categories of outputs (e.g "fat"
scriptpubkeys). Let's say P a block period, T a type of scriptpubkey and L a limiting
threshold for the number of T occurences during the period P. Beyond the L threshold, any
additional T scriptpubkey is making the block invalid. Or alternatively, any additional
T generating / spending transaction must pay some weight penalty...

Congestion control, which of course comes with its lot of shenanigans, is not very a novel
idea as I believe it has been floated few times in the context of lightning to solve mass
closure, where channels out-priced at current feerate would have their safety timelocks scale
ups.

No need anymore to come to social consensus on what is quantitative "spam" or not. The blockchain
would automatically throttle out the block space spamming transaction. Qualitative spam it's another
question, for anyone who has ever read shannon's theory of communication only effective thing can
be to limit the size of data payload. But probably we're kickly back to a non-mathematically solvable
linguistical question again [0].

Anyway, in the sleeping pond of consensus fixes fishes, I'm more in favor of prioritizing
a timewarp fix and limiting dosy spends by old redeem scripts, rather than engaging in shooting
ourselves in the foot with ill-designed "spam" consensus mitigations.

[0] If you have a soul of logician, it would be an interesting demonstration to come with
to establish that we cannot come up with mathematically or cryptographically consensus means
to solve qualitative "spam", which in a very pure sense is a linguistical issue.

Best,
Antoine
OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e4999
Le vendredi 17 octobre 2025 à 19:45:44 UTC+1, Antoine Poinsot a écrit :
Hi,

This approach was discussed last year when evaluating the best way to mitigate DoS blocks in terms
of gains compared to confiscatory surface. Limiting the size of created scriptPubKeys is not a
sufficient mitigation on its own, and has a non-trivial confiscatory surface.

One of the goal of BIP54 is to address objections to Matt's earlier proposal, notably the (in my
opinion reasonable) confiscation concerns voiced by Russell O'Connor. Limiting the size of
scriptPubKeys would in this regard be moving in the opposite direction.

Various approaches of limiting the size of spent scriptPubKeys were discussed, in forms that would
mitigate the confiscatory surface, to adopt in addition to (what eventually became) the BIP54 sigops
limit. However i decided against including this additional measure in BIP54 because:
- of the inherent complexity of the discussed schemes, which would make it hard to reason about
constructing transactions spending legacy inputs, and equally hard to evaluate the reduction of
the confiscatory surface;
- more importantly, there is steep diminishing returns to piling on more mitigations. The BIP54
limit on its own prevents an externally-motivated attacker from *unevenly* stalling the network
for dozens of minutes, and a revenue-maximizing miner from regularly stalling its competitions
for dozens of seconds, at a minimized cost in confiscatory surface. Additional mitigations reduce
the worst case validation time by a smaller factor at a higher cost in terms of confiscatory
surface. It "feels right" to further reduce those numbers, but it's less clear what the tangible
gains would be.

Furthermore, it's always possible to get the biggest bang for our buck in a first step and going the
extra mile in a later, more controversial, soft fork. I previously floated the idea of a "cleanup
v2" in private discussions, and i think besides a reduction of the maximum scriptPubKey size it
should feature a consensus-enforced maximum transaction size for the reasons stated here:
https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8. I wouldn't hold my
breath on such a "cleanup v2", but it may be useful to have it documented somewhere.

I'm trying to not go into much details regarding which mitigations were considered in designing
BIP54, because they are tightly related to the design of various DoS blocks. But i'm always happy to
rehash the decisions made there and (re-)consider alternative approaches on the semi-private Delving
thread [0] dedicated to this purpose. Feel free to ping me to get access if i know you.

Best,
Antoine Poinsot

[0]: https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711




On Friday, October 17th, 2025 at 1:12 PM, Brandon Black <fre...@reardencode.com> wrote:

>
>
> On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
>
> > But also given that there are essentially no violations and no reason to
> > expect any I'm not sure the proposal is worth time relative to fixes of
> > actual moderately serious DOS attack issues.
>
>
> I believe this limit would also stop most (all?) of PortlandHODL's
> DoSblocks without having to make some of the other changes in GCC. I
> think it's worthwhile to compare this approach to those proposed by
> Antoine in solving these DoS vectors.
>
> Best,
>
> --Brandon
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aPJ3w6bEoaye3WJ6%40console.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5135a031-a94e-49b9-ab31-a1eb48875ff2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTeerZWCJeMDFXF9sR4vowGsVcbp3M_FypDfSZW2qLZ%2BQ%40mail.gmail.com.