Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E38E2FF for ; Mon, 24 Aug 2015 02:54:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 292221F2 for ; Mon, 24 Aug 2015 02:54:35 +0000 (UTC) Received: by igfj19 with SMTP id j19so51928277igf.0 for ; Sun, 23 Aug 2015 19:54:34 -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=wfay3smOtbm1FU0NFECH22E6ItjXmsfQQZHmmriXR0Q=; b=azRMi5KNLPJ5Sjk4xR45OitR3oaDg74kbu4SKDLdzXxkyRTX/XVqTyxOREfipXynrV ifX6T39SCPQqE8C21rGn1gk508BH4crUS9eMgvIoNtVyZigH4HsYERe70+8tTYtRrIWK 9cf8n5TbaqlsR8VF4y0I2N8lpG5GwErbYVkrthP8xLP+nSrkzdZONJQsm0WVxxLBK7jw N8qOf+LHrRcZoCnFP4b5p0lZH2sxExVmlMa9RRHYTM24qYB98m/q/yCu/lOu7cLI3QVm VA9Dblun+fN9vGoon6VBEhXLzSqOQ+Yfbet4i1kHYGzcvGKv8qKmeE4dqdoepfq0YV3S boGw== X-Gm-Message-State: ALoCoQkN6PXQhH0souFKyf60OcDhB1TzoKa6kX8Jhml4aQXLz2FLfbqkadPhMlauTs0iCvW//3Kx MIME-Version: 1.0 X-Received: by 10.50.129.5 with SMTP id ns5mr12798647igb.40.1440384874667; Sun, 23 Aug 2015 19:54:34 -0700 (PDT) Received: by 10.107.138.14 with HTTP; Sun, 23 Aug 2015 19:54:34 -0700 (PDT) X-Originating-IP: [172.56.30.71] Received: by 10.107.138.14 with HTTP; Sun, 23 Aug 2015 19:54:34 -0700 (PDT) In-Reply-To: <85537faedb1e601d243e3edb666fa844@xbt.hk> References: <55DA6470.9040301@thinlink.com> <85537faedb1e601d243e3edb666fa844@xbt.hk> Date: Sun, 23 Aug 2015 19:54:34 -0700 Message-ID: From: Mark Friedenbach To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=047d7b3a9914cb77bd051e05bcfd 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 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 02:54:36 -0000 --047d7b3a9914cb77bd051e05bcfd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry this was meant for the list: There are only 32 bits in the version field. If you're going to spend a bit for perpetuity to indicate whether or not a feature is active, you'd better have a good reason to make that feature optional. I haven't seen a compelling use case for having BIP 68 be optional in that way. As you note, BIP 68 semantics is already optional by toggling the most significant bit, and that doesn't permanently burn a version bit. On Aug 23, 2015 7:41 PM, "jl2012 via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Gregory Maxwell via bitcoin-dev =E6=96=BC 2015-08-23 21:01 =E5=AF=AB=E5= =88=B0: > > >> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the >> discussion has any thought been given to represent one block with more >> than one increment? This would leave additional space for future >> signaling, or allow, for example, higher resolution numbers for a >> sharechain commitement. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > I think this comment is more related to BIP68 instead of OP_CSV? Without > further complicating the BIP68, I believe the best way to leave room for > improvement is to spend a bit in tx nVersion to indicate the activation o= f > BIP68. I have raised this issue before with > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010043= .html > However, it seems Mark isn't in favor of my proposal > > The idea is not to permanently change the meaning of nSequence. Actually, > BIP68 is "only enforced if the most significant bit of the sequence numbe= r > field is set." So BIP68 is optional, anyway. All I suggest is to move the > flag from nSequence to nVersion. However, this will leave much bigger roo= m > for using nSequence for other purpose in the future. > > AFAIK, nSequence is the only user definable and signed element in TxIn. > There could be more interesting use of this field and we should not chang= e > its meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 byte= s, > it could be used to indicate the value of the input to fix this problem: > https://bitcointalk.org/index.php?topic=3D181734.0 ) > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --047d7b3a9914cb77bd051e05bcfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry this was meant for the list:

There are only 32 bits in the version field. If you're g= oing to spend a bit for perpetuity to indicate whether or not a feature is = active, you'd better have a good reason to make that feature optional.<= /p>

I haven't seen a compelling use case for having BIP 68 b= e optional in that way. As you note, BIP 68 semantics is already optional b= y toggling the most significant bit, and that doesn't permanently burn = a version bit.

On Aug 23, 2015 7:41 PM, "jl2012 via bitcoi= n-dev" <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
=
Gregory Maxwell via bitcoin-dev =E6=96=BC 20= 15-08-23 21:01 =E5=AF=AB=E5=88=B0:


Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
discussion has any thought been given to represent one block with more
than one increment?=C2=A0 This would leave additional space for future
signaling, or allow, for example, higher resolution numbers for a
sharechain commitement.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

I think this comment is more related to BIP68 instead of OP_CSV? Without fu= rther complicating the BIP68, I believe the best way to leave room for impr= ovement is to spend a bit in tx nVersion to indicate the activation of BIP6= 8. I have raised this issue before with http://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= 15-August/010043.html However, it seems Mark isn't in favor of my p= roposal

The idea is not to permanently change the meaning of nSequence. Actually, B= IP68 is "only enforced if the most significant bit of the sequence num= ber field is set." So BIP68 is optional, anyway. All I suggest is to m= ove the flag from nSequence to nVersion. However, this will leave much bigg= er room for using nSequence for other purpose in the future.

AFAIK, nSequence is the only user definable and signed element in TxIn. The= re could be more interesting use of this field and we should not change its= meaning permanently. (e.g. if nSequence had 8 bytes instead of 4 bytes, it= could be used to indicate the value of the input to fix this problem: https://bitcointalk.org/index.php?topic=3D181734.0= )

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--047d7b3a9914cb77bd051e05bcfd--