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 027A7982 for ; Sun, 5 Jul 2015 17:07:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD3C21F9 for ; Sun, 5 Jul 2015 17:07:32 +0000 (UTC) Received: by igblr2 with SMTP id lr2so100710767igb.0 for ; Sun, 05 Jul 2015 10:07:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z18ucu+0gz83yGwlY5Nzd/ruc4way8HX9Mo7xwiaCp4=; b=CgQykLJc+e3gKtm5XBCGy4ug7qJTcxf0nIiUhMTyPcCBIehmgMhGsoFIfSG+QytkQx TxEmrM1iXBTOsybVZC1y2Qo35D2bgkIJelSBAcTZwO1yIiAXxI74BAxH5k+JikdcvcIt 2VLZfMnwpNRsY8QM4QFlAZeouJng6ws0LdRJdtNDgAGMXvO/J8ZXjRPJv2yjZ2tPfZXv 5C9J4sPl0N0JwuDqjrv+mHtNqsvRMxY1OQ/wJCzmC1XNd+fAbl7u7zBNXgkmeYr3uvtg n3HSZ29U7YGJwKAoSiGfhzyWv3IZyLa2Nkq9TE/CZPK/qFrzU6n60jST9KlHzOMnRckq L9UQ== X-Gm-Message-State: ALoCoQlAEZOLzdvE0mKV+r7+VRg+ULE7V/x18+4A1YrHvCDcnumBSFm0B8xFgL/XgqSXhdgUSZli X-Received: by 10.42.105.16 with SMTP id t16mr30392189ico.40.1436116052208; Sun, 05 Jul 2015 10:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.104 with HTTP; Sun, 5 Jul 2015 10:07:12 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: <55994696.1090705@thinlink.com> References: <55994696.1090705@thinlink.com> From: Mark Friedenbach Date: Sun, 5 Jul 2015 10:07:12 -0700 Message-ID: To: Tom Harding Content-Type: multipart/alternative; boundary=20cf303f64ca2603ac051a23d37d 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 17:07:34 -0000 --20cf303f64ca2603ac051a23d37d Content-Type: text/plain; charset=UTF-8 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 > --20cf303f64ca2603ac051a23d37d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note that you can put 0 in the sequence number field and i= t would work just as expected under the old rules. I will perhaps suggest i= nstead that Bitcoin Core post-0.11 switch to doing this instead for that ca= se.

On S= un, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh@thinlink.com> = wrote:
BIP 68 uses nSequence to specify r= elative 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 =3D MAX_INT - 1
specifies 0 relative locktime, rather than 1.=C2=A0 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/mail= man/listinfo/bitcoin-dev

--20cf303f64ca2603ac051a23d37d--