Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7B0E2CAF for ; Fri, 23 Sep 2016 13:43:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E20D3136 for ; Fri, 23 Sep 2016 13:43:36 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id 15so39983127uai.3 for ; Fri, 23 Sep 2016 06:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=f8D/X676k28N1n9nUSbTlQ+gTUL4aCIQ/BOFtFL/BLg=; b=ZCsGdCXpHpNvx+EZAttVSgdaYW+Xb1lCga/9S7uNVYtmU7VR1kATQRjAlGPePhrvF9 slBxu+nQ7C9Zo6Yo4vIQ2My+5rY6Pg60TQBLuPkkA7Z+Dcfd5LN7KpaDGbUmfUIie9bP sDoNQueQCOLaj/BbLd4F7MUOB0wfBNqJXGoXDELDbOO2LQay3f2QF+upnSfezEPwEzp9 bNROy6vkiVz2BgZEmwiJGLZto7ERJtVR/JJXh/5z+lAzd+taPT1v0lgIX1JX1Lyx+A2s kbHGVVr0wgktAzCwlLzXwXUyVHvilUEu2SR1Ip8Sso6ARyjUkpjZZYAwi7jHe1S0Pr3d aAvg== 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:from:date :message-id:subject:to; bh=f8D/X676k28N1n9nUSbTlQ+gTUL4aCIQ/BOFtFL/BLg=; b=HZWW/3afMA6M0EFBAak34Xa7P7DpLy813PgOF2nIhK3LKszcaNup4eXpWSfKm1J+t/ him7TvkuvsL6P/cG3woK7Y3UENJz8zuaNek1JMtMVCnOGvJCq7q2H7lxoHF/G7/ULust cbVEqsyqL6f1UP4yvcpkIBB362pakbi5ksccVCvuCEBlenQSdF+mNV1Zqml0tBcHfAX+ PsNthM0+d28Lr9ZHpxZE2NivzHbYPs+CsgpiokAu7010C+eKmHyeBaHUThp3zp25AExB N+gXiH+ITiE2IVDS1qlASX0Slxwga5WZu990s6pGQQD+iO1u37hKGQmYN3pWhBVwvBM3 CC8g== X-Gm-Message-State: AA6/9RlrdOLcipiPhOmZoJhHmki6OWQhrZKsfnopMGBQTK7sXaRGoScNdDgjSCgCuOT/u1mrjSAo7zQmFaRQ7Lqp X-Received: by 10.176.6.99 with SMTP id f90mr4580157uaf.63.1474638215967; Fri, 23 Sep 2016 06:43:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.136 with HTTP; Fri, 23 Sep 2016 06:43:15 -0700 (PDT) In-Reply-To: <201609230957.03138.luke@dashjr.org> References: <201609230957.03138.luke@dashjr.org> From: "Russell O'Connor" Date: Fri, 23 Sep 2016 09:43:15 -0400 Message-ID: To: Luke Dashjr , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c047696095bf2053d2cf70d X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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 X-Mailman-Approved-At: Fri, 23 Sep 2016 14:54:27 +0000 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 13:43:37 -0000 --94eb2c047696095bf2053d2cf70d Content-Type: text/plain; charset=UTF-8 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. On Fri, Sep 23, 2016 at 5:57 AM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin > scripting system to address reissuing bitcoin transactions when the coins > they > spend have been conflicted/double-spent. > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki > > Does this seem like a good idea/approach? > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c047696095bf2053d2cf70d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe Bitcoin currently enjoys the property that durin= g an "innocent" re-org, i.e. a reorg in which no affected transac= tions are being double spent, all affected transactions can always eventual= ly get replayed, so long as the re-org depth is less than 100.

My co= ncern with this proposed operation is that it would destroy this property.<= br>

On Fri, = Sep 23, 2016 at 5:57 AM, Luke Dashjr via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:
This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) = for the Bitcoin
scripting system to address reissuing bitcoin transactions when the coins t= hey
spend have been conflicted/double-spent.

https://github.com/luke-jr/bips= /blob/bip-cbah/bip-cbah.mediawiki

Does this seem like a good idea/approach?

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--94eb2c047696095bf2053d2cf70d--