path: root/64/439fec967e47533df0f39a788faaff737a9b98

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CEDCCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 Oct 2022 13:15:09 +0000 (UTC)
Received: by mail-lj1-x229.google.com with SMTP id m14so16779170ljg.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAB3F3DtNWajm669s9a=cs+Dft0PXDu1JHchzEw+yYLmRS+YSYQ@mail.gmail.com>
 <PS2P216MB1089C3131115B700C840BEFB9D239@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB1089C3131115B700C840BEFB9D239@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
From: Greg Sanders <gsanders87@gmail.com>
Date: Tue, 11 Oct 2022 09:14:54 -0400
Message-ID: <CAB3F3Dv9bY3uf-21wDW43s_xU=Xjg7s2MzXReoBxwTVVHgenjw@mail.gmail.com>
To: KING JAMES HRMH <willtech@live.com.au>
Content-Type: multipart/alternative; boundary="0000000000009bde0305eac21007"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <merge
version in core> becomes 10%+ of the network or so, like any other policy
relaxation.

On Tue, Oct 11, 2022 at 9:08 AM KING JAMES HRMH <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
> 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 <https://aka.ms/AAb9ysg>
> ------------------------------
> *From:* bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> 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 <bitcoin-dev@lists.linuxfoundation.org>
> *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

<div dir=3D"ltr">Propagation of these kinds of transactions will be hampere=
d until &lt;merge version in core&gt; becomes 10%+ of the network or so, li=
ke any other policy relaxation.</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Tue, Oct 11, 2022 at 9:08 AM KING JAMES H=
RMH &lt;<a href=3D"mailto:willtech@live.com.au">willtech@live.com.au</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
I am reading between the lines, wouldn&#39;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=A0<span style=3D"font-family:-apple-system,HelveticaNeue;=
display:inline">85 non-witness
 serialized bytes? If so we should not concern but retain the backward comp=
atibility especially since this was for a vulnerability?</span><span style=
=3D"display:inline">=C2=A0I have not checked to code to see what it does.</=
span>
<div dir=3D"auto"><span style=3D"display:inline"><br>
</span></div>
<div dir=3D"auto"><span style=3D"display:inline">KING JAMES HRMH</span></di=
v>
<div><br>
</div>
<div id=3D"m_-3825585021204174033ms-outlook-mobile-signature" dir=3D"auto">=
Get <a href=3D"https://aka.ms/AAb9ysg" target=3D"_blank">
Outlook for Android</a></div>
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_-3825585021204174033divRplyFwdMsg" dir=3D"ltr"><font face=3D"C=
alibri, sans-serif" style=3D"font-size:11pt" color=3D"#000000"><b>From:</b>=
 bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev-bounces@lists.linuxfoundation.org</a>&=
gt; on behalf of Greg Sanders via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt;<br>
<b>Sent:</b> Tuesday, October 11, 2022 11:50:07 PM<br>
<b>To:</b> Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br=
>
<b>Subject:</b> [bitcoin-dev] Relaxing minimum non-witness transaction size=
 policy restriction</font>
<div>=C2=A0</div>
</div>
<div>
<div dir=3D"ltr">Hello fellow Bitcoiners,
<div><br>
</div>
<div>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 &quot;reasonable&quot; constant chosen was not.</div=
>
<div><br>
</div>
<div>I&#39;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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The PR is here with more relevant background and alternatives=C2=A0inc=
luded in the thread:</div>
<div><a href=3D"https://github.com/bitcoin/bitcoin/pull/26265" target=3D"_b=
lank">https://github.com/bitcoin/bitcoin/pull/26265</a><br>
</div>
<div><br>
</div>
<div>Please let us know if there&#39;s a fundamental issue with this approa=
ch, or any other feedback.</div>
<div><br>
</div>
<div>Best,</div>
<div>Greg</div>
</div>
</div>
</div>

</blockquote></div>

--0000000000009bde0305eac21007--