FIELD OF THE INVENTION

The invention relates to a computer-implemented method of validating transactions in a blockchain, which transactions comprise a blockchain element indicating a transfer from a seller to a buyer.

The invention further relates to a computer system for implementing the method, a peer-to-peer network, nodes therein and a computer program product. BACKGROUND OF THE INVENTION

Electronic commerce represents a significant part of the world's economy. From selling books to electronic services, almost any item can be bought or sold online. An important challenge in electronic commerce is fraud and other reasons why a

transaction may go bad. A seller might not deliver or a buyer might not pay for any number of reasons. Because the parties are not directly interacting with each other as in a classic 'brick and mortar' commercial transaction, this represents a problem that slows down electronic commerce.

Various approaches have been developed to tackle this problem. A classic solution for example is to involve a trusted third party, such as a notary public or an escrow agent. The third party receives the item from the seller and the payment from the buyer, and subsequently transfers both to their intended recipients. This approach is still fraught with problems, as are other business schemes. A more reliable technical solution is therefore desirable.

In 2008, Satoshi Nakamoto (pseudonym) published the paper "Bitcoin: A peer- to-peer electronic cash system." In the paper a cryptographic scheme for facilitating electronic money was proposed, which has proven to be a revolution in the field.

Bitcoin represents electronic cash, doing away with a trusted third party an instead employing digital signatures and a peer-to-peer solution for the validation of cash transfers. A network of peers timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, the so-called blockchain, forming a record that cannot be changed without redoing the proof-of-work. The blockchain chain thus serves as proof of the sequence of events witnessed.

Over the years, the blockchain technology has been deployed for a great variety of technical applications, including so-called 'smart contracts' and digital asset or transaction registration. Smart contracts are computer protocols that facilitate, verify, or enforce the negotiation or performance of a contract. In asset or transaction registration, information regarding an asset or transaction is recorded as an item in a blockchain. As the record in a blockchain cannot be changed (under normal circumstances), this thus serves as proof of the correctness of the registered information. Code supporting this is a latent part of the bitcoin protocol, based on probabilistic and anonymous (proof-of- work based) Byzantine replication.

As the present inventor has realized for the first time, one disadvantage of the above applications is that no effective validation of real- world payments can be executed. The Bitcoin scheme enables validated currency transfers in terms of virtual cash, but these must be bought and sold in separate arrangements. Smart contract schemes enable execution and confirmation of contractual arrangements but do not execute the payment itself. There is therefore a need in the art for a technical solution providing validation of real- world payments in a distributed and automated fashion.

SUMMARY OF THE INVENTION

To address the above, the invention provides for a computer-implemented method of, and corresponding system for, validating transactions in a blockchain, which transactions comprise a blockchain element indicating a transaction from a seller to a buyer, characterized in that the transaction is recorded as validated through introduction in the blockchain of a further element indicating a receipt by a third party from either the buyer or the seller, said third party being referenced in an initial element or root element of the transaction in the blockchain.

This new further element represents technical information to enable automated calculation of a validation status of the transaction. Transactions are recorded as a sequence of interrelated blockchain elements, said interrelation being effected through use of a common cryptographic hash or other unique identifier for the transaction.

Introducing the further element into the block chain effectively introduces a circle: the item refers to the initial or root element, in an embodiment contains an identifier of the root, and with a simple calculation this circle can be detected by any node in the peer-to-peer network effectuating the blockchain. This detection serves as proof that the transaction has been completed: the goods have been delivered correctly and payment can be made. The calculation serves to execute this validation in an automated manner. Normally, upon detection of the circle a payout is initiated. Preferably a check is made first if a payment has already been made for this transaction, to avoid double spending.

In an embodiment, the first block (blockchain element) indicates a transfer from a seller to a buyer and a second block (blockchain element) indicates a receipt by the buyer from the seller. This embodiment extends the transaction recordation by employing three items: a first item indicating the delivery of the good or service, a second item indicating receipt of payment and a third item, being the item indicating validation of the transaction through the reference to the root of the transaction.

In another embodiment the third party executes a money transfer operation upon calculating the absence of the further element and upon execution adds the further element. Here the transfer of real- world money is enabled thanks to a technical step: checking for presence or absence of the further element through blockchain validation calculations. If that element is not yet present, i.e. the circle has not yet been found, then the transaction is technically valid. The third party subsequently validates the payment and records the execution thereof. The further element is then added to complete and thereby invalidate the transaction. Due to the validation of the transaction it is now known that this transfer is appropriate (the goods have been delivered) and unique (the transaction will be validated only once). This step becomes possible in an automated technical fashion thanks to the validation of the invention.

