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 6ACF79FB for ; Sun, 5 Jul 2015 16:17:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B76C61BF for ; Sun, 5 Jul 2015 16:17:20 +0000 (UTC) Received: by ieqy10 with SMTP id y10so100661232ieq.0 for ; Sun, 05 Jul 2015 09:17:20 -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:date :message-id:subject:from:to:cc:content-type; bh=Exb75tJq5y1xvvB5pafI7M2QiBsTRB0H8V+QBXsb8oo=; b=mPujDfPLhi0ftrV2o9L53rplpdX5MeGEVvAaaYVrx5gC7djQSG3Lbx2FXHl6wYuVDe rCSxz+YFrYpGwje7WKvPShUUaFs6t62fht3R2RACjqdbkSu35zsy7NJnr9qOnXXrncIA +lGud+FrroVTchQwoqz/lms9PqbiEVA9BdsY88PMR7BJkfLe0/E9dnRljiNlt9Gkh6He VCCh6gfqaFzuVfC5p3C3ceuAzC4OmzVSe7LMDvevNeGhyBpNXHIw0SkIeMuJkMZMGthg T/hG5OkoPzituQkljAU1nl+FJ+phwShzaYzu2WWQv6pmH2i2MfhIbfx1KJ6hSaaRfehE MLzQ== X-Gm-Message-State: ALoCoQlJJCJjpbqRVYOvZEPXZ0L4/B+v+psUxq2/WlgFrH2ZDxP5FTBo9Nw8ptZW0ICEj3i8VTyT MIME-Version: 1.0 X-Received: by 10.42.105.16 with SMTP id t16mr30201670ico.40.1436113039992; Sun, 05 Jul 2015 09:17:19 -0700 (PDT) Received: by 10.107.8.104 with HTTP; Sun, 5 Jul 2015 09:17:19 -0700 (PDT) X-Originating-IP: [172.56.16.163] Received: by 10.107.8.104 with HTTP; Sun, 5 Jul 2015 09:17:19 -0700 (PDT) In-Reply-To: <55994696.1090705@thinlink.com> References: <55994696.1090705@thinlink.com> Date: Sun, 5 Jul 2015 09:17:19 -0700 Message-ID: From: Mark Friedenbach To: Tom Harding Content-Type: multipart/alternative; boundary=20cf303f64ca9b42b3051a231f0b 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 16:17:21 -0000 --20cf303f64ca9b42b3051a231f0b Content-Type: text/plain; charset=UTF-8 Can you construct an example? Are there use cases where there is a need for an enforced lock time in a transaction with inputs that are not confirmed at the time the lock time expires? On Jul 5, 2015 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 > --20cf303f64ca9b42b3051a231f0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Can you construct an example? Are there use cases where ther= e is a need for an enforced lock time in a transaction with inputs that are= not confirmed at the time the lock time expires?

On Jul 5, 2015 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 =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
--20cf303f64ca9b42b3051a231f0b--