# US 12,217,257 B2 · Trustless deterministic state machine

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 12,217,257 B2
- Document ID: US12217257B2
- Status: Granted
- Kind: B2
- Application number: 17/952,851
- Filed: 2022-09-26
- Published: 2023-03-23
- Granted: 2025-02-04
- Earliest claimed: 2017-05-22
- Assignees: nChain Licensing AG
- Applicants: nChain Licensing AG
- Inventors: Ying Chan; Dean Kramer
- Web page: https://patentgrep.com/patent/US12217257B2

## CPC

- G06F 21/64: Protecting data integrity, e.g. using checksums, certificates or signatures
- G06Q 20/389: {Keeping log of transactions for guaranteeing non-repudiation of a transaction}
- G06F 16/2379: {Updates performed during online database operations; commit processing}
- G06F 21/6209: {to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself}
- G06F 21/645: {using a third party}
- G06Q 20/065: {using e-cash}
- G06Q 20/0658: {e-cash managed locally}
- G06Q 20/36: using electronic wallets or electronic money safes
- G06Q 20/3674: {involving authentication}
- G06Q 20/3825: {Use of electronic signatures}
- G06Q 20/3829: {involving key management}
- H04L 9/0637: {Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]}
- H04L 9/0643: {Hash functions, e.g. MD5, SHA, HMAC or f9 MAC}
- H04L 9/30: Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L 9/3236: {using cryptographic hash functions}
- H04L 9/3239: {involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD}
- H04L 9/3247: {involving digital signatures}
- G06Q 10/10: Office automation; Time management
- G06Q 2220/00: Business processing using cryptography
- H04L 9/3066: {involving algebraic varieties, e.g. elliptic or hyper-elliptic curves}
- H04L 9/3252: {using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes}
- H04L 9/50: {using hash chains, e.g. blockchains or hash trees}
- H04L 2209/56: Financial cryptography, e.g. electronic payment or e-cash
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- G06Q: INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)

## Abstract

The invention relates to distributed ledge technologies such as consensus-based blockchains. Computer-implemented methods for a trustless, deterministic state machine are described. The invention is implemented using a blockchain network, which may be, for example, a Bitcoin blockchain. A first transaction validate is received at a node in a blockchain network. The first transaction includes a first script that, as a result of being executed, causes the node to at least obtain a first set of field values of the first transaction, a second set of field values of a second transaction, and an input. The second transaction is obtained. The second transaction includes a second script that includes a set of rules and, as a result of being executed, causes the node to at least verify that the second script matches a third script embedded in the first set of field values, determine, based at least in part on the second set of field values, a current state, and determine, based at least in part on the current state, the input, and the set of rules, a next state. The first transaction is validated as a result of execution of the first script and the second script.

## Claims

### Claim 1

A method comprising:
receiving, at a node in a blockchain network, a first transaction to validate, the first transaction including a first script that, as a result of being executed, causes the node to at least obtain a first set of field values of the first transaction, a second set of field values of a second transaction, and an input;
obtaining the second transaction, the second transaction including a second script that includes a set of rules, the second script, as a result of being executed, causing the node to at least:
verify that the second script matches a third script embedded in the first set of field values;
determine, based at least in part on the second set of field values, a current state of a state machine;
determine, based at least in part on the current state of the state machine, the input, and the set of rules, a next state of the state machine; and
verify that the next state of the state machine is included in the first set of field values;
validating the first transaction as a result of execution of the first script and the second script to reassociate the digital asset from the first entity to the second entity; and
verifying a cryptographic secret of a source of the input, wherein validating the first transaction includes reassociating a digital asset from a first entity to a second entity, wherein the cryptographic secret is verified based on the elliptic curve digital signature (r,s) wherein:
r=x mod n;
s=k−1(m+r×a)mod n,
where x is an elliptic curve coordinate, n is a large prime number, k is a 256-bit number, m is the double SHA-256 of the transaction, r is a 256-bit number in the ECDS and a is the cryptographic secret.

### Claim 2 (depends on 1)

The method claimed in claim 1, wherein the input is embedded in a serialized previous transaction.

### Claim 3 (depends on 2)

The method claimed in claim 2, wherein a public key from the data source is included in a locking script of the serialized previous transaction.

### Claim 4 (depends on 1)

The method claimed in claim 1, further comprising verifying a cryptographic secret of a source of the input.

### Claim 5 (depends on 1)

The method claimed in claim 1, wherein the third script is a locking script that imposes a set of conditions for validation of a future transaction.

### Claim 6 (depends on 1)

The method claimed in claim 1, wherein the second script further causes the node to determine that a termination condition is unfulfilled.

### Claim 7 (depends on 6)

The method claimed in claim 6, wherein the termination condition is that a digital asset associated with the second transaction is of insufficient size to be transferred.

### Claim 8 (depends on 1)

The method claimed in claim 1, wherein the input is embedded in the second set of field values.

### Claim 9 (depends on 1)

The method claimed in claim 1, wherein the current state indicates a state of the second transaction.

### Claim 10 (depends on 1)

The method claimed in claim 1, wherein the next state indicates a state of the first transaction upon validation.

### Claim 11 (depends on 1)

The method claimed in claim 1, further comprising:
receiving a third transaction; and
obtaining a fourth script from the first transaction, the fourth script, as a result of being executed, causing the node to determine, based at least in part on the next state, a second input, and the set of rules, another state different from the next state and the current state.

### Claim 12 (depends on 1)

The method claimed in claim 1, wherein the current state and the next state are members of a set of possible states for the first and second transactions.

### Claim 13 (depends on 1)

The method claimed in claim 1, wherein validating the first transaction includes reassociating a digital asset from a first entity to a second entity.

### Claim 14 (depends on 1)

A system, comprising:
a processor; and
memory including executable instructions that, as a result of execution by the processor, causes the system to perform the method of claim 1.

### Claim 15 (depends on 1)

A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the method of claim 1.

### Claim 16 (depends on 1)

The method of claim 1, wherein the second script constrains an identity of a source of the input to be a particular data source.

### Claim 17 (depends on 1)

The method claimed in claim 1, wherein the set of rules is a state-transition matrix.