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 72095901 for ; Wed, 25 Nov 2015 01:15:19 +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 E8ED0149 for ; Wed, 25 Nov 2015 01:15:18 +0000 (UTC) Received: by padhx2 with SMTP id hx2so39247796pad.1 for ; Tue, 24 Nov 2015 17:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-type; bh=N9XqxPKPC4S9ab8pdXjYKjNgZoieVSPHhE94SUIvyTs=; b=E4OiyOi1Uq6NA8AAfZvbgwbErZJxZSp/TOwOeT2HnP8Juhdf4IBdnJ6Lu4cduy11G3 384igB1nBR6Ok9BoGgscxM+9RkgQ/uKay0ldF6ZwqTF0fT6f3pLfKlm1wOa2o8pJCKFZ 9mc8BBzDxawlupv9ZNoQrfUZH89UgVjxivaya6m+SxPH3vEOY4WmjfCAGjukwnzxwXIN raZDMArc9+NGm5d+gtcZuq/2LJW8CdYYzxM3EBiHEr+d6uD27VLFdcj+xHc0PNm8hLvq yxEN0TLXby6d8AeWU/PUlvS3zT1v+y28Yoam+fJ+yGIP5Rb6sdAter3LKHm0Oxr8+lmF 0Gcw== X-Received: by 10.98.70.141 with SMTP id o13mr27723188pfi.44.1448414118658; Tue, 24 Nov 2015 17:15:18 -0800 (PST) Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id 186sm16760534pfa.24.2015.11.24.17.15.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Nov 2015 17:15:18 -0800 (PST) From: "Eric Lombrozo" To: =?utf-8?q?Jorge=20Tim=c3=b3n?= , "Btc Drak" Date: Wed, 25 Nov 2015 01:14:55 +0000 Message-Id: In-Reply-To: Reply-To: "Eric Lombrozo" User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF" 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 X-Mailman-Approved-At: Wed, 25 Nov 2015 01:23:53 +0000 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: Wed, 25 Nov 2015 01:15:19 -0000 --------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable >From a system developer standpoint, CHECKMATURITYVERIFY ties together=20 the semantics of this opcode with another existing feature in the system= =20 (coinbase maturity). HOWEVER... from an application developer standpoint, I think the concept of a=20 timelock is more relevant. Maturity is a concept that was introduced for= =20 the sake of reducing the disruptive impact of reorgs. Miners would=20 prefer to be able to spend the coins immediately, but instead they are=20 forced to wait due to inherent limitations of the system. Timelocks, on=20 the other hand, are typically used to control when funds can be moved.=20 In these use cases, one or more of the parties involved explicitly want=20 there to be a delay even if there were an idealized situation in which=20 consensus is always reached instantaneously and there were never any=20 reorgs. Moreover, since we already have CLTV, adding RCLTV or some variant=20 thereof makes the relationship between the two more explicit. So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY. As for whether to explicitly use CHECK_..._VERIFY, consider that with=20 segregated witness it will be possible to add opcodes that can push=20 values onto the stack (rather than just hard failing or NOP), so there's= =20 something to be said for naming consistency. - Eric ------ Original Message ------ From: "Jorge Tim=C3=B3n" To: "Btc Drak" Cc: "Bitcoin Dev" Sent: 11/24/2015 4:31:55 AM Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY=20 (BIP112) >I agree, I believe the first name that an op with equivalent=20 >functionality had was simply op_maturity. >At least I remember we discussed such an opcode when discussing pegged=20 >sidechains' design. > >I kind of dislike the check_x_verify naming pattern. We want all new=20 >operands to return if whatever they're checking/verifying fails, fine.=20 >Do we have to repeat this redundant naming pattern forever due to that=20 >discovery? >I hope not, but if that's the case my vote is for CMV. >As said before, I believe the documentation and code comments can=20 >become much more clear with this change. > --------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From a system developer standpoint, CHECKMATURITYVERIFY ties together= the semantics of this opcode with another existing feature in the system= (coinbase maturity).
 
HOWEVER...
 
from an application developer standpoint, I think the concept of a = timelock is more relevant. Maturity is a concept that was introduced for= the sake of reducing the disruptive impact of reorgs. Miners would prefer= to be able to spend the coins immediately, but instead they are forced = to wait due to inherent limitations of the system. Timelocks, on the other= hand, are typically used to control when funds can be moved. In these use= cases, one or more of the parties involved explicitly want there to be = a delay even if there were an idealized situation in which consensus is = always reached instantaneously and there were never any reorgs.
 
Moreover, since we already have CLTV, adding RCLTV or some variant = thereof makes the relationship between the two more explicit.
 
So my vote goes to RCLTV or RCHECKLOCKTIMEVERIFY.
 
As for whether to explicitly use CHECK_..._VERIFY, consider that with= segregated witness it will be possible to add opcodes that can push values= onto the stack (rather than just hard failing or NOP), so there's somethin= g to be said for naming consistency.
 
- Eric
 
 
 
------ Original Message ------
From: "Jorge Tim=C3=B3n" <bitcoin-dev@lists.linuxfoundation.org>
To: "Btc Drak" <btcdrak@gmail.= com>
Sent: 11/24/2015 4:31:55 AM
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY= (BIP112)
 

I agree, I believe the first name that an op with equivalent= functionality had was simply op_maturity.
At least I remember we discus= sed such an opcode when discussing pegged sidechains' design.

I kind of dislike the check_x_verify naming pattern. We want= all new operands to return if whatever they're checking/verifying fails,= fine. Do we have to repeat this redundant naming pattern forever due to= that discovery?
I hope not, but if that's the case my vote is for CMV.<= BR>As said before, I believe the documentation and code comments can become= much more clear with this change.

--------=_MB2CC52C3C-758E-4813-8CEA-D5AEF5558DBF--