public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
Date: Sun, 2 Oct 2016 19:26:18 -0400	[thread overview]
Message-ID: <CAMZUoKn+mTQMsbuomFQ=vG5K88F2gdUe4jwrRAyMLeTr3M1Tyw@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-oxpDdXEcPTYtj6os58cVMgwoqyXvu5UMMQzD3QbvMtxA@mail.gmail.com>

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

  parent reply	other threads:[~2016-10-02 23:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-02 15:49 [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS Sergio Demian Lerner
2016-10-02 16:17 ` Peter Todd
2016-10-02 17:00   ` Sergio Demian Lerner
2016-10-02 17:11     ` Peter Todd
2016-10-02 17:18       ` Andrew Johnson
2016-10-02 17:24         ` Peter Todd
2016-10-02 21:28         ` Luke Dashjr
2016-10-02 21:46           ` Russell O'Connor
2016-10-02 22:36             ` Sergio Demian Lerner
     [not found]               ` <CAMZUoKnE9VNnUHrDTtZOroBp=SC_eY1fEAsEOz=4b1=5v_wHaA@mail.gmail.com>
2016-10-02 23:00                 ` [bitcoin-dev] Fwd: " Russell O'Connor
     [not found]                 ` <CAKzdR-oxpDdXEcPTYtj6os58cVMgwoqyXvu5UMMQzD3QbvMtxA@mail.gmail.com>
2016-10-02 23:26                   ` Russell O'Connor [this message]
2016-10-02 21:54           ` [bitcoin-dev] " Russell O'Connor
2016-10-02 17:26       ` Sergio Demian Lerner
2016-10-02 17:34         ` Peter Todd
2016-10-02 18:17 ` Russell O'Connor
2016-10-24 17:37 ` Johnson Lau
2016-10-25 16:38   ` Sergio Demian Lerner
2016-10-25 17:45     ` Johnson Lau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZUoKn+mTQMsbuomFQ=vG5K88F2gdUe4jwrRAyMLeTr3M1Tyw@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=sergio.d.lerner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox