* [bitcoin-dev] Script Abuse Potential?
[not found] <mailman.11263.1483391161.31141.bitcoin-dev@lists.linuxfoundation.org>
@ 2017-01-02 21:39 ` Steve Davis
2017-01-03 3:27 ` Jeremy
0 siblings, 1 reply; 8+ messages in thread
From: Steve Davis @ 2017-01-02 21:39 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
Hi all,
Suppose someone were to use the following pk_script:
[op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)..., op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
This still seems to be valid AFAICS, and may be a potential attack vector?
Thanks.
[-- Attachment #2: Type: text/html, Size: 1336 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-02 21:39 ` [bitcoin-dev] Script Abuse Potential? Steve Davis
@ 2017-01-03 3:27 ` Jeremy
2017-01-03 3:39 ` Johnson Lau
0 siblings, 1 reply; 8+ messages in thread
From: Jeremy @ 2017-01-03 3:27 UTC (permalink / raw)
To: Steve Davis, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
It is an unfortunate script, but can't actually
do
that much
it seems
. The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
Thus, it would seem the worst you could do with this would be to
(10000-520*2)*520*2
bytes ~=~ 10 MB.
Much more concerning would be the op_dup/op_cat style bug, which under a
similar script would certainly cause out of memory errors :)
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi all,
>
> Suppose someone were to use the following pk_script:
>
> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>
> This still seems to be valid AFAICS, and may be a potential attack vector?
>
> Thanks.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3428 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-03 3:27 ` Jeremy
@ 2017-01-03 3:39 ` Johnson Lau
2017-01-03 5:04 ` Russell O'Connor
2017-01-04 0:13 ` Jeremy
0 siblings, 2 replies; 8+ messages in thread
From: Johnson Lau @ 2017-01-03 3:39 UTC (permalink / raw)
To: Jeremy, bitcoin-dev; +Cc: Steve Davis
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
No, there could only have not more than 201 opcodes in a script. So you may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
For OP_CAT, just check if the returned item is within the 520 bytes limit.
> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> It is an unfortunate script, but can't actually do that much it seems. The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes. Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2 bytes ~=~ 10 MB.
>
> Much more concerning would be the op_dup/op_cat style bug, which under a similar script would certainly cause out of memory errors :)
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> Hi all,
>
> Suppose someone were to use the following pk_script:
>
> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)..., op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>
> This still seems to be valid AFAICS, and may be a potential attack vector?
>
> Thanks.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 4978 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-03 3:39 ` Johnson Lau
@ 2017-01-03 5:04 ` Russell O'Connor
2017-01-04 0:13 ` Jeremy
1 sibling, 0 replies; 8+ messages in thread
From: Russell O'Connor @ 2017-01-03 5:04 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
OP_2DUP? Why not OP_3DUP?
On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> No, there could only have not more than 201 opcodes in a script. So you
> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>
> For OP_CAT, just check if the returned item is within the 520 bytes limit.
>
> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
> It is an unfortunate script, but can't actually
> do
> that much
> it seems
> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
> Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2
> bytes ~=~ 10 MB.
>
> Much more concerning would be the op_dup/op_cat style bug, which under a
> similar script would certainly cause out of memory errors :)
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Suppose someone were to use the following pk_script:
>>
>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>
>> This still seems to be valid AFAICS, and may be a potential attack vector?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 5289 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-03 3:39 ` Johnson Lau
2017-01-03 5:04 ` Russell O'Connor
@ 2017-01-04 0:13 ` Jeremy
2017-01-04 3:13 ` Russell O'Connor
1 sibling, 1 reply; 8+ messages in thread
From: Jeremy @ 2017-01-04 0:13 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev, Steve Davis
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
Sure, was just upper bounding it anyways. Even less of a problem!
RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled. As
far as I know, the elements alpha proposal to reenable a limited op_cat to
520 bytes is somewhat controversial...
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau <jl2012@xbt•hk> wrote:
> No, there could only have not more than 201 opcodes in a script. So you
> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>
> For OP_CAT, just check if the returned item is within the 520 bytes limit.
>
> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> It is an unfortunate script, but can't actually
> do
> that much
> it seems
> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
> Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2
> bytes ~=~ 10 MB.
>
> Much more concerning would be the op_dup/op_cat style bug, which under a
> similar script would certainly cause out of memory errors :)
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> Suppose someone were to use the following pk_script:
>>
>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>
>> This still seems to be valid AFAICS, and may be a potential attack vector?
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 6098 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-04 0:13 ` Jeremy
@ 2017-01-04 3:13 ` Russell O'Connor
2017-01-04 14:45 ` Jorge Timón
0 siblings, 1 reply; 8+ messages in thread
From: Russell O'Connor @ 2017-01-04 3:13 UTC (permalink / raw)
To: Jeremy, Bitcoin Protocol Discussion; +Cc: Steve Davis
[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]
For the record, the OP_CAT limit of 520 bytes was added by Satoshi
<https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R425>
on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT
was disabled.
The previous limit was 5000 bytes.
On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Sure, was just upper bounding it anyways. Even less of a problem!
>
>
> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled. As
> far as I know, the elements alpha proposal to reenable a limited op_cat to
> 520 bytes is somewhat controversial...
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau <jl2012@xbt•hk> wrote:
>
>> No, there could only have not more than 201 opcodes in a script. So you
>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>>
>> For OP_CAT, just check if the returned item is within the 520 bytes limit.
>>
>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> It is an unfortunate script, but can't actually
>> do
>> that much
>> it seems
>> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
>> Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2
>> bytes ~=~ 10 MB.
>>
>> Much more concerning would be the op_dup/op_cat style bug, which under a
>> similar script would certainly cause out of memory errors :)
>>
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>>
>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> Hi all,
>>>
>>> Suppose someone were to use the following pk_script:
>>>
>>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>>
>>> This still seems to be valid AFAICS, and may be a potential attack
>>> vector?
>>>
>>> Thanks.
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 7169 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-04 3:13 ` Russell O'Connor
@ 2017-01-04 14:45 ` Jorge Timón
2017-01-05 16:22 ` Jeremy
0 siblings, 1 reply; 8+ messages in thread
From: Jorge Timón @ 2017-01-04 14:45 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Dev; +Cc: Steve Davis
[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]
I would assume that the controversial part of op_cat comes from the fact
that it enables covenants. Are there more concerns than that?
On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> For the record, the OP_CAT limit of 520 bytes was added by Satoshi
> <https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R425>
> on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT
> was disabled.
> The previous limit was 5000 bytes.
>
> On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> Sure, was just upper bounding it anyways. Even less of a problem!
>>
>>
>> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled. As
>> far as I know, the elements alpha proposal to reenable a limited op_cat to
>> 520 bytes is somewhat controversial...
>>
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>> <https://twitter.com/JeremyRubin>
>>
>> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau <jl2012@xbt•hk> wrote:
>>
>>> No, there could only have not more than 201 opcodes in a script. So you
>>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>>>
>>> For OP_CAT, just check if the returned item is within the 520 bytes
>>> limit.
>>>
>>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> It is an unfortunate script, but can't actually
>>> do
>>> that much
>>> it seems
>>> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
>>> Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2
>>> bytes ~=~ 10 MB.
>>>
>>> Much more concerning would be the op_dup/op_cat style bug, which under
>>> a similar script would certainly cause out of memory errors :)
>>>
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>> <https://twitter.com/JeremyRubin>
>>>
>>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Suppose someone were to use the following pk_script:
>>>>
>>>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>>>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>>>
>>>> This still seems to be valid AFAICS, and may be a potential attack
>>>> vector?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 8266 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Script Abuse Potential?
2017-01-04 14:45 ` Jorge Timón
@ 2017-01-05 16:22 ` Jeremy
0 siblings, 0 replies; 8+ messages in thread
From: Jeremy @ 2017-01-05 16:22 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev, Steve Davis
[-- Attachment #1: Type: text/plain, Size: 6072 bytes --]
@Russell: Appreciate the historical note, but as that op code was
simultaneously disabled in that patch I don't think we can look back to how
it was non-functionally changed (that number means nothing... maybe Satoshi
was trying it out with 520 bytes but then just decided to all-out disable
it and accidentally included that code change? Hard to say what the intent
was.).
@Jorge:
That's one part of it that is worth hesitation and consideration. I'm not a
fan of the 520 byte limit as well. My gut feeling is that the "right"
answer is to compute the memory weight of the entire stack before/after
each operation and reasonably bound it.
Below text is from the chain core documentation:
"""
Most instructions use only the data stack by removing some items and then
placing some items back on the stack. For these operations, we define the
standard memory cost applied as follows:
Instruction’s memory cost value is set to zero.
For each item removed from the data stack, instruction’s memory cost is
decreased by 8+L where L is the length of the item in bytes.
For each item added to the data stack the cost is increased by 8+L where L
is the length of the item in bytes.
----
Every instruction has a cost that affects VM run limit. Total instruction
cost consists of execution costand memory cost. Execution cost always
reduces remaining run limit, while memory usage cost can be refunded
(increasing the run limit) when previously used memory is released during
VM execution.
"""
Is there a reason to favor one approach over the other? I think one reason
to favor a direct limit on op_cat is it favors what
I'll dub "context free" analysis, where the performance doesn't depend on
what else is on the stack (perhaps by passing very large arguments to a
script you can cause bad behavior with a general memory limit?). On the
other hand, the reason I prefer the general memory limit is it solves the
problem for all future memory-risky opcodes (or present day memory risks!).
Further, OP_CAT is also a bit leaky, in that you could be catting onto a
passed in large string. The chief argument I'm aware of against a general
memory limit argument is that it is tricky to make a non-implementation
dependent memory limit (e.g., can't just call DynamicMemoryUsage on the
stack), but I don't think this is a strong argument for several
(semi-obvious? I can go into them if need be) reasons.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Wed, Jan 4, 2017 at 9:45 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
> I would assume that the controversial part of op_cat comes from the fact
> that it enables covenants. Are there more concerns than that?
>
> On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> For the record, the OP_CAT limit of 520 bytes was added by Satoshi
>> <https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R425>
>> on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT
>> was disabled.
>> The previous limit was 5000 bytes.
>>
>> On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> Sure, was just upper bounding it anyways. Even less of a problem!
>>>
>>>
>>> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled.
>>> As far as I know, the elements alpha proposal to reenable a limited op_cat
>>> to 520 bytes is somewhat controversial...
>>>
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>> <https://twitter.com/JeremyRubin>
>>>
>>> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau <jl2012@xbt•hk> wrote:
>>>
>>>> No, there could only have not more than 201 opcodes in a script. So you
>>>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>>>>
>>>> For OP_CAT, just check if the returned item is within the 520 bytes
>>>> limit.
>>>>
>>>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>> It is an unfortunate script, but can't actually
>>>> do
>>>> that much
>>>> it seems
>>>> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
>>>> Thus, it would seem the worst you could do with this would be to (10000-520*2)*520*2
>>>> bytes ~=~ 10 MB.
>>>>
>>>> Much more concerning would be the op_dup/op_cat style bug, which under
>>>> a similar script would certainly cause out of memory errors :)
>>>>
>>>>
>>>>
>>>> --
>>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>>> <https://twitter.com/JeremyRubin>
>>>>
>>>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Suppose someone were to use the following pk_script:
>>>>>
>>>>> [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
>>>>> op_2dup, op_hash160, <addr_hash>, op_equalverify, op_checksig]
>>>>>
>>>>> This still seems to be valid AFAICS, and may be a potential attack
>>>>> vector?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
[-- Attachment #2: Type: text/html, Size: 13288 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-01-05 16:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.11263.1483391161.31141.bitcoin-dev@lists.linuxfoundation.org>
2017-01-02 21:39 ` [bitcoin-dev] Script Abuse Potential? Steve Davis
2017-01-03 3:27 ` Jeremy
2017-01-03 3:39 ` Johnson Lau
2017-01-03 5:04 ` Russell O'Connor
2017-01-04 0:13 ` Jeremy
2017-01-04 3:13 ` Russell O'Connor
2017-01-04 14:45 ` Jorge Timón
2017-01-05 16:22 ` Jeremy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox