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 C64889C for ; Mon, 24 Aug 2015 00:25:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7125D112 for ; Mon, 24 Aug 2015 00:25:18 +0000 (UTC) Received: by pacti10 with SMTP id ti10so9815290pac.0 for ; Sun, 23 Aug 2015 17:25:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=4wxou3BdMb24FdjaVET97vWuW5UJNxd406bPlRh3D8Q=; b=bTrCSDsqjhSmSxwTsZhEkLF8p7gh9OzVGi2ZBME5fOWBbffVARb9AaYVavxkISf8Pr d3F5qqQEB+dAx1XHFO2O+Xf6CDPcrcEksdVJ4ZpcyQE+wS30vRyb1PEXWt/J6PzD3bUv CGJfCz6c4hJePnaJqt8AohVDI/S44ogw/Rk97a8gl06+nOfJ8uyL+7Nl297+hTuNNoy7 VnoIYzpLE5ajhnaS6rEl37bXASnG3hb41ULgWpiNKLbmcgZRHbwzAd5V+Toh+CihCh9+ /Lq6fzT0rAz6dW9KSvCmmIoh+wo+KWmNan02cVYPudKn0FN5hF5if3Z4dbk89xgcd031 RoLg== X-Gm-Message-State: ALoCoQnvPdi3hRUk4LTTAe9ONr7yNSfp6H1OikLV4vMjV0CGfqn4BhE3g7tRwhCXtt8dQPPGlENh X-Received: by 10.68.68.233 with SMTP id z9mr39680263pbt.140.1440375918139; Sun, 23 Aug 2015 17:25:18 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id nj9sm15122526pdb.77.2015.08.23.17.25.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Aug 2015 17:25:16 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Tom Harding Message-ID: <55DA6470.9040301@thinlink.com> Date: Sun, 23 Aug 2015 17:25:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010801010703040004020303" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,UC_GIBBERISH_OBFU autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime 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: Mon, 24 Aug 2015 00:25:18 -0000 This is a multi-part message in MIME format. --------------010801010703040004020303 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote: > I am indifferent on this issue (the bit inversion), but so far only > Jorge has spoken up. I opted for this detail during implementation in > order to preserve existing semantics, even if those semantics are not > commonly used. This was the conservative choice, driven in part > because I didn't want the proposal to be held up by the other side > saying "this is confusing because it changes how sequence numbers > work! it used to count up but now it counts down!" > > I can see both sides and as I said I'm indifferent, so I went with the > conservative choice of not messing with existing semantics. However if > there is strong preferences from _multiple_ people on this matter it > is not too late to change. If anyone feels strongly about this, please > speak up. > > On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón > > wrote: > > I repeated my nit on https://github.com/bitcoin/bips/pull/179 > > > On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev > > wrote: > > Please note there is now a PR for this BIP[1] and also a pull > request for > > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. > > > > [1] https://github.com/bitcoin/bips/pull/179 > > [2] https://github.com/bitcoin/bitcoin/pull/6564 > --------------010801010703040004020303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit ack no inversion. This can actually allow more direct preservation of existing semantics.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html


On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote:
I am indifferent on this issue (the bit inversion), but so far only Jorge has spoken up. I opted for this detail during implementation in order to preserve existing semantics, even if those semantics are not commonly used. This was the conservative choice, driven in part because I didn't want the proposal to be held up by the other side saying "this is confusing because it changes how sequence numbers work! it used to count up but now it counts down!"

I can see both sides and as I said I'm indifferent, so I went with the conservative choice of not messing with existing semantics. However if there is strong preferences from _multiple_ people on this matter it is not too late to change. If anyone feels strongly about this, please speak up.

On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón <bitcoin-dev@lists.linuxfoundation.org> wrote:
I repeated my nit on https://github.com/bitcoin/bips/pull/179


On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Please note there is now a PR for this BIP[1] and also a pull request for
> the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
>
> [1] https://github.com/bitcoin/bips/pull/179
> [2] https://github.com/bitcoin/bitcoin/pull/6564

--------------010801010703040004020303--