The Rails release of BSV (v1.0.5) introduces several game changing features that have long been in the making.

1. Activation of the Journalling Block Assembler by default
2. Batch transaction submission
3. Free consolidation transactions

This release is code-named RAILS because its major features are aimed to open new and innovative payment cases using the BSV blockchain protocol and ledger, and empower BSV blockchain companies to build more infrastructure for payments – “payment rails.”

It is the last of these that we will focus on in the post.

The dust limit

Once upon a time some BTC developers, mindful of their parental responsibilities to all participants in the Bitcoin network, introduced a protective mechanism called the Dust limit. Leaving aside the debate about the rightness or wrongness of paternalistic developer attitudes, this limit persists today as a policy enforced by default by miners. It was put in place as an attempt to prevent people from falling into a particular trap.

A typical Bitcoin transaction looks something like this:

The notable part of this example transaction is that values paid (in satoshis) are very large in comparison to the fee. The payment is about $11 USD in today’s money whilst the fee is a tiny fraction of a cent. This tiny fee is what makes micropayments possible. No one wants to pay a significant chunk of their transactions as fees but when they are so low payments of even 1c are very feasible. But there is a lower limit to what makes sense economically. And if you cross that limit far enough you get into territory where you can effectively render some satoshis unusable.

In the above example, we are trying to go beyond micro-payments and into what we will call “nano-payments” by attaching a tiny 10 satoshi output to an existing transaction. This is where the dust limit would normally kick in to prevent the transaction going through, because under the standard fee policies that we are all accustomed to in Bitcoin, this output would require a higher fee to spend than the value of the output itself. It’s economically cheaper to just write that 10 satoshis off than it is to ever spend it. Unless perhaps we wait and hope that BSV blockchain rises many orders of magnitude and fees in satoshis fall equally.

Payment channels are a well-known mechanism enabling exchanges of value incrementally in units so small that they wouldn’t be economical in a Bitcoin transaction on their own. But there are other ways. 

Consolidation transactions

A Bitcoin transaction has a variable number of inputs and a variable number of outputs. When a transaction is accepted the previous outputs (which are referenced by the inputs) are removed from the UTXO database and the outputs are added. So the net effect on the size of the UTXO database (in terms of discrete items not bytes) after accepting a transaction can be expressed as:

utxo_delta = nOutputs - nInputs. 

From a miner’s point of view the size of the UTXO database matters because the larger it is the higher the cost of maintaining it. This is offset by the increased value of transaction fees that results but it is still in all miner’s economic interests to trim the UTXO where possible. Enter the concept of a consolidation transaction which has many inputs and few outputs such that the utxo_delta is substantially negative resulting in a shrinking of the UTXO database. Since this is already an economic net positive for a miner it is feasible for a miner to allow such a transaction with zero fee.

In doing so not only do we enable a lot of existing dust UTXOs to become useful again, but we also open up some powerful new use cases that are not possible with the current dust limit.

In the above example we see a normal transaction with additional 10 satoshi outputs attached. The recipient of these outputs simply collects enough of them to meet the criteria for a free consolidation transaction then converts the collective value of 1000 inputs into a single, higher-value output. The size of the UTXO database is reduced by 999 entries. One might argue that these are UTXOs that wouldn’t have been created without this model being feasible, which may well be true, however, even ignoring existing dust cleanup benefits we end with essentially a net cost in UTXO size of zero whilst enabling highly flexible new use cases.

Nano service use cases

So how might you make use of the ability to pay as low as 1 satoshi for a service? Well that’s for other creative minds to explore but in terms of normal operations of the Bitcoin network here’s a few examples:

• Paying a specific miner a few satoshis to return you a Merkle proof when a transaction is mined (regardless of whether they mine it).
• Paying a specific miner to watch for double spends and notify you.
• Payments to a paymail host.
• Paying a channels server to store and forward your messages while you’re offline (more on that later).
• Paying for insurance or countersigning by a specialist multisig custodian.

Basically any service that is related to an economic transaction could be paid for in this way. The main caveat is there needs to be an existing transaction moving value in excess of a typical transaction fee for the nano-payment to piggy back off of.

What about payment channels?

Payment channels are a perfectly valid way to achieve nano-payments which are useful in many scenarios. A payment channel only becomes useful when the likely settled amount is in excess of a transaction fee, but it allows incremental shifts of value in similarly small amounts to a consolidation transaction. This is useful where you might want to repeatedly use the same nano-service. There are trade-offs around implementation complexity to consider. Where a consolidation transaction differs is that it can be used as a one-off for a particular service without establishing a payment channel-like relationship with the counterparty. Which of the two makes the most sense will come down to a use-by-use evaluation.

