diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2016-10-02 19:00:16 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-10-02 23:00:19 +0000 |
| commit | 7e5ab6f71cd919b720c594125c306bca09545663 (patch) | |
| tree | c674b3bfbacac857d3aaea98216334cf292e50c4 | |
| parent | d037169f28d67ad3e005de2af8e1f6c60706daca (diff) | |
| download | pi-bitcoindev-7e5ab6f71cd919b720c594125c306bca09545663.tar.gz pi-bitcoindev-7e5ab6f71cd919b720c594125c306bca09545663.zip | |
[bitcoin-dev] Fwd: Re: Drivechain proposal using OP_COUNT_ACKS
| -rw-r--r-- | 3a/56eaa855fe9c96f3251804c7b9d621d6e44ad8 | 183 |
1 files changed, 183 insertions, 0 deletions
diff --git a/3a/56eaa855fe9c96f3251804c7b9d621d6e44ad8 b/3a/56eaa855fe9c96f3251804c7b9d621d6e44ad8 new file mode 100644 index 000000000..b000c6d3a --- /dev/null +++ b/3a/56eaa855fe9c96f3251804c7b9d621d6e44ad8 @@ -0,0 +1,183 @@ +Return-Path: <roconnor@blockstream.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BFBE578D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 2 Oct 2016 23:00:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com + [209.85.213.51]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26C84135 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 2 Oct 2016 23:00:18 +0000 (UTC) +Received: by mail-vk0-f51.google.com with SMTP id y190so115417060vkd.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 02 Oct 2016 16:00:18 -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=Ob6cwHhXhFhv9f/REMFKo4yqCV0Fap9OOumQdbunMMs=; + b=PP5MJh55/rsCCeU8oLtH0wrufHsdofFqYNM4mm1kVj1Cd45F3JGaWpopqspGaol3jZ + 7BzXHfmu6HiwYeKR3crPtFcu6rnF7xGxQUk3HnQdKlpOFcpECNplrwhw3w1hPXVGLPup + gP3Uz/n2ErKq+zD8IM+7GYtJ4ipASEYek6N0bxFQRm/Gywv3jixrOHAnRYH9VubxPTxJ + YR+VOMekOhcdpqkvm6dVbirAbICQvTqG92NmtZIY6/D0r14FZvKOJspCn7QkxoHNGdCE + 6iMl3s9BH8P0KkNwF5k2CP3wO+yPeGbgtpHsrh0Hjh1+0NvIPemUbFfdhbCfT3sw2mxG + QQGA== +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=Ob6cwHhXhFhv9f/REMFKo4yqCV0Fap9OOumQdbunMMs=; + b=SV8ge7F2805y2phoVj2y6sWaaL5iLX/hBNXYg9fhUs0gDKhukCij3CANd/p/URY7h2 + zra1ToiXo6PXU/wShmM7/mzYnTyZwu7Kr9QoJ8t1M6T9ENSUpxgFL/nybCah2ojisewL + kreSto6jJiLeQrToIlDT31XuViNKu6eFx97c1sl5xdd+j/maIjordDa5dgyTix3KBzIT + 6BqpCkceTCsf91EJoHOwwWCKRKFLfsP8ng3Si7akQHqrxLwpnqLvOxW5NIhTTwvHVMF7 + /jAFDGvEUO6UGCp6PsmSJZ9NJYSE662F6lI8bRfSR2lykB05FTgtanjN4tAsKuDE7n7l + oiTQ== +X-Gm-Message-State: AA6/9RkbJKm0jMGk8lODTCfSPfc8lCObiHkYXtqb9esbGMekQbxQuPsSocyOARREka78Am7cman++PakMUaVq3dD +X-Received: by 10.31.34.68 with SMTP id i65mr12291253vki.77.1475449217062; + Sun, 02 Oct 2016 16:00:17 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 16:00:16 -0700 (PDT) +Received: by 10.176.3.102 with HTTP; Sun, 2 Oct 2016 16:00:16 -0700 (PDT) +In-Reply-To: <CAMZUoKnE9VNnUHrDTtZOroBp=SC_eY1fEAsEOz=4b1=5v_wHaA@mail.gmail.com> +References: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com> + <20161002171137.GA18452@fedora-21-dvm> + <CAAy62_+cqR0-DBbKhePo+VqTJc099zXJR0EurLyb1XURUCT36g@mail.gmail.com> + <201610022128.52401.luke@dashjr.org> + <CAMZUoKkPrVeqv3Xitp42e1mCqxj3pMSOUW_pTTrb36jc9w71Vg@mail.gmail.com> + <CAKzdR-oSQq+P-eibn4-0sraXRrmeC-7K+-xFB2cu4hKtSjHBUA@mail.gmail.com> + <CAMZUoKnE9VNnUHrDTtZOroBp=SC_eY1fEAsEOz=4b1=5v_wHaA@mail.gmail.com> +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Sun, 2 Oct 2016 19:00:16 -0400 +Message-ID: <CAMZUoKmOXm8wVBMS5W+LpEu5u75N7XW65dN+RVFOW7ePkAM5+Q@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary=001a113dc8b477b3c8053de9ca55 +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Sun, 02 Oct 2016 23:15:08 +0000 +Subject: [bitcoin-dev] Fwd: Re: 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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 02 Oct 2016 23:00:19 -0000 + +--001a113dc8b477b3c8053de9ca55 +Content-Type: text/plain; charset=UTF-8 + +I forget to send to bitcoin-dev. + +> 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. +>> +>> +>> + +--001a113dc8b477b3c8053de9ca55 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr">I forget to send to bitcoin-dev.</p> +<p dir=3D"ltr">> A related problem is that if this transaction is reorge= +d 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=C2=A0 t= +he same height, which is not guaranteed.<br> +><br> +> This affects fungabity of coins generated from these transactions.<br> +><br> +><br> +> On Oct 2, 2016 18:37, "Sergio Demian Lerner" <<a href=3D"= +mailto:sergio.d.lerner@gmail.com">sergio.d.lerner@gmail.com</a>> wrote:<= +br> +>><br> +>><br> +>><br> +>> On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-d= +ev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev= +@lists.linuxfoundation.org</a>> wrote:<br> +>>><br> +>>><br> +>>>> But I would argue that in this scenario, the only way it<b= +r> +>>>> would become invalid is the equivalent of a double-spend..= +. and therefore it<br> +>>>> may be acceptable in relation to this argument.<br> +>>><br> +>>><br> +>>> The values returned by OP_COUNT_ACKS vary in their exact value= + depending on which block this transaction ends up in.=C2=A0 While the prop= +osed use of this operation is somewhat less objectionable (although still o= +bjectionable to me), nothing stops users from using OP_EQUALVERIFY and and = +causing their transaction fluctuate between acceptable and unacceptable, wi= +th no party doing anything like a double spend.=C2=A0 This is a major probl= +em with the proposal.<br> +>><br> +>><br> +>> Transactions that redeem an output containing (or referencing by m= +eans of P2WSH) an OP_COUNT_ACKS are not broadcast by the network. That mean= +s that the network cannot be DoS attacked by flooding with a transaction th= +at will not verify due to being too late.<br> +>> The only parties that can include the redeem transaction are the m= +iners themselves.<br> +>> Therefore I see no problem that an OP_COUNT_ACKS scriptSig transac= +tion is invalidated after the liveness times expires.<br> +>> If there is no expiration, then polls can last forever and the sys= +tem fails to provide DoS protection for block validation since active polls= + can accumulate forever. <br> +>><br> +>><br> +>></p> + +--001a113dc8b477b3c8053de9ca55-- + |