From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 18 Oct 2025 02:25:27 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vA3Bl-00052D-QI for bitcoindev@gnusha.org; Sat, 18 Oct 2025 02:25:26 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-3c97a571859sf4898781fac.1 for ; Sat, 18 Oct 2025 02:25:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1760779519; cv=pass; d=google.com; s=arc-20240605; b=Ur6bnTQZJP96rQMsdu9iwyZzljv4GKDr6Dw2GgXFjJ0BMtcpwwVZ5d4247Ml5sJRkf jJVp7xDhSbHU03uqTXwZqDibdv9GKfjLI9WiHb7h0fektyGd+QKNBqcEadYMadZkE0qI Cq9VTr4QhqiUNC+30PJo2x83AojLM9iAlzDcoGmahr5YHdc4bKMFpzsuwKcmufKuaEWP ZbUnXkAuvzeS6PVn13tDCUaLRkWBLuskbCBXH3DZ2czzVPsSTV4GoM2wgXcpGlNZqghE TeoygBp4wBe1NFQiqx9Wow3I9/R6BkPTzi+NOggLULjfdbobdvWPGQqNaAa/v18JAScd WtXw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=VG/pn5MiCFSwlVIvKQBNoY0CT2G0qSwS0kFiVheCaCk=; fh=XE7U7EExjRv77cNYuB3GtZ/7J2ZoOffRwiJOnAZAuX4=; b=ianUsK0vLnWtx5ZH/4MhVeoC68LhhIpcwO/PyzJR5MaUFovc6Llls1yeBLKdrjvaBU PRJYUSo7YHgvEPn+t7TWGPWsHbmnTyF4AlVHnAJ/v0GNg+Rdx+6c2wi0EyCNARzQVZLz WSLpZsx3WvhOmN/t07wn6EAPHxiPdUfnRRY+DbxgKiMdYoTFTBXYfzSjPdXtw3n7GWPP df3SO6r6m4TgJao30jC0NC0B2B3GOLk2VHGtN5MAFCvpdRxNDN6s4vYMe9nk76r6owoq 26hd/OZBLSaPB/ro4MvUW8cvkH3SsCsvRjKnZE3jOInnnqA8pKb7n+K8DQ/PK1v4wx44 5IoQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=BFojIJQW; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::436 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1760779519; x=1761384319; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=VG/pn5MiCFSwlVIvKQBNoY0CT2G0qSwS0kFiVheCaCk=; b=veaT4MahqF89m3VBLQAotax4dSL3MXd2dmtZ9IpOb97M1yRCbZmKiNpEuigF7GJ2Tn /Bpyn3YpDr/hOpAObbwbQmKLKPhVBmZDozRmzEV3J5oa5pPUB6s2bhXx9afZrf7frgfM KOQEcYY2Ln2No7N2e32MeVaUIJ99TZml1Dnfv1hnEO/zhJb92VklWUHIdC9EsgZgd2ce YLaHUxIUtdqQSDjGrstkOZeBZzqu6wg43DKZ44RGEuIEqfrUmLRQLX8p+6yCS9mypFNW fi71iVsMdXLqfdAB/3qGBG0IM4RKGe8U4ZJzzdB1T8byZQyyEti0rzRY51hlzFdH/j38 aQGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760779519; x=1761384319; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VG/pn5MiCFSwlVIvKQBNoY0CT2G0qSwS0kFiVheCaCk=; b=NwRguFgbRmBp34QtAKSN0tFjYwCSFr8zPWO9bdlwlnNg5sUaV9Ahxz21gz0TIr9D/I mD0LXc1pKWhokTckFip2k7aTy4XdQMXXuwEDb4iYdEuQIZZd7K11lyxTkCHMkvk9kiPz pIUnnoZGT5PDWVqK26N4eodRFp+4Qhq+wQaO3bckkL6YlLHWb0URJukUjy1vvmyT3vUS 20JKQOMAgdH6xFOEobiUW3edA9LUMeeQrvio1CkYeg/lPjYYAIy7OPyj8iBcyXG9wB9T g7emJgyMTeVGQNMP8tWg6ca5yXluUOImqqQt1OIqvmzaZrBmctzvuJgvfpL63wdUncrr Ac7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760779519; x=1761384319; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=VG/pn5MiCFSwlVIvKQBNoY0CT2G0qSwS0kFiVheCaCk=; b=czjMbLfR3rUU73F0uSJGmxzjn1jpncJ7/s1qIs51VnOn8DhtBjQ5pVQMe9VE92WS9n deazeD/FfwRSsDKX2cDJq+tqh5Yng1JzBE6R0GuoOSheBA+l3CFPbeMVMulMyLgLi02T d9hTvhvhLb3kiMaZoXAezy5vmsCN5AVJX3jeIJapK3uwiXfUNvjVJUakKItfb6DjpKNH SWsiRSEDpAd5CBX0pr4sx7VtqTpCF0ZV2uBV1KyWC7gJX2XNrPW/j/aL2OeeXoGd7L/0 l7qsZKOHji8nM2Uc0GLh8QILJHHC1gbCxJ9BRJJ4AcwTHbL2+jebe1twLAESsp6qm/64 INeg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVs3C3AKMzEW/J/uvJzkKzu48A+tYCqmdeg4nFoXc77tRCHLNGqCpl+pLWOwcpWW8Km0IKohTX+s+bM@gnusha.org X-Gm-Message-State: AOJu0YzWQprp8UV3xjtv+DeSHkPopEG3hdCnt5mO5POvejesg9Qoi64H vfOBwEHC1GU88l7ZlReVVraCzxiz33f/N3ocgeybITRbsoScWwP1PGwK X-Google-Smtp-Source: AGHT+IFnOFi5oEVU9qGKLSzoNmVm/rA3THoUKPUuisexuG+gTzvZUQi2qUTHFDXW4lpXOlQtNE4AfQ== X-Received: by 2002:a05:6870:a2ca:b0:355:eb2c:476b with SMTP id 586e51a60fabf-3c98acd34bcmr2663898fac.5.1760779518753; Sat, 18 Oct 2025 02:25:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd67QAm8ZM3QvrqsVubji2vES/MM/1A8sudu6RZQ6FyRuQ==" Received: by 2002:a05:6871:c703:b0:32b:b1dc:4a51 with SMTP id 586e51a60fabf-3c9746acf42ls945200fac.0.-pod-prod-00-us; Sat, 18 Oct 2025 02:25:14 -0700 (PDT) X-Received: by 2002:a05:6808:470c:b0:43d:2e4a:e5c0 with SMTP id 5614622812f47-441fb7ea9e9mr4883474b6e.1.1760779513981; Sat, 18 Oct 2025 02:25:13 -0700 (PDT) Received: by 2002:a05:6808:1786:b0:443:86bf:6d36 with SMTP id 5614622812f47-443a461323dmsb6e; Fri, 17 Oct 2025 21:03:57 -0700 (PDT) X-Received: by 2002:a05:6e02:3e04:b0:430:bce3:1b72 with SMTP id e9e14a558f8ab-430c529240bmr102636925ab.7.1760760237158; Fri, 17 Oct 2025 21:03:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1760760237; cv=none; d=google.com; s=arc-20240605; b=JywZHweoPICzZCGq8nEBS4qQwP/6Ex5HMjcDWzacR0kFn3mjMFQdcKlyluPipDMEr9 RJGJNji1sHSttBIiTzMWnmOm/dQJ0y/talPIhKxc8DikkPHhQMnb7az0cxS5RNjEBNni yn6U8+AANBqQSgrnB7tNpyXgqgRRPWf0q0406WOM259P3f6P4Z7Qk8It3VI+g4PppHsx VzhXS/Pjkht38a5Ia8rduhvTZmgnSfoCyLlnWblzIv4fvtSDwDvqHsaJgUvE6dH+fypn uXUFe2a1cylz3nf9czSU4PJOuT+mEi4CR7ARed6QSVMOk40yBol777zQDz8S6pGh81YS 6fqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=95OCsE59TtEyPg2GJYI2Uem+o+R3MG+ED0whLbhDa84=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=hEL1t/xOECY5WiFbPK63v1WnbXJZiqZ+qJllRKDM3B3LSC2VSuaisx25/RZQ6jJhbx RWExBR6Rc7BzDfl05x9TUGhKSEH+4GqpOb/r0SjdsNvtB7JbdzuuU3rUoBLHs/l82H8O y+3mzhg9WePDTi9Nw1MvhTcNXdX7el2U9iqtnxpLNVJ90CaxWe8hynfwYhRICO1Rj05/ sG1JUjxjCahhYZ3lkcDvm9eiWhw9Lo66NyD7hhuyj+brI1PFeJa8LcggtAvzkGWW5+vh QpLEEL+rXE5azGZjag4cbk6scEehmiJ7LFYlRlxpHDbLE/HiBOQz188hFK3xpUKvZsL+ n+Fg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=BFojIJQW; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::436 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com. [2607:f8b0:4864:20::436]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-430d0705260si1031285ab.1.2025.10.17.21.03.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Oct 2025 21:03:57 -0700 (PDT) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::436 as permitted sender) client-ip=2607:f8b0:4864:20::436; Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-794e300e20dso3034895b3a.1 for ; Fri, 17 Oct 2025 21:03:57 -0700 (PDT) X-Gm-Gg: ASbGnctCbBRTfJU9Q9xft5eTICj27vFApisYmggIiIIqwYK7zex4sBtfhNLAkK1PtvA lB913ZfcUbpEWELN6uDp5hTOIZS+O+U5toUBMoboAaY30nNUBVyjncrKwg2j9EYUBK3pXvPSY03 SVm7CpHTbc3a5Krw8PxKB0PzM6fux2l5a6wX8irPYWYfwcxNP47ULnTQfwRL34f7kzLZwWFKPY+ PGHn9NRcV7MD2khcDhZJGjqQyQavswFBqQyvb5pYKOlzdxfrYoZP6LJr7gBXvvqexKaUuI= X-Received: by 2002:a17:902:ebc7:b0:27c:3690:2c5d with SMTP id d9443c01a7336-290915216d8mr122756895ad.0.1760760236338; Fri, 17 Oct 2025 21:03:56 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> <5135a031-a94e-49b9-ab31-a1eb48875ff2n@googlegroups.com> In-Reply-To: <5135a031-a94e-49b9-ab31-a1eb48875ff2n@googlegroups.com> From: Greg Maxwell Date: Sat, 18 Oct 2025 04:03:43 +0000 X-Gm-Features: AS18NWCASNWzn32vUNt_JtRyFqiI5PtepULVDf9YRRxPfq9Bqg98uckXvsq-aoQ Message-ID: Subject: Re: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Antoine Riard Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006bf3c1064166f006" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=BFojIJQW; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::436 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000006bf3c1064166f006 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Antoine Riard 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 tha= n > 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: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31d72f0e499= 9 > Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a =C3= =A9crit : > >> 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 i= n >> 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/1= 732/8. >> I wouldn't hold my >> breath on such a "cleanup v2", but it may be useful to have it documente= d >> 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/71= 1 >> >> >> >> >> 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 reaso= n >> 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-a1eb= 48875ff2n%40googlegroups.com > > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAAS2fgTeerZWCJeMDFXF9sR4vowGsVcbp3M_FypDfSZW2qLZ%2BQ%40mail.gmail.com. --0000000000006bf3c1064166f006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Limits on block construction that cross transactions = make it harder to accurately estimate fees and greatly complicate optimal b= lock construction--=C2=A0 the latter being important because smarter and mo= re computer powered mining code generating higher profits is a pro centrali= zation=C2=A0factor.

