Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

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

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

If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the transaction
probably won't be able to be included at a different height.

On Oct 2, 2016 19:16, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:

> It can be included at another block at a differnt height. It can be
> included anytime during the liveness period which starts 100 blocks later
> than the poll period ends. I'm reading the BIP now and it's true that this
> is not enterily clear. I will try to clarify.
>
>
> On Sun, Oct 2, 2016 at 7:58 PM, Russell O'Connor <roconnor@blockstream.io>
> wrote:
>
>> 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: 4154 bytes --]