Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B622EC000E for ; Sun, 5 Sep 2021 03:20:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 97C1D400D7 for ; Sun, 5 Sep 2021 03:20:15 +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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4SZxz-XtacU for ; Sun, 5 Sep 2021 03:20:14 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 167424002B for ; Sun, 5 Sep 2021 03:20:13 +0000 (UTC) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1853K99f010933 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 4 Sep 2021 23:20:10 -0400 Received: by mail-lj1-f174.google.com with SMTP id d16so5244458ljq.4 for ; Sat, 04 Sep 2021 20:20:10 -0700 (PDT) X-Gm-Message-State: AOAM532A2zlULKb0+Sm7hlc+Ai85J48y+BoawCpFDEFeyCfvGIxnTKOX CgMkjBSyXQ7BvS15YE48ZKMRLYq1mmNoSx8DZ4w= X-Google-Smtp-Source: ABdhPJxnkI9xSMinNz9VsZ0D9w/eyES3/9tjVppA9XOh8csW0Zmt1M35lJBZUQumvJ7UkWVwm/csar/ZYbqwQAI16Hc= X-Received: by 2002:a2e:88d0:: with SMTP id a16mr5108604ljk.81.1630812008572; Sat, 04 Sep 2021 20:20:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sat, 4 Sep 2021 20:19:57 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000776cc505cb37021b" Cc: Bitcoin development mailing list 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: Sun, 05 Sep 2021 03:20:15 -0000 --000000000000776cc505cb37021b Content-Type: text/plain; charset="UTF-8" In working on resolving this issue, one issue that has come up is what sequence values get used by wallet implementations? E.g., in Bitcoin Core a script test says BIP125_SEQUENCE_NUMBER = 0xfffffffd # Sequence number that is rbf-opt-in (BIP 125) and csv-opt-out (BIP 68) Are any other numbers currently expected by any wallet software to be broadcastable with the DISABLE flag set? Does anyone use *this* number? Is there any advantage of this number v.s. just 0? Do people commonly use 0xfffffffd? 0xfffffffe is special, but it seems the former has the alternative of either 0 valued sequence lock (1<<22 or 0). Are there any other sequence numbers that are not defined in a BIP that might be used somewhere? Cheers, Jeremy -- @JeremyRubin On Fri, Sep 3, 2021 at 8:32 PM Jeremy 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/ > > I've proposed patching it here > https://github.com/bitcoin/bitcoin/pull/22871, it is proper to widely > survey the community before patching to ensure no one is depending on the > current semantics in any live application lest this tightening of > standardness rules engender a confiscatory effect. > > Best, > > Jeremy > > -- > @JeremyRubin > > --000000000000776cc505cb37021b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In working on resolving t= his issue, one issue that has come up is what sequence values get used by w= allet implementations?

E.g., in Bitcoin Core a script test says
=

BIP125_SEQUENCE_NUMBER =3D 0xfffffffd =C2=A0# Sequence number that is rbf-= opt-in (BIP 125) and csv-opt-out (BIP 68)

Are any other numbers c= urrently expected by any wallet software to be broadcastable with the DISAB= LE flag set? Does anyone use *this* number? Is there any advantage of this = number v.s. just 0? Do=C2=A0people commonly use 0xfffffffd? 0xfffffffe is s= pecial, but it seems the former has the alternative of either 0 valued sequ= ence lock (1<<22 or 0).

Are there any other sequence numbers th= at are not defined in a BIP that might be used somewhere?

Cheers,

Jeremy
<= div dir=3D"ltr">--
@JeremyRubin


=
On Fri, Sep 3, 2021 at 8:32 PM Jeremy= <jlrubin@mit.edu> wrote:
Best,

Jeremy

--000000000000776cc505cb37021b--