SPV Envelope
by Julie G on 20 July 2021
Category
Expiry date
Licence
Applies to
Standard Stage
In Consideration Draft Internal Review Public Review Published Recommended
Thanks for submiting your comments!

The Bitcoin SV Technical Standards Committee is calling for expressions of interest to join the Working Group as a reviewer of the TS 2021.012-20: SPV Envelope standard during the drafting process. If you wish to participate in the internal development phase of this standard, please complete the application form. You are also required to submit a short article not exceeding 500 words, addressing the application criteria, as part of the application process.

Deadline to apply has been extended. Applications must be received by August 18, 2021. Note that a public review process will be open to anyone who wishes to provide input later on this standard development process.

View application criteria
SPV envelope in a nutshell

The SPV envelope, along with encapsulated Merkle Proof, is fundamental to the Simplified Payment Verification (SPV) model that underpins bitcoin scaling. SPV Envelopes establish a standardised method of communicating the supplementary information required for independent transaction checks to be performed. 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.

TS 2021.012-20

SPV Envelope

ProposerAngus Adams
TSC SponsorAndy Mee
AuthorsAngus Adams, Ty Everett, Jad Wahab
ReviewersOpen for expression of interest to join the working group

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)

Brief Working Group process description

ExternalCall for expressions of interest to serve on review panel
InternalDraft >> Review >> Iterate (if required)
InternalSpecialist review (legal, IP, Compliance) >> Iterate to draft (if required)
ExternalPublic review >> respond to comments >> Iterate to draft (if required)
ExternalRatification by TSC

Application criteria

Persons wishing to apply to join the working group should meet the following criteria:

  • Can demonstrate at least one of the following:
    • Subject matter expertise in the standard proposal’s specific domain. Bachelor’s degree or equivalent experience in a relevant field of study e.g. Engineering, Computer Science, Mathematics, other relevant science fields
    • Are a key stakeholder in the outcomes of this standard either as an existing or future user or implementer of the standard
    • Have significant experience in standards development associated with an internationally recognised standards institution
  • Are willing to sign a mutual multi-party NDA for the duration of the Working Group lifecycle.
    • The NDA define what should be considered as confidential information so that it is clear to all parties throughout their relationship what is considered confidential and what subsequently cannot be disclosed. The NDA will ensure participants are clear what information (of theirs) is protected, and what information (of the other parties) cannot be disclosed, marking participant comfortable to discuss with other parties for the purpose of developing a standard. It also means that if participants are generating IP during the working group process, they will have some re-assurance that they can protect that IP themselves, if they want to.
  • Are willing to sign a Copyright Assignment for the content of the Standard document.
    • Copyright protects the words in the document, the figures, pseudo-code, data structures, etc. The owner of the copyright can control publication, distribution and modification of the work. Contributors to the standard will be asked to sign a Copyright Assignment to transfer copyright ownership from the authors to the Bitcoin Association. The assignment is a Conditional Assignment, that is, the transfer of ownership is only effected on certain conditions being satisfied by the Bitcoin Association. As copyright owner, Bitcoin association will be responsible for managing the copyright, thus allowing contributors to focus on the technical standard itself. It also simplifies downstream licensing, since third parties need only seek a licence from a single Licensor.
  • Have sufficient time to commit to the review process over the expected lifetime of the Working Group. The time commitment will depends on lenght and complexity of each standards. The expected time commitment will also depend on the role.
    • Author: As a guideline a typical technical document can take between 24 and 50 hours to complete usually across 3-4 months. Additional time for the review process will be required.
    • Reviewer: as a guideline, Working Group life cycles are expected to be in the range of 2-3 months and would typically require 5-10 hours review work split across 2-3 iterations of a draft standard.
Interested in working on this standard?

This standard is in the working group formation stage. If you are interested in becoming a member of the working group you need to create an account and complete an application form.

Already have an account? Login
Become a Contributor
If you wish to join us on this mission to make BSV the public blockchain of choice please fill in our preliminary registration form below. We look forward to having you on board.