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 D5D8FC7D for ; Fri, 23 Sep 2016 23:43:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 754811C3 for ; Fri, 23 Sep 2016 23:43:51 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id v205so4052193vke.1 for ; Fri, 23 Sep 2016 16:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3IR2YjPNUrMAOQ4IcnyD4gC3UsBU33zny/87kpyeIVU=; b=YTAYBXtL0vJlKZM0n4vDWcXCAoKpd7OBkwPZh/JyyfmbWru+TjVDEA34nXoyUay2E9 DN3fj/6+m0fyXmpibGw1m0wI+pvO5Fh9YLouAzvLmHRPhiCuKYnSsq8JFGKOb02CbTMy MIcuy8QJqKz2Rkzcsa22+j5CKpwlyjCOJK2grGbx6cAqK0mdjzqHL3XnQr3kKQ1s9jAC U35xv/HzOZ3ZVefVxyFqeBuA4iuZ3bGG4kpwl0raspdbT022gHkWWdW1MpXhb7sDws8v 8sZWeM+YNpCqYh55Q/ihT0H5S1BLrxDto5sd2+cVK1nFBrdvyJL4lmii7+pgbki9WocA foXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3IR2YjPNUrMAOQ4IcnyD4gC3UsBU33zny/87kpyeIVU=; b=nGzKfSUJAE1cMG8hYn3eHMipDL7KNvOGO3+y2JBNsrW6C3JD6UBZ4dQk2tvk2seKxn 6N4I3YtNtOm5umT+SZKEgV6TABSmtuTFG45fI7e9pKgqeCLdI8wh151s3aHs4rIGA0Z5 NXxzCIHsW15SbEoAOgrjUSUALBcCQc7cwimULHfb+KcQiQR86H+MsnncrhsMM7BHo4II PJt+p9knrAQlzBLNKNs8h673jsqzvE2733dwD0KbQz5l/fFMuKjt3p0E7QlZx5oiuUjF aU/I+HPgPPZ1XbQpCIKWvnl21bTxpntbI82inzbonB8XM76oLDlDx96+peiZFZA3bDv6 VPog== X-Gm-Message-State: AA6/9RnIPZQ4fdjwYBDc3rmDdaM8Vo6TU4t1ix0sVeSVW17MUqM9QbY4WNaT91l5nRBhGYurpbRZIys5MN0ZBQ== X-Received: by 10.31.61.213 with SMTP id k204mr670026vka.173.1474674230691; Fri, 23 Sep 2016 16:43:50 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.33.145 with HTTP; Fri, 23 Sep 2016 16:43:49 -0700 (PDT) In-Reply-To: <201609232220.41783.luke@dashjr.org> References: <201609230957.03138.luke@dashjr.org> <201609232220.41783.luke@dashjr.org> From: Gregory Maxwell Date: Fri, 23 Sep 2016 23:43:49 +0000 X-Google-Sender-Auth: QD5YL5Ml3s56b4a4Bvl9eWuT1As Message-ID: To: Luke Dashjr , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 23:43:52 -0000 On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev wrote: > In the innocent use case of this opcode, a double-spend has already occurred, > and this should be a strict improvement. In the non-innocent abuse of this > opcode, I don't see that it's any worse than simply double-spending. There is a fungibility hit... right now, absent double spends (and privacy issues), every coin you might get paid is equal. With this script feature as described, you could get paid a coin which has one of these in its recent past, pinning the block immediately before it. A reorg long enough to remove that block-- due to an attack, or an ordinary block race, or some kind of consensus glitch (like we had in March 2013 or around the activation of BIP65)-- is _guaranteed_ to invalidate those coins, even without any double spend. If the scheme doesn't do as I suggest and prevent over-eager usage (perhaps 100 is too much, I just decided to match coinbases); then it should probably have a consensus enforced explicit "maximum survivable reorg" that is traced along with the outputs, so that someone who received exposed coins could handle it sensibly. Just for plain engineering reasons, I still think it is important to now allow overly short back references. If the reference has to be a few blocks back we don't need to worry about short forks breaking propagation, and simple mempool handling like purging all CBAH transactions on a large reorg would work fine. It need not be so long as to implicate Petertodd's concern that you could only use it where it wouldn't matter. (Though I also disagree that a depth of 100 achieves that, consider persistent chain forks).