SegWit

The Risks of Segregated Witness: Problems under Evidence Laws.

Jimmy Nguyen

2020 07 15

https://coingeek.com/the-risks-of-segregated-witness-problems-under-evidence-laws/

Jimmy Nguyen https://www.linkedin.com/in/jimmy-nguyen-457123/

This op-ed originally appeared on The Computer & Internet Lawyer and we republished with permission from its author, Jimmy Nguyen.

The bitcoin community still debates whether Segregated Witness will help the network’s scalability or will instead create more problems. As I have previously written, SegWit raises legal questions because it would enable full digital signature (witness) data to be dropped from the transaction data; this would undermine the ability of bitcoin digital signatures to also be used as electronic contract signatures (for example, for smart contracts). Another key legal issue is evidentiary authentication of blockchain transactions. Ideally, we are moving to a world where the bitcoin network can power smart contracts and be used for numerous types of data transactions. But in such a world, what happens if companies and consumers cannot easily authenticate and prove those transactions later when there are legal disputes? In this piece, I’ll examine the problem under evidence laws.

How SegWit Changes Bitcoin

The original Bitcoin whitepaper (in section 2) by Satoshi Nakamoto defines “an electronic coin” as “a chain of digital signatures”. Each owner transfers ownership control of the coin to the next owner by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. The transaction data conveys the inputs and outputs of coins being spent, and could also carry additional data to be recorded in the bitcoin transaction.

A normal bitcoin transaction stores both transaction and signature (witness) data together in a block, with the signatures accounting for approximately 60% of the data size. As described in my prior post, this means bitcoin transactions signatures could satisfy e-signature laws, which often require the electronic contract signature to be “attached to or logically associated” with the contract terms – which could, for example, be coded into bitcoin transaction data. (Of course, all bitcoin digital signatures are not meant to also be electronic contract signatures; however, they were originally set up in a manner that could satisfy the requirements of electronic contract signature law if the parties wanted to use them for that purpose. For example, Alice could sign her bitcoin transaction – or at a more advanced level, a smart contract whose terms are encoded with the transaction data – using her bitcoin digital signature which serves two purposes: (1) to verify the transaction to be sent and validated to the bitcoin network, and also (2) to confirm her assent to the transaction or smart contract terms for purposes of electronic contract law.)

