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 CDC5D1D46 for ; Tue, 6 Oct 2015 00:29:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60C2E31 for ; Tue, 6 Oct 2015 00:29:18 +0000 (UTC) Received: by wicge5 with SMTP id ge5so143687427wic.0 for ; Mon, 05 Oct 2015 17:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vP14prdk8iEaBPN+6ZLT4G/pKRzmmsPlcjrXm/HGDr4=; b=JVVzs9dCZlLOIr3Nepv3D83f2yZ4k5Z8KODxEAe9mSotStVBTdM713xlwEeN9dMBWK Mj3UwwtD35TzBZIp196PDQcxR+q/r/NycgrLR4dnkvR4RW45w4YsROycNKbQ7Z9yKJCC pPi2tXzawJ4jcRbzbqGzEnNPhxUscW7RbqWwOFXcOXKl6j62CyIXkcl5NUVd7rYh3Vv7 0AYW+CQ/kGwoTHD0LnCYhKC4pu2HgP9gIM5JfQvL/LtkdAowEqTxembECjlVp9wFctsF u/awNNDrtBawuIugtL4UpjOkIWlA4+3EZFkxBqoCdQ4AloDw+1tYkLf1IxDtkdaMA7q4 hRQQ== X-Received: by 10.194.240.200 with SMTP id wc8mr9908389wjc.21.1444091357012; Mon, 05 Oct 2015 17:29:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.200 with HTTP; Mon, 5 Oct 2015 17:28:57 -0700 (PDT) In-Reply-To: <20151003143056.GA27942@muck> References: <20151003143056.GA27942@muck> From: Btc Drak Date: Tue, 6 Oct 2015 01:28:57 +0100 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=089e013d19e05ba616052164b84e X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change 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: Tue, 06 Oct 2015 00:29:18 -0000 --089e013d19e05ba616052164b84e Content-Type: text/plain; charset=UTF-8 Regarding the keeping nSequence for future expansion I believe this has been covered in the specification section of BIP68[1]: For transaction version >= 2, if the MSB of nSequence is unset, the field is interpreted as relative locktime, otherwise no special consensus meaning is attached (and thus free for repurposing in the future). Effectively if the MSB is set, the remaining 31 bits (out of 32) are free. Also please note the BIP112 text has been updated with several more usecases. --089e013d19e05ba616052164b84e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rega= rding the keeping nSequence for future expansion I believe this has been co= vered in the specification section of BIP68[1]: For transaction version >= ;=3D 2, if the MSB of nSequence is unset, the field is interpreted as relat= ive locktime, otherwise no special consensus meaning is attached (and thus = free for repurposing in the future). Effectively if the MSB is set, the rem= aining 31 bits (out of 32) are free.
Also please note the BIP112 text has bee= n updated with several more usecases.
--089e013d19e05ba616052164b84e--