Peter Todd [ARCHIVE] on Nostr: š Original date posted:2017-05-22 š Original message:On Mon, May 22, 2017 at ...
š
Original date posted:2017-05-22
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/5c5d8739/attachment.sig>
š Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/5c5d8739/attachment.sig>