From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Andrew Johnson <andrew.johnson83@gmail.com>
Date: Sun, 2 Oct 2016 21:28:51 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.21-gentoo; KDE/4.14.24; x86_64; ; )
References: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com>
	<20161002171137.GA18452@fedora-21-dvm>
	<CAAy62_+cqR0-DBbKhePo+VqTJc099zXJR0EurLyb1XURUCT36g@mail.gmail.com>
In-Reply-To: <CAAy62_+cqR0-DBbKhePo+VqTJc099zXJR0EurLyb1XURUCT36g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201610022128.52401.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
Precedence: list

On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project?  If not, you're wildly off topic.

I think that's the concern: we don't - and *can't* - know. Pending patents are 
not publicly visible, as far as I am aware, and the BIP process does not 
(presently) require any patent disclosure.

Of course, it is entirely possible to voluntarily provide a disclosure of 
patents in the BIP (and ideally a free license to such patents, at least those 
for the BIP). This is an alternative possibility to resolve patent concerns if 
Rootstock is not prepared to adopt a defensive patent strategy in general 
(yet?).

On Sunday, October 02, 2016 6:17:12 PM Russell O'Connor via bitcoin-dev wrote:
> If I understand this BIP correctly, the values pushed onto the stack by the
> OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
> block that this happens to be included in.
> 
> This isn't going to be acceptable.  The validity of a transaction should
> always be monotone in the sense that if a transaction was acceptable in a
> given block, it must always be acceptable in any subsequent block, with the
> only exception being if one of the transaction's inputs get double spent.

I don't know if it's possible to implement decentralised sidechains without 
"breaking" this rule. 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.

Luke