[bitcoin-dev] A proposal to reintroduce the disabled script opcodes

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

[Hampus Sjöberg via bitcoin-dev]

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]

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.

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

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

[Ethan Heilman via bitcoin-dev]

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