Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E876C273 for ; Fri, 27 Nov 2015 08:10:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 426B3115 for ; Fri, 27 Nov 2015 08:10:54 +0000 (UTC) Received: by padhx2 with SMTP id hx2so108303725pad.1 for ; Fri, 27 Nov 2015 00:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=kNF3mQnSaBbca8wuRBqdntE4DHsbzMWvnuPVYBxcWSI=; b=uBh4CQfGCQBMX7FAGDwDEwFS3ZwyeU85CuES9aUqa6ohzid8rYIN1CwHi/9eGwKzsp KpQQD9/bnjapwQ5YLZrw7I/MYembWcAZeGam++SH2ORXo6ADdNhubtWqMKpLyiwcg3CT 9xWBVZUMBdUseF/LoUixvLHD35j2X6MvfNrjWj/NrkOHovpb+C1+Nv+d6ox5KIZyBxRj lQDBXAiXqMrCffugVXt5mvX2v3AOxPI23pRZXL0zwi8ZUTVYc9VxaTV431Xsm+CdQU89 o6HnqXSJwKh8dezjTuZV/QO9TiJgPLQK4kzmmtiGrZ1vYOquHVdsWBS+QQnLAxdgwao2 8pEQ== X-Received: by 10.66.150.165 with SMTP id uj5mr65856616pab.23.1448611853699; Fri, 27 Nov 2015 00:10:53 -0800 (PST) Received: from [192.168.1.19] (ip72-207-65-162.sd.sd.cox.net. [72.207.65.162]) by smtp.gmail.com with ESMTPSA id 79sm32106794pfb.67.2015.11.27.00.10.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Nov 2015 00:10:53 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <87ziy0qeca.fsf@rustcorp.com.au> References: <87ziy0qeca.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL" Content-Transfer-Encoding: 8bit From: Eric Lombrozo Date: Fri, 27 Nov 2015 00:10:49 -0800 To: Rusty Russell , Mark Friedenbach , Btc Drak Message-ID: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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] Alternative name for CHECKSEQUENCEVERIFY (BIP112) 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: Fri, 27 Nov 2015 08:10:55 -0000 ------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense. It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin. HOWEVER...there might be ways around this issue using segwit. I've been pondering the possibility of adding an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash. Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well. I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications. Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed. This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to. If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits. I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet. - Eric On November 26, 2015 8:02:45 PM PST, Rusty Russell wrote: >Eric Lombrozo via bitcoin-dev >writes: >>>From an app developer's perspective, I think it is pretty blatantly >> clear that relative timelock is *the* critical exposed functionality >> intended here. > >As someone who actually developed scripts using CSV, I agree with Mark >(and Matt). The relative locktime stuff isn't in this opcode, it's in >the nSequence calculation. > >So, I vote to keep CSV called as it is. > >Thanks, >Rusty. ------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense.

It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin.

HOWEVER...there might be ways around this issue using segwit.

I've been pondering the possibility of adding an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash.

Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well.

I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications.

Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed.

This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to.

If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits.

I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet.

- Eric



On November 26, 2015 8:02:45 PM PST, Rusty Russell <rusty@rustcorp.com.au> wrote:
Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
From an app developer's perspective, I think it is pretty blatantly
clear that relative timelock is *the* critical exposed functionality
intended here.

As someone who actually developed scripts using CSV, I agree with Mark
(and Matt). The relative locktime stuff isn't in this opcode, it's in
the nSequence calculation.

So, I vote to keep CSV called as it is.

Thanks,
Rusty.
------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL--