Skip to content

Instantly share code, notes, and snippets.

@RobinLinus

RobinLinus/enhancing-bitcoin-script.md

Last active April 22, 2022 19:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save RobinLinus/379790b1279e810a750deeedd989a911 to your computer and use it in GitHub Desktop.
Save RobinLinus/379790b1279e810a750deeedd989a911 to your computer and use it in GitHub Desktop.
Download ZIP
Enhancing Bitcoin's scripting capabilities with client-side validation
Raw
enhancing-bitcoin-script.md

Enhancing Bitcoin's scripting capabilities with client-side validation

TL;DR: We can enhance Bitcoin's scripting capabilities with client-side validation protocols. However, off-chain protocols like RGB or Taro do require some on-chain data.

Suppose we're given a client-side validation scheme for tokens on Bitcoin such as Omni, RGB, or Taro.

We want to express a simple spending condition that we cannot express in Bitcoin Script alone. For example, a hashed timelock contract that uses SHA3 instead of SHA2. So we want to express:

  • Alice can take the token if she reveals the SHA3 preimage of <hash> within a week.
  • Otherwise, after one week, Bob can take the token.

The issue here is that we cannot force Alice to actually reveal the preimage. This is because the contract is not enforceable by Bitcoin (Script) consensus, so an invalid RGB/Taro spend is still a valid Bitcoin spend. Alice can always refuse to follow the rules and simply burn the token instead of revealing the preimage. This is unfair for Bob.

To solve that issue Bob needs to specify upfront a second UTXO that acts as a fallback for Bob to recover the token in case Alice breaks the rules and burns it.

For the contract's state to be unambigous Alice has to reveal her preimage publicly on-chain (e.g. in an op_return). This way everyone can independently verify if Alice actually obeyed the contract. (Or if Bob is allowed to use the second UTXO to recover the burned token.)

Summary: If Alice reveals the pre-image on-chain by time X the token teleports to UTXO A, otherwise it teleports to UTXO B.

Without on-chain data

If the protocol wants to avoid all on-chain data (such as RGB and Taro) then Alice has to use a collateral which incentivises her to obey the contract. However, this approach has fundamental issues and limitations:

  • The collateral has to be at least 1:1. Otherwise, Alice can cause more damage to Bob than Bob to Alice. This generally means Alice can extort Bob for the excess amount and it would be rational for Bob to accept (hostage situation).
  • When Alice commits the pre-image and reveals it later when spending the token, she never actually reveals it to Bob, because the commitment is revealed peer-to-peer to the next recipient only.
  • A software error on one side causes losses for both sides.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment