The Risks of Segregated Witness: Possible Problems Under US Contract Law

UPDATE 28th June 2017, 14:50 BST: This opinion piece has attracted a significant critical response. Critiques to its technical and legal presentations can be found here.

Jimmy Nguyen is chief intellectual property, communications and legal officer for nChain, a research and development firm focused on blockchain technology that is developing an alternative bitcoin software client.

In this opinion piece, Nguyen offers a critical take on the proposed SegWit scaling solution for bitcoin, arguing that the technical changes could raise legal issues under electronic contract law in the US and elsewhere.

The Bitcoin Core development team's proposed scaling solution, called Segregated Witness (SegWit), would separate signature data ("witnesses") from transaction data, and a new solution, Segwit2x, builds upon that proposal.

Most debate over SegWit centers on questions about technical impact and risks.

Given my legal background, I want to raise a significant risk that SegWit (if activated) will create in the legal system: by separating and discarding signature data, SegWit would make the legal proof and authentication of electronic contracts and transactions significantly more difficult.

This legal issue could create major practical problems in the business world.

If companies and individuals are moving to a world where they engage in electronic contracts and transactions on the bitcoin network, what happens if they cannot easily prove and authenticate those transactions later in cases of legal disputes or to satisfy regulatory compliance?

Today, a standard bitcoin transaction records both transaction and signature data together, with the signatures accounting for approximately 60% of the data size.

The transaction data conveys what value is sent or information is recorded in the bitcoin transaction. The signature (witness) data is important because it verifies the persons involved, and authenticates that they in fact sent or received the transaction. But SegWit assumes that signature data is only needed when transactions are being validated, and can thereafter be discarded as unimportant.

Rather than directly raising the 1MB block size, SegWit would indirectly increase the block's capacity to store more transactions by separating the signature data from the transaction data. It then creates two hashes:

How is this data stored in a block? The bitcoin protocol already uses a Merkle tree (a heretical data structure composed of hashes of information) to efficiently store transaction data, and places the Merkle root into the block header of every mined block. SegWit proposes creating a second Merkle tree to separately store the witness hashes, but does not keep the actual signature data.

As SegWit’s inventor Pieter Wuille explained, "These signatures are only needed at time of validation." Once a given transaction is validated contemporaneously, SegWit retains only the witness hash (in the second Merkle tree) and defaults to discarding the full digital signature.

While some nodes could elect to retain the full digital signatures, this creates three possible scenarios:

Consider how this would operate in the world of paper contracts. Once parties sign the hard copy of a contract, the signature block is cut off from the body (where the terms are written). The signature block is then converted to an identifier for indexing and that identifier is placed into a filing cabinet with hundreds of other signature identifiers. The actual signature block itself is discarded in most instances.

Years later, if you want to prove that you signed (or did not sign) a specific contract, you could find the signature block identifier, but you may not able to retrieve the physical signature block itself.

The end result of SegWit would be unreliability: you could find the witness hash, but it's not certain that you could find the digital signature.

In 1996, the American Bar Association reviewed the need for electronic signatures to facilitate online transactions. In its Digital Signature Guidelines, it identified two attributes that were key to replicating physical signatures in a digital environment:

Most digital signature regimes, including the NIST (National Institute of Standards and Technology) standards and eIDAS in the European Union, follow similar principles. Indeed, bitcoin's signature method satisfies these digital signature principles by using the public-private key approach to signing transactions.

The original bitcoin white paper (in section 2) even defines an electronic coin "as a chain of digital signatures," and notes that a payee can "verify the signatures to verify the chain of ownership." Thus, the bitcoin system relies on the ability of digital signatures for verification.

In contrast, SegWit favors transaction authentication over signer authentication, with little thought to the havoc this might cause when transactions are later disputed.

SegWit could make it very difficult for parties to a transaction or electronic contract to later prove its authenticity.

In the US, electronic contracts (and digital signatures) between businesses and consumers are generally valid under the federal e-SIGN Act. That law defines an "electronic signature" – a more flexible concept than a digital signature such as those used by bitcoin – to be something "attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record."

This requirement provides the basis for authenticating that a contract has been signed and authorized by all parties, much like a physical signature on paper can be used to show later that the parties actually signed the contract.

