From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Oct 2025 16:46:06 -0700 Received: from mail-oo1-f61.google.com ([209.85.161.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v9BC2-000677-88 for bitcoindev@gnusha.org; Wed, 15 Oct 2025 16:46:06 -0700 Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-6500f45b699sf159577eaf.0 for ; Wed, 15 Oct 2025 16:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1760571960; x=1761176760; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=KxMqttNFKi5h8HgIhZFGA2h4s+QTuiL6XUT5TouNI4Y=; b=Zy63Hi4dn7S8uhPlctzk5K1NHQQIz4G3C2pxYKCb+g3sAmJgpwbe7HBMdKQWFcyLIm Lb65BaPSnduQW4IG0CUg1f6AUgmyIiAu+ejpLSY/9DbJQbk+441AyGtnbNf7W4QlJd1n PEZbg2hT5aFop4IUK6w6zM6Rr6CBtKvcUMfjlgqQJ5Uyp497Aqd9qeCj7NmyEYlUauGb aEUbKquK9VKETo/cX9w37t+i9NlJmBEIy9cp7Ohpbxlr3w+JYJX1FQ0dAhURW1xVPWa/ GPe6IsmnGZeu3//jO5DqepesL+AHwsf2zTr/ngchnXiyRx2LfpbrJYfQMMdZ57gLJhy6 NPRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rodarmor.com; s=google; t=1760571960; x=1761176760; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=KxMqttNFKi5h8HgIhZFGA2h4s+QTuiL6XUT5TouNI4Y=; b=WFnp8XkPm1WTmEvZnolRQuiEtBg7rsUczEczuHHIhbD+tYKgdfJQJxf/s4kXxCtwO6 H9r1gt4jQf0+GxQc+TbGaQ/k2QnnK31+WnLcoozkQlUrYgykMCP3g1TDAnOcUoS0mlLE wMG8unY8VZaryPQxxmleR0WHf7Py6vCV98XquzvzAxzB7r7x/7/Skfc4b7/FN3KN1H5X c2Yv+FUa1Z3lDPPBO+R2IlFkxrohvPvMpelPDpdKeSem5r50UJtkRAq85GswSkwBvqzW r8f1SH0WVocn4hduMo3SoHEnoPfiTh9mUn8FEvzSv9i1OAqxzaAfEQWVA96H7dFn4iAv H7Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760571960; x=1761176760; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=KxMqttNFKi5h8HgIhZFGA2h4s+QTuiL6XUT5TouNI4Y=; b=g1uioLOhyKKvezWrCL182TB+nKL+B4gLVCDldBgoUHZJJYBJWvCK2BM9V56f/GSxjB UUL+iimigLtfBlpf5afDpWHxYYgqU0h+rhcvMbZ5/3uuXUFlc/WQ6iztPOLcAMQJ+sB6 37T2RA5r7WPxjdzy8j2hKgRc64C+TuSPuCccWgTrEPyZHK4+QH4EyDjPysQ/ryypNDMP Hc5D/TcRflljl4GlooMf8vpQxAinIziYF4h/n0mFdBEdyZRc4AqQ3bjTHl2Hp2C3QaHf T4M284NKAJ0bzTU08Wbd7yhnSCq066YbItzZkvDo4r53O4l5qwvF2UozHJuiAfCjv7C4 L3BA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUd1FsgzXW5mwfJusv+7UftDmeS+AeWBuLrwURuvUSRCIJSeVYhuRtVKG2VNlQQKj9gwCHc0/ns30tw@gnusha.org X-Gm-Message-State: AOJu0YxxEskUc2CdfzoKRavdrNEF3rGzuvbrthYcLmDPwVXx9LwIbbbe uRi0ss26KnBIs5dsqowj7vEDZYu76wdEZ1YjGoVB42KY9/zuMja/HSHG X-Google-Smtp-Source: AGHT+IFRZcF+9TvNLoTscOwHfC7RRHsZEZVsLPeQG2pOgnkclQhieue6mcnYaE13LXYyYxmAMnezbA== X-Received: by 2002:a05:6820:994:b0:650:3149:fdca with SMTP id 006d021491bc7-650314a15famr6310335eaf.6.1760571959795; Wed, 15 Oct 2025 16:45:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4804RS/tlBc5e1InnOyAUoyuZBgT7qOxZh349tIrwBBg==" Received: by 2002:a05:6820:4084:b0:621:9037:deeb with SMTP id 006d021491bc7-651bea76061ls55728eaf.2.-pod-prod-03-us; Wed, 15 Oct 2025 16:45:55 -0700 (PDT) X-Received: by 2002:a05:6808:1246:b0:441:8f74:f14 with SMTP id 5614622812f47-4418f741fe3mr11592264b6e.62.1760571955657; Wed, 15 Oct 2025 16:45:55 -0700 (PDT) Received: by 2002:a05:690c:a9b:b0:780:f7eb:fdf with SMTP id 00721157ae682-7815b1fb141ms7b3; Wed, 15 Oct 2025 13:04:27 -0700 (PDT) X-Received: by 2002:a05:690c:a083:10b0:781:64f:2b42 with SMTP id 00721157ae682-781064f399cmr181180237b3.68.1760558666461; Wed, 15 Oct 2025 13:04:26 -0700 (PDT) Date: Wed, 15 Oct 2025 13:04:26 -0700 (PDT) From: Casey Rodarmor To: Bitcoin Development Mailing List Message-Id: <961e3c3a-a627-4a07-ae81-eb01f7a375a1n@googlegroups.com> In-Reply-To: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> Subject: [bitcoindev] Re: [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_89872_1412476994.1760558666144" X-Original-Sender: casey@rodarmor.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.7 (/) ------=_Part_89872_1412476994.1760558666144 Content-Type: multipart/alternative; boundary="----=_Part_89873_592518992.1760558666144" ------=_Part_89873_592518992.1760558666144 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that "Bitcoin could need it in the future?" might be a good enough reason not to do this. Script pubkeys are the only variable-length transaction fields which can be covered by input signatures, which might make them useful for future soft forks. I can imagine confidential asset schemes or post-quantum coin=20 recovery schemes requiring large proofs in the outputs, where the validity of the=20 proof determined whether or not the transaction is valid, and thus require the proofs to be in the outputs, and not just a hash commitment. On Thursday, October 2, 2025 at 2:59:24=E2=80=AFPM UTC-7 PortlandHODL wrote= : > Proposing: Softfork to after (n) block height; the creation of outpoints= =20 > with greater than 520 bytes in the ScriptPubkey would be consensus invali= d.=20 > > This is my gathering of information per BIP 0002 > > After doing some research into the number of outpoints that would have=20 > violated the proposed rule there are exactly 169 outpoints. With only 8= =20 > being non OP_RETURN. I think after 15 years and not having discovered use= =20 > for 'large' ScriptPubkeys; the reward for not invalidating them at the=20 > consensus level is lower than the risk of their abuse.=20 > > -=20 > *Reasons for * > - Makes DoS blocks likely impossible to create that would have any= =20 > sufficient negative impact on the network. > - Leaves enough room for hooks long term > - Would substantially reduce the divergence between consensus and= =20 > relay policy > - Incredibly little use onchain as evidenced above. > - Could possibly reduce codebase complexity. Legacy Script is=20 > largely considered a mess though this isn't a complete disablement = it=20 > should reduce the total surface that is problematic. > - Would make it harder to use the ScriptPubkey as a 'large'=20 > datacarrier. > - Possible UTXO set size bloat reduction. > =20 > - *Reasons Against * > - Bitcoin could need it in the future? Quantum? > - Users could just create more outpoints. > =20 > Thoughts? > > source of onchain data =20 > > > PortlandHODL > > --=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/= 961e3c3a-a627-4a07-ae81-eb01f7a375a1n%40googlegroups.com. ------=_Part_89873_592518992.1760558666144 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think that "Bitcoin could need it in the future?" might be a good enough<= br />reason not to do this.

Script pubkeys are the only variable= -length transaction fields which can be
covered by input signatures, w= hich might make them useful for future soft
forks. I can imagine confi= dential asset schemes or post-quantum coin recovery
schemes requiring = large proofs in the outputs, where the validity of the proof
determine= d whether or not the transaction is valid, and thus require the
proofs= to be in the outputs, and not just a hash commitment.
On Thursday, October 2, = 2025 at 2:59:24=E2=80=AFPM UTC-7 PortlandHODL wrote:
Proposing: Softfork to after (n) bl= ock height; the creation of outpoints with greater than 520 bytes in the Sc= riptPubkey would be consensus invalid.

This is my gathering of info= rmation per BIP 0002

After doing some research into the number of ou= tpoints that would have violated the proposed rule there are exactly 169 ou= tpoints. With only 8 being non OP_RETURN. I think after 15 years and not ha= ving discovered use for 'large' ScriptPubkeys; the reward for not i= nvalidating them at the consensus level is lower than the risk of their abu= se.=C2=A0
  • Reasons for
    • Makes DoS blocks likely = impossible to create that would have any sufficient negative impact on the = network.
    • Leaves enough room for hooks long term
    • Would s= ubstantially reduce the divergence between consensus=C2=A0 and relay policy=
    • Incredibly little use onchain as evidenced above.
    • Could po= ssibly reduce codebase complexity. Legacy Script is largely considered a me= ss though this isn't a complete disablement it should reduce the total = surface that is problematic.
    • Would make it harder to use the Script= Pubkey as a 'large' datacarrier.
    • Possible UTXO set size blo= at reduction.

  • Reasons Against=C2=A0
      Bitcoin could need it in the future? Quantum?
    • Users could just= create more outpoints.
Thoughts?

source of onchain data=C2=A0=

PortlandHODL

--
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/bitcoind= ev/961e3c3a-a627-4a07-ae81-eb01f7a375a1n%40googlegroups.com.
------=_Part_89873_592518992.1760558666144-- ------=_Part_89872_1412476994.1760558666144--