The invention further advantageously provides for a peer-to-peer network comprising plural nodes, said nodes being configured for validating transactions in a blockchain, which transactions comprise a blockchain element indicating a transaction from a seller to a buyer, one of said nodes being additionally configured for introducing in the blockchain a further element indicating a receipt by a third party from either the buyer or the seller, said third party being referenced in an initial element of the transaction in the blockchain.

The invention further advantageously provides for a node for use with the peer- to-peer network of the invention, being configured for introducing in the blockchain a further element indicating a receipt by a third party from either the buyer or the seller, said third party being referenced in an initial element of the transaction in the blockchain. This node operates as a separate service, e.g. to facilitate the real-world payment, and adds the further element to indicate this has been done. The invention further advantageously provides for a node for use in the peer-to- peer network of the invention, being configured for causing execution of a money transfer operation upon calculating the absence of the further element.

The invention further advantageously provides for a computer-readable storage medium comprising executable code for causing a computer to operate as a peer-to-peer node of the invention.

BRIEF DESCRIPTION OF THE FIGURES

The invention will now be explained in more detail with reference to the figures, in which:

Fig. 1 schematically illustrates a peer-to-peer network 100 comprising nodes 101-a...101-n, said nodes being configured for validating transactions in a blockchain;

Fig. 2 schematically illustrates the blockchain aspect of the invention in more detail in the form of a flowchart; and

Fig. 3 A through 3F illustrate blockchain elements related to steps in the flowchart of Fig. 2.

