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 1XZLqn-0003xF-Cg for bitcoin-development@lists.sourceforge.net; Wed, 01 Oct 2014 15:29:57 +0000 X-ACL-Warn: Received: from p3plsmtpa07-05.prod.phx3.secureserver.net ([173.201.192.234]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XZLqm-00037f-4l for bitcoin-development@lists.sourceforge.net; Wed, 01 Oct 2014 15:29:57 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa07-05.prod.phx3.secureserver.net with id xrVo1o00G2nUpUh01rVpxY; Wed, 01 Oct 2014 08:29:50 -0700 Message-ID: <542C1DEC.8010007@certimix.com> Date: Wed, 01 Oct 2014 12:29:48 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20141001130826.GM28710@savin.petertodd.org> In-Reply-To: <20141001130826.GM28710@savin.petertodd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [173.201.192.234 listed in list.dnswl.org] X-Headers-End: 1XZLqm-00037f-4l Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time 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: Wed, 01 Oct 2014 15:29:57 -0000 I like the proposal. I suggest that applications and nodes should only broadcast transactions having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value. If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is equal to the current height and equal to the timeout value, but that peer is one block behind in the blockchain, the transaction will be rejected by the peer and the source will be banned. Another option will be not to ban peers sending transactions failing to verify OP_CHECKLOCKTIMEVERIFY , but I don't like this. Still another option would be that the sender checks periodically the height of it's peers (using the version command) in order to be sure to send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers that are up to date with the blockchain. Regards, Sergio.