Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CEDCCC002D for ; Tue, 11 Oct 2022 13:15:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 93B3E4098B for ; Tue, 11 Oct 2022 13:15:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 93B3E4098B Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=ng5JrTAC X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUmFk8PAmPPS for ; Tue, 11 Oct 2022 13:15:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 323B640272 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by smtp2.osuosl.org (Postfix) with ESMTPS id 323B640272 for ; Tue, 11 Oct 2022 13:15:09 +0000 (UTC) Received: by mail-lj1-x229.google.com with SMTP id m14so16779170ljg.2 for ; Tue, 11 Oct 2022 06:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lFXFbtAuTrW6VJSHb6AmQ+543Jl/+e7RtULpZQ/2UDo=; b=ng5JrTACrgBe1h30bkNbIM9UCJJc5qcnozNDYaeaU8cjuKARIJSjE4UwevHni5lN8G n2dk/8ZnFUj+kBMIBEuKl3CyNNJ5WXaCb2tKTWZIpo80E81UEbEj/bM+xDAraZlrnfRU OtwmzuKFW+ggfCXYEdjiUDq3uOcAv1kHhtqcopDbTlHhy1RHSp0ZZnXHq7UbijhXYJ+x bj6UDyextIJEWYjLOqXjcu7qfGUrElxfgFtcOH365fdgiqDSib20fNzeKz8ENLJD1mVb oFNTWcwkUY/bESNuAdKMeZtQGv2fgGKJIRFBzX3CRt8TbFQVnMml5ZrKU8t+zsm4qnOB Gr6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lFXFbtAuTrW6VJSHb6AmQ+543Jl/+e7RtULpZQ/2UDo=; b=1mWcc5yxZ1f+sDHrzfEkU+PE4Rbl9vmt+ATxivJ9j4PrEyAS+vfLJQeft6PoM2hp4C u8ZBKZy0NRasr7xm1vKzWgDPPdCIFCFOuFitlsdPdyOLf893D8lVetk679hXLfwqqyVR zgxTDAz6OyETOkDNV8gRfSq41ZOKpxStnAKjBRfL6QMq1fKbVNs2ScoOQlaLi+DJ/NUX 1S8umhQr0B+HvOhcNQ2y3wJi/2dvAw+e02B/TW0otY1lR43HoJwAUIwppK4r4kz5hz2E 575vQapgPqfA6oO0Y7bz4lDBQ++cwwnYH9s+iuoSIa8EwF2LQwEVaHkTFVynn8jc/+n5 COWQ== X-Gm-Message-State: ACrzQf3Kx+XG8kh42AW4EiCCOzKNsgo1EiwL2J1gbnsuc8bizBw0MNx0 l+YqnNoxmPaKF4HYR2pT2EgDS59ipF+zQCWAXQXUq15R X-Google-Smtp-Source: AMsMyM55DK7CIGQf+t23FAlsnUXpcbTOun4M4w14u8e8cfceoRFpa3mtYqyLaYVM8d7VN0H/b16yjKhgA5wHt5RUvIs= X-Received: by 2002:a05:651c:c88:b0:26d:fea6:36b1 with SMTP id bz8-20020a05651c0c8800b0026dfea636b1mr9323967ljb.433.1665494106757; Tue, 11 Oct 2022 06:15:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Tue, 11 Oct 2022 09:14:54 -0400 Message-ID: To: KING JAMES HRMH Content-Type: multipart/alternative; boundary="0000000000009bde0305eac21007" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Relaxing minimum non-witness transaction size policy restriction X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2022 13:15:11 -0000 --0000000000009bde0305eac21007 Content-Type: text/plain; charset="UTF-8" Propagation of these kinds of transactions will be hampered until becomes 10%+ of the network or so, like any other policy relaxation. On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH wrote: > I am reading between the lines, wouldn't that mean an older client like > v0.18 may not be able to receive a transaction from a newer client if it > has to validate 85 non-witness serialized bytes? If so we should not > concern but retain the backward compatibility especially since this was for > a vulnerability? I have not checked to code to see what it does. > > KING JAMES HRMH > > Get Outlook for Android > ------------------------------ > *From:* bitcoin-dev on > behalf of Greg Sanders via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> > *Sent:* Tuesday, October 11, 2022 11:50:07 PM > *To:* Bitcoin Dev > *Subject:* [bitcoin-dev] Relaxing minimum non-witness transaction size > policy restriction > > Hello fellow Bitcoiners, > > After looking at some fairly exotic possible transaction types, I ran into > the current policy limit requiring transactions to be 85 non-witness > serialized bytes. This was introduced as a covert fix to policy fix > for CVE-2017-12842. Later the real motivation was revealed, but the > "reasonable" constant chosen was not. > > I'd like to propose relaxing this to effectively the value BlueMatt > proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would > allow a single input, single output transaction with 4 bytes of OP_RETURN > padding, rather than padding out 21 bytes to get to p2wpkh size. > > The alternative would be to also allow anything below 64 non-witness > bytes, but this seems fraught with footguns for a few bytes gain. > > The PR is here with more relevant background and alternatives included in > the thread: > https://github.com/bitcoin/bitcoin/pull/26265 > > Please let us know if there's a fundamental issue with this approach, or > any other feedback. > > Best, > Greg > --0000000000009bde0305eac21007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Propagation of these kinds of transactions will be hampere= d until <merge version in core> becomes 10%+ of the network or so, li= ke any other policy relaxation.

On Tue, Oct 11, 2022 at 9:08 AM KING JAMES H= RMH <willtech@live.com.au>= ; wrote:
I am reading between the lines, wouldn't that mean an older client like= v0.18 may not be able to receive a transaction from a newer client if it h= as to validate=C2=A085 non-witness serialized bytes? If so we should not concern but retain the backward comp= atibility especially since this was for a vulnerability?=C2=A0I have not checked to code to see what it does.

KING JAMES HRMH

= Get Outlook for Android
From:= bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Greg Sanders via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org>
Sent: Tuesday, October 11, 2022 11:50:07 PM
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: [bitcoin-dev] Relaxing minimum non-witness transaction size= policy restriction
=C2=A0
Hello fellow Bitcoiners,

After looking at some fairly exotic possible transaction types, I ran = into the current policy limit requiring transactions to be 85 non-witness s= erialized bytes. This was introduced as a covert fix to policy fix for=C2= =A0CVE-2017-12842. Later the real motivation was revealed, but the "reasonable" constant chosen was not.

I'd like to propose relaxing this to effectively the value BlueMat= t proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would= allow a single input, single output transaction with 4 bytes of OP_RETURN = padding, rather than padding out 21 bytes to get to p2wpkh size.

The alternative would be to also allow anything below 64 non-witness b= ytes, but this seems fraught with footguns for a few bytes gain.

The PR is here with more relevant background and alternatives=C2=A0inc= luded in the thread:

Please let us know if there's a fundamental issue with this approa= ch, or any other feedback.

Best,
Greg
--0000000000009bde0305eac21007--