But under SegWit, can it really be said that the electronic signature is "attached to or logically associated with" the transaction data in a manner sufficient to show intent to approve, given the segregated data trees and the possibility for signature data being discarded?

Moreover, the federal e-SIGN Act indicates the legal validity or enforceability of an electronic contract record "may be denied if such electronic record is not in a form that is capable of being retained and accurately reproduced for later reference by all parties or persons who are entitled to retain the contract or other record."

That is a key provision of the statute – an electronic contract may be denied validity or enforceability if it is not kept in a form that can be accurately reproduced later.

Yet, as we have seen, SegWit is not concerned with maintaining digital signatures, only with validating transactions as they occur. The SegWit approach creates significant uncertainty as to whether only a hash of signature data can meet the e-SIGN statutory requirements to prove a digital signature.

Thus, under SegWit, a business or consumer wishing to definitely prove a transaction could, at most, re-associate the witness hash with the corresponding transaction data. However, there will likely be no way to recover the digital signature itself, which means the electronic contract or record may be denied legal validity or enforceability under the e-SIGN Act.

Digital signatures could only be recovered if some node chose to retain all full signature data. Yet a node only has economic incentive to do so if it acts as a commercial archive service, charging fees to retrieve and authenticate full digital signatures. This would create a new form of intermediary needed for digital signatures, which is antithetical to bitcoin’s decentralized nature.

Similar problems would arise under US state laws.

The vast majority of US states (47, plus the District of Columbia and the US Virgin Islands) have codified a version of the Uniform Electronic Transactions Act (UETA), which also recognizes that electronic transactions are valid.

Similar to the federal e-SIGN Act, the UETA defines an electronic signature as an "electronic sound, symbol or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record."

New York state’s version goes even further, stating that an electronic signature is considered to be "attached to or logically associated with an electronic record" if the electronic signature is "linked to the record during transmission and storage."

But with SegWit not requiring the signature data to be transmitted and stored, a party seeking to repudiate a transaction might argue that SegWit signatures generally cannot meet the New York definition of an electronic signature.

The question of whether an "electronic sound, symbol or process" is "attached to or logically associated with a record" is often a complicated factual question.

For example, in Young vs Rose, an Arizona court of appeals explained that whether a "thank you" email sent in response to an email with an agreement attached was an "electronic signature" was not clear, and required a review of facts outside the court pleadings and the agreement.

SegWit threatens to further complicate this type of factual inquiry about what constitutes a satisfactory "electronic signature."

Certainly, laws can be updated to address these questions in a world of bitcoin transactions and contracts. For example, in March 2017, the state of Arizona passed legislation (HB 2417) to amend its version of the UETA to confirm that electronic signatures, records or contracts secured through blockchain technology are valid under the state law.

It also recognizes that smart contracts are valid. However, the law requires that qualifying blockchain technology be "immutable and auditable and provides an uncensored truth." In a SegWit world where signature data is pruned off, will blockchain records truly be auditable and provide an uncensored truth?

Furthermore, the Arizona bill does not address whether transactions, smart contracts or blockchain signatures must be recorded fully intact (with transaction and signature data together), or if they are no longer presumed valid if signature data is discarded.

If SegWit is activated, the validity of such contracts may become unclear under Arizona’s new law, as well as other state laws.

Can the US legal system solve these problems? That's always possible, but law is always slow to catch up with transformative tech. And SegWit makes the challenges harder by pruning away a key element of any contract or transaction – embedded proof that the parties authorized the transaction to happen. Nor does it provide any easy mechanism for signature data to be “attached to or logically associated” later with transaction data.

That would contravene the US legal framework for electronic contracts, could scare businesses from operating more on the blockchain, and impedes the greater vision of a bitcoin network powering all kinds of transactions and smart contracts of the future.

This legal uncertainty is a significant risk of SegWit that bitcoin community members have not weighed – but definitely need to consider – before they decide whether to support SegWit (or Segwit2x).

Disclosures: nChain is developing an alternative bitcoin software client that aims to compete with the offering developed by Bitcoin Core. CoinDesk is a subsidiary of Digital Currency Group, which helped organize the SegWit2x proposal.

Digital law image via Shutterstock