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 --]
next prev 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 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$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sergio.d.lerner@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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