The simplicity of Flexible Transactions

Flexible Transactions is a technology I wrote that does only one thing, and it does it well. It upgrades the way that a Bitcoin transaction is stored.

The way that Satoshi Nakamoto initially designed the way that transactions were stored is a very old-fashioned idea. The old format lists byte-by-byte what is allowed and what comes next. As you can imagine that specification is quite large. It is in actual fact hardly documented at all.

To make a bit more clear what the old format does is it specifies separately the size of a list and the actual items of a list. It would be so much simpler if you could just skip the size of the list from your specification.

Flexible Transactions adds a way to ignore the details by adding a simple repetitive design. Then instead of talking about low level ordering of bytes, we describe the allowed types of tokens. Where a token is for instance the previous-transaction-id, another is amount.

This has the effect that computer code that reads or writes the transaction format is shorter. It has a lot less details to worry about. Its about 25% less lines of code to write out a Flexible Transaction than it is to write out an old type transaction.

Building blocks

As Flexible Transactions basically reduces saving and loading of a transaction to a series of tokens, that makes building on top of it very simple. So the question is how can we leverage this simple model for our benefit?

First idea was that we can fix malleability. After we activate FlexTrans the fixing of malleability is only 20 lines of extra code. That seemed cheap enough, so that change is made default part of FlexTrans.

Second idea was to fix a more esoteric issue where a hardware wallet needed to trust the computer it was connected to. In FlexTrans we add the amount as a required part of a transaction. This is no longer unique and Bitcoin Cash introduced this as a required part too. So we went a bit further and added the ability to create cheap double-spent proofs as a way to protect receivers from the risk of double-spends.

Smallest possible transaction

A couple of days ago we were brainstorming about how to save more bytes in transactions. In itself Flexible Transactions already saves about 5% space on old transactions. The question is how much further we could go, theoretically.
The first idea I came up with is to change the first 4 bytes of the version of a transaction to become a variable-width-integer. This would be backwards compatible with current transactions if we just state that bytes 2,3&4 are always zero in the old format.
For Flexible Transactions (and any future transaction version) it would remove a further 3 bytes.

A second idea is about the way that any transaction input currently refers to the previous transaction it attempts to spend. The way that is done is to store a 32 byte transaction-id. Without removing this feature, we could add an optional way to refer to a previous transaction by registering a block-height as well as a transaction-index into that block. This would only take around 7 bytes, and thus save 25 bytes.

Using Flexible Transactions the introduction of more tokens, like the 2 I just described, is extremely cheap. We can ignore the saving/loading complexity and focus only on the actual meaning of the new tokens.
The downside of block-height idea is that a pruning node would need to have a second way to do lookups of transactions in the UTXO database.

Another idea I came up with is based on a pattern we see often in the blockchain. A person has a bitcoin-address and over time she receives dozens of payments on that one address. Due to the way that Bitcoin works, spending from that one address actually requires each and every incoming payments to match one signature on the spending transaction.

The idea then is to introduce a new tag in Flexible Transactions which essentially states 'repeat previous signature'. The effect is that if you spend 10 payments from 1 address, you only need to sign your transaction once and then provide 9 bytes for the following nine inputs. This saves over 100 bytes for each input.

I wanted to share this way of thinking with you because I think its very exciting and allows a lot of things to become simpler. I also wanted to know if you think Flexible Transactions is something that should be enabled on Bitcoin Cash in a year or two.