From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7E020C000E for ; Mon, 6 Sep 2021 03:17:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 57E2180F68 for ; Mon, 6 Sep 2021 03:17:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj0hQpnaSmkT for ; Mon, 6 Sep 2021 03:17:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3367F80F61 for ; Mon, 6 Sep 2021 03:17:30 +0000 (UTC) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1863HSYl018911 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 5 Sep 2021 23:17:29 -0400 Received: by mail-lj1-f172.google.com with SMTP id w4so8887956ljh.13 for ; Sun, 05 Sep 2021 20:17:29 -0700 (PDT) X-Gm-Message-State: AOAM530cSvY9Pa1TcBvb/czNoA1IJvgtjyXDf+VYJOUiPk/HpXMIYkTI QE4eXZ4jGHHL1N8FTTHBnmhLkBcSd7tPoKTHRy0= X-Google-Smtp-Source: ABdhPJwgzBJcjmWJ6DGSukUM4M4e43tw8rkLgWHInD/p6lXLlrJIe5I53+olBfWoeWQ55Fx6N+1d1VRtQI+eQOOegE8= X-Received: by 2002:a2e:a7cf:: with SMTP id x15mr8891298ljp.227.1630898247907; Sun, 05 Sep 2021 20:17:27 -0700 (PDT) MIME-Version: 1.0 References: <20210906023525.nui6beegrzopwfq4@ganymede> In-Reply-To: <20210906023525.nui6beegrzopwfq4@ganymede> From: Jeremy Date: Sun, 5 Sep 2021 20:17:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000bb418705cb4b1686" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect 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: Mon, 06 Sep 2021 03:17:32 -0000 --000000000000bb418705cb4b1686 Content-Type: text/plain; charset="UTF-8" BIP 68 says >= 2: *This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.* BIP-112 says not < 2 // Fail if the transaction's version number is not set high // enough to trigger BIP 68 rules. if (static_cast(txTo->nVersion) < 2) return false; A further proof that this needs fix: the flawed upgradable semantic exists in script as well as in the transaction nSeqeunce. we can't really control the transaction version an output will be spent with in the future, so it would be weird/bad to change the semantic in transaction version 3. -- @JeremyRubin On Sun, Sep 5, 2021 at 7:36 PM David A. Harding wrote: > On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote: > > Hi Bitcoin Devs, > > > > I recently noticed a flaw in the Sequence lock implementation with > respect > > to upgradability. It might be the case that this is protected against by > > some transaction level policy (didn't see any in policy.cpp, but if not, > > I've put up a blogpost explaining the defect and patching it > > https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/ > > Isn't this why BIP68 requires using tx.version=2? Wouldn't we just > deploy any new nSequence rules with tx.version>2? > > -Dave > --000000000000bb418705cb4b1686 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BIP 68 says >= =3D 2:
This specification defines the meaning of sequence num= bers for transactions with an nVersion greater than or equal to 2 for which= the rest of this specification relies on.
BIP-112 says not &l= t; 2
// Fail if the trans= action's version number is not set high
// enough to trigger BIP 68 = rules.
if (static_cast<uint32_t>(txTo->nVersion) < 2) return= false;

=
A further proof that this needs fix: the flawed upgradable semant= ic exists in script as well as in the transaction nSeqeunce. we can't r= eally control the transaction version an output will be spent with in the f= uture, so it would be weird/bad to change the semantic in transaction versi= on 3.

--


On Sun, Sep 5= , 2021 at 7:36 PM David A. Harding <dav= e@dtrt.org> wrote:
On Fri, Sep 03, 2021 a= t 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
> Hi Bitcoin Devs,
>
> I recently noticed a flaw in the Sequence lock implementation with res= pect
> to upgradability. It might be the case that this is protected against = by
> some transaction level policy (didn't see any in policy.cpp, but i= f not,
> I've put up a blogpost explaining the defect and patching it
> https://rubin.io/bitcoin/2021/09/03/up= gradable-nops-flaw/

Isn't this why BIP68 requires using tx.version=3D2?=C2=A0 Wouldn't = we just
deploy any new nSequence rules with tx.version>2?

-Dave
--000000000000bb418705cb4b1686--