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
|
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--
|
