Ethan Heilman [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-22 📝 Original message:My OP_CAT usecase only ...
📅 Original date posted:2017-05-22
📝 Original 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.
On Mon, May 22, 2017 at 12:14 PM, Peter Todd <pete at 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
📝 Original 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.
On Mon, May 22, 2017 at 12:14 PM, Peter Todd <pete at 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