Jeremy Rubin [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-01 📝 Original message:I agree this emulation ...
📅 Original date posted:2022-02-01
📝 Original message:I agree this emulation seems sound but also tap out at how the CT stuff
works with this type of covenant as well.
Happy hacking!
On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> > CTV was an output of my personal "research program" on how to make simple
> > covenant types without undue validation burdens. It is designed to be the
> > simplest and least risky covenant specification you can do that still
> > delivers sufficient flexibility and power to build many useful
> applications.
>
> I believe the new elements opcodes [0] allow simulating CTV on the liquid
> blockchain (or liquid-testnet [1] if you'd rather use fake money but not
> use Jeremy's CTV signet). It's very much not as efficient as having a
> dedicated opcode, of course, but I think the following script template
> would work:
>
> INSPECTVERSION SHA256INITIALIZE
> INSPECTLOCKTIME SHA256UPDATEE
> INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE
> INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE
>
> PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE
> PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE
>
> { for <x> in 0..<numoutputs-1>
> <x> INSPECTOUTPUTASSET CAT SHA256UPDATE
> <x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT
> SHA256UPDATE
> }
>
> SHA256FINALIZE <expectedhash> EQUAL
>
> Provided NUMINPUTS is one, this also means the txid of the spending tx is
> fixed, I believe (since these are tapoot only opcodes, scriptSig
> malleability isn't possible); if NUMINPUTS is greater than one, you'd
> need to limit what other inputs could be used somehow which would be
> application specific, I think.
>
> I think that might be compatible with confidential assets/values, but
> I'm not really sure.
>
> I think it should be possible to use a similar approach with
> CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style
> signatures on elements/liquid. Though you'd probably want to have the
> output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN
> IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256
> DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're
> not signing something that might be misused in a different context later)
>
>
> Anyway, since liquid isn't congested, and mostly doesn't have lightning
> channels built on top of it, probably the vaulting application is the
> only interesting one to build on top on liquid today? There's apparently
> about $120M worth of BTC and $36M worth of USDT on liquid, which seems
> like it could justify some vault-related work. And real experience with
> CTV-like constructs seems like it would be very informative.
>
> Cheers,
> aj
>
> [0]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> [1] https://liquidtestnet.com/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/54203ebd/attachment-0001.html>;
📝 Original message:I agree this emulation seems sound but also tap out at how the CT stuff
works with this type of covenant as well.
Happy hacking!
On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> > CTV was an output of my personal "research program" on how to make simple
> > covenant types without undue validation burdens. It is designed to be the
> > simplest and least risky covenant specification you can do that still
> > delivers sufficient flexibility and power to build many useful
> applications.
>
> I believe the new elements opcodes [0] allow simulating CTV on the liquid
> blockchain (or liquid-testnet [1] if you'd rather use fake money but not
> use Jeremy's CTV signet). It's very much not as efficient as having a
> dedicated opcode, of course, but I think the following script template
> would work:
>
> INSPECTVERSION SHA256INITIALIZE
> INSPECTLOCKTIME SHA256UPDATEE
> INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE
> INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE
>
> PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE
> PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE
>
> { for <x> in 0..<numoutputs-1>
> <x> INSPECTOUTPUTASSET CAT SHA256UPDATE
> <x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT
> SHA256UPDATE
> }
>
> SHA256FINALIZE <expectedhash> EQUAL
>
> Provided NUMINPUTS is one, this also means the txid of the spending tx is
> fixed, I believe (since these are tapoot only opcodes, scriptSig
> malleability isn't possible); if NUMINPUTS is greater than one, you'd
> need to limit what other inputs could be used somehow which would be
> application specific, I think.
>
> I think that might be compatible with confidential assets/values, but
> I'm not really sure.
>
> I think it should be possible to use a similar approach with
> CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style
> signatures on elements/liquid. Though you'd probably want to have the
> output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN
> IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256
> DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're
> not signing something that might be misused in a different context later)
>
>
> Anyway, since liquid isn't congested, and mostly doesn't have lightning
> channels built on top of it, probably the vaulting application is the
> only interesting one to build on top on liquid today? There's apparently
> about $120M worth of BTC and $36M worth of USDT on liquid, which seems
> like it could justify some vault-related work. And real experience with
> CTV-like constructs seems like it would be very informative.
>
> Cheers,
> aj
>
> [0]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> [1] https://liquidtestnet.com/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/54203ebd/attachment-0001.html>;