<oembed><type>rich</type><version>1.0</version><title>David A. Harding [ARCHIVE] wrote</title><author_name>David A. Harding [ARCHIVE] (npub16d…x4wrd)</author_name><author_url>https://yabu.me/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-09-05&#xA;📝 Original message:On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:&#xA;&gt; Hi Bitcoin Devs,&#xA;&gt; &#xA;&gt; I recently noticed a flaw in the Sequence lock implementation with respect&#xA;&gt; to upgradability. It might be the case that this is protected against by&#xA;&gt; some transaction level policy (didn&#39;t see any in policy.cpp, but if not,&#xA;&gt; I&#39;ve put up a blogpost explaining the defect and patching it&#xA;&gt; https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/&#xA;&#xA;Isn&#39;t this why BIP68 requires using tx.version=2?  Wouldn&#39;t we just&#xA;deploy any new nSequence rules with tx.version&gt;2?&#xA;&#xA;-Dave&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 833 bytes&#xA;Desc: not available&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210905/2f55d419/attachment.sig&gt;</html></oembed>