[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS

["Russell O'Connor" <roconnor@blockstream.io>]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

I forget to send to bitcoin-dev.

> A related problem is that if this transaction is reorged out during an
innocent reorg, one that doesn't involve a double spend, the transaction
may never get back in unless it occurs at exactly  the same height, which
is not guaranteed.
>
> This affects fungabity of coins generated from these transactions.
>
>
> On Oct 2, 2016 18:37, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:
>>
>>
>>
>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> 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.
>>
>>
>> Transactions that redeem an output containing (or referencing by means
of P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That means
that the network cannot be DoS attacked by flooding with a transaction that
will not verify due to being too late.
>> The only parties that can include the redeem transaction are the miners
themselves.
>> Therefore I see no problem that an OP_COUNT_ACKS scriptSig transaction
is invalidated after the liveness times expires.
>> If there is no expiration, then polls can last forever and the system
fails to provide DoS protection for block validation since active polls can
accumulate forever.
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]