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

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

[Mark Boldyrev]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

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

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org>:

> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 2122 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

On Fri, May 19, 2017 at 09:07:41AM +0300, Mark Boldyrev via bitcoin-dev wrote:
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Ethan Heilman]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote:
> >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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Ethan Heilman]

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.




On Mon, May 22, 2017 at 12:14 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote:
>> >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