Discussion:
A proposal to reintroduce the disabled script opcodes
Add Reply
Mark Boldyrev via bitcoin-dev
2017-05-19 06:07:41 UTC
Reply
Permalink
Raw Message
Back in 2010, there was a bug found in Core which allowed denial-of-service
attacks due to the software crashing on some machines while executing a
script - see CVE-2010-537.
I believe the removed ("disabled") opcodes should be re-introduced along
with a standardized behavior definition.
For example, when execution of an opcode results in an arithmetic error,
such as OP_DIV with a zero divisor, the script should exit and fail.
The string splice opcodes should also check their arguments for
correctness, etc.

These opcodes would enhance the flexibility of scripts and allow
sophisticated native smart contracts to be created.
Hampus Sjöberg via bitcoin-dev
2017-05-19 13:13:03 UTC
Reply
Permalink
Raw Message
AFAICT, re-enabling these old OP-codes would require a hardfork.

If we had SegWit enabled, we could via a soft fork allocate new OP-codes
for the same functionality (by introducing a new version of Script).
I believe the Elements alpha project has been experimenting with
re-enabling old OP-codes: https://elementsproject.org/elements/opcodes/

2017-05-19 8:07 GMT+02:00 Mark Boldyrev via bitcoin-dev <
Post by Mark Boldyrev via bitcoin-dev
Back in 2010, there was a bug found in Core which allowed
denial-of-service attacks due to the software crashing on some machines
while executing a script - see CVE-2010-537.
I believe the removed ("disabled") opcodes should be re-introduced along
with a standardized behavior definition.
For example, when execution of an opcode results in an arithmetic error,
such as OP_DIV with a zero divisor, the script should exit and fail.
The string splice opcodes should also check their arguments for
correctness, etc.
These opcodes would enhance the flexibility of scripts and allow
sophisticated native smart contracts to be created.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter Todd via bitcoin-dev
2017-05-22 14:09:19 UTC
Reply
Permalink
Raw Message
Post by Mark Boldyrev via bitcoin-dev
Back in 2010, there was a bug found in Core which allowed denial-of-service
attacks due to the software crashing on some machines while executing a
script - see CVE-2010-537.
I believe the removed ("disabled") opcodes should be re-introduced along
with a standardized behavior definition.
For example, when execution of an opcode results in an arithmetic error,
such as OP_DIV with a zero divisor, the script should exit and fail.
The string splice opcodes should also check their arguments for
correctness, etc.
These opcodes would enhance the flexibility of scripts and allow
sophisticated native smart contracts to be created.
It'd help your case if you gave us some examples of such scripts being used.

See the CHECKSEQUENCEVERIFY and my own CHECKLOCKTIMEVERIFY bips for examples of
how to write up such use-cases.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Ethan Heilman via bitcoin-dev
2017-05-22 14:41:40 UTC
Reply
Permalink
Raw Message
Post by Peter Todd via bitcoin-dev
It'd help your case if you gave us some examples of such scripts being used.
I want OP_CAT so that I can securely and compactly verify many hashes and
hash preimages. This would shrink offchain Tumblebit transactions
significantly.

For instance if I want a transaction TxA which checks that a transaction
TxB releases preimages x1,x2,...,x10 such that
y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check
that the preimahes hash correctly. With OP_CAT I would only have to store
one hash in TxA, yhash

ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10)

TxA could then just hash all the preimages supplied by TxB and confirm they
hash to TxA. This would reduce the size of TxA from approx 10*32B to
32+10*16B. I have a version which improves this further but it is more
complex.

Most of the math OP codes aren't particularly helpful due to their 32bit
nature and their strange overflow behavior.
Peter Todd via bitcoin-dev
2017-05-22 16:14:04 UTC
Reply
Permalink
Raw Message
Post by Ethan Heilman via bitcoin-dev
Post by Peter Todd via bitcoin-dev
It'd help your case if you gave us some examples of such scripts being
used.
I want OP_CAT so that I can securely and compactly verify many hashes and
hash preimages. This would shrink offchain Tumblebit transactions
significantly.
For instance if I want a transaction TxA which checks that a transaction
TxB releases preimages x1,x2,...,x10 such that
y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check
that the preimahes hash correctly. With OP_CAT I would only have to store
one hash in TxA, yhash
ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10)
TxA could then just hash all the preimages supplied by TxB and confirm they
hash to TxA. This would reduce the size of TxA from approx 10*32B to
32+10*16B. I have a version which improves this further but it is more
complex.
Most of the math OP codes aren't particularly helpful due to their 32bit
nature and their strange overflow behavior.
Great! That's exactly the type of justifying use-case we need for a BIP.

An OP_CAT will have to have limits on maximum output size; how big an output
does your application need?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Ethan Heilman via bitcoin-dev
2017-05-22 16:43:11 UTC
Reply
Permalink
Raw Message
My OP_CAT usecase only needs to glue together hash outputs, so two 32
Bytes inputs generating a 64 Byte output. However increasing this
would enable additional space savings. I would push for an OP_CAT
which can generate an output of no greater than 512 Bytes. Is there
are maximum byte vectors size for script?

The ideal instruction for this usecase be an instruction that pops N
vectors of the stack, concatenates them together and hashes them.
OP_CATHASH256(N) --> OP_HASH256(v1||v2||..||vN)
where || denotes concatenation. You could do this in a streaming
fashion so that memory usage would never exceed 32 Bytes regardless of
the size of the input vectors.

However I recognize that OP_CAT is more generally useful and it
already in scripts but just disabled.
Post by Peter Todd via bitcoin-dev
Post by Ethan Heilman via bitcoin-dev
Post by Peter Todd via bitcoin-dev
It'd help your case if you gave us some examples of such scripts being
used.
I want OP_CAT so that I can securely and compactly verify many hashes and
hash preimages. This would shrink offchain Tumblebit transactions
significantly.
For instance if I want a transaction TxA which checks that a transaction
TxB releases preimages x1,x2,...,x10 such that
y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check
that the preimahes hash correctly. With OP_CAT I would only have to store
one hash in TxA, yhash
ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10)
TxA could then just hash all the preimages supplied by TxB and confirm they
hash to TxA. This would reduce the size of TxA from approx 10*32B to
32+10*16B. I have a version which improves this further but it is more
complex.
Most of the math OP codes aren't particularly helpful due to their 32bit
nature and their strange overflow behavior.
Great! That's exactly the type of justifying use-case we need for a BIP.
An OP_CAT will have to have limits on maximum output size; how big an output
does your application need?
--
Loading...