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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
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 DA61A7AA
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Oct 2016 23:26:20 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id q42so136892496uaq.2
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CAKzdR-oxpDdXEcPTYtj6os58cVMgwoqyXvu5UMMQzD3QbvMtxA@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>
<CAKzdR-oxpDdXEcPTYtj6os58cVMgwoqyXvu5UMMQzD3QbvMtxA@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 2 Oct 2016 19:26:18 -0400
Message-ID: <CAMZUoKn+mTQMsbuomFQ=vG5K88F2gdUe4jwrRAyMLeTr3M1Tyw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: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" <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.
>>>
>>>
>>>
>>>
>
--001a1135bf3096b43a053dea2788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the =
transaction probably won't be able to be included at a different height=
.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Oct 2, 2016 19=
:16, "Sergio Demian Lerner" <<a href=3D"mailto:sergio.d.lerner=
@gmail.com">sergio.d.lerner@gmail.com</a>> wrote:<br type=3D"attribution=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">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.<br><br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sun, Oct 2, 2016 at 7:58 PM, Russell O'Connor <span=
dir=3D"ltr"><<a href=3D"mailto:roconnor@blockstream.io" target=3D"_blan=
k">roconnor@blockstream.io</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><p dir=3D"ltr">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.</p>
<p dir=3D"ltr">This affects fungabity of coins generated from these transac=
tions.</p><div class=3D"m_-4669536286330019941HOEnZb"><div class=3D"m_-4669=
536286330019941h5">
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Oct 2, 2016 18=
:37, "Sergio Demian Lerner" <<a href=3D"mailto:sergio.d.lerner=
@gmail.com" target=3D"_blank">sergio.d.lerner@gmail.com</a>> wrote:<br t=
ype=3D"attribution"><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><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Oct 2, 2016 =
at 6:46 PM, Russell O'Connor via bitcoin-dev <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfounda<wbr>tion.org</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"=
>But I would argue that in this scenario, the 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_-466953628633001994=
1m_6898796195115061803m_-6562678653958902122m_-7804185298995190977gmail-im"=
>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.<br></span></d=
iv></div></div></div></blockquote><div><br></div><div>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.<br></div><div>The only parties that can include the redeem tran=
saction are the miners themselves.<br></div><div>Therefore I see no problem=
that an OP_COUNT_ACKS scriptSig transaction is invalidated after the liven=
ess times expires.<br></div><div>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. <br><br><br></div><div><br=
></div></div></div></div>
</blockquote></div></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
--001a1135bf3096b43a053dea2788--
|
