Unleashing the power of bitcoin-sv by upgrading the script language

I’m working on a project based on Bitcoin-SV. Mainly we are trying to develop more complex bitcoin scripts to expand bitcoin’s usage to other applications that expand beyond just “sending bitcoins”. From this experience I’ve reached to some thoughts that I’m sharing here.

Having scalable contracts

Ethereum contracts allow for way more complex programming than bitcoin scripts. But the main problem they have is the need for a unified state, which creates scalability issues. The good thing with bitcoin is that you can validate a transaction just by running it in isolation since it doesn’t depend on any external state. The miner will later include it in a block if it’s not a double spend and that’s it. Bitcoin scripts can be pretty complex, but there are some constraints that, if changed, could really unleash the power of bitcoin.

Transactions chain as a decentralised state

One could think about a transactions chain as a chain of small states, and a transaction as an operation that given a state A will return a state B. It’s like a database where you actually link “rows”, so you don’t really need to know the complete state, only the “rows” that you are using. The transaction itself is like at the same time the “lock” that prevents two people of using the same “row” (thus keeping consistency) and the code that makes the state transformation.

Accessing a transaction context

Right now bitcoin scripts cannot access a transaction’s information, which prevents them from accessing this “mini-state”. One technique that we are using is sCrypt’s pseudo OP_PUSH_TX, but is not good enough since you need to include the transaction preimage in every unlocking script that you want to access that information. That only includes some hashes so in order to really access the data you need to also include it separately, hash it and then compare the hashes. This whole process increments a transaction’s size and makes it hard to access to it.

So the first thing that would be useful is the ability to access outputs and inputs information through some op-codes like OP_PUSH_OUTPUT (N) or OP_PUSH_INPUT (N). Both are actually present when running a transaction’s unlocking scripts, so it’s only a matter of making this information available to the script language itself. This would allow for all kinds of arbitrary rules that a transaction should match in order to unlock a particular input.

Iterating over inputs and outputs

The other thing would be to add some bounded iteration mechanism to iterate over inputs and outputs. This way the language would keep being turing-incomplete, avoiding loops and scripts that may never end, but still make it flexible to make expressions of the kind “the sum of all outputs should be X”.

Conclusion

I think that looking at a transactions chain as a decentralised state can make us rethink the way we are using bitcoin currently and what could be done with bitcoin script. Small changes could expand the use cases for bitcoin, while keeping it scalable and fast to process.