From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: "Russell O'Connor" <roconnor@blockstream•io>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
Date: Sun, 2 Oct 2016 19:36:29 -0300 [thread overview]
Message-ID: <CAKzdR-oSQq+P-eibn4-0sraXRrmeC-7K+-xFB2cu4hKtSjHBUA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkPrVeqv3Xitp42e1mCqxj3pMSOUW_pTTrb36jc9w71Vg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
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: 2124 bytes --]
next prev parent reply other threads:[~2016-10-02 22:37 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 [this message]
[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 ` [bitcoin-dev] " Russell O'Connor
2016-10-02 21:54 ` 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=CAKzdR-oSQq+P-eibn4-0sraXRrmeC-7K+-xFB2cu4hKtSjHBUA@mail.gmail.com \
--to=sergio.d.lerner@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(echo .)io \
/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