How does SegWit change the picture? Rather than directly raising the 1MB block size, SegWit would indirectly increase a block’s capacity to store more transactions by separating the signature (witness) data from the transaction data. It then creates two hashes: (1) a “regular” hash of just the transaction data, without the signatures; and (2) a “witness hash” consisting of a hash of both of the transaction data and the witness data. For storage in a block, the bitcoin protocol already uses a Merkle tree (a hierarchical 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 creates a second Merkle tree to separately store the witness hashes, but importantly does not require nodes to keep the signature data.

In fact, SegWit assumes that signature data is only needed when transactions are being validated, and can thereafter be discarded as unimportant. As described by its original proponent Pieter Wuille, “[t]hese signatures are only needed at time of validation”; SegWit treats “signatures [as] not part of the transaction”, its “redesign would allow you to drop this [signature] data.” (Mr. Wuille is a co-founder of Blockstream, a blockchain technology company which helps support Bitcoin Core and advocates for SegWit).

Moreover, bitcoin nodes would not be required to keep the signature data. As Wuille further explained, “[SegWit] allows you to drop the signatures from relay whenever you are relaying to a node that is not actually doing full-validation at the time. It also allows us to effectively prune this data from history, maybe we’re fine with not all nodes in the network actually maintaining these gigabytes of signatures that are buried under years of proof-of-work now.” This is a key point because SegWit opens up the likelihood that most bitcoin nodes do not keep the signature data, because it is simply less efficient and costs more to do so.

If most nodes drop the signatures (which is the likely result), the blockchain can only reliably serve as a ledger for worldwide business transactions if:

• Some nodes choose to specialize in storing all signature data. This gives those nodes special weight (as a trusted source) to verify and authenticate bitcoin transactions and signatures. But this is antithetical to the idea of bitcoin as a decentralized, trustless system, with no central authority; or

• Companies and consumers operating on the blockchain must keep their own copy of transaction records (or their own nodes storing all blockchain transactions with signature data), so they have access to the signature data later if needed for legal proceedings or audits. But this requires massive data duplication and eliminates the efficiencies of using the blockchain as a decentralized ledger.

Evidence Authentication

Under courtroom evidence law, SegWit would make it more difficult for businesses and consumers to authenticate blockchain-recorded transactions. In civil and criminal court proceedings, evidence must be authenticated before it can be admitted. Under U.S. Federal Rule of Evidence 901, “[t]o satisfy the requirement of authenticating or identifying an item of evidence, the proponent must produce evidence sufficient to support a finding that the item is what the proponent claims it is.” This requirement is important to ensure litigants do not try to introduce falsified or tampered evidence.

How does this work in practice? Consider a lawsuit over an automobile accident. Drivers often seek to introduce pictures of the accident scene. They could testify from personal knowledge that they used their smartphones to take pictures immediately after the accident and confirm the images are authentic. Similarly, transaction and other business records can be admitted into court proceedings, but a witness typically must testify to authenticate the records. For example, if you are involved in a dispute with your stock exchange over a stock trade, the stock exchange could introduce its electronic records of your account and trades, but one of its employees needs to testify about the authenticity of the data. Likewise, you could produce your own printed copies of your stock trade history and testify about those printouts. Thus, transaction records generally require a witness to explain what the transaction record is, how it is kept or was generated, and what it represents.

How Can Blockchain Receipts Be Authenticated Without Signature Data?

How would this work in the blockchain world? If signature data is kept, it is easier to later authenticate the transaction record by referring to the bitcoin digital signature used to validate the transaction. This helps meet the evidentiary requirement that the blockchain record “is what the proponent claims it is” – in other words, the blockchain receipt for the specific transaction.

But SegWit allows signature data to be dropped from the transaction data, making the task of evidentiary authentication more difficult. If all nodes do not maintain signature data, who can testify as to the authenticity of signature data to match it to the relevant transaction data? While the direct parties to a transaction could hopefully do so, what happens if they relied upon bitcoin nodes to maintain the signature and transaction data and did not keep (or lost) their own records? Would that place nodes who opt to keep full signature data in a special “trusted” position to verify bitcoin transactions for legal proceedings (such as a government-approved service provider)? Or would mere evidence that a signature was necessary at the time of the bitcoin transaction satisfy a court, if no such signature can now be produced?

These evidence issues will also play out at the U.S. state level. As more blockchain technology enthusiasm grows, U.S. state legislatures are beginning to examine what is sufficient proof of blockchain business transactions. In 2016, the state of Vermont enacted H.868; it adds a statute to Vermont’s evidence rules (12 V.S.A. §1913) stating that a blockchain-based digital record is now considered a business record and thus admissible over hearsay objections – but importantly, only if the blockchain record is authenticated by the written declaration of a qualified person. One wonders, however, whether other states will follow suit, if SegWit reveals that key components of bitcoin transactions (such as signature data) can be dropped or altered from blockchain records. In order to pass statutes like the Vermont evidence law, blockchain advocates need to champion the reliability and immutability of blockchain records. But would legislators be so quick to recognize blockchain records if they knew the basic signature data that has always been saved with bitcoin transaction data could be dropped?

Need for a Witness

If signature data is not kept by any bitcoin nodes or only some of them, it creates a serious question of what witness (if any) can adequately authenticate bitcoin transactions from the blockchain. While it was not dealing with blockchain, the U.S. Court of Appeals for the 9^th Circuit decided an immigration case – U.S. v. Lizarraga-Tirado – which addressed questions about the admissibility of machine-generated evidence. (U.S. v. Lizarraga-Tirado, 789 F.3d 1107 (9^th Cir. 2015)). The case led James Ching, a Law.com contributor, to write a January 2016 blog asking Is Blockchain Evidence Inadmissible Hearsay? and triggered other online articles questioning whether blockchain evidence is admissible in court. As Ching describes, a blockchain verification “receipt must be introducible in litigation in order to be of any value as a verifier of a transaction. Because a receipt obviously is asserting the existence of the transaction, it must qualify as a business record or it is inadmissible hearsay under the Federal Rules of Evidence.” (These blockchain evidence issues were further examined in a June 2017 law review article entitled Blockchain Receipts: Patentability and Admissibility in Court.)

The Lizarraga case involved the deportation of a defendant who was found improperly entering (again) the United States through the Mexico border. The defendant claimed he had not actually crossed over the border to the U.S. side. However, the government sought to introduce the evidence of a Google Earth satellite view of the scene where the defendant was arrested, including a tack marker to reflect the border agent’s notation (on a mobile device) of where the arrest occurred (on the U.S. side of the border, according to the agent). But that pin marker was manually added to the machine-generated satellite image to record the agent’s contemporaneous impressions of where the arrest occurred.

To evaluate the admissibility of the Google Earth map image and the tack marker indicating whether the defendant crossed the U.S. border, the 9^th Circuit decided that machine-generated evidence can be admissible in court (and is not hearsay because it is a machine, rather than a person, making an assertion); however, the evidence still requires that some witness authenticate it. The party offering the machine evidence must show that the “machine is reliable and correctly calibrated, and that the data put into the machine (here, the GPS coordinates) is accurate.” (Lizarraga-Tirado, 789 F.3d at 1110.) The court noted that the rules of evidence allow for authentication of a “process or system” with evidence “describing the process or system and showing that it produces an accurate result.” In the case of Google Maps, its satellite mapping and GPS coordinates could be authenticated by a Google employee or other witness who works with the program frequently, if they can testify about how the Google Earth system works. The key is “to establish Google Earth’s reliability and accuracy.”

How would this authentication requirement be applied to a blockchain receipt offered as evidence in court? A witness would have to testify about the bitcoin network and its “reliability and accuracy” as a mechanism for maintaining business records. The Blockchain Receipts law review article noted above (at pp. 447-448) gives examples of what types of witnesses could serve this function to explain the blockchain and its transaction record system: “an exchange programmer, an avid Bitcoin user, a programmer attempting to replicate the blockchain, a digital currency expert, or an investor could all be brought in at trial.” That is certainly possible with respect to the original form of bitcoin transactions (which retain both transaction and signature data). But the task is more difficult with SegWit, which allows nodes to drop the signature data, and could lead to complex evidentiary battles about the “reliability and accuracy” of the blockchain-stored data.

Thought Experiments About the Legal Risks

At the 2017 Future of Bitcoin conference in Arnhem, Netherlands, Bitcoin Unlimited’s Chief Scientist Peter Rizun gave a presentation about why bitcoins with SegWit are not real bitcoins. To illustrate his point, he offered this thought experiment:

Imagine that you have 100 BTC in a segwit address and a few days later you notice that they’ve been transferred to an address that you do NOT control. You try to find the signature that authorized the transfer to prove the theft (you’re sure your private keys were secure so you think the signature must be bogus) but conveniently nobody seems to have it saved.

Can you prove that your funds were stolen?

In Rizun’s thought experiment, assume you sue your bitcoin wallet provider over the 100 BTC that you believe were stolen from your wallet. As Rizun points out, you need to find the signature associated with the transaction in order to prove it was fake and not authorized by you. But of course, you would not have kept it because you did not initiate the transaction. And if your wallet provider and no node has kept the signature for the disputed transaction, you are out of luck. At most, you or your wallet provider may only be able prove: (a) a transaction occurred on a particular date and time for the 100 BTC; and (b) there is string of hashes that indicate the transaction was authorized at that time. Is that enough to authenticate that transaction record for evidence purposes? And more importantly, even if that limited transaction record is authenticated and admissible in court, the signature data is missing and a key question in the case cannot be answered from the evidence.

I take Peter Rizun’s example a step further and offer this thought experiment based upon potential smart contracts that could be recorded on the blockchain, and electronically signed by one party using a bitcoin digital signature.

Alice enters into a smart contract to pay you 5 BTC to buy your used automobile. The contract’s terms are recorded on the blockchain as part of a transaction sending the 5 BTC to a SegWit address. Alice’s digital signature to validate the bitcoin transaction is also the means Alice uses to digitally sign to signify acceptance of the smart contract (for purposes of e-contract law). [In other words, Alice does not manually sign a paper contract, does not affix a digital copy of her handwritten signature to any document, and does not electronically sign a document using other means.]

Alice later disputes the smart contract, claiming that she did not authorize the transaction. You have a legal dispute over whether she in fact digitally signed the smart contract. But Alice’s signature data was pruned after the transaction was validated onto the blockchain, and she claims she did not digitally sign the transaction. You have no record of Alice’s private key used for the digital signature.

Can you prove that Alice digitally signed the smart contract?

This thought experiment illustrates the potential proof challenges of a SegWit world. It can be more difficult to prove that Alice digitally signed the disputed smart contract if you have no record of Alice’s private key used for the digital signature, and no node has kept the signature data.

As with electronic contract issues, legal systems can find ways to address these evidentiary proof problems. But SegWit makes the challenges harder by creating additional hurdles for authenticating blockchain records as evidence in legal proceedings. These risks could deter businesses from operating more on the blockchain, and impede the greater vision of a Bitcoin 2.0 network powering smart contracts and greater functionality in the future. The bitcoin community needs to demonstrate to courts, regulators and legislators that bitcoin records – and in particular signatures – are reliable and authentic; this effort is just getting started and should not be undermined by proposals such as SegWit which fundamentally change the nature of bitcoin.