From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xu8SX-00085V-26 for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 23:26:49 +0000 X-ACL-Warn: Received: from mail-ig0-f174.google.com ([209.85.213.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xu8SV-00009a-VO for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 23:26:49 +0000 Received: by mail-ig0-f174.google.com with SMTP id hn15so9115433igb.13 for ; Thu, 27 Nov 2014 15:26:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=Yk62AbEIHiOJq8nKWa7Vt4O/D8O7QlG+TE0trN++d5M=; b=m/JCmm5kLqZv4FCgRd169wQSQdOY2iscPwdruhpXJIY2g1BCCZJISeKW1bolNWjSnq v3hs3grV12L/ZewYSE8Dtl4O0mmigrZTwV69gEq3qQmSvlbZC0Fkvkp+1IXuSB5tvbDy 11Li2fR3igjK86altOKdiyP6gppc7+1BoOQn09XCQMYS2xf0YLvWKMHR2uJnGMKg2nYQ ArLmtZLg98ox8SlE74TOaaRtjCbAYgPSdI91SlGlmZe3NLQwmR40e+kUr2Evqs5wFnIg pvb5vI9QDHyMQqyM/Bsvpjc11S/VuarXkWxDpmRSJLCKGoMSpeeM3mGpId5vhi7XW5gr 25PQ== X-Gm-Message-State: ALoCoQkB3YEnNJyHu0P8YWYBshzkdxmWlnYqT18xai08pDDKkb0sY767N7o38ZlGkKxkfTgbf5Iy X-Received: by 10.42.94.14 with SMTP id z14mr21023817icm.35.1417129017585; Thu, 27 Nov 2014 14:56:57 -0800 (PST) Received: from [192.168.2.25] (135-23-143-85.cpe.pppoe.ca. [135.23.143.85]) by mx.google.com with ESMTPSA id y2sm4754561igl.8.2014.11.27.14.56.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Nov 2014 14:56:56 -0800 (PST) From: Richard Moore Content-Type: multipart/alternative; boundary="Apple-Mail=_F76000C2-1309-4CAB-B5DB-DF5DF1BEA39F" Message-Id: <63C13C3D-5333-4DEA-A42F-A4685DDE09DA@ricmoo.com> Date: Thu, 27 Nov 2014 17:56:54 -0500 To: Bitcoin Dev Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Xu8SV-00009a-VO Subject: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 23:26:49 -0000 --Apple-Mail=_F76000C2-1309-4CAB-B5DB-DF5DF1BEA39F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Heya, I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and = thought it might make more sense to instead have a OP_CHECKLOCKTIME = which would simply push an OP_TRUE or OP_FALSE onto the stack? That way someone could include multiple OP_CHECKLOCKTIME conditions in a = single script. It is trivial to always emulate OP_CHECKLOCKTIMEVERIFY by = using a OP_CHECKLOCKTIME OP_VERIFY sequence. As a second question, would it possibly make more sense to, rather than = relying on the nLockTime in a transaction, allow an opcode that would = use similar semantics, but against an item in the stack? Then you could = essentially include multiple nLockTimes in a single script and make = arbitrarily interesting (complicated?) scripts based on block height = and/or block timestamp. The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY Just something that came to mind while reading about = OP_CHECKLOCKTIMEVERIFY. Thanks, RicMoo = .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2= =B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8= =C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes.com www: http://GeneticMistakes.com --Apple-Mail=_F76000C2-1309-4CAB-B5DB-DF5DF1BEA39F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Heya,

I was wondering about BIP 65 regarding = the OP_CHECKLOCKTIMEVERIFY, and thought it might make more sense to = instead have a OP_CHECKLOCKTIME which would simply push an OP_TRUE or = OP_FALSE onto the stack?

That way someone could include multiple OP_CHECKLOCKTIME = conditions in a single script. It is trivial to always emulate = OP_CHECKLOCKTIMEVERIFY by using a OP_CHECKLOCKTIME OP_VERIFY = sequence.


As a second question, would it possibly = make more sense to, rather than relying on the nLockTime in a = transaction, allow an opcode that would use similar semantics, but = against an item in the stack? Then you could essentially include = multiple nLockTimes in a single script and make arbitrarily interesting = (complicated?) scripts based on block height and/or block = timestamp.

The = OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by = using

nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY


Just something that came to mind while reading about = OP_CHECKLOCKTIMEVERIFY.

Thanks,

RicMoo

.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2= =B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7= .=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA>

Richard Moore ~ Founder
Genetic = Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com

= --Apple-Mail=_F76000C2-1309-4CAB-B5DB-DF5DF1BEA39F--