Too late for OP_PUSH_TX or equivalent?

[mr-word]

(copied/edited from a message a sent to shadders)

---

I have one question about Bitcoin's L1.
I really hope I am not understanding something about Bitcoin's script and that I'm simply wrong about these posts.
Thank you in advance if you have a minute to process these, especially the most recent one (first in the list). I'm reaching out to you because every other BSV dev outright ignores what I'm trying to say and essentially switches to saying the equivalent of "you'll see, you nonbeliever". The spec is here now, it's either possible or not.

• https://word.site/2020/01/07/shape-of-mana/
• https://word.site/2019/12/09/shardlets/
• https://word.site/2019/11/28/csw-oracles/

To be very clear, I am not trying to make yet another network. I would absolutely love to discover this was possible on BSV, I want to be able to retract those posts and work on Bitcoin directly.

---

Someone pointed me to this repo for the actual spec and indeed and it looks like there is nothing that would enable this functionality without the use of oracles. However, OP_PUSH_TX would be relatively simple to implement, and general enough to achieve everything I describe in the posts above, and crucially it would not change the asymptotic validation complexity at all.

[shadders]

The functionality you describe for OP_PUSH_TX is already possible on bitcoin sv using a technique developed by Nchain a few years ago. Please get in touch through the support page at bitcoinsv.io to discuss further.

[mr-word]

without the use of oracles

Looking forward to hearing more!

[mr-word]

I emailed the address on the support page and haven't heard back. If the technique is patented as CSW has implied then I don't see what's wrong with sharing it. I don't mind waiting but I'm itching to start translating EVM-based contract systems into UTXO form.

[mr-word]

nvm, I see the discussion in atlantis chat. Thank you!

[shilch]

For the reader interested in the technique:

You can create a scriptPubKey that requires the spending transaction to be pushed to the stack. Then, inside script, you calculate the sighash and check it against the signature provided. Then you do an OP_CHECKSIGVERIFY to ensure that the provided signature really is a valid one.
On the stack you are now left with the spending transaction. It could actually be a different transaction but only if one found a collision (which is very very very unlikely). On that spending transaction you can put more constraints like where the output amounts should go.

[shade]

@shilch I'm confused, how can you calculate the sighash of the transaction without replacing the scriptSig with the scriptPubKey in the spending transaction. AFAIK scriptPubKeys can't reference themselves...

[shilch]

@shade Sorry for the delayed response, I somehow didn't get any notification from GitHub.
Could you explain that in more detail? I cannot follow.

[shade]

@shilch Oh no worries. Sorry about the late response from me too (same issue). I think the medium article from the Scrypt team cleared up my confusion.