US11120437B2 — Registry and automated management method for blockchain-enforced smart contracts (Part 2 of 2)
Document text
Research, not advice. Part of the Bitcoin research archive (October 2026). Claims labelled unverified, contested or fringe are reported, not endorsed; statuses of bills and rules are as of the date checked. Government, court and patent records are public domain; the research notes are CC BY 4.0.
cont.
)nued
CcBdparolepnaprtfbnthesub-usinghiskeytorv'aicrantdml
ECHQAUESLCOPDUPH<PubK-Bobash>VKE1RSI6F0GY
OrsEPec_QHdrA<hash>PUSeiHAp16Lmt0
nVeurmsbieorn SlcernigpthPubKBob-Sig nSueqmubencre Oslucetrnpiguptth lOseucntrgpituht
T2
-
BOB
S5 T1
S5
-
BOB
IDX
01
-
2
2,0 0 494,0 0 LockTime
U.S. Patent Sep. 14, 2021 Sheet 18 of 26 US 11,120,437 B2
standridechaplvemsg
for
butbn
-
&
rBSaROeutpcriqadtuln;o
2ABSOs>PutseoriatuMblneP-_5tdSca>bdiDaKlnrta2egdBA
Trans- S
n euqmu b
e necre
IDaction NiunmpofbuetrsOTurtPrevapnust OTIurntadPrevpnusxt
N
o u
fmtbp u
e t
r s OslucetrnpiguthOsuctrpiuptvOuatlpuetOslucetrnpigupth )nued
contFig
(
6c
.
Vneurmsbieorn Scriptsig
l
S e
c n
r i
g p
t h
t O
v u
a t
l p
u e
t
LockTime
his
Bob'ssing
-f
Ccbsdaroutpeniaprtlnheb
keyordviarocantdml
ECHOQsAUPuEcSL_CtVbKashP<->BobHrKDE1pRSiUI6uFpP0GYt
hashH>
<
HrsAecSdrOP
EQUALei1p6mt0
length
Vneurmsbieorn Slcernigptth -PubkSigBob nSeuqmubenecre Oslucetrnpigupth Osuctrpiut
S5
T3
-
BOB
1
-
S5
T2
BOB
01
IDX
- 2 2,0 0 491,0 0 LockTime
U.S. Patent Sep. 14, 2021 Sheet 19 of 26 US 11,120,437 B2
apsulathnoys
there
(
fee
the
The
that
note
maybe
twocihnigy
output
for
model
<<
theo)intgy
orade
both
apultahn«
Note
6d
.
Fig
Trans-IDaction NiunmpofbuetrsOTurtPrevapnust OTIurntadPrevpnusxt Slcernigpth
Vneurmsbieonr nSeuqmubenecreNoumtfbpuetrs vOuatlpuetOslucetrnpigupth LockTime
APultahnoSign
-
offnritgy
AOSPBsl_ca2oenArtsuiMbne-tgaMpASebutdaKhDostar1eiatBAyg POlsPHa_nPEuciCQHnaU_gAtr<-E>SLuDCpiVbtsHhEKoU1RuSrI6iKhFPt0GYy
CAHPOEulCtrKaMhnUa-P5OPbKoLrTdiISntIegGy
T4
S5
-
BOB Vneurmsbieorn 1
BOB
T2
S5
-
IDX
00
-
Slcernigpth nSeuqmubenecre 1,0 0 Oslucetrnpiguth LockTime
1
U.S. Patent Sep. 14 , 2021 Sheet 20 of 26 US 11,120,437 B2
9
Pich M -19
Pls
Third node
3 7
5 27
Network
23 Second node
First node
VcPic Vis Pis
15 Pic
Pis
13
t 11
17
Eavesdropper
Fig . 7
U.S. Patent Sep. 14 , 2021 Sheet 21 of 26 US 11,120,437 B2
5
3
7
Network
First node Second node
Share message (M) between the first and second nodes
300 400
330 /
Determine a first node second private Determine a first node second public
key (V2c) based on the first node key (Pac) based on the first node
master private key (Vic) and the master public key (P1c ) and the
Generator Value (GV) Generator Value (GV)
Generate a firstsigned message (SM1 ) 430
350
based on the message (M ) and the first
node second private key (V2c ).
Send the firstsigned message (SM1 ) 360
to the second node. 440
Receive the first signed message ( SM1 )
from the first node .
450 Validate signature on the first signed
message (SM1) with the determined
first node second public key (Pac ).
460 . Authenticate the first node based on the
370 result of validating first signed message (SM1 )
Determine a second node second public 470 Determine a second node second private
key (P2s ) based on the second node key (Vas) based on the second node
master public key (P1s) and the master private key (Vis ) and the
Generator Value (GV) Generator Value (GV)
480
Determine common secret (CS) based on Determine common secret (CS ) based on
first node second private key (V2c) and second node second private key (V25)
380
second node second public key (P2s) . and first node second public key (Pac ).
Fig . 8
U.S. Patent Sep. 14 , 2021 Sheet 22 of 26 US 11,120,437 B2
5
3 7
Network
200
100 First node Second node
110 210
Settle on ECC system using a Settle on ECC system using a
base value (G ) base value (G)
120
Generate first asymmetric cryptography
pair including : a first node master private
key (Vic );and a first node master public
key (P1c) based on the first node private
master key (Vic) and G
130
Send client master public key (Pic )
to the second node
220
Receive the first node
master public key (Pic )
230
Store first node
tea
master public P1C)
240
Generate second asymmetric cryptography
pair including : a second node master private
key ( 18) ; and a second node master public
key ( P18) based on the second node master
private key (Vis) and base value (G)
140 250
Send second node
Receive second node master public key (P?s ) to first node
master public key (P18 )
Store second node 150
master public key (P18)
Fig . 9
U.S. Patent Sep. 14 , 2021 Sheet 23 of 26 US 11,120,437 B2
5
3
7
Network
300
First node 310 Second node
Generate a message (M)
315
400
400
410
Send the message ( M ) to the second node
320 Receive the message (M ) from the first node
Determine a Generator Value (GV) 420
based on the message (M) Determine a Generator Value (GV)
330 based on the message (M)
430 '
Determine a first node second private
key (V2p) based on the first node master private Determine a first node second public
key (V1p ) and the Generator Value (GV) key ( Pac) based on the first node master public
key (Pic),GeneratorValue (GV ), and base value ( G)
Generate a firstsigned message (SM1 ) 350
based on the message (M) and the first 440
node second private key (V2c ). Receive first signed message ( SM1)
from the first node
360 450
Send first signed message (SM1 )
to the second node Validate signature on the first signed message (SM1 )
with the determined first node second public key (Pac )
460
Authenticate the first node based on the result of
validating the first signed message (SM1 )
370 470
Determine a second node second public Determine a second node second private
key (Pas) based on the second node master public key (Vas) based on the second node master private
key (PiS ), Generator Value (GV), and base point (G ) key ( 18) and the Generator Value (GV)
380 480
Determine common secret (CS) based on first node Determine common secret (CS) based on second node
second private key (V2c) and second node second second private key (25 ) and first node second
public key (P2 ) public key (P2c)
Fig . 10
U.S. Patent Sep. 14 , 2021 Sheet 24 of 26 US 11,120,437 B2
5
3 7
Network
300 400
First node Second node
Generate a firstsigned message (SM1) 350
based on the message ( M) and the first
node second private key Nac ).
Send the first signed message (SM1 ) 360
to the second node . 440
Receive the first signed message (SM1 )
from the first node .
Validate signature on the first signed 450
message (SM1 ) with the determined
first node second public key (Pac ).
460
Authenticate the first node based on the
result of validating first signed message (SM1)
Generate a second signed message (SM2) 462
based on the message (M) and the second
node second private key (Vas ).
372
Send the second signed message (SM2) 464
Receive the second signed message to the first node.
(SM2) from second node .
Validate signature on the second signed 374
message (SM2) with the determined
second node second public key (P2s ) .
376
Authenticate the second node based on the
result of validating the second signed message ( SM2)
Fig . 11
U.S. Patent Sep. 14, 2021 Sheet 25 of 26 US 11,120,437 B2
901 Bitcoinibntoernesdt
Bpiatycmoeints Salary
Savings
12
.
Fig
aBcaountks aCchoeuqnutse
XYZPIN
Maskeyt r
Paswords wAebBsitCe
U.S. Patent Sep. 14 , 2021 Sheet 26 of 26 US 11,120,437 B2
903
V1C
V2c
V2C
V2c " V3c
V3C'
Fig . 13
US 11,120,437 B2
1 2
REGISTRY AND AUTOMATED regarded as being limited to use within legal or commer
MANAGEMENT METHOD FOR cially -oriented contexts, and the term ' contract should not
BLOCKCHAIN -ENFORCED SMART be construed in such a limiting sense . For example, the
CONTRACTS contract may be a ticket for a train or airline, or for a concert
5 venue, and on which is printed an access code such as a
This invention relates generally to computer protocols machine readable barcode for providing unlocking a barrier.
and, more particularly, to the verification, enforcement and / Thus, an invention is provided herein as defined in the
or performance of condition controlled processes such as , appended claims .
for example, those relating to contracts . The invention is According to an aspect of the present invention , there is
particularly suited for use with a blockchain network , and 10 provided a computer -implemented method of controlling the
may be used to advantage with a smart contract . visibility and / or performance of a contract, the method
A blockchain is a decentralised , distributed computer comprising the steps :
system made up of unchangeable blocks which in turn are ( a) storing a contract on or in a computer -based reposi
made up of transactions. Each block contains a hash of the tory ;
previous block so that blocks become chained together to 15 (b ) broadcasting a transaction to a blockchain , the trans
create a record of all transactions which have been written action comprising:
to the blockchain since its inception . Transactions contain i ) at least one unspent output (UTXO ); and
small programs known as scripts embedded into its inputs ii ) metadata comprising an identifier indicative of the
and outputs, which specify how and by whom the outputs of location where the contract is stored ; and
the transaction can be accessed . Each unspent transaction 20 ( c ) renewing or rolling the contract on by :
( referred to as UTXO ) can be spent as an input into a new generating a new key using data relating to a previous key
transaction . associated with the contract;
The most widely known application of block chain tech- generating a script comprising the new key , the location
nology is the Bitcoin ledger, although other blockchain of the contract and a hash of the contract; and
implementations have been proposed and developed. While 25 paying an amount of currency to the script.
Bitcoin may be referred to herein for the purpose of con- By renewing or rolling the contract on by generating a
venience and illustration , it should be noted that the inven- new key using data relating to a previous key associated with
tion is not limited to use with the Bitcoin blockchain and the contract, generating a script comprising the new key, the
alternative blockchain implementations fall within the scope location of the contract and a hash of the contract, and
of the invention . 30 paying an amount of currency to the script, this provides the
Blockchain technology is known for the use of crypto- advantage that because the new key is related to the previous
currency implementation. However, in more recent times , key, authorised parties can view the source contract by
digital entrepreneurs have begun exploring both the use of means of its connection with the renewed or rolled on
the cryptographic security system Bitcoin is based on, and contract, thereby enabling verification of the rolled on
the data that can be stored on the Blockchain , to implement 35 contract, without any loss of certainty or privacy. The further
new systems . These include but are not limited to : advantage is provided that memory and processing capacity
Storing metadata can be reduced by storing the contract in a computer -based
Implementing digital tokens off- chain repository ( i.e. not forming part of the blockchain ),
Implementing and managing contracts . without loss of certainty or privacy, since the key associated
One of the key problems with modern contract manage- 40 with the renewed or rolled on contract is associated with the
ment is that it tends to be ad- hoc , with local stores and copies key of the source contract.
of contracts that are manually maintained . As a result, In the “ rollover ' situation , the UTXO may be spent
computer protocols known as “ smart contracts ” have begun sending it to the ' new ' rolled - on contract. However, it may
to attract attention as they can enable the automated enforce- be possible to cancel the existing contract by spending the
ment or performance of a contract, either partially or in its 45 output before the lock time and thus cancelling the whole
entirety. Smart contracts can provide benefits such as contract.
enhanced security and reduced transactions costs . However, The invention may provide a computer - implemented
while there are known technical solutions which aim to method and system for controlling the visibility and / or
ensure that these contracts cannot be modified once stored , performance of a contract. ‘ Visibility’may mean how and to
there is no generally accepted public registry to check the 50 whom the existence and / or contents of the contract are
validity of the contract i.e. whether it is still open or has been available or accessible . The contract may be a “ smart con
terminated . tract ”. The method may be an automated smart contract
Thus, it is desirable to provide a computer - implemented method . It may be a method for automating the process of
mechanism which can control public visibility of the exis- monitoring the existence, validity and / or performance of the
tence of a contract, and facilitate the ability of relevant 55 contract. As the contract may be represented in the form of
parties to manage, enforce and maintain performance - based at least part of a blockchain transaction, the invention may
processes such as contracts in an automated manner ( i.e. by be referred to as a tokenisation method / system . The meta
machine rather than human management). Importantly, this data in the transaction may provide a blockchain - imple
mechanism would provide a technical ability to specify mented token which is used to represent and /or access a
control conditions and triggers for behaviours defined within 60 contract.
the contract. The invention may provide a method /system which
It should be noted that the invention defined and described enables the storage of a contract in a repository ( registry ),
herein is not limited for use with contracts in the legal sense where a hash of the contract can be used as a look -up key for
of the word . The contract may be a document, file or other finding the contract.
mechanism which defines a set of behaviour ( s ) that can be 65 The method may comprise the steps :
triggered under specified conditions . The control condition storing a contract on or in a computer-based repository;
may be publically fulfilled . The invention should not be and
US 11,120,437 B2
3 4
broadcasting a transaction to a blockchain , the transaction pay -to -script -hash (P2SH ) address. Thus, the existence of a
comprising: contract ( or defined element within a contract) may be made
i ) at least one unspent output ( UTXO ); and publicly available using a transaction which is published to
ii ) metadata comprising an identifier indicative of the 5 the blockchain using a pay - to - script-hash address which
location where the contract is stored . maybe determined or provided by the issuer of the contract;
The contract may be interpreted as open or valid until the and / or the metadata of the contract.
UTXO is spent on the blockchain . The blockchain may or The method may further comprise the step of terminating
may not be the Bitcoin blockchain . This provides the benefit the contract by broadcasting a ( further) transaction to the
of a novel mechanism for representing the status or validity blockchain to spend the output (UTXO ) . The further trans
of The
a contract
methodonmaya blockchain
comprise as
therepresented
step of usingby antheoffUTXO
- chain. 10 action may comprise an input which is the output (UTXO );
computer - implemented process, agent or other entity to data ; andunlocking
and an
a public
script comprising a signature ; the meta
key.
observe the state of the blockchain and behave a certain way This may provide the benefit of automated termination of
based on whether or not the output is currently unspent. The
process may be arranged to interpret the unspent output as 15 the contract, via the use of a blockchain transaction to spend
an indicator of the status of the contract. In other words , the output.
while the output remains within the UTXO list on the The contract may define : i ) at least one condition , and ii )
blockchain i.e. the transaction is still unspent, this may be at least one action whose performance is dependent upon the
used to indicate the validity or ' open ' status of the contract evaluation of the condition . The condition may be a test
pointed to or referred by the metadata. The contract may be 20 which can be evaluated to true or false. The condition may
considered to be complete (terminated ) once the UTXO is be part of (eg a clause ) the contract . Completion or perfor
spent. This condition may be stated within the contract. mance of the condition may be required for fulfilment of the
However, once the UTXO has been spent the metadata may contract. The condition may be completed if it evaluates to
continue to contain a pointer or reference to the contract and true.
a hash of the contract so the contract may retain its function . 25 The metadata may comprise i ) an address or representa
The method may comprise the step of publishing the tion of an address of where the contract is stored in the
existence of the contract . This may be achieved by the computer -based repository ; and /or ii ) a hash of the contract.
following steps : The method may comprise the step of observing the
The Contract Issuer may create a new Contract Document blochchain state . It may comprise searching the blockchain
and publish this to the Repository. The location of the 30 to find a transaction containing the UTXO . It may comprise
store and the secure hash of that document may be the step of checking whether the contract has been termi
stored for later use ; nated by determining whether the unspent transaction
creating a redeem script covering the contract document UTXO is in the list of unspent transaction outputs for the
being secured , in a m of n multi - signature structure blockchain . This monitoring or checking process may be
where : 35 automated . It may be performed by a suitably programmed
m is at least one ; and computing agent or resource . It may be substantially as
n is m plus the number of metadata blocks described below in the section entitled “ Illustrative Com
including at least one public key in the script; this may be puting Agent for use with the invention ” . The agent may
the public key of the Contract Issuer. However, other perform an action based upon the spent or unspent status of
signatures may be required as well 40 the UTXO . Thus , the status of the UTXO may control or
paying an amount of currency e.g. Bitcoin to the script, influence the behaviour of an off -block computing agent.
preferably through a P2SH transaction The method may comprise the step of broadcasting a
waiting until the transaction has been published onto the transaction to the blockchain comprising an instruction to
Blockchain and extracting the transaction ID for the spend the output at a specified date and/ or time . The
published transaction 45 instruction may be a CheckLockTimeVerify instruction .
creating a new transaction , with a locktime set to the Access to some or all of the contents of the contract may
expiry time of the contract, paying the output from the be restricted to at least one designated authorised party. In
transaction back to the public key hash ; OR other words , authorisation may be required in order to access
For a rolling duration contract: using an automated com- or view some or all of the contract . In some embodiments,
puting agent to detect the transaction on the blockchain 50 protection mechanisms may be applied to the contract itself .
and wait until the contract expiry time before triggering For example, one or more portions of the file may be
code to roll it into a new contract; OR protected but the overall content may be public . This partial
For a completion -based contract (where x of y entities protection may apply to both the encryption of the informa
agree that the contract has been fulfilled ): creating a m tion within the contract as well as the hash detecting changes
of n multi - signature transaction and issuing it to these 55 to its content.
entities to co - sign upon completion . The contract may comprise a Deterministic Finite
The repository may be an off - block storage resource . In Automaton ( DFA ) to implement the contract. The Deter
other words , the repository may not form part of the block- ministic Finite Automaton may be defined using a codifica
chain itself. The computer-based repository may be or tion scheme. The Deterministic Finite Automaton may be
comprise a server . The repository may be a database or other 60 implemented using :
storage facility provided on a computer -based resource . The i ) at least one blockchain transaction, preferably using a
Repository may be indexed, allowing it to be searched . The scripting language;
repository may comprise a Distributed Hash Table. The ii ) a computing agent arranged to monitor the state of the
contract may be stored in or in association with the Distrib- blockchain (this may be as described in the section below
uted Hash Table (DHT ) . 65 entitled “ Illustrative Computing Agent for use with the
The transaction may further comprise a deterministic invention ” ); and / or
redeem or locking script address. The address may be a iii ) a set of instructions for a digital wallet .
US 11,120,437 B2
5 6
According to another aspect of the present invention, Any feature described herein in relation to one embodi
there is provided a computer implemented method of con- ment or aspect may also be used in relation to any other
trolling the visibility and / or performance of a contract, the embodiment or aspect . For example , any feature described
method comprising the steps : in relation to the method may also be used in relation to the
(a ) storing a contract on or in a computer -based reposi- 5 system and vice versa .
tory ; A non - exhaustive list of some of the benefits which may
(b ) broadcasting a transaction to a blockchain , the trans be provided by the invention is now provided .
action comprising: The invention may provide a technical arrangement which
i ) at least one unspent output (UTXO ); and simplifies the automated management of structured control
ii ) metadata comprising an identifier indicative of the 10 conditions , which may be referred to as “ contracts” herein .
This , in turn , makes it easier to agree the state of the contract
location where the contract is stored ; and
in the event of a dispute. The invention may also provide a
(c ) generating a sub - contract derived from the contract, mechanism
wherein the sub - contract is associated with a determin to hold a secure , public record of contracts in a
istic address and is generated by : manner which allows automated determination of their
15 validity by computer, and release of their details to autho
iii ) using a new public key derived using a seed ; rised entities upon validation . Thus, the invention may
iv ) storing the sub - contract in or on the repository with provide a security - enhanced control mechanism which per
a reference to the contract, and broadcasting a trans- mits or prohibits access to a resource in an intelligent
action to the blockchain comprising a script which manner .
includes the reference ; and / or 20 The invention also provides the ability to publish a
v ) adding a reference to the sub - contract to the meta- contract to an audience via a computer system such that the
data of the existing contract. details of the contract can be restricted to authorised entities
By generating a sub - contract derived from the contract, only, but the knowledge of the existence of the contract is
wherein the sub - contract is associated with a deterministic publically known . In other words , it can be public knowl
address and is generated by using a new public key derived 25 edge that there is a contract between A and B , and this can
using a seed, storing the sub - contract in or on the repository be publicly verified , but anything other than its existence is
with a reference to the contract, and broadcasting a trans- restricted to authorised parties (which might typically be A
action to the blockchain comprising a script which includes and B only ).
the reference and / or adding a reference to the sub - contract to It also provides a computer - implemented mechanism that
the metadata of the existing contract, this provides the 30 allows contracts to be time - bound ( i.e. they expire after a
advantage that sub -contracts can be independently managed certain time or on a given date); condition bound (i.e. they
without loss of certainty or privacy, since they are crypto- expire once the deliverable specified within the contract has
graphically bound to the source contract. In ition , been fulfilled ) or open -ended ( .e. they continue to roll on
memory and processing resources can be minimised by with a notice period to terminate them ).
storing the sub - contract in an off -block repository. 35 It may provide a mechanism to serve notice to terminate
The method may include the use of a computer -based that contract in a public fashion . For example, using nLock
agent to monitor the blockchain and / or execute actions Time + CheckLockTimeVerify (CLTV ) in a spend transaction
based on the content of contract. Such an agent may be to ‘enact the expiration .
substantially as described below in the section entitled It may provide a mechanism to structure a hierarchy of
“ Illustrative Computing Agent for use with the invention ” . 40 sub - contracts in a deterministic manner to allow control over
The invention may also provide a computer -implemented different aspects of the contract to be partitioned. For
system arranged to perform any of the method steps men- example , in a technology development process the require
tioned above , or any embodiment of the method described ments phase may have a different set of control triggers than
herein . The invention may provide a computer -implemented the development phase.
system for controlling the visibility and / or performance of a 45 As the invention may be implemented on a blockchain
contract, the system comprising: platform , and may extend the functionality of the blockchain
a computer -based repository arranged to store a contract; so that it can be used in a technically different way , the
and invention may provide an improved blockchain system or
a blockchain comprising a transaction , the transaction platform .
comprising: 50The invention may be used to turn any unspent transaction
i ) at least one unspent output ( UTXO ); and (UTXO ) into a smart contract, such as for digital access . For
ii ) metadata comprising an identifier representing the example, consider a scenario wherein a consumer pays a
location where the contract is stored . merchant for access to a service for a period of time . If the
The metadata may also store a hash of the contract. The merchant's payment address is implemented as a smart
contract may be a smart contract. 55 contract, then the invention can be used to implement an
The repository may comprise a database . It may comprise access control mechanism for the service. A check can be
a DHT. It may be indexed . searchable . It may comprise at made to ensure that the money has been paid , and an
least one security mechanism to control access to the con- automated process used to sweep the value at the end of the
tract. period to the merchant's account.
The system may also comprise a suitably configured 60 These and other aspects of the present invention will be
computing -based entity or agent. The agent may be arranged apparent from and elucidated with reference to , the embodi
to monitor and / or search the blockchain . It may be arranged ment described herein . An embodiment of the present inven
to perform at least one action based upon the state of the tion will now be described , by way of example only, and
blockchain . It may be arranged to determine whether the with reference to the accompanying drawings, in which :
UTXO has been spent or not. It may be arranged to perform 65 FIG . 1 shows an overview of how blockchain transactions
one or more actions based on whether or not the UTXO has can be used by an embodiment of the invention to implement
been spent. various contract - related tasks.
US 11,120,437 B2
7 8
FIG . 2a shows a simple state machine with two states : (i ) mechanisms (e.g. a programmed computing agent) whose
contract is open and ( ii ) contract is closed . behaviour is controlled by conditions or stipulations in the
FIG . 2b shows metadata definition for the scenario of contract itself. For example, the contract stipulates that it
FIG . 2a . The metadata is carried on the (bitcoin ) transaction will expire on a certain date, or that it will expire when a
output and which specifies the contract location and proof of 5 certain value reaches a specified threshold .
validity ( via the hash ). This principle of using unspent transaction outputs to
FIG . 2c shows an “ issuance ' transaction related to the represent contracts can be used in combination with other
scenario of FIGS . 2a and 2b , that initially stores the (hash of features, such as encryption techniques. This allows the
the) contract on the Blockchain . implementation of complex scenarios and activities . Effec
FIG . 2d cancels the contract of FIGS . 2a to 2c by 10 tively, the context around the unsigned transaction output
spending the bitcoin . UTXO and the associated metadata within the script that
FIG . 3a shows an illustrative metadata for a scenario enables it to be spent, allows the transaction to act as a
wherein an asset with hidden ownership is created and pointer or reference to an off - chain repository which con
published to the blockchain . tains the formal details of the contract. Herein , 'off - chain '
FIG . 3b shows an illustrative transaction to ‘ fund ' the 15 means that it is not part of the blockchain itself. This
asset of FIG . 3a . That is , to put some bitcoins into the asset's provides a mechanism whereby anyone can use a software
public key so that the asset can fund its transactions ( such as based component or tool to determine whether the contract
the publication transaction shown in 3c ) . has been terminated or is still valid /open by inspecting the
FIG . 3c shows an illustrative blockchain transaction for blockchain . Once the contract is terminated , this will be
the publication of the asset of FIGS . 3a and 3b. 20 recorded on the blockchain as a spent output in a transaction
FIG . 3d shows an illustrative transaction for closure of the and this available for public inspection . The blockchain
contract relating to FIGS . 3a , b and c . When cancellation of transaction becomes a permanent, unalterable and public
the contract is required, the UTXO is spent. In this scenario , record of the contract's existence and current status .
the requirement has been for both the Asset and the hidden The repository (which may also be called a “ registry ' or
owner of the asset to sign . 25 ‘ register ') may be implemented in a variety of ways includ
FIG . 4a shows an illustrative state machine model for a ing , for example, as a distributed hash table (DHT ) . A hash
scenario involving a lease contract. of the contract can be generated and stored as metadata
FIG . 4b shows an illustrative metadata for the scenario of within the blockchain transaction , and can serve as the
FIG . 4a . look- up key for referencing the contract from the block
FIG . 4c shows an illustrative transaction to publish the 30 chain . A reference to the location of the contract is also
ownership of the asset of FIGS . 4a and 4b onto the Block- provided within the transaction metadata. For example , the
chain . URL for the repository may be provided . While the metadata
FIG . 5a shows an illustrative state machine model for a is open to public view , the contract itself may not be , or may
scenario wherein a contract is rolled on . be partially protected.
FIG . 5b shows an illustrative metadata for the scenario of 35 Standard Bitcoin features such as CheckLockTimeVerify
FIG . 5a . ( CLTV ) can allow the contract to have a formal, automated
FIG . 5c shows an illustrative transaction which could be expiry at a point in the future. Use of the blockchain enables
used to publish the initial contract of FIGS . 5a and 5b and this expiry date to be a matter of secure ( unalterable) public
the initial rollover of the contract onto the Blockchain . record . This concept , in combination with the use of multiple
FIG . 5d shows an illustrative transaction for the termina- 40 encryption keys described below , enables the CLTV model
tion of the contract of FIGS . 5a to 5d . to automatically roll - on or renew the contract unless explic
FIG . 6a an illustrative state machine model for a scenario itly cancelled.
involving contract conditionality . The use of deterministic sub -keys, in combination with
FIG . 6b shows an illustrative metadata for the scenario of the tokenisation mechanism described herein , allows sub
FIG . 6a . 45 contracts or schedules against contracts to be created .
FIG . 6c shows an illustrative transaction which could be Further still , the use of off -block computing agents
used to create the initial contract and two sub - contracts and (oracles ) allows contract conditionality to be built in and
publish them . modified by trusted third -parties. This means that the agent's
FIG . 6d shows an illustrative transaction for use in action can be influenced by conditions ( eg “ IF ” statements )
relation to the scenario of ba to 6c . 50 which are provided within the contract definition .
FIGS . 7 to 13 show various aspects of a technique for Key Terms
deriving sub -keys from a parent key, this technique being The following terms may be used herein .
suitable for use in relation to aspects of the present inven- Contract issuer :
tion . This entity represents an actor that is responsible for the
Smart contracts built into the Blockchain can be enforced 55 publication of the contract onto the Blockchain
through logic which is embedded directly into the bitcoin Interested party:
transaction (i.e. within the locking/unlocking scripts ) and / or This entity represents an actor that may need to determine
through external computer -based applications. Such external whether a particular contract is still in place or not , or
computer-based applications which may be referred to as may need to determine the specifics of the contract.
“ agents ', ' oracles' or ' bots ’ . In addition , some contractual 60 Repository :
conditions can be enforced through other bitcoin transaction This entity represents a location which secures /stores a
elements such as the nLockTime field . structured representation of the contract that the Block
An invention is described herein where the contract is chain smart contract references ;
interpreted as remaining in effect as long as there is a valid Contract counterparty :
unspent transaction output UTXO on the blockchain repre- 65 This entity represents the counterparty to a specific con
senting the contract. It will be appreciated that this unspent tract. Note that in many cases , this entity will not be
state can be influenced and altered as a result of various present
US 11,120,437 B2
9 10
Contract: the Blockchain using a pay - to - script -hash address (P2SH ) . A
This is the structured document or file stored within the P2SH transaction is one in which the recipient must provide
repository and which is referenced from the Block- a script which matches the script hash , and also data which
chain . The contract can be any type of contract or makes the script evaluate to true, in order for the transaction
agreement. This may include, for example, financial 5 to be spent. In relation to embodiments of the present
contracts , title deeds , service contracts and more . A invention , the pay - to - script-hash (P2SH ) can be readily
contract can be public or private in terms of its content. determined from :
The contract is formalised in that it is expressed in a The issuer of the contract; and
structured manner using a codification scheme. The metadata of the contract.
Contract Model 10 In accordance with some embodiments of the invention ,
The basic elements of the contract model are as follows: the unspent transaction can be interpreted as an indicator of
A codification scheme that allows a complete description the status of the contract. An off -chain process can be
of any type of contract. The scheme may be a new arranged to monitor the blockchain and behave a certain way
construct or may use an existing facility such as XBRL , based on whether or not the output is unspent. In other
XML , JSON (etc. ) ;
A DFA (Deterministic Finite Automaton ) to implement 15 words the
, while this output remains within the UTXO list on
blockchain (i.e. the transaction is still unspent ), this
the Contract that can be fully defined within the codi indicates the validity of the contract pointed or referred to by
fication scheme. This is made up of: the metadata . The contract is considered to be complete once
A set of parameters, and where to source those param this output is spent. This condition ( that the contract remains
eters; 20 valid /open only as long as a UTXO exists for it) can be a
A set of state definitions
A set of transitions between the states, including the condition
stipulation
of the contract itself. However, it is not a necessary
of the protocol as in other embodiments an
trigger for the transition and the rules followed alternative termination condition may be in place . Note that
during the transition.
Rules definition table even after the transaction has been spent ( and therefore no
Definitions of the specific parameters for this instance of 25 longer exists in the UTXO list ) it still resides permanently on
the Contract; the Blockchain and still retains a pointer or reference to the
Mechanisms to secure and protect the Contract; contract and a hash of the contract so it could retain its
A “ browser ' to enable the contact to be made human- function even after being spent.
readable in formal legal language; and Sub -Contracts /Conditions
A ‘ complier’ to convert the codification scheme into 30 A sub - contract is a contract that it directly related to an
oracle code and /or a script such as a Bitcoin script . existing contract. A condition is a clause within an existing
Implementing the Contract contract that must be fulfilled to meet the terms of that
When the Contract is registered in a repository, the contract.
associated address e.g. URL and hash can be used as In accordance with an embodiment of the invention , both
metadata within a Blockchain transaction to associate the 35 sub - contracts and conditions can be implemented in the
transaction on the chain with the controlling contract itself. same manner i.e. as a contract which is implemented as an
This can be implemented in a variety of forms, but a suitable UTXO with a deterministic redeem script address. In both
codification scheme is provided below for completeness in cases , the entity can be interpreted as being complete when
the section entitled “ codification Scheme " . the UTXO is spent (in the case of a condition , this indicates
There are a number of different methods as to how the 40 that the condition has been satisfied ). As stated above , the
DFA contained within the contract definition can be imple- metadata will still contain a pointer or reference to the
mented : location of the entity within the repository, and also a hash
As a Blockchain transaction or sequence of transactions . of it . Therefore, in other embodiments, the sub - contract or
Various forms of DFA may be implemented directly condition may remain in existence and retain functionality
within the Bitcoin scripting language; the person even after the output has been spent, depending on the
skilled in the art will understand this and the present 45 contractually specified conditions.
invention is not limited with regard to the manner in There are a number of mechanisms which can be used to
which the DFA is implemented via blockchain trans- create the deterministic address for a condition or sub
action( s ) ; contract:
As an agent -based ( e.g. oracle ) process or sequence of deriving a new public key using seed information ;
processes. The section below entitled “ Illustrative 50 Creating and publishing the sub - contract, with a reference
Computing Agent for use with the invention” describes to the master contract, within the repository and using
the basic process for defining and running a suitable this as the metadata reference; and
agent to monitor the Blockchain and possibly other Adding the condition / sub - contract reference to the meta
external sources . data of the existing contract.
As a set of instructions for a smart Wallet. In this content, 55 Securing the Contract
a smart wallet is effectively simply a local oracle The formal representation of the contract ( ie the document
process which can handle certain contract conditions or file which specifies the content of the contract) can be
such as assignment of transaction inputs to a Block- secured in various ways depending on the formal needs of
chain transaction . that specific contract, although in all cases a public record of
Note that a given contract definition can be implemented the existence of the contract will be published on the
as a mixture of the above three mechanisms, where each 60 Blockchain contained within the metadata record ( see sec
contract state transition is effectively a separate implemen- tion entitled “ codification Scheme ” for details of a specific
tation . There are a number of methods of creating the metadata structure ).
implementation from a contract definition , including hand- From this blockchain record, authorised entities will be
crafting the relevant transactions / code . able to learn the location of the formal representation,
Publishing the Contract's Existence 65 together with the hash to determine that the formal repre
In order to publish the existence of a contract (or a defined sentation has not been modified since the transaction was
element within a contract) a transaction Tx is published to published .
US 11,120,437 B2
11 12
However, it is possible to further secure the formal For a number of contract types , the expiry of the contract
representation itself through a number of methods: can be published simultaneously with the publication of the
The document repository itself can present access control Contract itself. Effectively two transactions are created , one
mechanisms; and to publish the contract and get the transaction output repre
Theencryption
Contracttechniques
itself canlimiting
be secured through standard 5 senting the contract and a second one to spend that output.
access to those entities This second transaction has a CheckLockTimeVerify set on
with access to the relevant decryption keys.
In many cases , the Contract itself will have partial pro itendto spend the output on a given future date (representing the
tection on it . For example, some sections within the file standard waycontract
of the
but
). As per previous comment this is our
not the only way .
might be protected while the overall content is public e.g. the 10
details of how to implement a fixed rate loan are published This auto - spending can be extended to support the rolling
but the knowledge of who took out the loan , for how much on of a contract ( for example contracts that automatically
and at what rate is known only to the contracting parties. extend for a further twelve months if they are not cancelled ).
This partial protection applies to both the encryption of In this situation, the UTXO is spent sending it to the ' new '
the information within the contract as well as the hash 15 rolled - on contract. However, it is possible to cancel the old
detecting changes to its content. one by spending the output before the lock time and thus
For a number of contracts , the details of the contract can cancelling the whole contract .
be amended over its life and this should not require the Use Case Model
re - issuance of the contract itself. This can be achieved by
determining the scope of the hash over a sub - set of the FIG . 1 shows an overview of a use case model in
contract . An example where this might be useful is on the 20 accordance with an embodiment of the invention. This
implementation of a unit trust. The contract underpinning illustrative use case model demonstrates how standard Bit
the unit trust may not change, but beneficiary for the unit can coin transactions can be used to implement elements of the
be amended through on- sell of the con ct. In one embodi DFA directly within Bitcoin scripts . Examples of key use
ment, recording the changes can be achieved using subcon cases are now provided for the purpose of illustration .
tracts . 25
Terminating the Contract Creating the Contract
As the Blockchain provides a permanent, unalterable The Contract Issuer ( who is the primary actor in this
record of transactions, a contract cannot be terminated by example ) wishes to publish a contract onto the Blockchain
simply removing the associated Contract document. This for public visibility. This process is outlined in Table 1 :
Step Details
100.10 The Contract Issuer creates a new Contract Document and publishes this to a
Repository, storing the location of the store and the secure hash of that document
for later use . Note that this Repository can be public , private or semi-private
depending on the nature of the Contract Document itself . The Repository is
indexed allowing it to be searched by a variety of attributes .
100.20 The Contract Issuer creates a redeem script covering the contract document being
secured, in a m of n multi- signature structure where :
m is at least one ; and
n is m plus the number of metadata blocks (which will be at least two ).
The one public key that must always be supplied to this script is that of the Contract
Issuer. However, depending on the terms of the contract other signatures may be
required as well.
100.30 The Contract Issuer pays a nominal amount of currency e.g. Bitcoin to the redeem
script calculated in step 100.20 through a standard P2SH transaction .
100.40 The Contract Issuer waits until the transaction has been published onto the
Blockchain and extracts the transaction ID for the published transaction .
100.50 For a fixed duration contract, the Contract Issuer then creates a new transaction ,
with a locktime set to the expiry time of the contract, paying the output from step
100.40 back to the Contract Issuer's public key hash .
For a rolling duration contract, a computer -based agent can pick up the transaction
and wait until the contract expiry time before triggering the “ rollover ' use case of
table 3 below to roll it onto the contract .
For a completion -based contract (where x of y entities agree that the contract has
been fulfilled ), a m of n multi -signature transaction is created and issued to these
entities to co - sign upon completion ) .
means that the secure contract repository must have the 55 There are two key embodiments or variations to this
same storage and retention rules as the Blockchain itself scenario which are explained in detail below :
which is supported through a number of standard mecha
nisms . This means that the solution must present a mecha
nism for detecting the expiry of a contract through the 60 Creating a sub - contract from an existing contract
Rolling an existing contract over into a new one (renew
Blockchain record directly.
The method of termination is defined as a condition in the ing it)
contract and can be effected in a variety of ways , all of which
are conceptually covered by the present invention . In a Creating a Sub - Contract
preferred embodiment of the invention , termination is 65 In this situation, the Contract Issuer wishes to create a
handled through the spending of the UTXO that represents sub - contract from an existing contract. This process is
the contract. outlined in Table 2 :
US 11,120,437 B2
13 14
Step Details
150.10 The Contract Issuer creates a new sub -key from their public key used to create the
parent contract using a seed value in the derivation of the sub -key information from
the parent contract. This can be any derivation that the Contract Issuer wishes ( and
has committed to ) , but examples of appropriate seeds could include :
Transaction ID / index of the contract UTXO created in step 100.40 ; or
Redeem script hash created in step 100.20 .
It should be noted that this example assumes that the public key referred to above
would be the Contract Issuer's public key ; however, the skilled person will
appreciate that there is nothing to prevent this being the derived sub -key ( i.e. a sub
contract of a sub - contract ).
150.20 Depending on the nature of the sub -contract being created, the Contract Issuer
either:
Uses the location and hash of the master contract document ; or
Creates a new Contract Document with a link to the master embedded
within it , storing the location of the document and secure hash of that
document for later use ; or
Creates a new Contract Document with a link to the master embedded
within it , plus a list of the fields from the original Contract Document that is
covered . Effectively, this is a document which specifies that this sub
contract covers specific sections of another document rather than
duplicating the original information .
Note that this Repository can be public , private or semi-private depending on the
nature of the Contract document itself.
150.30 The Contract Issuer creates a redeem script covering the contract document being
secured , in a m of n multi- signature structure where :
m is at least one ; and
n is m plus the number of metadata blocks (which will be at least two ).
The one public key that must always be supplied to this script is that of the Contract
Issuer. However, depending on the terms of the contract other signatures may be
required as well .
150.40 The Contract Issuer pays a nominal amount of currency e.g. Bitcoin to the redeem
script calculated in step 150.30 through a standard P2SH ( pay - to - script- hash )
transaction .
150.50 The Contract Issuer waits until the transaction has been published onto the
Blockchain and extracts the transaction ID for the published transaction .
150.60 For a fixed duration sub - contract, the Contract Issuer then creates a new
transaction , with a locktime set to the expiry time of the contract, paying the output
from step 150.50 back to the Contract Issuer's public key hash .
35
According to one or more embodiments , the sub - contract signatory is < x > . In some embodiments , the transaction will
may be independently monitored . For example, consider a have two outputs: the fee to < x > plus the payment of the
property build contract where a sign -off from a surveyor is UTXO generated in step 150.50 .
required and the contract states “ subject to sign - off by < x > '. 40 Example Use Case : Roll - Over Existing Contract
To implement this, step 150.60 is created and circulated to In this use case , the Contract Issuer wishes to rollover an
< x > to sign. The repay script is not time locked but created existing contract into a new one . An illustrative process if
as a m of n multi- signature element where the required provided in table 3 :
Step Details
175.10 The Contract Issuer will check the Blockchain to determine whether the contract has
been cancelled or not by validating whether the previous UTXO has been spent or not .
If it has been spent , the process ends .
175.20 The Contract Issuer creates a new sub - key from their public key used to create the
parent contract and using it as a seed value in the derivation of the sub -key information
from the parent contract sequence. This can be any deterministic derivation that the
Contract Issuer wishes (and has committed to ) , but could be :
Sequence number ( e.g. rolled over instance ‘ 1 ' ) ; or
Date range for the rolled - over contract
The above assumes that the public key mentioned above would be the Contract Issuer's
public key, but in practice there is nothing to prevent this being a derived sub -key ( i.e. a
sub - contract of a sub -contract ). See section entitled “ Method of sub -key generation ” for
an example of how the sub -key can be created .
175.30 The Contract Issuer takes the location and hash of the existing contract document.
Note that this Repository can be public , private or semi-private depending on the nature
of the Contract Document itself.
175.40 The Contract Issuer creates a redeem script covering the contract document being
secured , in a m of n multi- signature structure where :
m is at least one ; and
n is m plus the number of metadata blocks ( which will be at least two ).
The two public keys that must always be supplied to this script is that of the Contract
Issuer and the Customer. However, depending on the terms of the contract other
signatures may be required as well .
175.50 The Contract Issuer pays a nominal amount of Bitcoin to the redeem script calculated in
step 175.40 through a standard P2SH transaction .
US 11,120,437 B2
15 16
-continued
Step Details
175.60 The Contract Issuer waits until the transaction has been published onto the Blockchain
and extracts the transaction ID for the published transaction .
175.70 A process (such as a bot or oracle - based implementation ) will pick up the transaction
and wait until the contract expiry time before re -triggering the “ roll over ? process of
table 3 to roll it on again if it has not been cancelled .
10
Example: Checking the Contract have been met . It is then possible to combine this concept
In this use case , an Interested Party wishes to confirm that with a process or application ( ' bot ' ) which can be used to
there is a contract in existence to cover the activity that ( s )he trigger the 20 BTC payments once the contract has been
is enquiring about . Such a process is shown in table 4 : marked as complete.
Step Details
200.10 The Interested Party will check the Blockchain to confirm whether the UTXO relating
to the contract they are interested in has been spent or not . Where the UTXO is still
unspent, then the contract remains valid . Where the UTXO is still unspent , but there
is a locktime transaction pending , then this will determine the expiry time for the
contract. Where the UTXO is spent, then the contract has been completed in some
regard.
The main variable above assumes that the Interested Party 25 For the purposes of illustration , some example scenarios
is aware of the transaction that governs the contract through are provided below which show some of the applications for
some other route ( in general, that is that they are either the which the invention can be used . In all of these scenarios, the
Contract Issuer or the Contract Counterparty ). However, any content of the contract itself is considered irrelevant and
entity that has access to the Contract Document and knowl- 30 non - limiting.
edge of the Contract Issuer will be able to check by : Example Scenario 1 : Public Registry of an Asset
Deriving the redeem script for the UTXO transaction ; and In this scenario , Bob decides to publish his ownership of
Scanning the Blockchain to find a UTXO with that an asset (e.g. his home) onto the Blockchain . Nothing else
matching redeem script hash . is done at this stage ; it is simply an asset that may then get
Example: Closing the Contract used in subsequent transactions. In this situation , there is no
In this use case , a Contract Issuer or Contract Counter- 35 termination date for the contract. FIG . 2a shows a simple
party wishes to close an existing contract. This process is state machine with two states : ( i ) contract is open and (ii )
illustrated in table 5 : contract is closed . FIG . 2b shows the metadata definition
Step Details
300.10 The instigator of the closure will check the blockchain to determine whether the
contract has been cancelled or not by validating whether the previous UTXO has
been spent or not . If it has been spent , the process ends as the contract has
already been closed .
300.20 If there is an existing closure transaction , then the instigator will simply sign this
transaction and submit onto the Blockchain
300.30 If there is not an existing closure transaction, then the instigator will create the
transaction with the transaction input being the UTXO of the last contract, and
the unlock script being their signature, the meta data associated with the contract
and their public key.
300.40 At the point that the transaction is accepted onto the Blockchain then it will be
public knowledge that the contract has been closed ( although only the
participants will know the specific reason why ).
Contract Conditions carried on the bitcoin Transaction output and which specifies
55 the contract location and proof of validity via the hash . FIG .
The same mechanism described above can be used to contract 2c shows an “ issuance ’ transaction that initially stores the
on the Blockchain (although, it actually only stores
monitor conditions within a given contract, such as check the hash not the actual contract ). FIG . 2d cancels the contract
points . For example, if a contract is determined to be worth by spending the bitcoin .
100 BTC , with 20 BTC to be paid at checkpoint 1 through 60 Example Scenario 2 : Creation and Registry of an Asset
5 , then the sub - contract model described above can be used with Hidden Ownership
to derive a master contract plus five sub - contracts. Each of BobThis is a slightly enhanced version of scenario 1 where
these sub - contracts can be marked as complete using the not want totodirectly
wants publish the asset onto the Blockchain , but does
same, or different, signatories ( such as notaries or similar, 65 In this situation, reveal his ownership .
Bob first creates a sub -key from his
for example ) . In this manner, a public record can be main public key to represent the asset. This sub -key is then
tained , showing that the conditions attached to the contract published as part of the asset's details onto the Blockchain .
US 11,120,437 B2
17 18
Once again, in this situation, there is no termination date for sibly using the sub -key generation technique described
the asset . ( A detailed example is provided below for one way below ) and publishes them . FIG . 6d shows the transaction
in which the sub -key may be generated. See section below for when the planning permission has been signed off.
entitled “ method of sub -key generation ”) . Codification Scheme
The state machine for this scenario is the same as that for 5 The metadata which is used to reference the contract can
scenario 1 , as shown in FIG . 2a . FIG . 3a shows the metadata be formatted in a variety of ways . However, a suitable
definition for this scenario . The metadata is carried on the codification scheme is described here.
bitcoin Transaction output and specifies the contract location A contract is transferable if the rights it defines are
and proof of validity (via the hash ). FIG . 3b shows the conferred upon the holder or owner of the contract . An
transaction to ' fund ' the asset . That is , to put some bitcoins 10 example of a non - transferable contract is one in which the
into the asset's public key so that the asset can fund its participants are named — that is , where the rights are con
transactions ( such as the publication transaction in FIG . 3c ) . ferred upon a specific named entity rather than the holder of
FIG . 3b does not show Bob's creation of the asset sub -key the contract . Only transferable contracts are discussed in this
as it is not a Bitcoin transaction . codification scheme .
FIG . 3c shows the blockchain transaction for the publi- 15 A token represents a specific contract that details or
cation of the asset. FIG . 3d shows the transaction for closure defines rights conferred by a contract . In accordance with the
of the contract. When the cancellation of the contract is present invention, the token is a representation of the con
required , the UTXO is spent. In this situation , the require- tract in the form of a bitcoin transaction .
ment has been for both the Asset and the hidden owner of the This codification method uses metadata comprising three
asset to sign . 20 parameters or data items. This data may be indicative of:
Example Scenario 3 : Lease Contract i ) an amount of shares available under the contract ( this
In this illustrative situation , Bob takes out a lease contract may be referred to herein as NumShares ');
with Eve for a fixed term of three years . The terms of the ii ) a quantity of transfer units to be transferred from a
contract will specify a number of payments. The details of sender to at least one recipient ( this may be referred to
the payment are not relevant in regard to the present inven- 25 herein as “ShareVal ' ); and
tion . However, the contract has a fixed term with no break iii ) a factor for calculating a value for the quantity of
clauses . transfer units ( this may be referred to herein as a
This has a simple state machine model as shown in FIG . “ pegging rate ” ) .
4a . FIG . 4b shows the metadata for this scenario . FIG . 40 An advantage of this codification scheme is that it can be
shows the transaction to publish the ownership of the asset 30 used to encapsulate or represent contracts as tokens on a
onto the Blockchain . Firstly, Bob provides some funding to blockchain using only the three parameters described above .
the asset , then the asset publishes itself. In effect, the contract can be specified using a minimum of
Example Scenario 4 : Rolling Contract these three data items . As this codification scheme can be
In this illustrative situation, Bob decides to lease a house used for any type of transferable contract, common algo
from Eve on a rolling annual basis , where he needs to 35 rithms can be devised and applied . Further detail of these
provide two months ' notice to cancel the lease at the renewal metadata items is provided as follows.
date otherwise it will automatically roll - on . This has a A divisible token is one in which the value on a transac
simple state machine model as shown in FIG . 5a . FIG . 56 tion output may be subdivided into smaller amounts allo
shows the metadata for this scenario . FIG . 50 shows the cated across multiple tokens ( i.e. allocated across multiple
transaction to publish the initial contract and the initial 40 transactions). The archetype is tokenised fiat currency.
rollover of the contract onto the Blockchain . Divisible contracts are defined as those that specify a
After the first year, Bob continues with the lease and does non - zero PeggingRate. For divisible contracts the tokenised
not terminate. Immediately after EVE - S3 - T2 is published value transferred in the transaction output is tied to the
then it is picked up by an automated computing agent and underlying bitcoin (BTC ) value via the PeggingRate . That
rolled- on for another year. It should be noted that it is also 45 is , the contract specifies the holder's rights in terms of a
possible that this could be done by EVE using internal logic pegging -rate . For non - divisible tokens there is no Peggin
of her own. gRate and the contract specifies the holder's rights in terms
After the second year, Bob chooses to terminate the lease of a fixed value ( e.g. like a bearer bond : “ this contract is
and submits a transaction using the same input as EVE -S3- redeemable for exactly $ 1000 ' or a voucher “ this contract is
T3 . However, because this transaction has not yet been 50 redeemable for one haircut '). For non - divisible contracts the
submitted , the input is unspent and if Bob's transaction is underlying transaction BTC value is irrelevant to the con
published to the Blockchain first it will invalidate EVE -S3- tract value .
T3 . Whilst the amounts involved are trivial, the bot will not The phrase " Underlying BTC value ” refers to the bitcoin
countersign the transaction unless the output is directed to amount (BTC ) attached to the transaction output. In the
Eve's public key hash ( or whatever the contract actually 55 Bitcoin protocol every transaction output must have non
states ) . The transaction for the termination of Bob's contract zero BTC amount to be considered valid . In fact, the BTC
is shown in FIG . 5d . amount must be greater than a set minimum (known as
Example Scenario 5 : Contract Conditionality ‘ dust ) which, at the time of writing, is currently set to 546
In this illustrative situation , Bob enters into a contract satoshis. 1 bitcoin is defined as being equal to 100 million
with a pool of builders to deliver a new property, and 60 satoshis. As the bitcoin transactions are here used only as a
specifies a number of conditions within the contract that means of facilitating an exchange of ownership , the actual
require independent sign -off ( the first being the approval of underlying BTC amount is arbitrary : the true value lies in the
the plans from the local planning authority ). This has a contract specification. In theory every token could be carried
simple state machine model as shown in FIG . 6a . FIG . 6b by dust .
shows the metadata for this scenario . FIG . 6c shows the 65 In accordance with the present codification scheme, spe
transaction wherein Bob creates the initial contract and the cifically for divisible tokens, the underlying BTC value does
two sub -contracts ( after deriving the relevant sub -key, pos- have a meaning : it bears a relationship to the contract value
US 11,120,437 B2
9
19 20
via a PeggingRate. The PeggingRate is itself arbitrary and is be set to 50 cents, in which case transfers may only be
chosen so as to keep the underlying BTC amount small . The executed in ‘ lots ' of 50 cents . ShareVal may also be
reason for using a PeggingRate rather than simply underly- expressed as a percentage: for example if a breeder wants to
ing every token transaction with dust is because the protocol sell a racehorse in 10 equal shares then the ShareVal = 10 % .
of the present invention facilitates divisibility: when a token 5 ShareVal must be > 0 and must be defined on the contract.
is split into several transaction outputs of smaller amounts it TotalIssuance represents the total value of shares issued .
is not necessary to adjust the original contract. Rather, the This value only relates to limited contracts as for unlimited
contract value of each subdivided token is simply calculated contracts the issuance is not fixed and more shares may be
based on the PeggingRate and the subdivided amount of issued . If the shares are expressed as a percentage then the
underlying BTC value. 10 TotalIssuance = 100 % by definition .
A limited token is one in which a total issuance value is For limited contracts NumShares, ShareVal, and Totalis
fixed ( or ' limited ' ) by a fixed non - zero number of shares as suance are related in the following way :
defined by a quantity called NumShares. Therefore, no NumSharesx Share Val = TotalIssuance .
further shares may be issued under a limited contract. For
example a contract for part ownership of a race horse is 15 A value of O for TotalIssuance implies it is an unlimited
limited to 100 % ofthe race horse (e.g. 100 shares at 1 % each contract. An example of an unlimited contract is fiat cur
or 10 shares at 10 % each, etc. ). An unlimited contract rency ( so TotalIssuance is set to 0 ) ; examples of limited
implies that the issuer is able to underwrite further issuances contracts are : ( i ) limited edition commemorative coins ( 1000
of shares, for example by adding the required amount of fiat minted , where 1 share = 1 coin) : TotalIssuance = 1000x
currency into their Reserve Account. NumShares must be 20 1 = 1000 coins ; and ( ii ) seats at a ticketed venue , where
explicitly stated on all contracts . Limited contracts must TotalIssuance = total number of seats available .
have NumShares > 0 ; unlimited contracts are denoted by The circulation is defined as the total value of unspent
setting NumShares = 0 . tokens (i.e. as determined by transactions in UTXO
The archetypical example is a currency reserve (analo- unspent transaction output). The full set of all unspent
gous to a gold reserve) such that the total value held in the 25 transactions is kept in a list available to all bitcoin nodes . For
reserve bank account matches the total value in promissory example, if an issuer initially issues $ 10,000 as fiat currency
notes in existence (i.e. unredeemed tokens ). This concept type tokens and over time $ 5500 worth of tokens are
extends beyond currency reserves to include stock inven- redeemed, then the circulation = $ 4500 ( being the value of
tory . For example, an issuer of licensed printed t - shirt tokens unredeemed tokens). This value should reconcile to the
may start with an inventory of 10,000 T -shirts in stock and 30 balance in the associated reserve account.
may issue a divisible token to represent those 10,000 t - shirts Method of Sub -Key Generation
(where, say , each share = 1 t - shirt ). The original token could Above, Table 3 and the example scenarios refer to situ
be subdivided and each subdivided token would be redeem- ations where it is advantageous to generate a sub -key from
able for a number of t- shirts according to the transaction an original (master) key. A method for achieving this is now
output's underlying BTC value as defined by the Peggin- 35 provided for illustration of one way in which this could be
gRate. If demand increases, however, the issuer may decide performed .
to issue further shares ( i.e. increase the number of shares in FIG . 7 illustrates a system 1 that includes a first node 3
circulation by ( say) another 10,000 ) . In such cases it is which is in communication with a second node 7 over a
incumbent on the issuer to deposit a further 10,000 t - shirts communications network 5. The first node 3 has an associ
into his reserve account (i.e. stock warehouse) in order to 40 ated first processing device 23 and the second node 5 has an
underwrite the further issuance. Thus, the total number of associated second processing device 27. The first and second
t - shirts in stock (where stock acts as “ reserve account ) at nodes 3 , 7 may include an electronic device, such as a
any one time = the total number of unredeemed shares . computer, phone, tablet computer, mobile communication
PeggingRates only apply to divisible contracts , wherein device, computer server etc. In one example, the first node
the value of a share ( represented by a quantity called 45 3 may be a client (user ) device and the second node 7 may
ShareVal) is pegged to the underlying BTC amount. For be a server. The server may be a digital wallet provider's
example , the contract might specify that the issuer promises server.
to redeem the token at a rate of $ 10,000 for every underlying The first node 3 is associated with a first asymmetric
1 BTC . That would mean ( for example) that a transaction cryptography pair having a first node master private key
with a tokenised underlying output value of 15,400 satoshis 50 (Vic) and a first node master public key (Pic ). The second
would be redeemable for $ 1.54 . A value of 0 for the node ( 7 ) is associated with a second asymmetric cryptogra
PeggingRate indicates that the contract is non - divisible ( i.e. phy pair having a second node master private key (Vis) and
can only be transferred whole , like a bearer bond ). When the a second node master public key (P1s ). In other words , the
PeggingRate is set to 0 (meaning non- divisible token ) the first and second nodes are each in possession of respective
underlying BTC value is not relevant to the contract value 55 public -private key pairs.
and can be set at any amount. Normally in this case it is The first and second asymmetric cryptography pairs for
desirable to keep the underlying BTC amount as small as the respective first and second nodes 3 , 7 may be generated
possible ( i.e. set to dust) to minimise operating costs . during a registration process, such as registration for a
NumShares is the total ( fixed ) number of shares available wallet . The public key for each node may be shared publicly,
under the ( Limited ) contract. For limited contracts Num- 60 such as over communications network 5 .
Shares must be a whole number greater than zero . For To determine a common secret (CS ) at both the first node
unlimited contracts NumShares is not fixed as more shares 3 and second node 7 , the nodes 3 , 7 perform steps of
can be issued at any time (provided they are underwritten ), respective methods 300 , 400 without communicating private
which is denoted by setting the value to 0 . keys over the communications network 5 .
A share is defined as the unit of transfer and the ShareVal 65 The method 300 performed by the first node 3 includes
is the value of that unit . For example, for fiat currency , the determining 330 a first node second private key (V2c ) based
unit of transfer may be set to 1 cent. Or, for example, it may on at least the first node master private key (Vic) and a
US 11,120,437 B2
21 22
Generator Value (GV) . The Generator Value may be based message ( M) may be public and therefore may be transmit
on a message ( M) that is a shared between the first and ted over an unsecure network 5. One or more messages (M )
second nodes, which may include sharing the message over may be stored in a data store 13 , 17 , 19. The skilled person
the communications network 5 as described in further detail will realise that sharing of the message can be achieved in
below. The method 300 also includes determining 370 a 5 a variety of ways .
second node second public key (P2s) based on at least the Advantageously, a record to allow recreation of the com
second node master public key (P1s) and the Generator mon secret ( CS ) may be kept without the record by itself
Value (GV ). The method 300 includes determining 380 the having to be stored privately or transmitted securely.
common secret (CS ) based on the first node second private Method of Registration 100 , 200
key (V2c ) and the second node second public key (P2s ). 10 An example of a method of registration 100 , 200 will be
Importantly , the same common secret (CS ) can also be described with reference to FIG . 9 , where method 100 is
determined at the second node 7 by method 400. The method performed by the first node 3 and method 200 is performed
400 includes determining 430 a first node second public key by the second node 7. This includes establishing the first and
(P2c) based on the first node master public key (Pic) and the second asymmetric cryptography pairs for the respective
Generator Value (GV ). The method 400 further include 15 first and second nodes 3 , 7 .
determining 470 a second node second private key ( V2s) The asymmetric cryptography pairs include associated
based on the second node master private key ( V is ) and the private and public keys, such as those used in public -key
Generator Value (GV ). The method 400 includes determin- encryption . In this example, the asymmetric cryptography
ing 480 the common secret ( CS ) based on the second node pairs are generated using Elliptic Curve Cryptography
second private key (V2s) and the first node second public 20 (ECC ) and properties of elliptic curve operations.
key (Pc ). In the method 100 , 200 , this includes the first and second
The communications network 5 may include a local area nodes agreeing 110 , 210 on a common ECC system and
network , a wide area network , cellular networks, radio using a base point ( G) . (Note: the base point could be
communication network , the internet, etc. These networks, referred to as a Common Generator, but the term ‘ base point?
where data may be transmitted via communications medium 25 is used to avoid confusion with the Generator Value GV ). In
such as electrical wire , fibre optic , or wirelessly may be one example, the common ECC system may be based on
susceptible to eavesdropping, such as by an eavesdropper secp256K1 which is an ECC system used by Bitcoin . The
11. The method 300 , 400 may allow the first node 3 and base point ( G) may be selected, randomly generated, or
second node 7 to both independently determine a common assigned .
secret without transmitting the common secret over the 30 Turning now to the first node 3 , the method 100 includes
communications network 5 . settling 110 on the common ECC system and base point (G) .
Thus one advantage is that the common secret (CS ) may This may include receiving the common ECC system and
be determined securely and independently by each node base point from the second node 7 , or a third node 9 .
without having to transmit a private key over a potentially Alternatively, a user interface 15 may be associated with the
unsecure communications network 5. In turn, the common 35 first node 3 , whereby a user may selectively provide the
secret may be used as a secret key ( or as the basis of a secret common ECC system and / or base point ( G) . In yet another
key ). alternative one or both of the common ECC system and / or
The methods 300 , 400 may include additional steps. See base point (G) may be randomly selected by the first node 3 .
FIG . 11. The method 300 may include, at the first node 3 , The first node 3 may send , over the communications net
generating a signed message ( SM1 ) based on the message 40 work 5 , a notice indicative of using the common ECC
( M) and the first node second private key (V2c ). The method system with a base point (G) to the second node 7. In turn ,
300 further includes sending 360 the first signed message the second node 7 may settle 210 by sending a notice
( SM1 ) , over the communications network , to the second indicative of an acknowledgment to using the common ECC
node 7. In turn , the second node 7 may perform the steps of system and base point ( G) .
receiving 440 the first signed message ( SM1 ) . The method 45 The method 100 also includes the first node 3 generating
400 also includes the step of validating 450 the first signed 120 a first asymmetric cryptography pair that includes the
message ( SM2 ) with the first node second public key (P2c) first node master private key (Vic) and the first node master
and authenticating 460 the first node 3 based on the result of public key (Pic) . This includes generating the first node
validating the first signed message ( SMI ) . Advantageously , master private key (Vic) based , at least in part, on a random
this allows the second node 7 to authenticate that the 50 integer in an allowable range specified in the common ECC
purported first node (where the first signed message was system . This also includes determining the first node master
generated ) is the first node 3. This is based on the assump- public key (Pic) based on elliptic curve point multiplication
tion that only the first node 3 has access to the first node of the first node master private key ( Pic) and the base point
master private key (Vic) and therefore only the first node 3 ( G ) according to the formula :
can determine the first node second private key (V2c) for 55 Pic = VicXG (Equation 1 )
generating the first signed message ( SM1 ) . It is to be
appreciated that similarly, a second signed message ( SM2 ) Thus the first asymmetric cryptography pair includes:
can be generated at the second node 7 and sent to the first Vic : The first node master private key that is kept secret
node 3 such that the first node 3 can authenticate the second by the first node .
node 7 , such as in a peer-to - peer scenario . 60 Pic : The first node master public key that is made publicly
Sharing the message ( M) between the first and second known .
nodes may be achieved in a variety of ways . In one example , The first node 3 may store the first node master private
the message may be generated at the first node 3 which is key (Vic) and the first node master public key ( Pic) in a first
then sent, over the communications network 5 , the second data store 13 associated with the first node 3. For security,
node 7. Alternatively, the message may be generated at the 65 the first node master private key (Vic) may be stored in a
second node 7 and then sent, over the communications secure portion of the first data store 13 to ensure the key
network 5 , to the second node 7. In some examples, the remains private.
US 11,120,437 B2
23 24
The method 100 further includes sending 130 the first The message ( M) may be sent over an unsecure network as
node master public key (Pic ), over the communications the message (M) does not include information on the private
network 5 , to the second node 7 , as shown in FIG . 9. The keys.
second node 7 may , on receiving 220 the first node master 5 Determining a Generator Value (GV ) 320
public key ( Pic) , store 230 the first node master public key The method 300 further includes the step of determining
(Pic) in a second data store 17 associated with the second 320 a Generator Value (GV ) based on the message (M) . In
node 7 . this example , this includes determining a cryptographic hash
Similar to the first node 3 , the method 200 of the second of the message . An example of a cryptographic hash algo
7 includes generating 240 a second asymmetric cryptogra rithm includes SHA - 256 to create a 256 - bit Generator Value
phy pair that includes the second node master private key 10 (GV ). That is :
(Vis ) and the second node master public key (Pis ). The GV = SHA - 256 (M ) ( Equation 4)
second node master private key (Vis) is also a random It is to be appreciated that other hash algorithms may be
integer within the allowable range. In turn , the second node
master public key (Pis) is determined by the following 15 Hash. This used may include other hash algorithms in the Secure
Algorithm ( SHA ) family . Some particular examples
formula :
include instances in the SHA - 3 subset , including SHA3-224 ,
Pus = V1sxG (Equation 2 ) SHA3-256 , SHA3-384 , SHA3-512 , SHAKE128 ,
Thus the second asymmetric cryptography pair includes : RACE SHAKE256 . Other hash algorithms may include those in the
Integrity Primitives Evaluation Message Digest
Vis : The second node master private key that is kept 20 (RIPEMD ) family. A particular example may include RIP
secret by the second node . EMD - 160 . Other hash functions may include families based
Pis: The second node master public key that is made on Zémor - Tillich hash function and knapsack -based hash
publicly known. functions.
The second node 7 may store the second asymmetric
cryptography pair in the second data store 17. The method 25 Determining a First Node Second Private Key 330
The method 300 then includes the step 330 of determining
200 further includes sending 250 the second node master 330 the first node second private key (V2c) based on the
public key (P1s ) to the first node 3. In turn , the first node 3 second node master private key (Vic ) and the Generator
may receive 140 and stores 150 the second node master Value (GV ). This can be based on a scalar addition of the
public key ( P1s ). first node master private key (Vic) and the Generator Value
It is be appreciated that in some alternatives , the 30 (GV ) according to the following formula :
respective public master keys may be received and stored at (Equation 5 )
a third data store 19 associated with the third node 9 ( such V2c = Vic +GV
as a trusted third party ). This may include a third party that Thus the first node second private key (V2c) is not a
acts as a public directory, such as a certification authority. random value but is instead deterministically derived from
Thus in some examples, the first node master public key 35 the first node master private key. The corresponding public
(Pic) may requested and received by the second node 7 only key in the cryptographic pair, namely the first node second
when determining the common secret ( CS ) is required (and public key ( P2c) , has the following relationship:
vice versa ). P2c = V2cxG ( Equation 6 )
The registration steps may only need to occur once as an
initial setup. 40 Substitution of V2c from Equation 5 into Equation 6
Session Initiation and Determining the Common Secret provides :
by the First Node 3 P2c = (Vic +GV ) xG ( Equation 7 )
An example of determining a common secret ( CS ) will
now be described with reference to FIG . 10. The common where the ' + ' operator refers to scalar addition and the ‘ x '
secret (CS ) may be used for a particular session , time , 45 operator refers to elliptic curve point multiplication. Noting
transaction, or other purpose between the first node 3 and the that elliptic curve cryptography algebra is distributive,
second node 7 and it may not be desirable, or secure, to use Equation 7 may be expressed as :
the same common secret ( CS ) . Thus the common secret (CS ) P2c = VicXG + GVXG ( Equation 8 )
may be changed between different sessions , time , transac Finally, Equation 1 may be substituted into Equation 7 to
tions , etc.
The following is provided for illustration of the secure 50 provide:
transmission technique which has been described above. P2c = Pic +GVXG ( Equation 9.1 )
Generating a Message ( M ) 310
In this example, the method 300 performed by the first P2c = P1c + SHA - 256 ( M )xG (Equation 9.2 )
node 3 includes generating 310 a message ( M) . The message 55 In equations 8 to 9.2 , the ' + ' operator refers to elliptic
( M) may be random , pseudo random , or user defined . In one curve point addition . Thus the corresponding first node
example, the message ( M) is based on Unix time and a nonce second public key ( P2c) can be derivable given knowledge
( and arbitrary value ) . For example, the message ( M) may be of the first node master public key (Pic ) and the message
provided as : (M ) . The second node 7 may have such knowledge to
Message ( M ) = UnixTime + nonce ( Equation 3 ) 60 independently determine the first node second public key
(P2c) as will be discussed in further detail below with
In some examples, the message ( M) is arbitrary . However respect to the method 400 .
it is to be appreciated that the message ( M) may have Generate a First Signed Message ( SM1 ) Based on the
selective values ( such as Unix Time , etc ) that may be useful Message and the First Node Second Private Key 350
in some applications. 65 The method 300 further includes generating 350 a first
The method 300 includes sending 315 the message (M) , signed message ( SM1 ) based on the message (M ) and the
over the communications network 3 , to the second node 7 . determined first node second private key (V2c ). Generating
US 11,120,437 B2
25 26
a signed message includes applying a digital signature The mathematical proof for Equations 12.1 and 12.2 is the
algorithm to digitally sign the message ( M) . In one example, same as those discussed above for Equations 10.1 and 10.2 .
this includes applying the first node second private key The Second Node 7 Authenticating the First Node 3
(V2c) to the message in an Elliptic Curve Digital Signature The method 400 may include steps performed by the
Algorithm (ECDSA) to obtain the first signed message 5 second node 7 to authenticate that the alleged first node 3 ,
( SM1 ) . Examples of ECDSA include those based on ECC is the first node 3. As discussed previously, this includes
systems with secp256k1 , secp256r1, secp384r1 , receiving 440 the first signed message ( SM1 ) from the first
se3cp521r1 . node 3. The second node 7 may then validate 450 the
The first signed message ( SM1 ) can be verified with the signature on the first signed message ( SM1 ) with the first
corresponding first node second public key ( P2c) at the 10 node second public key ( P2c) that was determined at step
second node 7. This verification of the first signed message 430Verifying
.
the digital signature may be done in accordance
( SM1 ) may be used by the second node 7 to authenticate the with an Elliptic Curve Digital Signature Algorithm
first node 3 , which will be discussed in the method 400 (ECDSA) as discussed above. Importantly, the first signed
below. message ( SM1 ) that was signed with the first node second
Determine a Second Node Second Public Key 370 15
private key (V2c ) should only be correctly verified with the
The first node 3 may then determine 370 a second node corresponding first node second public key ( P2c ) , since V2c
second public key ( P2s ). As discussed above , the second and P2c form a cryptographic pair. Since these keys are
node second public key (P2s ) may be based at least on the deterministic on the first node master private key (Vic) and
second node master public key (Pis) and the Generator the first node master public key (Pic ) that were generated at
Value (GV ). In this example, since the public key is deter- 20 registration of the first node 3, verifying first signed message
mined 370 ' as the private key with elliptic curve point ( SM1 ) can be used as a basis of authenticating that an
multiplication with the base point (G) , the second node alleged first node sending the first signed message ( SM1 ) is
second public key (P2s) can be expressed , in a fashion the same first node 3 during registration. Thus the second
similar to Equation 6 , as : node 7 may further perform the step of authenticating ( 460)
25 the first node 3 based on the result of validating ( 450 ) the
P2s = V2sXG (Equation 10.1 ) first signed message.
The Second Node 7 Determining the Common Secret
P2s = P 1s+ GVXG (Equation 10.2 ) The method 400 may further include the second node 7
The mathematical proof for Equation 10.2 is the same as based on the 470
determining a second node second private key (V2s)
second node master private key ( V is ) and the
described above for deriving Equation 9.1 for the first node 30 Generator Value (GV ). Similar to step 330 performed by the
second public key ( P2c) . It is to be appreciated that the first first node 3 , the second node second private key (V2s) can
node 3 can determine 370 the second node second public key be based on a scalar addition of the second node master
independently of the second node 7 . private key (Vis) and the Generator Value (GV ) according
Determine the Common Secret 380 at the First Node 3 to the following formulas:
The first node 3 may then determine 380 the common 35 V2s = V1s +GV ( Equation 13.1 )
secret ( CS ) based on the determined first node second
private key (V2c) and the determined second node second V2s = V1s + SHA - 256 ( M ) ( Equation 13.2 )
public key ( P2s ). The common secret (CS ) may be deter The second node 7 may then , independent of the first node
mined by the first node 3 by the following formula : 3 , determine 480 the common secret ( CS ) based on the
40
S = V2cXP 25 ( Equation 11 ) second node second private key (V2s) and the first node
Method 400 Performed at the Second Node 7 second public key (P2c ) based on the following formula:
The corresponding method 400 performed at the second S = V2s4P2c (Equation 14)
node 7 will now be described. It is to be appreciated that Proof of the Common Secret ( CS ) determined by the First
some of these steps are similar to those discussed above that 45 Node 3 and Second Node 7
were performed by the first node 3 . The common secret ( CS ) determined by the first node 3 is
The method 400 includes receiving 410 the message (M ) , the same as the common secret ( CS ) determined at the
over the communications network 5 , from the first node 3 . second node 7. Mathematical proof that Equation 11 and
This may include the message ( M) sent by the first node 3 50 Equation 14 provide the same common secret (CS ) will now
at step 315. The second node 7 then determines 420 a be described .
Generator Value (GV ) based on the message (M) . The step Turning to the common secret (CS ) determined by the first
of determining 420 the Generator Value (GV ) by the second node 3 , Equation 10.1 can be substituted into Equation 11 as
node 7 is similar to the step 320 performed by the first node follows:
described above . In this example , the second node 7 per (Equation 11 )
forms this determining step 420 independent of the first node 55 S = V2cXP2s
3.
The next step includes determining 430 a first node S = V2cX ( V25 * G )
second public key (P2c) based on the first node master S = ( V2cxV2s )xG ( Equation 15 )
public key (Pic) and the Generator Value (GV ). In this
example, since the public key is determined 430 ' as the 60 Turning to the common secret (CS ) determined by the
private key with elliptic curve point multiplication with the second node 7 , Equation 12.1 can be substituted into Equa
base point ( G) , the first node second public key ( P2c) can be tion 14 as follows :
expressed , in a fashion similar to Equation 9 , as : S = V2sXP2c ( Equation 14)
P2c = V2cXG (Equation 12.1 ) 65 S = V25* ( V2cxG )
P2c = P1c +GVxG (Equation 12.2 ) S = ( V2s * V2c )xG (Equation 16 )
US 11,120,437 B2
27 28
Since ECC algebra is commutative, Equation 15 and The second node 7 may then determine the next genera
Equation 16 are equivalent, since : tion of the first node second public key ( P2c' ) and the second
S = ( V2cxV2s )xG = ( V25 * V2c )xG ( Equation 17 ) node second private key (V2s ') similar to steps 430 and 470
described above, but adapted with the following formulas:
The Common Secret (CS ) and Secret Key 5
Pac=Pc + GVXG ( Equation 21.1 )
The common secret ( CS ) may now be used as a secret key,
or as the basis of a secret key in a symmetric -key algorithm V2s ' = Vis +GV ' ( Equation 21.2 )
for secure communication between the first node 3 and
second node 7 . The first node 3 and the second node 7 may then each
The common secret (CS) may be in the form of an elliptic 10 determine the next generation common secret (CS ' ) . In
curve point (Xs, ys ). This may be converted into a standard particular, the first node 3 determines the next generation
key format using standard publicly known operations agreed common secret ( CS ' ) with the formula :
by the nodes 3 , 7. For example, the xs value may be a 256 - bit CS'= V2cXP2s' (Equation 22 )
integer that could be used as a key for AES256 encryption .
It could also be converted into a 160 - bit integer using 15 The second node 7 determines the next generation com
RIPEMD160 for any applications requiring this length key . mon secret (CS ' ) with the formula :
The common secret ( CS ) may be determined as required . CS'= V2s'XP2c (Equation 23 )
Importantly, the first node 3 does not need to store the
common secret (CS ) as this can be re -determined based on Further generations (CS" , CS '" , etc. ) can be calculated in
the message (M) . In some examples, the message (s ) (M) 20 the same way to create a chain hierarchy. This technique
used may be stored in data store 13 , 17 , 19 (or other data requires that both the first node 3 and the second node 7 keep
store ) without the same level of security as required for the track of the original Message (M) or the originally calcu
master private keys. In some examples, the message ( M) lated Generator Value (GV ), and to which node it relates. As
may be publicly available . However depending on some this is publicly known information there are no security
application, the common secret (CS ) could be stored in the 25 issues regarding the retention of this information . Accord
first data store ( X ) associated with the first node provided the ingly, this information might be kept on ‘hash tables '
common secret (CS ) is kept as secure as the first node master ( linking hash values to public keys ) and distributed freely
private key (Vic ). across the network 5 ( for example using Torrent ). Further
Advantageously, this technique can be used to determine more , if any individual common secret ( CS ) in the hierarchy
multiple common secrets that may correspond to multiple 30 is ever compromised, this does not affect the security of any
secure secret keys based on a single master key cryptogra- other common secrets in the hierarchy provided the private
phy pair . keys Vic , Vis remain secure .
Hierarchy of Generator Values (Keys ) Tree Structure of Keys
For example, a series of successive Generator Values As well as a chain (linear) hierarchy as described above ,
(GVs) may be determined , where each successive GV may 35 a hierarchy in the form of a tree structure can be created .
be determined based on the preceding Generator Value With a tree structure, a variety of keys for different purposes
(GV ). For example, instead of repeating steps 310 to 370 and such as authentication keys, encryption keys , signing keys,
410 to 470 to generate successive single -purpose keys , by payment keys, etc. may be determined whereby these keys
prior agreement between the nodes, the previously used are all linked to a single securely maintained master key.
Generator Value (GV ) can be rehashed repeatedly by both 40 This is best illustrated in FIG . 12 that shows a tree structure
parties to establish a hierarchy of Generator Values. In effect, 901 with a variety of different keys . Each of these can be
the Generator Value, based on the hash of a message (M) , used to create a shared secret with another party . Tree
can be a next generation message (M' ) for the next genera- branching can be accomplished in several ways, three of
tion of Generator Value (GV ' ). Doing this allows successive which are described below .
generations of shared secrets to be calculated without the 45 ( i ) Master Key Spawning
need for further protocol-establishment transmissions, in In the chain hierarchy, each new ' link ' (Public /Private key
particular transmission of multiple messages for each gen- pair) is created by adding a multiply rehashed Message to
eration of common secrets . The next generation common the original master key. For example, (showing only the
secret (CS ' ) can be computed as follows. private key of the first node 3 for clarity ):
Firstly, both the first node 3 and the second node 7 50 V2c = Vic + SHA - 256 ( M ) ( Equation 24)
independently determine the next generation of the Genera
tor Value (GV ' ). This is similar to steps 320 and 420 but V2c '= Vic + SHA - 256 (SHA -256 ( M )) ( Equation 25 )
adapted with the following formulas:
M = SHA - 256 (M ) ( Equation 18 ) 55 V2c " = Vic + SHA -256 ( SHA - 256 (SHA -256 ( M ))) ( Equation 26 )
and so on.
GV ' = SHA - 256 ( M ) ( Equation 19.1 ) To create a branch, any key can be used as a sub -master
( Equation 19.2 )
key. For example V2c' can be used as a sub -master key (V3c)
GV ' = SHA - 256 (SHA - 256 (M )) by adding the hash to it as is done for the regular master key:
The first node 3 may then determine the next generation 60 V3c = V2c ' + SHA -256 ( M ) ( Equation 27 )
of the second node second public key ( P2s') and the first
node second private key (V2c' ) similar to steps 370 and 330 The sub -master key (V3c) may itself have a next genera
described above , but adapted with the following formulas: tion key (V3c'), for example :
P2s '= P 1s + GVXG ( Equation 20.1 ) 65 V3c ' = V2c + SHA - 256 (SHA -256 ( M ) ) ( Equation 28 )
This provides a tree structure 903 using the master key
V2c '= Vic +GV ( Equation 20.2 ) spawning method as shown in FIG . 13 .
US 11,120,437 B2
29 30
(ii ) Logical Association The Turing Machine includes two stacks :
In this method all the nodes in the tree (public/private key Data stack : This is represented by the Blockchain as
pairs ) are generated as a chain (or in any other way ) and the described above .
logical relationships between the nodes in the tree is main- Control stack : This is represented by the agent function .
tained by a table in which each node in the tree is simply 5 This stores information relating to the repeat control
associated with its parent node in the tree using a pointer. flow function .
Thus the pointer may be used to determine the relevant The separation of the control stack from the data stack
public / private key pairs for determining the common secret provides
occurring
the advantage of preventing infinite loops from
within the Bitcoin core , mitigating denial -of
key (CS ) for the session . 10 service attacks.
( iii ) Message Multiplicity The agent manages and runs subroutines that are able to
New private /public key pairs can be generated by intro loop via any type of loop construct (e.g. FOR -NEXT ;
ducing a new message at any point in the chain or tree. The REPEAT UNTIL ; etc ). An illustrative embodiment
message itself may be arbitrary or may carry some meaning described herein includes a process using one example of the
ornumber
function (e.g. it might be related to a “real bank account 15 “repeat' construct.The user may specify the index (i) and the
, etc ) . It may be desirable that such new messages for limit (J ) . These represent the current iteration number ( typi
forming the new private /public key pairs are securely cally counted starting from 0) and the total number of
retained . iterations of the repeat loop respectively .
Illustrative Computing Agent for Use with the Invention For each iteration :
The present invention can utilise a computing resource or 20 1. The Index increments by 1. For the exit condition , the
agent to perform automated aspects of the contract process . iterations will stop when the index reaches the limit
An example of a suitable agent is provided below, although 2. A code block containing an “ if condition then action "
other implementations may be used . ( ICTA ) statement is executed ; the action may be any
The agent may operate in conjunction with the block- action on or off the blockchain ;
chain , using it as the non - erasable tape in the implementa- 25 3. A cryptographic hash of this subroutine is computed.
tion of a Turing machine. This agent runs in parallel with the This can be stored in the Blockchain as part of a
blockchain network , overseeing and handling the execution transaction . Since the hash is unique to each code , it
of a ( looping) process . The looping process is designed to will enable verification of which code has been used
perform a given task such as , for example, the automation of The body of the loop includes a code block . Each code
a process or control of a device or system . This parallel 30 mentblock contains a “ If condition then action ” ( ICTA ) state
. This monitors the current state of the Blockchain for
resource monitors the state of the blockchain and can cause
transactions to be written to the blockchain . In one sense , it transactions matching the:
utilises the Blockchain as a non - erasable tape of the Turing Start or triggering condition (e.g when a particular date is
reached ).
Machine , with the following definitions and features: 35 Repeat condition (i.e. a metadata or hash associated with
1. the Blockchain acts as the tape of the Turing Machine. the previous iteration ).
Each transaction in the Blockchain represents a cell on Stop condition ( i.e. last iteration of the loop ) .
the tape. This cell can contain symbols from a finite The ICTA statement enables the agent to decide on the
alphabet. next transaction to make, based on the current state of the
2. The tape head can read information from the blocks that 40 blockchain . Making the next transaction involves broadcast
have already been written onto the Blockchain . ing the transaction onto the Bitcoin network , and writing the
3. The tape head can write new blocks , containing many new transaction onto the Blockchain . This acts as a record
transactions, to the end of the Blockchain . However, that this iteration has been executed . Once the transaction
they cannot write onto blocks that already exist . As has been written onto the Blockchain , the Manager will
such , the Blockchain tape is non - erasable. 45 subsequently find that the previous iteration has been
4. Metadata for each transaction can be stored as part of executed and written onto the Blockchain , and will execute
a multi- signature pay - to - script-hash (P2SH ) transac- the next iteration . The latter continues until the repeat loop
tion . exits when the index ( i ) reaches the limit (I ) specified in the
An important function of the agent is to act as an code block .
automated entity that monitors the current state of the 50 Each transaction is saved in the blockchain in a way that
Blockchain . It can also receive a signal or input from any can be reused . In a Bitcoin implementation, each signature
off - block source . Depending on the Blockchain state and / or in a transaction is appended with a SIGHASH flag. This flag
a received input, the agent may perform certain actions . The can take on different values , each indicating whether other
agent decides which action ( s ) are to be performed. These parts of the transaction can be amended without involvement
may or may not involve actions in the “ real world ' i.e. off 55 of the owner of this signature. A reusable transaction has the
block ) and / or actions on the Blockchain ( such as creating SIGHASH flag ‘ SigHash_AnyoneCanPay' in one of the
and broadcasting new transactions). The action that the transaction inputs. This permits anyone to contribute to the
agent takes may be triggered by the Blockchain state . The inputs of the transaction . This parameter enables the agent's
agent may also decide on the next set of transactions to be ICTA function to be executed and repeated multiple times
broadcast to the Bitcoin network, and subsequently written 60 and with different inputs. Use of the function can be
to the Blockchain . restricted to authorised parties — for example, via copyright
The agent's action ( s ) run in parallel and simultaneously to of the reusable transaction .
the Blockchain ( eg Bitcoin) network . In a sense , this extends The ' If condition ' section of the ICTA code block can
the function of blockchain ( eg Bitcoin) script. This continu- monitor any type of condition . This is similar to other
ous monitoring implements the “ loop ' control - flow con- 65 programming languages (e.g. C , C ++ , Java ) and not limited
structs making the combined agent and Blockchain system to information stored on the Blockchain . For example, it
Turing Complete . could monitor the date and time ( i.e. when a certain date and
US 11,120,437 B2
31 32
time are reached ) or monitor the weather ( i.e. when the metadata recorded with the transaction also gives the ability
temperature is below 10 ° C. and it is raining) , monitor the
to record an audit trail of how the code has been executed in
conditions of a contract or a trust (i.e. when company A buys
the past.
company B ) . There are several ways in which the agent could respawn
The ‘ Then action ' section of the ICTA code block can 5 the repeat loop code block at each iteration . The code block
execute a number of actions . The invention is not limited might be hard - coded into the agent itself, or could be stored
with regard to the number or type of actions that can be in a private or publicly available file, or stored as an entry
taken . The action is not limited to a transaction on the
Blockchain , although a transaction containing metadata on a private or public hash table file, or a combination of the
above . The code block could be static with hard - coded
related to the action may be written on the Blockchain . 10 variables or could be static but contain parameter ( s ) that can
The metadata can be of any form . However, in one be populated . The parameters could be single values of any
embodiment, the metadata may store a hyperlink to a file data format, or could be small chunks of code , or be
containing more data or instructions relating to the action . combinations of the above . The parameters could be popu
The metadata may store both a hyperlink to a hash table
containing more data or instructions relating to the action 15 lated by retrieving them directly from metadata in a trans
along with a hash of the action that acts as the loop -up key action ( e.g. bitcoin transaction ) or from an external source
such as an internal database or a private /public file or hash
for the hash table .
The agent's control stack can be implemented in a number table or any combination of the above . Pointers to the
of ways that are specific to the needs of each user. For external source of parameter values might be stored in
example, the repeat loop of the control stack can be based on 20 metadata in a transaction.
any Turing Complete language. One possible choice of The following steps provide one example of how the
language is the Forth style stack - based language. An advan- agent can respawn a repeat loop code block at the ith
tage of using this language is that it keeps the control stack iteration . In this example, the code registry is a hash table
consistent in programming style with the Bitcoin scripts whereby the hash values act as look -up keys for the table and
which are already known and in wide usage . 25 are stored in metadata on transactions.
Using the Bitcoin Script's Alternate Stack as a Data 1. The agent monitors the Blockchain for transactions that
Storage Space contain hashes of the code block that matches entries in
The Bitcoin script contains commands, also called op the code registry.
codes , which enable users to move data onto an alternative 2. The agent finds a transaction that contains the corre
stack , known as the “ alt stack ' . 30
sponding hash ( H1 ) .
The op codes are : 3. The agent reads the ‘Metadata - CodeHash ', gets the
OP_TOALTSTACK — which moves data from the top of CodeHash field to get H and uses it to retrieve the code
the main stack onto the top of the alt stack . ( C ). If RIPEMD - 160 (SHA256 ( C )) equals H1 , the
OP_FROMALTSTACK — which moves data from the top 35 code has not been changed and it is safe to proceed to
of the alt stack to the top of the main stack . the next step .
This enables data from intermediate steps of calculations
to be stored in the alt stack , similar to the ‘memory ' function 4. The agent reads the ‘Metadata - CodeHash ' which stores
which allows data to be stored on the calculator. In one the index I , and respawns the code at the ith iteration . In
embodiment, the alt stack is used for configuring bitcoin other words, the loop is ‘reloaded at the appropriate
scripts to solve small computation tasks and returning the 40 iteration
results in the computation . 5. The signature of the User is included in the P2SH
Using a Code Register to Manage the Agent command to verify the origin of the metadata .
The agent also manages a registry of all the codes that it 6. The agent reads the ‘Metadata - OutputHash’and ‘Meta
owns and runs . This registry is structured like a lookup table data -OutputPointer ' to retrieve the output of the previ
or dictionary that maps a specific key to a specific value . The 45 ous steps , if these data are required for this iteration of
key and value pair is represented by the hash of the code the loop .
block ( Hz ) and the IPv6 address of where the code is stored It should be noted that the above -mentioned embodiments
respectively. To retrieve the code block using the key H1 , the illustrate rather than limit the invention , and that those
lookup table is used to retrieve the associated value ( this is skilled in the art will be capable of designing many alter
the location where the code is stored ) and retrieves the 50 native embodiments without departing from the scope of the
source code accordingly. The implementation of the code invention as defined by the appended claims . In the claims ,
registry can vary. any reference signs placed in parentheses shall not be
Transaction Metadata of the Agent's Code , and Re- construed as limiting the claims . The word “ comprising ” and
Spawning of the Loop " comprises ” , and the like , does not exclude the presence of
Information required to respawn the agent's loop at a 55 elements or steps other than those listed in any claim or the
particular iteration is stored as metadata in the transaction specification as a whole. In the present specification, " com
recorded on the Blockchain . prises ” means “ includes or consists of ” and “ comprising ”
In this way, a transaction on the blockchain stores or means “ including or consisting of ” . The singular reference
provides access to information about a given iteration of the of an element does not exclude the plural reference of such
loop which is being executed on the agent. This information 60 elements and vice -versa . The invention may be implemented
can include the values of any variables associated with the by means of hardware comprising several distinct elements,
loop , such as index i , and any other necessary information and by means of a suitably programmed computer. In a
such as values for parameters used in the code block or device claim enumerating several means, several of these
location - related data specifying where further required means may be embodied by one and the same item of
information can be accessed . 65 hardware. The mere fact that certain measures are recited in
The metadata itself is stored as part of a multi - signature mutually different dependent claims does not indicate that a
pay - to - script -hash script ( P2SH ) in the transaction . The combination of these measures cannot be used to advantage.
US 11,120,437 B2
33 34
The invention claimed is : 7. A method according to claim 1 , wherein :
1. A computer - implemented method of controlling the i ) the contract is stored in a Distributed Hash Table
visibility and / or performance of a contract, the method (DHT) ; and / or
comprising: ii ) the method comprises:
(a ) storing a contract on or in a computer -based reposi- 5 broadcasting a transaction to the blockchain compris
tory ; ing an instruction to spend the output at a specified
( b )action
broadcasting a transaction to a blockchain, the trans
comprising: date and / or time , wherein the instruction is a Check
lockTimeVerify instruction.
i ) at least one unspent output (UTXO ); and
ii ) metadata comprising an identifier indicative of a 10 i8.) access
A method according to claim 1 wherein :
to some or all of the contents of the contract is
location where the contract is stored ; restricted to at least one designated authorised party ;
(c ) interpreting the contract as open or valid until the and / or
unspent output (UTXO ) is spent on the blockchain ; and ii ) the contract comprises a Deterministic Finite Automa
(d) renewing or rolling the contract on by : ton ( DFA ) to implement the contract;
generating a new key using data relating to a previous 15
key associated with the contract; wherein the Deterministic Finite Automaton is defined
generating a script comprising the new key, the location using a codification scheme.
of the contract and a hash of the contract; and 9. A method according to claim 8 wherein the Determin
paying an amount of currency to a transaction com istic Finite Automaton is implemented using :
prising the script . 20 i ) at least one blockchain transaction , using a scripting
2. A method according to claim 1 wherein the transaction language;
further comprises a deterministic redeem script address , ii ) a computing agent arranged to monitor the state of the
wherein the redeem script address is a pay -to -script- hash blockchain ; and / or
( P2SH ) address. iii ) a set of instructions for a digital wallet .
3. A method according to claim 2 and further comprising 25 10. A system , comprising:
the step of terminating the contract by broadcasting a further one or more processors ; and
transaction to the blockchain to spend the output (UTXO ). memory storing instructions that, as a result of execution
4. A method according to claim 3 wherein the further by the one or more processors, cause the system to :
transaction comprises: ( a ) store a contract on or in a computer -based repository ;
an input which is the output (UTXO ) ; and 30
(b ) broadcast a transaction to a blockchain , the transaction
an unlocking script comprising a signature; the metadata ; comprising:
and a public key.
5. A method according to claim 1 wherein the contract i ) at least one unspent output (UTXO ); and
defines: ii ) metadata comprising an identifier indicative of a
i ) at least one condition ; and 35 location where the contract is stored ;
ii ) at least one action whose performance is dependent ( c ) interpret the contract as open or valid until the unspent
upon the evaluation of the condition; and /or output (UTXO ) is spent on the blockchain ; and
wherein the metadata comprises: ( d) renew or rolling the contract on by :
i ) an address or representation of an address of where the generating a new key using data relating to a previous
contract is stored in the computer -based repository; 40 key associated with the contract;
and /or
ii ) a hash of the contract.
generating a script comprising the new key, the location
6. A method according to claim 1 and comprising: of the contract and a hash of the contract ; and
checking whether the contract has been terminated by paying an amount of currency to a transaction com
determining whether the UTXO is in a list of unspent 45 prising the script .
transaction outputs for the blockchain . * *