MIME-Version: 1.0
In-Reply-To: <201610022128.52401.luke@dashjr.org>
References: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>
	<20161002171137.GA18452@fedora-21-dvm>
	<CAAy62_+cqR0-DBbKhePo+VqTJc099zXJR0EurLyb1XURUCT36g@mail.gmail.com>
	<201610022128.52401.luke@dashjr.org>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 2 Oct 2016 17:46:43 -0400
Message-ID: <CAMZUoKkPrVeqv3Xitp42e1mCqxj3pMSOUW_pTTrb36jc9w71Vg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c047d3e9d2e23053de8c486
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
Precedence: list

--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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex" class=3D"gmail_quote">But I would argue that in=
 this scenario, the only way it<br>
would become invalid is the equivalent of a double-spend... and therefore i=
t<br>
may be acceptable in relation to this argument.<br></blockquote><div><br></=
div><div>The values returned by <span class=3D"gmail-im">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.<br></span></div></div></div></di=
v>

--94eb2c047d3e9d2e23053de8c486--