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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YpEUV-0004ca-Ov for bitcoin-development@lists.sourceforge.net; Mon, 04 May 2015 11:24:51 +0000 Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YpEUU-0001Xn-K5 for bitcoin-development@lists.sourceforge.net; Mon, 04 May 2015 11:24:51 +0000 Received: by wgso17 with SMTP id o17so146823218wgs.1 for ; Mon, 04 May 2015 04:24:44 -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=mStEpuqVG/pzlrApd4S/qgwa4RH57iKHeNRgeFg2i/4=; b=GwCn1U8H7dvuJW5Yykny4c3ukZoZMWVeODkgh4Ijjs5q1o3amoYYEKqg4NZhtSiiIr hvuQDZrB+RCVOhjwkKpzvtkvORYGUnDTgkKiFpEHoB/KwZ5d2sldMh+gHP1oUmSaXbRV +kVWGSUKJCiNy74hfS8p3w1vQ1687Kvnxvs3qtDT1zNJ63Cst2hyCDwJmhun9QyYyKua jv1vpojTBDWvWc60ZDjZoA7O114x+CIZyu4B2nrCi873c3R4IMtY58cPDaKPjPpu/XzB vv9S/uViH60kVjFzhZ5eHuJy40k7OjAd1KIj5xjmUp102iFjaqSQS2Hmd6n5HdF0mrbw PJNQ== X-Gm-Message-State: ALoCoQlxyvkqH3IIT1/uGJn5qEh5RddEV7eRYXPmqUlsXUppV1qT80lqrvzEb+DkqAJc2xfF57Jp MIME-Version: 1.0 X-Received: by 10.194.92.137 with SMTP id cm9mr41404948wjb.133.1430738684419; Mon, 04 May 2015 04:24:44 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Mon, 4 May 2015 04:24:44 -0700 (PDT) In-Reply-To: <5546D653.4070404@bluematt.me> References: <20141001130826.GM28710@savin.petertodd.org> <55075795.20904@bluematt.me> <20150421075912.GA25282@savin.petertodd.org> <5546D653.4070404@bluematt.me> Date: Mon, 4 May 2015 13:24:44 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Matt Corallo Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.2 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YpEUU-0001Xn-K5 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: Mon, 04 May 2015 11:24:51 -0000 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 = 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.