Return-Path: <tomh@thinlink.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F08BA04 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 5 Jul 2015 16:25:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C3421CE for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 5 Jul 2015 16:25:17 +0000 (UTC) Received: by pactm7 with SMTP id tm7so82245622pac.2 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 05 Jul 2015 09:25:16 -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=2Qs9+6CMn+U4iJqs/FpC4MVhyfl7AH43Z7Yb+qt9ugo=; b=Zc1Mc/DxplfDDlEtr5zv8EpvjpStc5RppVxA62qB3wmemE0ThnLgk5lFzwOKXlT6by 5tPmHHxiX4ao4LeGbWHi5DQ0oMplzoaJuKEgqad2+4ZcnNhQ6CU8BkklE20AhOJlwY7W 7Zdnz+Lr4l+hZ1IgRS/r55ywGi7cnZScyl3r3l/iXRbm2HGWMrrjkQWZIdUtBx5+x3+w 42jqxsIiAT/BgHZX6pqXX1wN4mX6Qesc9raaseHxKmxVhzh0b+a1ZVISuHNklSmDH+KH Gc9tzcGp43YWlkJbaI4RF3PejTl6WDfCPrfg7sEZc6rjFnPyN+N5LKpu+nCwxHX6wgkd VLlw== X-Gm-Message-State: ALoCoQk5op6aDpg+9KQ6p54a3ehEzMx9GxLYercGkTtNF2zJZZDOMPJY9BYMXUUqaPR7Z3TltzoS X-Received: by 10.66.229.65 with SMTP id so1mr96386681pac.92.1436113516650; Sun, 05 Jul 2015 09:25:16 -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 ml6sm15325306pdb.69.2015.07.05.09.25.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 09:25:14 -0700 (PDT) Message-ID: <55995A6D.8090703@thinlink.com> Date: Sun, 05 Jul 2015 09:25:17 -0700 From: Tom Harding <tomh@thinlink.com> 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 <mark@friedenbach.org> References: <55994696.1090705@thinlink.com> <CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com> In-Reply-To: <CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------020504080806030408030003" 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sun, 05 Jul 2015 16:25:17 -0000 This is a multi-part message in MIME format. --------------020504080806030408030003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Since you're removing a working capability, you should be the one to prove it is unneeded. But the simple example is the case where the input is also locked. On 7/5/2015 9:17 AM, Mark Friedenbach wrote: > > 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" <tomh@thinlink.com > <mailto: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 > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --------------020504080806030408030003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Since you're removing a working capability, you should be the one to prove it is unneeded.<br> <br> But the simple example is the case where the input is also locked.<br> <br> <br> <div class="moz-cite-prefix">On 7/5/2015 9:17 AM, Mark Friedenbach wrote:<br> </div> <blockquote cite="mid:CAOG=w-sgM+H0bGBfZxLhbUHF3y=v4vdBAOTDsZ1LEc3dLzsf6g@mail.gmail.com" type="cite"> <p dir="ltr">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?</p> <div class="gmail_quote">On Jul 5, 2015 8:00 AM, "Tom Harding" <<a moz-do-not-send="true" href="mailto:tomh@thinlink.com">tomh@thinlink.com</a>> wrote:<br type="attribution"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BIP 68 uses nSequence to specify relative locktime, but nSequence also<br> continues to condition the transaction-level locktime.<br> <br> This dual effect will prevent a transaction from having an effective<br> nLocktime without also requiring at least one of its inputs to be mined<br> at least one block (or one second) ahead of its parent.<br> <br> The fix is to shift the semantics so that nSequence = MAX_INT - 1<br> specifies 0 relative locktime, rather than 1. This change will also<br> preserve the semantics of transactions that have already been created<br> with the specific nSequence value MAX_INT - 1 (for example all<br> transactions created by the bitcoin core wallet starting in 0.11).<br> <br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a moz-do-not-send="true" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br> <a moz-do-not-send="true" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> </blockquote> </div> </blockquote> <br> </body> </html> --------------020504080806030408030003--