TS 2021.012-20

Transaction ancestors

Please note this standard was previously named SPV Envelope. The working name is used in the proposal below.

Purpose

The SPV envelope, along with encapsulated Merkle Proof, is fundamental to the Simplified Payment Verification (SPV) model that underpins bitcoin scaling. As there is likely to be a wide variety of wallet implementations transmitting and receiving SPV information for various reasons, it simplifies implementations if a standard format is adopted.

What is the problem you are trying to solve?

In many cases, broadcasters of transactions to miners do not have the information required to perform an independent check of transaction validity, namely, pass/fail assessment, correct miner fee and signature integrity. Additionally, SPV envelope enables a higher level of confidence in transactions with unconfirmed ancestors, such as reduced double spend risk, and transactions with interim state, such as state channels.

What are you hoping to achieve?

Establish a standardised method of communicating the supplementary information needed for these independent transaction checks to be performed.

Is there an industry need?

Industry has expressed a desire for SPV capability, of which SPV envelope is foundational. SPV allows wallet providers to interoperate with less trust, becoming more robust and resilient. Today, we already see communication issues between leading wallet implementations on BSV. In almost all cases, issues arise when a broadcaster of a transaction cannot review the details of each transaction’s inputs prior to broadcast. This eliminates the ability to run transaction checks prior to broadcast. Under the SPV paradigm, all supplementary transaction information is provided, allowing wallet providers to mitigate the above issue.

Value proposition

SPV envelopes allow for standardised SPV payment communications which have the following benefits:

• Transactions can fail prior to committing to the network. SPV allows for transaction screening such that invalid transactions including those that do not pay enough fees can be excluded. This is desirable because:
  • Nodes can ban senders of invalid transactions.
  • An unexpectedly low fee could result in:
    • transaction invalidity
    • a lower service level such as a slower confirmation
    • no Merkle Proof
    • or double spend callback
• Consider the case where a transaction’s miner fee is insufficient for primary mempool acceptance. Such a transaction would remain unconfirmed in the miner’s secondary mempools.

• Transactions with interim states can be handled with a higher level of confidence in validity (state channels).

• Transactions that are incrementally signed (multisig) can fail as soon as an incorrect signature is used. This is as opposed to discovering the entire transaction is invalid upon submission to a miner.

• Transactions with unconfirmed ancestors can be handled with a higher level of confidence (if optional mAPI responses are provided). -If a public key can be linked to an identity, signature integrity can be verified prior to node submission for legally binding digital signatures (and sufficient legal records).

Who do you see as the intended beneficiaries?

Wallet services (BSV native unit and tokens).

What are the ways in which the beneficiaries will benefit?

When a wallet receives a transaction from a competing wallet implementation, it can run a pre-broadcast validity check. Prior to broadcasting to a miner, the wallet can check if:

• the transaction is valid
• the miner fee is correct
• and verify the integrity of each input’s signatures.

Optionally, mAPI response information within each SPV envelope can provide the wallet with a higher degree of confidence that the transaction will not be double spent.

Collaborators

n/a

Prior art

The Merkle Proof Standard is encapsulated by SPV Envelope.

Proposed solution

The SPV Envelope is a data structure that encapsulates a transaction along with Merkle Proofs and full transactions of confirmed ancestors. This structure may also need to include intermediate unconfirmed ancestors to make an unbroken chain back to a confirmed transaction. Optionally, unconfirmed transactions can be accompanied by mAPI responses signed by miners to demonstrate that the transaction has been broadcast and accepted for block inclusion.

The inclusion of a combination of Merkle Proofs and signed mAPI responses will provide all the information required to assess the likelihood of the transaction being confirmed is provided. The recipient can optionally register for double spend notifications on all unconfirmed ancestors via mAPI if the mAPI responses are deemed inadequate. We use raw transaction bytes, as the transaction IDs need to be calculated as part of the proof process.

Transactions will need to be parsed in order to determine input references as well as output values to calculate fees. It is generally assumed that an SPV envelope will contain a proof for only one transaction. However, the data structure accommodates the case where more than one transaction is included.

Required data

We can see from the above description that the following data is required within the SPV Envelope:

1. The full transaction to be broadcasted.
2. The full transactions of each input in bullet point 1.
3. The full transactions of each input in bullet point 2, if any input in bullet point 2 are unconfirmed. This is being traced back to the first confirmed transaction ancestor.
4. The Merkle Proof of each confirmed transaction in bullet points 2 and 3
5. The mAPI response for each unconfirmed transaction in bullet points 2 and 3 (optional)

SPV Envelope structure

(u) = unconfirmed

(c) = confirmed

The root must be a (u)

The root may contain txid and mapiResponses

Every (c) must be the end of a branch

Every (u) must have input branches that all end in (c)

Every (c) must have a rawTx and proof

Every (u) must have a rawTx and specify its inputs

If any (u) contains mapiResponses, all (u) must contain it

However, mapiResponses is always optional for the root

A sample structure is defined below:

txid1-(u)

•txid2-(c)

•txid3-(u)

• •txid4-(u)

•  • •txid5-(u)

•  •  • •txid6-(c)

• •txid7-(c)

•txid8-(c)

{

  txid: 'txid1', // Optional

  rawTx: '...',

  mapiResponses: [ // Optional

    {}, // Response from miner 1

    {} // Response from miner 2

  ],

  inputs: {

    txid2: {

      rawTx: '...',

      proof: 'tscBinaryProof'

    },

    txid3: {

      rawTx: '...',

      mapiResponses: [ // Optional

        {}, // Response from miner 1

        {} // Response from miner 2

      ],

      inputs: {

        txid4: {

          rawTx: '...',

          mapiResponses: [ // Optional

            {}, // Response from miner 1

            {} // Response from miner 2

          ],

          inputs: {

            txid5: {

              rawTx: '...',

              mapiResponses: [ // Optional

                {}, // Response from miner 1

                {} // Response from miner 2

              ],

              inputs: {

                txid6: {

                  rawTx: '...',

                  proof: 'tscBinaryProof'

                }

              }

            }

          }

        },

        txid7: {

          rawTx: '...',

          proof: 'tscBinaryProof'

        }

      }

    },

    txid8: {

      rawTx: '...',

      proof: 'tscBinaryProof'

    }

  }

}