In the figures, same reference numbers indicate same or similar features. In cases where plural identical features, objects or items are shown, reference numerals are provided only for a representative sample so as to not affect clarity of the figures.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Fig. 1 schematically illustrates a peer-to-peer network 100 comprising nodes 101-a...101-n, said nodes being configured for validating transactions in a blockchain. As such, blockchain networks are well-known in the art and this disclosure will therefore not discuss their implementation in detail. Reference is made to Mastering Bitcoin: Unlocking Digital Cryptocurrencies by Andreas M. Antonopoulos (O'Reilly 2015) for a good introductory text. Transactions in this context may refer to any type of transaction in which one item is exchanged for another, typically but not necessarily for money. Items can be physical or digital goods, or items that grant access to online or offline services.

A transaction from a seller to a buyer is recorded in the blockchain as one or more blockchain elements referencing such transaction. The element will include identificational elements of the parties, the transaction itself or both. Identification of either party may be done in any way, as long as the identification is sufficient for the purpose of the transaction. The transaction may be identified as a single identifier referencing an external record, as a complete summary of the transaction, or any other means of identification as deemed suitable for a particular implementation.

In practice, a hash code is generated to make the transaction element unique. A preferred embodiment therefore is to take the information needed for uniquely identifying the transaction, e.g. an identifier of the seller, an identifier of the buyer and/or a transaction number, and apply a cryptographic hash function such as the well- known SHA-256 algorithm. The outcome is then added to the blockchain as a new element. For purposes of the invention it is preferred that the hash code is calculated from at least a bank account number such as the IB AN of the buyer.

In a preferred embodiment recording the transaction comprises adding first an transaction element representing a step of transferring the item sold from seller to buyer, and second a transaction element representing a step of successfully receiving this item at the buyer. However, a single element representing the transaction as a whole is also possible.

Upon successful receipt of the item, a payment must be made. In accordance with the invention this payment will be effected in a real-world currency from the seller to the buyer. The amount may be recorded in the transaction element.

When the buyer is satisfied with the received item, and payment therefore can be executed, a further element is added to the blockchain. This further element indicates a receipt by a third party from either the buyer or the seller, said third party being referenced in an initial element of the transaction in the blockchain. In this disclosure this third party will also be referred to as an oracle. The third party will typically be a bank or other financial institution that will effectuate the real-world money transfer operation from the buyer to the seller upon calculating the presence of the further element.

The third party will effectuate the money transfer only for a valid transaction. To The further element creates a circle in the blockchain elements, as the third party is referenced in a root item of the blockchain. This circle can be uniquely identified with known blockchain algorithms. According to the invention, a payout in real- world money can be effected in connection with a transaction if the circle has not yet been detected, or if it has been detected but no payout under that transaction has been registered at the institution. Upon such payout the circle is completed, thus marking the transaction as complete and hence now invalid for future payouts. Fig. 2 schematically illustrates the blockchain aspect of the invention in more detail in the form of a flowchart. The flowchart assumes an external facility through which a buyer and seller may get in contact with each other to execute a transaction, such as a sale of a physical or digital good for a price expressed in real-world money (as opposed to cryptocurrencies such as Bitcoin). This facility is in principle independent of the invention. What matters is that both buyer and seller are able to initiate the creation of elements in the blockchain indicating certain steps in the transaction. They may create such elements themselves, or have a third party perform such creation.

In step 201, a buyer deposits real money with a bank or other financial institution. This institution serves as the above-referenced third-party. In connection with a transaction to which the deposit relates, the institution supplies to the buyer a unique identifier, such as a hashcode, for the transaction. This identifier will be used as a reference. As an example, identifier 7234yuh2346t will be used. Note that the identifier can be supplied in response to the deposit but could also be issued earlier, e.g. upon an indication of the buyer or the seller that a transaction is about to occur. In step 202, the institution stores information regarding the transaction, including the hash code, in an internal database. This allows for authoritative validation of the information.

In step 203, the institution adds an element to the blockchain, which element refers to the transaction and therefore includes identifier 7234yuh2346t. Preferably, the blockchain implementation is configured such that only the institution can add elements. Alternatively, the institution may digitally sign or otherwise certify elements in order to allow others to identify the elements as originating with the institution. In cryptocurrency terms, the money is put into the wallet of the institution, this is wallet 0.

An example of such an element is shown in Fig. 3A. This element or block contains hashes of previous and next elements and identifies the transaction with identifier 7234yuh2346t. In the example, additional information on the transaction is included in the form of a value of the payment by the buyer, 40 Euros.

In step 204, a new element is added that indicates a transfer of money to the buyer, this is wallet 1. Before this transaction is executed the blockchain software will check the previous transactions and validate the transaction if the money is really available with the institution. An example of the element providing for the transfer is shown in Fig. 3B. If the check is negative, the method instead proceeds to step 220.

In step 205, the transaction between the buyer and seller is recorded. Again, before this transaction is executed the blockchain software will check the previous transactions and validate the transaction if the money is really available with the institution. In cryptocurrency terms, the money has been transferred from wallet 1 to wallet 2, as shown in Fig. 3C.

In step 207, a transfer between seller and institution is illustrated. Here, the seller wants to receive the money in real currency, which can be provided by the institution as this money has been received in step 201. To execute this transfer, the seller transfers the digital money to wallet 0, associated with the institution. This is illustrated in Fig. 3D.

In step 208 a payment of the example amount of 40 Euros to the seller is executed. To complete this payment, an element is added that indicates a receipt by a third party, the institution, from either the buyer or the seller. This element said third party being referenced in a root item of the blockchain, i.e. the item in Fig. 3A. With this element, a loop is now present in the transaction elements. The transaction started in Fig. 3A originating from the root item, i.e. the institution, and in Fig. 3E that same transaction returns to the root item. This loop indicates the payment has been

completed. A later request on payout on this transaction, e.g. as per step 206, will not be accepted.

In step 220, the method deals with situations where after step 204, the buyer finds something is amiss with the transaction. For example, the goods never arrived, or they are faulty. In such a case, the buyer would want to cancel the transaction so as to prevent a payout to the seller. This means that step 205 in the above process must not occur, so that the element of Fig. 3C is not added. Instead, an alternate element is added in step 220, as per Fig. 3F. Here the money is transferred from wallet 1 (buyer) to wallet 0 (root). Next, the method executes payout as per step 208 but this time the money is paid back to the buyer.

CLOSING NOTES

The above provides a description of several useful embodiments that serve to illustrate and describe the invention. The description is not intended to be an exhaustive description of all possible ways in which the invention can be implemented or used. The skilled person will be able to think of many modifications and variations that still rely on the essential features of the invention as presented in the claims. In addition, well- known methods, procedures, components, and circuits have not been described in detail. Some or all aspects of the invention may be implemented in a computer program product, i.e. a collection of computer program instructions stored on a computer readable storage device for execution by a computer. The instructions of the present invention may be in any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs) or Java classes. The instructions can be provided as complete executable programs, as modifications to existing programs or extensions ("plugins") for existing programs. Moreover, parts of the processing of the present invention may be distributed over multiple computers or processors for better performance, reliability, and/or cost.

Storage devices suitable for storing computer program instructions include all forms of non- volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices, magnetic disks such as the internal and external hard disk drives and removable disks, magneto-optical disks and CD-ROM disks. The computer program product can be distributed on such a storage device, or may be offered for download through HTTP, FTP or similar mechanism using a server connected to a network such as the Internet. Transmission of the computer program product by e-mail is of course also possible.

When constructing or interpreting the claims, any mention of reference signs shall not be regarded as a limitation of the claimed feature to the referenced feature or embodiment. The use of the word "comprising" in the claims does not exclude the presence of other features than claimed in a system, product or method implementing the invention. Any reference to a claim feature in the singular shall not exclude the presence of a plurality of this feature. The word "means" in a claim can refer to a single means or to plural means for providing the indicated function.