Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YpQwG-0007iY-05 for bitcoin-development@lists.sourceforge.net; Tue, 05 May 2015 00:42:20 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.176 as permitted sender) client-ip=209.85.212.176; envelope-from=btcdrak@gmail.com; helo=mail-wi0-f176.google.com; Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YpQwF-0003vV-3J for bitcoin-development@lists.sourceforge.net; Tue, 05 May 2015 00:42:19 +0000 Received: by wicmx19 with SMTP id mx19so88900515wic.1 for ; Mon, 04 May 2015 17:42:13 -0700 (PDT) X-Received: by 10.194.78.49 with SMTP id y17mr46900881wjw.131.1430786533088; Mon, 04 May 2015 17:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.136.196 with HTTP; Mon, 4 May 2015 17:41:52 -0700 (PDT) In-Reply-To: References: <20141001130826.GM28710@savin.petertodd.org> <55075795.20904@bluematt.me> <20150421075912.GA25282@savin.petertodd.org> <5546D653.4070404@bluematt.me> From: Btc Drak Date: Tue, 5 May 2015 01:41:52 +0100 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=047d7bfcf1de0de1ef05154af3c1 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HK_RANDOM_FROM From username looks random -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (btcdrak[at]gmail.com) -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: 1YpQwF-0003vV-3J Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) 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: Tue, 05 May 2015 00:42:20 -0000 --047d7bfcf1de0de1ef05154af3c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 4, 2015 at 12:24 PM, Jorge Tim=C3=B3n wrote: > What I was describing was an attempt to fix a similar proposal by Mark > Friedenbach, but it didn't needed fixing: I was simply > misunderstanding it. > Mark's RCLTV is completely reorg safe, so there's no need for the 100 > block restriction. It also keeps the script validation independent > from the utxo. > Here's is how it works: > > The operator takes a relative_height parameter and it checks that the > nSequence of the input is lower than that parameter. > > Additionally, a new check at the transaction level: > > for (unsigned int i =3D 0; i < tx.vin.size(); i++) { > // ... > if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight) > return state.Invalid(false, REJECT_INVALID, > "bad-txns-non-final-input"); > // ... > } > > Well, this is assuming that we're only using it with heights and not > timestamps. > Mark, feel free to elaborate further. Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For absolute CLTV I think it's important to have timestamps so that trust fund use cases are practical (e.g. spendable on 18th birthday), because the exact date a future block will be mined on is unpredictable if it's far enough in the future (out by days or even weeks). --047d7bfcf1de0de1ef05154af3c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 4, 2015 at 12:24 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
What I was describing was an a= ttempt to fix a similar proposal by Mark
Friedenbach, but it didn't needed fixing: I was simply
misunderstanding it.
Mark's RCLTV is completely reorg safe, so there's no need for the 1= 00
block restriction. It also keeps the script validation independent
from the utxo.
Here's is how it works:

The operator takes a relative_height parameter and it checks that the
nSequence of the input is lower than that parameter.

Additionally, a new check at the transaction level:

for (unsigned int i =3D 0; i < tx.vin.size(); i++) {
// ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (coins->nHeight + tx= .vin[i].nSequence < nSpendHeight)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return state.Invali= d(false, REJECT_INVALID,
"bad-txns-non-final-input");
// ...
}

Well, this is assuming that we're only using it with heights and not ti= mestamps.
Mark, feel free to elaborate further.

Does = dropping timestamp refer just to RCLTV or absolutely CLTV also? For absolut= e CLTV I think it's important to have timestamps so that trust fund use= cases are practical (e.g. spendable on 18th birthday), because the exact d= ate a future block will be mined on is unpredictable if it's far enough= in the future (out by days or even weeks).

<= /div>
--047d7bfcf1de0de1ef05154af3c1--