From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D290B1D for ; Sun, 5 Jul 2015 19:50:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8593F1C2 for ; Sun, 5 Jul 2015 19:50:57 +0000 (UTC) Received: by pdjd13 with SMTP id d13so93158730pdj.0 for ; Sun, 05 Jul 2015 12:50:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=eRzh9IKHFFEHwJ1JS+sZuFrlitd64S3ytOjTZk0pg/E=; b=j80idiHdDg03qoogqSe8hE1DvTCzFFZCG0OHpEDwzJ92M8dhpTvf3PhIcS//TS0jHf Keut2HNsrvMA42+UXRLxmZZuVzQuiHifZe4deiGMB553WzyX3IEHlpAhdv3FBK9qWS1I /8nraGATVPRmhxC8BFQfpCGqfS1yrxjIdjf4MdNKjlQeVe2CwMk35nwF58sYL89Fdl+/ /dEJnPl0qTYdYbKZDb/Eka2kvfId+CYNqhpLZv8nLu8fY1CKBhTWNsUxGvegvfFUkRew BgaOSYJezHua+damaCqlnwLh7Z+gkjqdD8Ll79IKDL5UY/V7MU2TSsMyVBJMqoPlDL6D 2joQ== X-Gm-Message-State: ALoCoQmLolv/FkXxR7woizKPHQzt8T4qlIz/laH76eTXqqYsa3AWjc9ISB9MsciWyo1wgi0JviML X-Received: by 10.68.229.40 with SMTP id sn8mr96727822pbc.59.1436125857200; Sun, 05 Jul 2015 12:50:57 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by mx.google.com with ESMTPSA id bn5sm15658039pbc.82.2015.07.05.12.50.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 12:50:55 -0700 (PDT) Message-ID: <55998AA3.4060801@thinlink.com> Date: Sun, 05 Jul 2015 12:50:59 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mark Friedenbach References: <55994696.1090705@thinlink.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010806040100030708050205" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 19:50:58 -0000 This is a multi-part message in MIME format. --------------010806040100030708050205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Or you could flip the definition of your activation bit. That would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values. It would also allow an explicit relative locktime of 0, which would help applications avoid accidentally finalizing the whole transaction when they only meant to not impose a relative locktime on one input. On 7/5/2015 10:07 AM, Mark Friedenbach wrote: > Note that you can put 0 in the sequence number field and it would work > just as expected under the old rules. I will perhaps suggest instead > that Bitcoin Core post-0.11 switch to doing this instead for that case. > > On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding > wrote: > > BIP 68 uses nSequence to specify relative locktime, but nSequence also > continues to condition the transaction-level locktime. > > This dual effect will prevent a transaction from having an effective > nLocktime without also requiring at least one of its inputs to be > mined > at least one block (or one second) ahead of its parent. > > The fix is to shift the semantics so that nSequence = MAX_INT - 1 > specifies 0 relative locktime, rather than 1. This change will also > preserve the semantics of transactions that have already been created > with the specific nSequence value MAX_INT - 1 (for example all > transactions created by the bitcoin core wallet starting in 0.11). > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --------------010806040100030708050205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Or you could flip the definition of your activation bit.  That would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values.

It would also allow an explicit relative locktime of 0, which would help applications avoid accidentally finalizing the whole transaction when they only meant to not impose a relative locktime on one input.


On 7/5/2015 10:07 AM, Mark Friedenbach wrote:
Note that you can put 0 in the sequence number field and it would work just as expected under the old rules. I will perhaps suggest instead that Bitcoin Core post-0.11 switch to doing this instead for that case.

On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh@thinlink.com> wrote:
BIP 68 uses nSequence to specify relative locktime, but nSequence also
continues to condition the transaction-level locktime.

This dual effect will prevent a transaction from having an effective
nLocktime without also requiring at least one of its inputs to be mined
at least one block (or one second) ahead of its parent.

The fix is to shift the semantics so that nSequence = MAX_INT - 1
specifies 0 relative locktime, rather than 1.  This change will also
preserve the semantics of transactions that have already been created
with the specific nSequence value MAX_INT - 1 (for example all
transactions created by the bitcoin core wallet starting in 0.11).


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------010806040100030708050205--