From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DA61A7AA for ; Sun, 2 Oct 2016 23:26:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AC15148 for ; Sun, 2 Oct 2016 23:26:20 +0000 (UTC) Received: by mail-ua0-f182.google.com with SMTP id q42so136892496uaq.2 for ; Sun, 02 Oct 2016 16:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LX44P+thc66F0cK7QLvfjNjkt43GV3ChA9lTymBazjU=; b=UiTUCLagEnYVC/4CWnmnYhZcf1G9FOBwPUj9B2vOJ2UgjWZgL/6rSnqB5PktJXQbuR wFU1IunPWkTFlbj6iAAnPfxk+/dp3mcA6G7BtMSGR5wAf9buOl1nBn4PyLmiAaiIQH8K LVLGD9Jj66yf85uKF+RCtL1IWuvSwppoBGErAIQUTC7kjnytvKFVG2PhjXVqbxxWAA3/ 1P5XwF7piYY8ltZ3ZVNij+TqaZrd5cDPTTV02030234Az+8Z0w+HhVFHZmdvTkycgoIJ D6JJpMfmm2iPjHdOAfdTX0RQmP2pNND6VF0Yyxw8uVOyiIKxViYIJxVltJn10qH1AyGf fUQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LX44P+thc66F0cK7QLvfjNjkt43GV3ChA9lTymBazjU=; b=K+0D2dZ7OAB46U1I6hDS5Vm7BG7wHJ1xzju/ORVD0/JHZ8TvQhb3BKdYzIWkndo6Yg iqnLs78n0+yupY1YcX53Q/28bc43vLApJ9b9g7BUAt1O+uQ8PcF5urFrtcgyzCbbrFVQ crm/ZDSNSNoQxNkArtl+8mw4EAneAT1J18k709n6GjEqe8RKJMu9FOMxh7aZyEJZL7dR BcLd2qUznvb5BePjWQLv9EcBOGoUj/XwmMDdVUdVXCtQ975qY3C+ANlX4qJnuW/XIL52 Ajexa++zKEL7CTEZgiibQOzLgVk1e0bIZRwsQI3r6NYtskPasclStQ07XsELYMJvOOVq gg/A== X-Gm-Message-State: AA6/9RlUF7VxTBJlN9cTMQuyEGC+sO2wAjQL3peGWattcxjgCAzHS5GsyNB0AJTbprvLEnmmpXPgYUNkduRXIyFW X-Received: by 10.176.1.195 with SMTP id 61mr11422056ual.155.1475450779376; Sun, 02 Oct 2016 16:26:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 16:26:18 -0700 (PDT) Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 16:26:18 -0700 (PDT) In-Reply-To: References: <20161002171137.GA18452@fedora-21-dvm> <201610022128.52401.luke@dashjr.org> From: "Russell O'Connor" Date: Sun, 2 Oct 2016 19:26:18 -0400 Message-ID: To: Sergio Demian Lerner , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1135bf3096b43a053dea2788 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 03 Oct 2016 08:48:18 +0000 Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 23:26:21 -0000 --001a1135bf3096b43a053dea2788 Content-Type: text/plain; charset=UTF-8 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" 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 > 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" >> 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. >>> >>> >>> >>> > --001a1135bf3096b43a053dea2788 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 ano= ther block at a differnt height. It can be included anytime during the live= ness 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 reo= rged out during an innocent reorg, one that doesn't involve a double sp= end, the transaction may never get back in unless it occurs at exactly=C2= =A0 the same height, which is not guaranteed.

This affects fungabity of coins generated from these transac= tions.


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 <bitc= oin-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 i= t
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 tran= saction ends up in.=C2=A0 While the proposed use of this operation is somew= hat 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 d= ouble spend.=C2=A0 This is a major problem with the proposal.

Transactions that red= eem an output containing (or referencing by means of P2WSH) an OP_COUNT_ACK= S are not broadcast by the network. That means that the network cannot be D= oS attacked by flooding with a transaction that will not verify due to bein= g too late.
The only parties that can include the redeem tran= saction are the miners themselves.
Therefore I see no problem= that an OP_COUNT_ACKS scriptSig transaction is invalidated after the liven= ess times expires.
If there is no expiration, then polls can = last forever and the system fails to provide DoS protection for block valid= ation since active polls can accumulate forever.



--001a1135bf3096b43a053dea2788--