P2pool as prior art for nChain’s Turing Complete Transactions patent — or, how to patent all blockchain apps without anybody noticing
I recently became interested in a potential application of the Bitcoin ABC’s proposed OP_CHECKDATASIGVERIFY (OP_DSV) opcode. This opcode appears to be derived from the OP_CHECKSIGFROMSTACKVERIFY opcode which was added to Elements Alpha on (edit: fixed date) May 28, 2015. These opcodes allow a script to include an ECDSA signed message as data in the script itself, and then to verify this data is a valid signature. This feature can be used in Bitcoin Cash to authenticate messages from a trusted third party, like an oracle for the BTC/USD exchange rate, or a PGP keyserver. It seems pretty cool in terms of what it could enable.
But I heard rumors from Craig Wright that he thought this opcode was covered by one of his patents.
“That’s a nice blockchain you’ve got there. It would be terrible if something were to happen to it.”
I decided to check out the patent to see if his claim had any merit.
This patent claims a priority date of 2016–02–23. Incidentally, this is later than the Elements Alpha code from which OP_CDSV was derived, and which Craig claims that his patent covers. However, I did not learn that fact until after the first version of this article was published. Thanks to Johnson Lau, for pointing this out.
His patent appears to be an attempt to describe a clone of Ethereum built as a second layer on top of Bitcoin. He even cites Ethereum in the patent description. Incidentally, this is exactly what the original plan was for how to build Ethereum, which intended to use OP_RETURN in a simiilar fashion to Counterparty (2014), to store arbitrary data in the blockchain for later retrieval, processing, and Turing-complete execution. Trying to patent an early concept version of someone else’s platform after being inspired by their released version seems to me like, to use the technical term, a “dick move.” Regardless, the law is the law, and the patent is pending.
While it seemed to me like either Ethereum-on-BTC or Counterparty themselves might qualify as prior art, I don’t know those platforms and their history well enough to say for sure. So I kept reading.
When I got to the claims, it became clear that the patent was extremely broad, and covered a wide range of early blockchain applications, some of which predate the patent by over four years. These projects would likely serve as prior art should patent enforcement be attempted. As I am an active developer of p2pool, I ended up reading the patent through the lens of that project. As the core of p2pool was written in 2012, it would have priority over nChain’s patent if it were found applicable.
I mentioned this to Craig Wright via Twitter, curious to see how he would respond:
As is typical for twitter, his response was very insightful and illuminating, and showed what a fine grasp of the intricacies of the issue the good doctor has:
Well, that settles that matter. Glad we cleared it all up.
But I was bored, so I went into the issue a bit further for kicks.
On a high level, it seemed that Craig thought his idea was particularly insightful. You could get a Turing-complete system capable of looping to interact with blockchains! The system can use transactions to store data and/or instructions, which can be used to effect changes on objects outside the blockchain via interaction with the Turing-complete looping process! It hits all the buzzwords. But when you take out all the buzzwords and replace them with simpler, more common terms, it loses its appeal, and starts to seem rather mundane. A “Turing-complete system” just means a computer program. Pretty much all programs contain at least one loop, so we’re still really just talking about a basic program. And it stores data or code in the blockchain? Yeah, so we have a blockchain program. And it reads that code or data in order to effect changes on objects outside the blockchain? Hmm, like maybe a monitor? Or a web page, like a block explorer? Okay, so we’re still just talking about a basic blockchain program.
So that’s what this patent is really for. “AGENT-BASED TURING COMPLETE TRANSACTIONS INTEGRATING FEEDBACK WITHIN A BLOCKCHAIN SYSTEM” is just a synonym for a blockchain app.
With that in mind, I decided to go through the claims to see how they would hold up. What follows is a claim-by-claim breakdown of the patent and whether p2pool’s implementation would qualify as prior art.
Claims:
1. A method of using a blockchain to control a process executing on a computing resource, the method comprising the step: (a) executing the loop on the computing resource, and (b) using the state of the blockchain to influence the execution of the loop.
This claim covers any program with a loop that reads some data from a blockchain and does something with it. This is absurdly broad, and is the basis for all subsequent claims up to Claim 18. P2pool definitely qualifies. If you’re short on time, you might want read Claim 18, and then skip everything else.
2. A method according to claim 1, wherein information relating to at least one iteration of the loop is stored in a transaction on the blockchain.
This covers a program that writes data to the blockchain inside a transaction. P2pool uses an OP_RETURN in the coinbase transaction to commit hashrate data, public keys, share difficulties, share transaction references, and a whole lot of other data to the blockchain, often comprising 100 kB or more. Since an OP_RETURN is limited to 40 bytes, p2pool hashes the data first, and only stores the hash. P2pool qualifies.
3. A method according to claim 2 wherein the information is stored as metadata in the transaction.
I’m not clear whether this claim is referring to the part of the transaction being a metadata field, or the nature of the data being stored is metadata. In either case, p2pool qualifies. OP_RETURN is probably the most meta of all transaction data. P2pool also stores merged mining information into the coinbase scriptsig field, which is a region of data typically used for noting the name of the miner that mined the block or for praying to God and debating religion. And if the claim is on the information itself being metadata, then a SHA256 of the data is definitely meta. P2pool qualifies.
4. A method according to any preceding claim and further comprising the step of generating a cryptographic hash of code relating to the loop and, preferably, storing the cryptographic hash within a transaction on the blockchain.
Yeah, we just went over that. P2pool qualifies.
5. A method according to any preceding claim wherein the computing resource is arranged to monitor the state of the blockchain for a transaction comprising a cryptographic hash of code relating to the loop.
The p2pool software runs in different instances on different computers (“nodes”) simultaneously. These nodes share messages with each other to collaborate on the shared project of mining blocks, and they use the OP_RETURN committed hash data to verify that each one is behaving properly and not trying to cheat. So far so good.
But wait! There’s a new word in this claim: “code”. That’s probably referring to an instruction stream, not merely an encoding of data. Most of what p2pool encodes in its OP_RETURN commitment is just data, not code. But wait! P2pool also includes a field which describes which revision of the p2pool code needs to be run to verify the correctness and implications of the other encoded data. So does p2pool qualify under claim 5? Hmm, p2pool probably qualifies? It’s a bit ambiguous. But if p2pool doesn’t qualify for this claim, then neither does OP_DSV. Moving on.
6. A method according to any preceding claim, the method further comprising the step: for each iteration of the loop:
(a) evaluating a condition and performing at least one action based on the outcome of the evaluation, wherein the at least one action comprises:
(i) causing at least one transaction to be written to the blockchain; and/or
(ii) causing an off-blockchain action to be performed.
Based on what p2pool sees in the OP_RETURN commitment, and based on whether the commitment is valid according to the rules determined by the code revision, p2pool will send different work to the slave mining computers via stratum, and will attempt to commit a different coinbase signature to the blockchain. So p2pool does both (i) and (ii). P2pool qualifies.
7. A method according to claim 5 or 6, wherein the condition relates to:
(a) data received, detected or generated by the computing resource; or
(b) the state of the blockchain.
P2pool uses data received over the network (i.e. shares from collaborating p2pool nodes) and data generated locally (e.g. timestamps), as well as data in the state of the blockchain (e.g. block height and allowed block subsidy) to generate work which it sends out to miners in claim 6(ii), for example. P2pool qualifies.
8. A method according to any preceding claim, wherein the computing resource is arranged to monitor:
(a) the state of the block chain;
(b) a value generated or received by the computing resource; and/or
(c) a data or signal source provided off the blockchain;
P2pool monitors all three. It checks the state of the blockchain so it knows what the previous block’s hash was, among other things. It checks timestamps generated locally, and share hashes received from other nodes. And it gets nonce and extranonce1 values back from its SHA256 miners. P2pool qualifies.
9. A method according to any preceding claim, and comprising the steps:
i) using the blockchain as a storage component for data, instructions or a pointer to data and/or instructions; and
ii) using a computing resource as a control flow management component for a Turing complete process, the computing resource being arranged to execute a looping mechanism.
P2pool stores data and the revision ID pointer to verification instructions in the blockchain, so it qualifies under (i). But p2pool also needs to perform (ii). What does (ii) even mean?
It’s basically just saying it uses a computer program running in a loop. P2pool itself qualifies as that computing resource. Remote mining hardware (e.g. Linux computers running cgminer on ARM CPUs with dedicated SHA256 coprocessors) would also qualify. Fine. P2pool qualifies, despite the obtuse language.
10. A method according to any preceding claim and further comprising the step:
restarting the loop at a specified iteration if the computing resource finds a predetermined hash of a portion of code in a transaction within the blockchain.
This one is a bit weird, but… P2pool looks for the hashes of the public keys (i.e. Bitcoin addresses) of other known miners inside the encoded transaction. P2pool then jumps to the point in the p2pool code relating to that miner’s record of work completed, and adds to that record to account for the work done by that miner. P2pool qualifies.
11. A method according to claim 10 wherein information relating to the iteration is specified using metadata provided within, or in association with, the transaction.
Those pubkey hashes are stored in association with the OP_RETURN in the coinbase transaction. P2pool qualifies.
12. A method according to any preceding claim wherein code for the loop is:
(a) hard-coded into or on the computing resource;
(b) stored in a private or publicly available file; and/or
(c) stored as an entry on a private or public hash table file; and/or
(d) a static code block with hard-coded variables or at least one parameter.
The software for verifying shares received on the network and for verifying the OP_RETURN commitments is stored on disk in p2pool/data.py, as one of several static code blocks with several parameters and variables. After loading p2pool, that code gets mapped into Python dictionary objects, which are hash tables. P2pool qualifies for every one of those points.
13. A method according to any preceding claim wherein code for the loop is associated with or comprises at least one parameter which is:
(a) populated, initialised or instantiated with a single value of any data format;
(b) a portion of code;
(c) retrieved from metadata in a blockchain transaction or from an source external to the computing resource;
(d) retrieved from a database, or a private or public file or hash table; and/or
(e) populated using values which are accessed using at least one pointer to a data source, preferably wherein the at least one pointer is stored as metadata in a transaction on the blockchain.
P2pool can (a) initialize some of the parameters it uses itself (e.g. for the initial share when starting a new share chain), (b) (if code means software) choose which subroutine to run based on the share revision identifier, (c) get data from previous shares’ coinbase OP_RETURNs, (d) load previous shares from disk, and (e) reassemble transaction lists by using p2pool’s unique transaction reference system for encoding the transactions in a block using a (share height, transaction offset) pair. P2pool qualifies, once again, on every point.
14. A method according to any preceding claim, wherein the computing resource
comprises or is in communication with a registry which enables the computing resource to access a pre-stored version of the subroutine.
So… like a dispatch table for finding the code for each function in the program? Okay, yes, p2pool has several of those, just like every other computer program written since 1960. Each multiple dependent claim costs $820 in a patent application, right? Well spent, Craig. Well spent. P2pool qualifies.
15. A method according to claim 14 wherein the registry stores:
i) a cryptographic hash of code relating to the loop; and
ii) information indicative of a location where a copy of the code can be accessed from.
Okay, so the dispatch table is a hash table? P2pool stores variable and function names in dicts, which are hash tables. But maybe that’s a stretch on the “cryptographic hash of code” part. P2pool maybe qualifies. This claim probably would need to be covered by Counterparty or Ethereum as prior art. Good show, Craig, you might have thought of something that p2pool didn’t need to back in 2012.
16. A method according to any preceding claim and further comprising the step of:
using a blockchain transaction to update code for the loop so that the existing code is replaced with new code;
preferably wherein the transaction is a multi- signature P2SH transaction.
P2pool has a code upgrade voting mechanism by which participants vote on what code revision ID they want to be using next. If 95% of all shares during an interval vote for a new revision, the code revision in use gets replaced. P2pool qualifies.
17. A method according to claim 16 and further comprising the steps:
storing a hash of the existing code and a hash of the new code.
Storing it where? On disk? in memory in our dict hash table? Note that this claim does not say cryptographic hash. That’s a bit sloppy. P2pool qualifies.
18. A computer-based system arranged to use a blockchain to control a process executing on a computing resource, the system comprising:
a blockchain; and
a computing resource arranged to execute a loop such that execution of the loop is influenced by state of the blockchain.
Finally, another independent claim. Unfortunately, this claim is essentially identical to Claim 1. So this is again just a blockchain program. P2pool qualifies.
19. A system according to claim 18, wherein information relating to at least one iteration of the loop is stored in a transaction on the blockchain; preferably wherein the information is stored as metadata in the transaction.
Each processed share gets committed into a blockchain called the share chain. Some shares also get committed into the main Bitcoin blockchain. P2pool qualifies.
— -
Anyway, I’m getting bored of this exercise, so I’m going to stop here.
There are 10 more claims left in the patent. Several of the remaining ones deal with hashes of code, which seems to be the aspect of this patent that p2pool does not cover well. Some of them are vaguely worded enough that they could simply refer to Bitcoin transactions (which contain code in their output scripts or p2sh scriptsigs), which p2pool would cover. But a few code-related claims are likely to hold up against a p2pool prior art defense.
Would any of those remaining claims cover OP_DSV? I find that implausible, since OP_DSV does not deal with hashes of code. Everything OP_DSV should be covered by p2pool.
Counterparty and Ethereum would almost certainly wipe out any remaining claims not coveed by p2pool.
What can we learn from this exercise?
We’ve learned that Craig Wright has filed a patent that is quite basic and general in most of its claims. Most of the patent simply covers a program that uses a blockchain as a data storage mechanism. Instead of writing data and code to a disk, you put a hash of it in a transaction and store it on Bitcoin. In no way do the claims of this patent use the consensus rules of Bitcoin to enforce the accuracy of the program. The most unusual claims in his patent cover putting a cryptographic hash of code into the blockchain, and reading that hash and executing code from a lookup table in other circumstances. This is essentially a clone of Counterparty and Ethereum’s method of encoding smart contract data into the blockchain. It is likely that Counterparty and Ethereum would invalidate the remaining claims. Ethereum in particular should be pretty effective, as it was already at Proof-of-Concept client 7 by the time of this nChain patent‘s priority claim.
All of the claims that do not specifically deal with hashes of code being committed to the blockchain can be refuted using p2pool as prior art. As OP_DSV does not read or write code from the blockchain, and only verifies signatures, it should not be covered by the remaining claims.
I am not a lawyer, and could be wrong about this, but in my opinion, the claim that this patent would cover OP_DSV is spurious.
However, even if that is the case, patents have other uses. One of the main uses of patents is to cow and intimidate. And this is what Craig has been doing. He has been using veiled threats based on his patent applications in his attempt to guide protocol development.
(Incidentally, while looking for this tweet, I experienced some difficulty, as it wouldn’t show up while I was logged in. Finally, I found it after searching in Incognito Mode. Apparently, CSW didn’t appreciate receiving my feedback and blocked me.)
I know that claim is spurious. Does Craig know that claim is spurious?
Well, he should. The International Search Authority filed its opinion on the novelty and clarity of this patent application a while ago, and it was about as scathing as a patent officer can get. They recommended rejecting all claims in 2017. (Kudos to /u/cryptocached for discovering the ISA reviews.)
Craig must have known that when he posted his tweets on Aug 26th, 2018. Clearly, he didn’t care that his patent was invalid. He figured he could get some use out of it anyway by cowing and intimidating the competition. So we know:
Craig Wright is a patent troll. And not very good at it, either.
Unfortunately, that does not make him harmless. Although he has a high rejection rate in his patents, Craig is extremely prolific in his applications, and it is likely that sooner or later one of these frivolous patents will get approved. If and when that happens, it will be a huge blow to all cryptocurrencies and blockchain technologies. It behooves us all to organize and form an association whose purpose it is to fight against patents like these, such as by filing prior art as an amicus curiae during the patent search process, or by assisting in the legal defense of whomever is first to be sued as a result of this Faustian bargain by nChain and Craig Wright.