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 32D50CAD for ; Fri, 23 Sep 2016 18:57:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 96B56184 for ; Fri, 23 Sep 2016 18:57:58 +0000 (UTC) Received: by mail-ua0-f182.google.com with SMTP id 15so54744839uai.3 for ; Fri, 23 Sep 2016 11:57:58 -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; bh=DzcZHMJ4JitBnuz2ieuCx8LG8BfkWBjKO9zcfItnSa4=; b=HTWVcx8VotnFjrKqjXMsUe37DkWD67X9Jdcg3iXHnsTuRukBI/l1XSkYf7YeNTHAtC al8Ytwm6aaHShwrs4Y2BaZDLLjgUrupsJuOqWZYg0R80sMt1lrpg4gQmMtUueNESKYwi EMRaEOoPUULuL33c3rDxegFcXPklFoQkUYTlVYF76FSyv0DzUVccXWdF0ylkLESORc2L 7zRoUEwIC9s+3/+H2kFaKJjSImz2o6OTYtzWPctkrqphwkB1mLJWLDMH150PgCfuc5hZ X0QDVgvRVZr59YpGLzBtwlsyQi3fJPQmgZIpaxlASO/4myTgE49qPJDkhFUFbJKIdSyL 53dA== 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; bh=DzcZHMJ4JitBnuz2ieuCx8LG8BfkWBjKO9zcfItnSa4=; b=Q3KY0aEqaLS07w367cGaD3mR0k7PPfOqtbNjCc+0rSfshgUZtwua9XAwsWZbD6z0qj E4dAnEXzneO0NIkje1k8Kr9g64RTyC+N3jY0QotYdSH+SLi66VkitOs0DdXqx+Mj85xI QK68FmBnWAzliNxhD4+EdkXmFEhbuVjHPnD7TNaeyEKUjulZpeE6hi1d/p+A5ySJnYXL AmOlK6ahDrLEGhoFuze9hAwCnCZQAIsmkxZszUdggaHi5dvc1y/f+acbZ8Mw1hThOtRw 2Is6uivEZy0pt5/deMiHMyjpolle/81Si3vpN15ynhlKe81XC/RHEZb1ZDMUKvSK0V5B CHcA== X-Gm-Message-State: AA6/9Rnpi+fBZolbFmmsfClkR72duqtCajCOvtEXJjv+ai7x0c/dGV2bHSFvKIt+0swXoCU9nkyLwQoB/QBklw== X-Received: by 10.176.5.129 with SMTP id e1mr5721662uae.114.1474657077634; Fri, 23 Sep 2016 11:57:57 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.33.145 with HTTP; Fri, 23 Sep 2016 11:57:57 -0700 (PDT) In-Reply-To: References: <201609230957.03138.luke@dashjr.org> From: Gregory Maxwell Date: Fri, 23 Sep 2016 18:57:57 +0000 X-Google-Sender-Auth: 7CqjqylK7fp0RywCps-G3Pdn_G4 Message-ID: To: 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 18:57:59 -0000 On Fri, Sep 23, 2016 at 1:43 PM, Russell O'Connor via bitcoin-dev wrote: > I believe Bitcoin currently enjoys the property that during an "innocent" > re-org, i.e. a reorg in which no affected transactions are being double > spent, all affected transactions can always eventually get replayed, so long > as the re-org depth is less than 100. > My concern with this proposed operation is that it would destroy this > property. The reorg safety impact of this proposal could be eliminated and the mempool handling complexity greatly reduced if the transaction was required to be locktimed at least 100 blocks after the block its referencing. This would also resolve a rather severe DOS weakness that the spec has with the suggestion that nodes would relay this rule without validating it. With the depth restriction nodes could relay one (or a couple) blocks early without creating a situation where someone can consume relay resources with near zero odds of paying a fee for them. Irritatingly, applications of this rule would really want to be applied at signing time (like locktime is), not as part of a scriptpubkey. With it part of a scriptpubkey two moves are required. I think solving this is important. FWIW, this scheme more has been proposed before for another reason-- effectively allowing users to 'vote against' long reorgs by making sure their transactions can't be included in them. Though for that application it was only needed to use 32 bits of the block hash.