So how do we use them?

Much like the early days of raising of the OP_RETURN limit, there will be a few initial barriers to getting such transactions accepted. Many will recall the efforts required to find nodes that supported it and to build connection pathways between enabled nodes so that OP_RETURN transactions could propagate. It took some time and became more reliable over time until blanket adoption was achieved. This will be similar but with a key accelerator provided by the Merchant API (henceforth known as mAPI).

Firstly the creation of dust outputs themselves are still limited to some degree by the dust limit. This limit will be removed entirely by the end of the year allowing even 0 value outputs. In the meantime the 1.0.5 release of bitcoin has at least fixed the hard limit and made it a function of the relay fee set by the Miner. This means that Miners who have upgraded to 1.0.5 should accept outputs greater than 140 satoshis. 

Until widespread deployment by Miners is achieved the dust limit will remain a barrier to getting these transactions relayed which means you shouldn’t assume the same level of zero-conf assurance as a transaction with only non-dust outputs. But for use cases where zero-conf doesn’t matter this is safe to use right now.

Secondly for non-zero conf scenarios the p2p propagation can be bypassed entirely once mAPI supports these transactions. This is a feature of the mAPI 1.2 which is targeted for release in October. Once you couple a 1.2 mAPI with a 1.0.5 BSV you’ll be able to submit both dust output transactions and consolidation transactions directly to a Miner.

Definition of a Consolidation transaction

In order for a transaction to be classified as consolidation by the BSV software, some strict conditions must be met. nChain and the SV team have done some exhaustive analysis to choose these criteria in order to ensure the mechanism isn’t gameable. We have erred very much on the side of caution and so there is plenty of room for the criteria to be relaxed in the future, but the current criteria enable a consolidation transaction to be constructed fairly simply.

A consolidation transaction is a transaction that reduces the number of UTXO’s by a margin that is more valuable for the network than the implied fee. Hence we allow consolidation transactions free from any fees.

The conditions for a consolidation transaction are as follows:

• The scriptPubKey sizes from the transaction outputs spent are compared to the scriptPubKey sizes of the consolidation transaction. The sum of the former must be greater than the sum of the latter multiplied by the consolidation factor (configuration parameter: minconsolidationfactor)
• The transaction input count must be greater than the transaction outputs count multiplied by minconsolidationfactor
• All inputs must have a confirmation count of at least minconsolidationinputmaturity.
• scriptSig sizes of the consolidation transaction have an upper limit of maxconsolidationinputscriptsize bytes long to prevent gaming.
• Inputs spent in consolidation transactions must meet the old test of isStandard() if acceptnonstdconsolidationinput equals 0
• The default value for maxconsolidationinputscriptsize is 150 bytes.
• The default value for minconsolidationfactor is 20
• The default value for minconsolidationinputmaturity is 6 (equivalent to one hour)
• The default value for acceptnonstdconsolidationinput is 0 meaning only standard inputs allowed
• Setting minconsolidationfactor to 0 disables the free consolidation transactions feature

The condition as the formula is:

c = minconsolidationfactor
m = minconsolidationinputmaturity
s = maxconsolidationinputscriptsize
a = acceptnonstdconsolidationinput
isFree = nInputs >= c * nOutputs
       && confirmationCount(input) >= m for all inputs 
       && sum(inputTxScriptPubKeyBytesLen[]) >= c * sum(outputTxScripPubKeytBytesLen[])
       && inputTxScriptSig <= s for all inputTxScriptSig
       && isStandardInput(input) for all inputs unless a == 1

As a general rule of thumb:

• Consolidate at least 100 inputs to one output.
• Only use standard p2pkh inputs or bare multisig with no more than 2 signatures.
• Only use inputs confirmed for at least 6 blocks.
  • This rule can be gotten around simply by constructing the transaction using all available inputs but not broadcasting it until 6 blocks after you made it.

By following these guidelines you should fall well within the strict criteria. The worst that can happen if you don’t is that the transaction will get rejected with a ‘too low fee’ message in which case you can adjust it and try again.

The available set of transaction pricing models will ultimately be determined by miners and tested by market forces. This particular model is intended as a demonstration of what’s possible when restrictions are lifted. The SV team looks forward to seeing in what innovative ways nano-payments can be used.