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 E9897BD9 for ; Mon, 5 Oct 2015 15:33:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A3A0FF for ; Mon, 5 Oct 2015 15:33:32 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so120394264wic.1 for ; Mon, 05 Oct 2015 08:33:31 -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=l5a10SVUgc+1nxTDxykQxlXLS+JkJYoqqct+/64Vqsg=; b=PJeMIPe0fsbAoCOS8zvOA8QoG1Vli2QgMhIXcbGJLtet+jmJf6GG0Hkosqp4fzGo3l JiGBk1L3yO3rrwTwz8w81sr1j6nqePGhJ1cc9xuUzQXF1xvaPRmKiXQXcB8FbC+Tm30l AXQk/jz6koz790B4y8aOIurFSNqsHMt2AJJykr8K/7cP5gLB7yhv/5IQzOm1fZgcHBYV YydiepmyjuSlejomwyjgfrnmG9uO9aPj63kTol6rxJObLF7h20ayRnQhz/UKnxFTM1le 6r5L1ovIEr73teeMEU3dDM/90mQD9OqefoPmE4YtWHUg8f7nw/1YnLDcbenXJbX1jyPi 9CGQ== X-Gm-Message-State: ALoCoQmzqh3tSVhytdwdjA0tXz9MsMK3Q0Suw9nM4c/sIJoFGJjfhcImAY12EYkMhLC5l6Ovs6UP MIME-Version: 1.0 X-Received: by 10.194.77.240 with SMTP id v16mr29884939wjw.109.1444059210989; Mon, 05 Oct 2015 08:33:30 -0700 (PDT) Received: by 10.194.114.199 with HTTP; Mon, 5 Oct 2015 08:33:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Oct 2015 17:33:30 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mike Hearn Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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: Mon, 05 Oct 2015 15:33:33 -0000 On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn wrote: > Hi Jorge, > > I'm glad we seem to be reaching agreement that hard forks aren't so bad > really and can even have advantages. It seems the remaining area of > disagreement is this rollout specifically. >> >> a non-upgraded full node and an upgraded full will converge on what they >> see: "the most-work valid chain" will be the same for both. > > Indeed it will, but the point of fully verifying is to not converge with the > miner majority, if something goes wrong and they aren't following the same > rules as you. Defining "work" as "converge with miner majority" is fine for > SPV wallets and a correct or at least reasonable definition. But not for > fully verifying nodes, where non-convergence is an explicit design goal! > That's the only thing that stops miners awarding themselves infinite free > money! As Greg explained to you repeatedly, a softfork won't cause a non-upgraded full node to start accepting blocks that create more subsidy than is valid. It's only the new rule (in this case, BIP65) that they won't validate. That's very different security from an SPV node, and as Greg also explained, SPV nodes could be much more secure than bitcoinj nodes (they could, for example, validate the coinbase transaction of every block). If a non-upgraded node it's not a "full node" for you, that's fine, but it is for everyone else. So please stop confusing other people. Assuming the majority of the hashrate upgraded, there's almost no risk for non-upgraded full nodes. >> Are you going to produce a bip65 hardfork alternative to try to convince >> people of its advantages over bip65 (it is not clear to me how you include a >> new script operand via hardfork)? > > No, I'm focused on the block size issue right now. I don't think there's > much point in improving the block chain protocol if most users are going to > be unable to use it. But the modification is simple, right? You just replace > this bit: > > CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode > > with this > > CHECKLOCKTIMEVERIFY defines a new opcode (0xc0) > > and that's it. The section upgrade and testing plan only says TBD so that > part doesn't even need to change at all, as it's not written yet. Thanks, I wasn't aware that there was room for new opcodes that weren't noops already. Can you give an example of an attack in which a non-upgraded full node wallet is defrauded with BIP65 but could not with the hardfork alternative (that nobody seems to be willing to implement)? Please, don't assume 0 confirmation transactions or similar unreasonable assumptions (ie see section 11 "Calculations" of the Bitcoin whitepaper).