Virtual transactions

#1

Motivation

Bitcoin transactions can contain multiple inputs and outputs. Where inputs point to the outputs of the prior transactions. The current block validation process has to verify every input is not spent. As far as I know if one of the following is true it is considered that the input is not spent.

  1. When the referred the transaction + output index is a confirmed transaction and it’s not spent. To verify that, We have a database of unspent coins. And it’ll get updated once a block is connected or disconnected.
  2. When the referred transaction + output index is in the mempool and it’s considered as unspent. To verify this, The block creation process should verify the spent inputs that refer to txs in the mempool is only spent once. (I’m not sure if this is the only condition it should verify).

The motivation for virtual transactions is to eliminate the need to verify the second possibility.

Concept

The goal of virtual transactions are to maintain the function of spending unconfirmed transactions while removing the need for the validation of inputs that refer to a tx in the same block (stored in the mempool).

Two things are needed to achieve this goal.

  1. A new transaction type (lets call it TXV), It is an array of virtual transactions (lets call that VTX).
  2. A new local validator. The validator executes all unlocking scripts of the inputs to verify the validity of multiple chained transactions, And it verifies the balance of VTXs that have references to outputs of another VTX.

Each VTX is aware of all of its prior VTXs and the inputs of it can refer to output of them (VTXs that has came prior to it).

TXV needs to remain compatible with the rest of the current codebase. To achieve that it will be morphed to a regular transaction by concatenating all inputs and outputs except for the spent outputs and inputs that have a pointer to a VTX.

A VTX don’t have a global id until it’s included in a block.

If I’m not mistaken, The morphed tx will keep the balance of the transaction. But all unlocking scripts are no longer valid. Which I believe it’s not a major issue.

And every output can be spent once it’s included in a block and a txid is assigned to it.

The txid will remain to be the hash of the TXV, However since these types of transaction are designed to be replaceable, The txhash can change until it’s included in a block.

I’m aware a lot of work is needed to maintain compatibility, building tx formats, parsers, compilers & maybe a new types of data when it comes to communications between the nodes. etc etc.

It don’t consider this as an important feature to be added at this point in time. However, I believe this addition will enable parallel validation of txs until a block creation. Which is a huge upgrade compared to the current mempool implementation.

#2

We talked briefly on Telegram and we agreed that the problem this solves isn’t a big enough problem to change the protocols for, but it still is a fun thought experiment so I’ll try to see if it makes sense.

This creates a bit of an issue. A TXID isn’t assigned, it is calculated from the content. Similarly, the signatures of pay to public-key-hash are signing the actual content of the transaction.

As such I expect that your proposed “compression” of the history of transactions would end up breaking all signatures. Including the first signature spending money already in a block.

I would suggest looking at payment-channels. Payment channels - Bitcoin Wiki

This is similar in your setup except that it basically repeatedly double-spends a transaction with one that pays the receiver more and more money.
The end result is similar, only one transaction to be mined.

#3

Note, The transaction that wraps the virtual transactions doesn’t have any inputs, There’s no need for it to have a predefined content.
The inputs of VTXs would be able to sign, Since they’ll have a predefined content and they would be very similar to a regular transaction. However, The difference is that a modified version of the current validator is needed to take the new rules into account.
In terms of compression, No data is lost. However, Compatibility is needed because a lot of the codebase & the code of other bch tools are dependent on the current tx data structure. If it can represent itself as a standard transaction, It will remain compatible, However, The validation of unlocking scripts would become invalid & the locally spent coins will be invisible.

I understand a lot of work is needed to have this feature. In that respect, At the moment the benefit is certainly not worth the effort.