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 34D1692 for ; Sun, 2 Oct 2016 21:47:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6341CE for ; Sun, 2 Oct 2016 21:47:04 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id p25so15169474uaa.1 for ; Sun, 02 Oct 2016 14:47:04 -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 :cc; bh=yrWq9ILzv0nzXWGCYBk4yocPrQ8Ycvf9UHHJ6ROuNwg=; b=iTXELbbqlu/egSDlxNGoO+b48TscfFtpLUOo0OvxiF2pvilj5QFojdjDz6LULgoPoB 76/4S+WBOIF5sqfUnPcL5pcUBu9HqdJJCDdmzmccgIYpSIGCHLFbEtCw06gXWsuHPouE 9O01DoGXS7U85eLS7VO34ok03CeOG74Ppf/rno86L3ph0FdbwEzFGW4gFgZ7CAjwFVjr IgMLKCIpA0ao0o0GMZnRVxcRkgc+97jZnMrHWkOaIcmdShNuUfLdBZjtiMyahvvNFDdg sl37pp+ilGK1hqbBzSx0LJ4SN17z9dbBilfxbuCmL5ItlA2XA26uc/VRJrd0D6w6HKrA mjHA== 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:cc; bh=yrWq9ILzv0nzXWGCYBk4yocPrQ8Ycvf9UHHJ6ROuNwg=; b=UQ80sVIz2uV8z0OCMkHtnIR36jdzwkhUVCz5S8r7DLBAjFlpEI0q+81RV26kmBCCgk e1MHFIR/yIiF7V8D9j6O+xSEF/ioNh24RRy8gU8rpeSW6CW8A6DIbOb21rBGh7Onv7B3 O7fDy3kxl+XatMeXBxdLHKjQK2U4/EShl8hHm0zJntEOb07RomO00gbL9qyi9+np98YI iLPqrIJzK+vYMlvPSIqm+I4qe9RuexWpV4+9S6c7oaKZruaqjfCvC02m96/YDZXA0cN2 DuKrcPmEul5LtG53uvBQu5QFB8U9ntdiHS/WDMOn8on/MvoY+liRP+vswfOT3MUK7pYi l//A== X-Gm-Message-State: AA6/9RlRpjb2begJFronfAZG4kNEYo6k36Jd1HdunJ7HAWkJl2vHiRULxw1rllJ2qbEtWOiI1WU9XLpDj6G1TzZy X-Received: by 10.159.40.71 with SMTP id c65mr2519710uac.46.1475444823888; Sun, 02 Oct 2016 14:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 14:46:43 -0700 (PDT) In-Reply-To: <201610022128.52401.luke@dashjr.org> References: <20161002171137.GA18452@fedora-21-dvm> <201610022128.52401.luke@dashjr.org> From: "Russell O'Connor" Date: Sun, 2 Oct 2016 17:46:43 -0400 Message-ID: To: Luke Dashjr , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c047d3e9d2e23053de8c486 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: Sun, 02 Oct 2016 22:29:16 +0000 Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS 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: Sun, 02 Oct 2016 21:47:05 -0000 --94eb2c047d3e9d2e23053de8c486 Content-Type: text/plain; charset=UTF-8 > But I would argue that in this scenario, the only way it > would become invalid is the equivalent of a double-spend... and therefore > it > may be acceptable in relation to this argument. > The values returned by OP_COUNT_ACKS vary in their exact value depending on which block this transaction ends up in. While the proposed use of this operation is somewhat less objectionable (although still objectionable to me), nothing stops users from using OP_EQUALVERIFY and and causing their transaction fluctuate between acceptable and unacceptable, with no party doing anything like a double spend. This is a major problem with the proposal. --94eb2c047d3e9d2e23053de8c486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
But I would argue that in= this scenario, the only way it
would become invalid is the equivalent of a double-spend... and therefore i= t
may be acceptable in relation to this argument.

The values returned by OP_COUNT_ACKS vary= in their exact value depending on which block this transaction ends up in.= =C2=A0 While the proposed use of this operation is somewhat less objectiona= ble (although still objectionable to me), nothing stops users from using OP= _EQUALVERIFY and and causing their transaction fluctuate between acceptable= and unacceptable, with no party doing anything like a double spend.=C2=A0 = This is a major problem with the proposal.
--94eb2c047d3e9d2e23053de8c486--