The story behind the OP_PUSH_TX technique

Getting your Trinity Audio player ready...

Recently, Stas Trock wrote about how real-world stateful smart contracts can be implemented, deployed and transacted against on the Bitcoin SV ledger. Stas worked closely with sCrypt founder Xiaohui Liu, leveraging the platform to develop the contract. In a Medium post about stateful smart contracts, Xiaohui credited nChain for the concept of OP_PUSH_TX.

We reached out to Steve Shadders, CTO of nChain to follow up on his involvement in this proof-of-concept.

Who came up with the idea of OP_PUSH_TX?

The primary author was a former nChain researcher Ying Chan back in 2016/2017. Others were also involved in the project I believe but Ying’s expertise in this area is unparalleled.

A character named Mr. Word asked about this a few months ago: How did the idea of OP_PUSH_TX come to be?

Since I was not there at the time, I thought I’d ask Ying to answer this directly:

(The) motivation was I wanted to see what limitations of bitcoin could be overcome given unlocked opcodes and no limit

Back then it was still just BTC on the scene

In OP_PUSH_TX, the private key is pushed on-chain. Can you talk through why the private key does not need to be secured in this case?

It is only the private key used to generate a signature over the pushed transaction. That signature is needed to verify that OP_CHECKSIG runs validly and confirms what you’ve calculated matches the transaction you’re currently in.

Since the private key doesn’t actually secure any funds there is no loss of security if you publish it as long as you don’t use it again.

By pushing the private key, the calculations become vastly simpler as you can recalculate many elements of the ECDSA signature algorithm.

You would use a DIFFERENT private key to secure the transaction itself, which is of course not revealed.

Can you talk through how keys are not necessary to spend Bitcoin with the scripting language fully unlocked?

Technically a script doesn’t require signature checks, however they are normally used as a mechanism to restrict the ability to transfer coins to a person that holds a secret.

A hash puzzle does this also, but it requires publication of the secret when you solve the script puzzle. 

An ECDSA signature allows proof of knowledge of a private key without having the reveal the private key.

Are any of the techniques utilized here nChain intellectual property? If so, which patents in particular?

There are at least nine related patents that I’m aware of that specifically deal with this technique and additional extensions. The artificial limits imposed on BTC at the time of invention meant that we had to wait to restore the protocol to be able to see them in a live environment.

We are currently reviewing and retesting these techniques against Genesis Bitcoin rules.

Could OP_CODESEPARATOR (or any other op codes) influence the functionality here?

I’m sure OP_CODESEPERATOR could be used to create composite functionality but it is not required for this technique.

Steve, you mentioned to me previously that you explained this technique to the Bitcoin Cash lead developers in early 2018, before the birth of Bitcoin SV. Could you elaborate on what happened there?

In March 2018 there was furious debate in the BCH community about a proposed new op code OP_GROUP. Essentially this op code allowed you to “colour” a UTXO and impose a very limited forward condition on that UTXO and all its descendants that it must carry the same colour.

This was touted as a method of enabling permission-less tokens on BCH. The proposal was so controversial that the discussions turned to possibility of a hash war and a chain split.

Wanting neither a chain split nor the new OP_GROUP op code, nChain explained the technique would solve the same problem along with enabling much more and did not require any new op codes at all. It just required restoring the script language to its former glory which was supposed to already be on the BCH roadmap.

This solution satisfied ABC’s desire to introduce this op code and also met the function requirements that Bitcoin Unlimited were pushing for. Unfortunately, the proposal was met with skepticism that it would even work and that the scripts would be too large.

We’ve proven the first point already through the work that the sCrypt team has done. The second will be demonstrated to be a non-problem in time using additional techniques I’m working on.

Why in your opinion would this demonstration encourage adoption?

There has long been a belief that Bitcoin lacked one fundamental feature that Ethereum has. That is the ability carry forward conditions of a script into the next transaction. That is, you can set out conditions for spending a coin, but you can’t make one of those conditions: that a specific condition must be included in the next descendant transaction.

This technique shows that it is can be done and busts that myth. By having access to the transaction in the script itself you can check the transaction for script portions or check for other characteristics and force the script to fail if they are not present.

Conclusion

Thank you, Steve, for taking the time to answer these questions. I hope the readers can get a better view into the various scripting techniques that are now possible on Bitcoin SV.

The quotes in this article were lightly edited for clarity.