Bitcoin offers developers “complete flexibility” and the chance to create something completely new, said Bitcoin Association Training and Development Manager Brendan Lee. He hosted a virtual session on constructing transactions with Bitcoin Script as part of the Bitcoin SV Hackathon webinar series, organized by the Bitcoin Association.
Lee’s talk focused mainly on the Bitcoin Script elements and processes used to construct Bitcoin signatures. However he also touched on some background including the differences between Bitcoin and pre-fork coins like BTC and BCH, and covered the “why” of doing things in certain ways.
Bitcoin Script, he said, is based on Forth—a language that has existed since the 1960s and one Lee has used himself for years. He described it as “a powerful and complete language,” and “like talking to a little brain.” Bitcoin Script itself, he predicted, will become a new kind of computing architecture, to the point where we’ll see processors designed and produced specifically to handle it.
How to build transactions: the basics
Constructing a signed Bitcoin transaction is based on predicate—that is, a statement which can be evaluated against a proposed solution. The Script first feeds inputs onto the stack, which the Script evaluation engine evaluates as true or false, then determines whether a transaction can be broadcast to the network.
He demonstrated some code examples for both simple and multi-signature (multisig) transactions, noting that multisig has always been part of Bitcoin, and that BSV allows about five different ways to construct them. What BSV no longer has is P2SH multisig, or pay-to-script-hash, which was added to the BTC protocol after Satoshi Nakamoto left the project, and according to Lee is “a very insecure way to create transactions.” A BSV node will still validate a transaction that contains P2SH code, though it will ignore that code.
BSV multisig transactions have no limits on the number of signatures required in a multisig transaction, in keeping with its unbounded and unlimited philosophy. However at this stage, checking more than a few signatures in a transaction is computationally expensive, and is not the most efficient way to do things.
He also explained how nLockTime works, saying some sequence values could be left undefined and the transaction itself coded to broadcast at a future date (near or distant). The originator may then alter the transaction at any point before that date.
Lee also demonstrated the various types of SIGHASH functions, including NONE, SINGLE, ALL, ANYONECANPAY, and combinations of those. He explained the advantages and disadvantages of using them, and noted the full potential of each type is yet to be explored.
Legal implications of signing transaction data
One interesting point Lee focused on was the fact that a private key can count as a legal signature, and that any data a transaction contains could hold the originator legally liable once…