Brendan Lee: Bitcoin transactions offer complete flexibility, potential

Getting your Trinity Audio player ready...

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 it’s signed.

“This is a point I really want to hammer home,” he said. Bitcoin is private but not anonymous, and it’s always possible to tie a Bitcoin private key to a real-world identity.

“Bitcoin provides many tools that allow you to moderate what goes into a transaction… you can think of ways to apply your own identity, and apply it in useful ways.”

For this reason, he said, a developer would want to be prudent about what data in the transaction can be signed. This is more of an issue on BSV and on the Metanet, where a single transaction can potentially contain a lot more than just payment information—for instance, user-generated data such as a social network post. An existing example is Baemail, which encrypts the full text of an email message and includes it in a transaction.

If you don’t know what’s in a transaction, or don’t want to be held legally responsible for signing it, Lee added, it’s best to use Script to ignore those parts of the transaction. The OP_CODESEPARATOR function is useful in this case, and the evaluator will ignore any data placed after the second one in a transaction script.

Questions, answers, and huge potential

It was clear from the questions and answers that most participating in the webinar were beginners, if not to Bitcoin then certainly to the BSV protocol. Questions ranged from what tools and languages were best to develop for Bitcoin, and whether there were existing code libraries to use.

Lee said programming language is usually a matter of choice, but added that the most widely-used language in BSV is actually JavaScript (eg: Money Button Connect), though there are some notable Python projects, like ElectrumSV.

“The nature of Bitcoin Script is interesting,” he said. “It’s virtually unlimited in what you can do, but it’s not very user-friendly at the moment. It can be very easy to make a mistake, so be careful.”

“Not very user-friendly” refers to BSV being relatively new, at least in terms of its extended data-processing abilities. But that’s also an advantage: it offers opportunities for developers to build templates and libraries for others to use, something Lee predicted there would be a market for in the coming years.

All said, Bitcoin is an open book and it’s an exciting environment for new and existing developers to enter. There’s so much potential still to be explored. For developers, that presents an opportunity to not spend their careers regurgitating existing code and structures, but to explore and invent. And the rewards for those who invent something novel and innovative could be far greater.