Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6181C002D for ; Tue, 11 Oct 2022 12:50:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B445560C08 for ; Tue, 11 Oct 2022 12:50:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B445560C08 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=FkiUXm72 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0RYR-TeyYqz for ; Tue, 11 Oct 2022 12:50:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5141260BF7 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5141260BF7 for ; Tue, 11 Oct 2022 12:50:21 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id sc25so25005097ejc.12 for ; Tue, 11 Oct 2022 05:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=u+PJmf57gXt+8wn1HJUrPpQeqeEMua2+rkHEDa56Jjc=; b=FkiUXm72NAsg/dkDTR8CWH1WI1J2kSq7N9BFs2kLf2eFMG0D9v2RX60RUVCAT/xmcX Wq+30tBrhoijrlnI0gHjRmKyTnBRwyMAjutjryAvycM28BP72ruYfpUKS22NWEIs50Af fprSFTKYswg7iOm/ZCTMve3gi2XNNy5mUHkvGpg8JMz7Q0toEyK4gS0azaVrPBn/NpnN tuuuNQtro4ei+klkZJgVmjq82beXnvK0RaLvo374Y0QeQ1fBf2TE/m3v88PGtHIxYDUY T6xJpB+cinHhmF4DjWVnT3WYUBjxuMjXZc5Q3TP0hRo6yg00nzEsVNk+Q3uTZ037ohP2 S/Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=u+PJmf57gXt+8wn1HJUrPpQeqeEMua2+rkHEDa56Jjc=; b=qbHUIkznczXzwFeHKzunfgI4bJed9vRqLNFLVtwWwmgr0xLoDsZrjtYZh7GAm8G7Hg VTE4Fc6i+xa5nf4Ox/wwRC+ovLE7ii4E6WmWYq2tucws56YJggERfY756hdAPONpQYOV q0Quex8P4KbXq2ceW3nRsBfQw66gGjpYB8arz1YfY4E8duR+6Oc5YWArFoWRCRaszPYz kXnehLnGpIvwt4VRLrlfyUECihd2NMx5gikGwdfcM5rzrbjdLOXHHeBPf2yAPR6xE+eh slYi/ay6xOOpSbvrSFrU26jp0QNGppifBLvi3k7RBeU0oGKT0DcFvUzE5e5lAkDjf9rD Im3g== X-Gm-Message-State: ACrzQf3dcZbY2xaL/chPHvnoxEVEEbZIPndV1wtAsCcV2cznlqgaarV5 elNd6Qtw96Rc0VkjzI8gZl37sgJDMt72CYwrcEjnl4R8vyI= X-Google-Smtp-Source: AMsMyM4ndwidE/x2OU1SujpK3JFClJNS5L8sT/RVEekiWhBeSsd+mgGBNthc0t5S1MjbInqFSO01CyDoEKsg0vV6bOw= X-Received: by 2002:a17:907:3f8b:b0:783:2008:e562 with SMTP id hr11-20020a1709073f8b00b007832008e562mr19000924ejc.261.1665492618903; Tue, 11 Oct 2022 05:50:18 -0700 (PDT) MIME-Version: 1.0 From: Greg Sanders Date: Tue, 11 Oct 2022 08:50:07 -0400 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000ed04ea05eac1b7b3" Subject: [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 12:50:23 -0000 --000000000000ed04ea05eac1b7b3 Content-Type: text/plain; charset="UTF-8" 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 --000000000000ed04ea05eac1b7b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello fellow Bitcoiners,

After looking = at some fairly exotic possible transaction types, I ran into the current po= licy limit requiring transactions to be 85 non-witness serialized bytes. Th= is was introduced as a covert fix to policy fix for=C2=A0CVE-2017-12842. La= ter the real motivation was revealed, but the "reasonable" consta= nt chosen was not.

I'd like to propose relaxin= g this to effectively the value BlueMatt proposed in the Great Consensus Cl= eanup: 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 fraug= ht with footguns for a few bytes gain.

The PR is h= ere with more relevant background and alternatives=C2=A0included in the thr= ead:

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

Best,
Greg
= --000000000000ed04ea05eac1b7b3--