When new opcodes were added (or rather re-enabled) in May 2018 hardfork of Bitcoin Cash there was quite an expectation of a smart contract boom. What can we see today, nearly half year later? There were some cool new ideas mostly revolving around token protocols utilizing OP_RETURN to store metadata attached to coins. There’s also ChainBet protocol utilizing OP_MOD to provide cryptographically proven random bets, and recently Forfeits were proposed that use OP_CHECKDATASIG (that is expected to activate in November hardfork) to prove doublespend attempt.
I re-read the paragraph above and found it too technical.
This is a glimpse of what I struggled every time I tried to read some spec or article that proposes a new, clever Bitcoin Cash smart contract. This is because of Script. This famous, intentionally not Turing-complete, FORTH-like language feels for me almost like one of those esoteric languages made with the sole purpose of making your brain hurt. This is mainly because it belongs to a quite obscure family of stack-oriented languages. That means no ordinary variables that programmers are used to. Instead you have to keep the entire execution stack in your head to understand what’s going on. And it’s Reverse Polish Notation. Oh, I know it! I remember doing that exercise on a blackboard during a CS 101 lecture 10 years ago. …
Let’s say, Alice and Bob have an open channel. Bob is a merchant. Alice is a client.
We create 2 LN nodes, lets call them Twin-of-death-1 and Twin-of-death-2.
Twin-of-death-1 creates a payment channel with Alice and only Alice. That means Alice can use this channel only to send money to the twin and no one else.
Twin-of-death-2 creates a payment channel with Bob and only Bob. That means Bob can use this channel only to send money to the twin and no one else.
Twin-of-death-1 makes a payment to Twin-of-death-2 routed through Alice-Bob channel with an amount such that the balance is 100% on Bob’s side now. …