In terms of effectiveness=C2= =A0the "spam" will just make itself indistinguishable from the mo= st common transaction traffic from the perspective of such metrics--=C2=A0 = and might well drive up "spam" levels because the higher embeddin= g cost may make some of them use more transactions.=C2=A0 The competition f= or these buckets by other traffic could make it effectively a block size re= duction even against very boring ordinary transactions.=C2=A0 ... 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 fa= r 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=C2=A0or else they'd already be using s= omething else... some are even in favor of higher costs since the high fees= are what create the scarcity needed for their seigniorage.

<= /div>
But yeah I think your comments on priorities are correct.


On Sat, Oct 18, 2025 at 1:20=E2=80=AFAM = 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 bitcoi= n script with future (post-quantum) cryptographic schemes.
Previous prop= osal of the annex were deliberately designed with variable-length fieldsto flexibly accomodate a wide range of things.

I believe there is o= ne 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 oc= curences during the period P. Beyond the L threshold, any
additional T s= criptpubkey is making the block invalid. Or alternatively, any additionalT 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 a= t current feerate would have their safety timelocks scale
ups.

No= need anymore to come to social consensus on what is quantitative "spa= m" or not. The blockchain
would automatically throttle out the bloc= k space spamming transaction. Qualitative spam it's another
question= , for anyone who has ever read shannon's theory of communication only e= ffective thing can
be to limit the size of data payload. But probably we= 're kickly back to a non-mathematically solvable
linguistical questi= on 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
ourselve= s in the foot with ill-designed "spam" consensus mitigations.
=
[0] If you have a soul of logician, it would be an interesting demonstr= ation to come with
to establish that we cannot come up with mathematical= ly or cryptographically consensus means
to solve qualitative "spam&= quot;, which in a very pure sense is a linguistical issue.

Best,
= Antoine
OTS hash: 6cb50fe36ca0ec5cb9a88517dd4ce9bb50dd6ad1d2d6a640dd4a31= d72f0e4999
Le vendredi 17 octobre 2025 =C3=A0 19:45:44 UTC+1, Antoine Poinsot a = =C3=A9crit=C2=A0:
https://delvingbitcoi= n.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 i= t 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 bl= ocks. But i'm always happy to
rehash the decisions made there and (re-)consider alternative approache= s on the semi-private Delving
thread [0] dedicated to this purpose. Feel free to ping me to get acces= s if i know you.

Best,
Antoine Poinsot

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




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

>=20
>=20
> On 2025-10-16 (Thu) at 00:06:41 +0000, Greg Maxwell wrote:
>=20
> > But also given that there are essentially no violations and n= o reason to
> > expect any I'm not sure the proposal is worth time relati= ve to fixes of
> > actual moderately serious DOS attack issues.
>=20
>=20
> I believe this limit would also stop most (all?) of PortlandHODL&#= 39;s
> DoSblocks without having to make some of the other changes in GCC.= I
> think it's worthwhile to compare this approach to those propos= ed by
> Antoine in solving these DoS vectors.
>=20
> Best,
>=20
> --Brandon
>=20
> --
> 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%40con= sole.

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

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