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 A63A886 for ; Tue, 24 Nov 2015 05:05:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0120126 for ; Tue, 24 Nov 2015 05:05:52 +0000 (UTC) Received: by wmuu63 with SMTP id u63so80743228wmu.0 for ; Mon, 23 Nov 2015 21:05:51 -0800 (PST) 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=C5edk59HJ5NXtL6I+G9BWrfOPGMGMolzzW++285HUBI=; b=PzYKWEvPI1VZyVYySVCl/uBfPIfkqtCRAl5kCasCbu8vTV9R44X6ZehiSOJhRK/WQ+ Gt7/vcgObfQbLo0w9dumOUHw+ZgSq6Axjtfrtk+unfQ0j+UJZaKMFEHUkjrg4bYxeSiw XV/DM+/3/DF0fQIDhaRatfvE615ZzTRpiC7Uk8Q7+4MIrQ/EYc4Bd/h52Hq/0D18PCcN 9NdouaXdIqCJ1r09busE0WIlPnyOBKDGt5UQsSlBMkXT97bVEFAj0bLBofM7Pzif2w+w lulHCoSdO3dUzqdx6Bg6lT+9PfxlcYGC4sF1E10X8WrlYA4lsFNpvaFDmk/fW8dXsd6q FZjA== X-Received: by 10.28.23.136 with SMTP id 130mr21708269wmx.94.1448341551644; Mon, 23 Nov 2015 21:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.61.135 with HTTP; Mon, 23 Nov 2015 21:05:32 -0800 (PST) In-Reply-To: <20151124043618.GA7999@muck> References: <20151124043618.GA7999@muck> From: Btc Drak Date: Tue, 24 Nov 2015 05:05:32 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=001a114700d0b304f50525424b38 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, 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 Subject: Re: [bitcoin-dev] BIP68: Second-level granularity doesn't make sense 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, 24 Nov 2015 05:05:53 -0000 --001a114700d0b304f50525424b38 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The downside of BIP68 as written is users of by-height locktimes have 14 > bits unused in nSequence, but by-time locktimes have just 5 bits unused. > This presents an awkward situation if we add new meanings to nSequence > if we ever need more than 5 bits. Yet as shown above, the extra > granularity doesn't have a practical benefit. > > > Recommendation: Change BIP68 to make by-time locks have the same number > of bits as by-height locks, and multiply the by-time lock field by the > block interval. > I think you might be referring to the old specification. I believe this was brought up before and the specification was changed so the same number of bits were used for by-time and by-height. Please see https://github.com/bitcoin/bips/pull/245 However, I am glad you came to the came conclusions independently because "re-invention" often confirms good ideas :) --001a114700d0b304f50525424b38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
The downside of BIP68 as written is users of by-height locktimes ha= ve 14
bits unused in nSequence, but by-time locktimes have just 5 bits unused. This presents an awkward situation if we add new meanings to nSequence
if we ever need more than 5 bits. Yet as shown above, the extra
granularity doesn't have a practical benefit.


Recommendation: Change BIP68 to make by-time locks have the same number
of bits as by-height locks, and multiply the by-time lock field by the
block interval.

I think you might be re= ferring to the old specification. I believe this was brought up before and = the specification was changed so the same number of bits were used for by-t= ime and by-height. Please see=C2=A0https://github.com/bitcoin/bips/pull/245=C2=A0
<= br>
However, I am glad you came to the came conclusions independe= ntly because "re-invention" often confirms good ideas :)




--001a114700d0b304f50525424b38--