1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 32811723
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Oct 2016 22:37:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
[209.85.220.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A94D687
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Oct 2016 22:37:10 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id j129so141846314qkd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 02 Oct 2016 15:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=zFU8TVjj4w5MIlnzpJFp7ACNC5uKJXXM1/BvqSt1lDc=;
b=Stq/UVxa5rxH5ssk17KzB6veYeY7WOSbsbUmAQuW4+2GM7NcfcOZCLQNtR9uo1QcuS
2LPj6/Wyu4Tt8vSRgz8I0Z9KFyzRBDx82ywfWeaeZgmE7Gbhk/DYMKM/wqM2hMqnLLmV
+QKlM8EtC9GgcVMJoP/SyjARRXIf7o/PP5lkrpdc8q8I506XuDldfYEjN7en6X9kC0aa
d+qr20sDZGxWLRiKJkX1SJI4rcU/HSEE123JQ1vf/zOiViHdgtasw2vB6dzwQTVysOhB
135FDeeyAVVFxmHR5RSBB0DR4wG5a93G3e3LLq2eYTcxMnfO2fdyrI/fLlnJU85CKyH4
s89A==
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:cc;
bh=zFU8TVjj4w5MIlnzpJFp7ACNC5uKJXXM1/BvqSt1lDc=;
b=HH8L3+eZP/Tj6wxmCwyqBljZXjwUDwR4QSJ0embCO9jdXom/0GZjQksi3muRBe7pcy
Z1y0nwVjCifou9dWgOtJQMulu2gTdmRObmskL1H/L9hpvDbDvc6XQz6NWfI5WX3DGMmf
EJzU5s813ulbTDa0gT29q3deR4szsZOa8lVVXOJWvYYc27JgXOGVSYESxsnKmzXx6t+5
8/GETJ/YaI2xCHrcZ6pYWKc+Xb1aXDUkSqNWl1FlEC4eMZOKbc/HSkODzVF6o9K+HlZz
EtGl73Vhl0KoM35cEFnwS+Tk3nJVG3IyOTRtJYdLr0b6ONLnc3FtLR4iE+K5PDknANSn
FP8g==
X-Gm-Message-State: AA6/9RkhkOVFI34S5dn70hyD8Xn70d/ogGLbK9z2j9ny+kV7yZyajLsnMDuuNh8d2LMIylYIHm/FSSRUD1Cu7w==
X-Received: by 10.55.128.129 with SMTP id b123mr16989384qkd.322.1475447829997;
Sun, 02 Oct 2016 15:37:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.35.7 with HTTP; Sun, 2 Oct 2016 15:36:29 -0700 (PDT)
In-Reply-To: <CAMZUoKkPrVeqv3Xitp42e1mCqxj3pMSOUW_pTTrb36jc9w71Vg@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>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Sun, 2 Oct 2016 19:36:29 -0300
Message-ID: <CAKzdR-oSQq+P-eibn4-0sraXRrmeC-7K+-xFB2cu4hKtSjHBUA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c06652ecaacaa053de977c7
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 <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 22:37:11 -0000
--94eb2c06652ecaacaa053de977c7
Content-Type: text/plain; charset=UTF-8
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.
--94eb2c06652ecaacaa053de977c7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <s=
pan dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote">But I would argue that in this scenario, t=
he only way it<br>
would become invalid is the equivalent of a double-spend... and therefore i=
t<br>
may be acceptable in relation to this argument.<br></blockquote><div><br></=
div></span><div>The values returned by <span class=3D"m_-780418529899519097=
7gmail-im">OP_COUNT_ACKS vary in their exact value depending on which block=
this transaction ends up in.=C2=A0 While the proposed use of this operatio=
n is somewhat less objectionable (although still objectionable to me), noth=
ing stops users from using OP_EQUALVERIFY and and causing their transaction=
fluctuate between acceptable and unacceptable, with no party doing anythin=
g like a double spend.=C2=A0 This is a major problem with the proposal.<br>=
</span></div></div></div></div></blockquote><div><br></div><div>Transaction=
s 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 c=
annot be DoS attacked by flooding with a transaction that will not verify d=
ue to being too late.<br></div><div>The only parties that can include the r=
edeem transaction are the miners themselves.<br></div><div>Therefore I see =
no problem that an OP_COUNT_ACKS scriptSig transaction is invalidated after=
the liveness times expires.<br></div><div>If there is no expiration, then =
polls can last forever and the system fails to provide DoS protection for b=
lock validation since active polls can accumulate forever. <br><br><br></di=
v><div><br></div></div></div></div>
--94eb2c06652ecaacaa053de977c7--
|
