WO2021005269A1

WO2021005269A1 - Blockchain-based transaction from offline wallet

Info

Publication number: WO2021005269A1
Application number: PCT/FI2020/050484
Authority: WO
Inventors: Ville RUNOLA
Original assignee: Northcrypto Oy
Priority date: 2019-07-11
Filing date: 2020-07-07
Publication date: 2021-01-14
Also published as: EP3997647A1

Abstract

A solution (protocol) how to pay, using an offline device, with cryptocurrency associated with an electronic wallet in the offline device, without revealing the private key, is disclosed. The offline device has no connection, at the moment, to a blockchain network managing the cryptocurrency. The solution is based on delivering a transaction created and signed by the electronic wallet in the offline device via an electronic wallet intermediary application in an online device to nodes in the blockchain network.

Description

BLOCKCHAIN-BASED TRANSACTION FROM OFFLINE WALLET

FIELD

The present invention relates to blockchain-based transactions, and es pecially for transactions from electronic wallets that have no connection to block- chain network.

BACKGROUND ART

The evolvement of communication technology, particularly wireless communication technology and end user apparatuses, has enabled versatile com munication possibilities and introduction of different services, including electronic transactions of different cryptocurrencies implemented through corresponding blockchains. Cryptocurrency funds are registered to addresses, and a distributed ledger stores, in chained blocks, transactions, and thereby keeps track on funds available in each registered address. A wallet, which is a software application usu ally in an end user’s device, stores one or more private key-public key pairs, each pair being associated with a specific address, and thereby with the funds registered to the specific address. The private key is used for signing transactions from the funds registered to the specific address. The specific address is based on the public key, or is the public key. The specific address is often called a wallet address. The wallet address is used for sending cryptocurrency from the funds and to funds in the wallet address. A simplified procedure, when a buyer wants to pay his purchase using his/her cryptocurrency funds, is following: the buyer’s wallet creates a trans action message containing at least the corresponding wallet address, seller’s wallet address, and an amount to be paid, and then the transaction is signed by the wallet by inputting the private key and the transaction message as inputs to a crypto graphic sign function. The signing verifies that the origin of the transaction is legit imate. Once the transaction is signed, the buyer’s wallet sends, usually using public communications network, such as Internet, the signed transaction to computers, called nodes, in a blockchain network for the cryptocurrency. The nodes know the buyer’s public key and use it verify the transaction and the authenticity of the sig nature. For example, the nodes may input the transaction message, the public key and the signature to one or more verify functions, which output true if the signature is authentic (and false if the signature is not authentic). If the signature is authentic, and the transaction fulfills other conditions of the cryptocurrency used, the trans action will eventually be stored to the ledger, the amount of cryptocurrency is sent from the funds in the buyer’s wallet address to funds in the receiver’s wallet address. Hence, anyone knowing the private key, can sign a transaction and trans fer funds registered to a wallet address corresponding to the private key. There fore, keeping the private key secret is of utmost importance. However, that creates a problem when the buyer’s wallet, or more precisely the device comprising the wallet, is offline, i.e. not having a connection to the blockchain network, the prob lem being how to pay with the cryptocurrency while keeping the private key secret.

BRIEF DESCRIPTION

The invention relates to a method, a program product, an apparatus and a system which are characterized by what is stated in the independent claims. The preferred embodiments are disclosed in the dependent claims.

A general aspect introduces a solution (protocol) how to pay, using an offline device, with the cryptocurrency without revealing the private key. The so lution is based on the idea that a transaction signed by a wallet in an offline device is delivered via a wallet intermediary application in an online device to nodes in the blockchain network.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, exemplary embodiments will be described in greater detail with reference to accompanying drawings, in which

Figure 1 shows simplified architecture of a system and block diagrams of some apparatuses;

Figure 2 illustrates an example of a content in a signed transaction;

Figures 3, 4 and 5 are flow chart illustrating exemplary functionalities;

Figure 6 illustrate an example of information exchange; and

Figures 7 and 8 are block diagrams of exemplary devices.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, words "comprising" and "including" should be understood as not limiting the de scribed embodiments to consist of only those features that have been mentioned and such embodiments may contain also features/structures that have not been specifically mentioned. The present invention is applicable to any device configurable to imple ment a blockchain-based electronic wallet for a cryptocurrency and/or an elec tronic wallet intermediary application, and which is capable to communicate over a short-range connection directly with another device.

An extremely general architecture of an exemplary system 100 is illus trated in Figure 1. Figure 1 is a simplified system architecture only showing some elements, functional entities, which are logical units whose implementation may differ from what is shown, and some equipment. It is apparent to a person skilled in the art that the system comprises any number of shown elements, other equip ment, and structures that are not illustrated.

The system 100 illustrated in Figure 1 comprises end users’ devices, de picted in Figure 1 by two devices 110, 120, having a direct short-range connection 101, a public network 102, such as Internet, and a blockchain network 103 com prising a plurality of computing devices called nodes 130 (only one node illustrated in Figure 1).

The device 110, 120 refers to computing devices (equipment, appa ratus), that may be a portable device or a non-portable device, and it may also be referred to as a user terminal or an edge device or an end user’s device. A non limiting list of computing devices (apparatuses) include wireless mobile communi cation devices operating with or without a subscriber identification module (SIM) in hardware or in software, including, but not limited to, the following types of de vices: mobile phone, smart-phone, laptop and/or touch screen computer, tablet (tablet computer), desktop computer, point-of-sale terminal, smart screen (smart display), multimedia device, and wearable devices, including augmented reality de vices and virtual reality devices. It should be appreciated that the depicted two de vices may be devices of the same type, or of different types.

In the illustrated example of Figure 1, one of the devices depicts and of fline device 110, i.e. a device currently not having a connection to the blockchain network 103, and the other one depicts an online device 120 having a connection to the blockchain network 103. However, as described below, it should be appreci ated that the device, which is called herein as the offline device 110, may also some times have a connection to the blockchain network, the terms "offline device" and "online device" are used herein only for a sake of clarity, instead of using terms "first device" and "second device", the terms better depicting their status (mode) at the time the functionality described herein may take place. The offline device 110 and the online device 120 may exchange infor mation over a short-range connection 101, which is a direct connection between the devices 110, 120 to transmit information. The short-range connection 101 may be based on any short-range wireless or wired communication technology, that may or may not require connection establishment steps. A non-limiting list of ex amples for short-range wireless communication technologies include Bluetooth communication standards, and other wireless local area network technologies, such as radio frequency technologies including Wi-Fi, ZigBee, USB Bluetooth, near field communication (NFC), radio-frequency identification (RFID), and optical wireless technologies including Li-Fi and other technologies using at least one of visible light spectrum, ultraviolet and infrared radiation. For example, an optical reader, such as a camera, configured to read a barcode, i.e. a machine-readable op tical label that contains information, such as a QR code, (quick response code) is considered to have a short-range connection, when the reader reads the barcode.

The offline device 110 comprises an electronic wallet 111. The elec tronic wallet may be called a blockchain wallet, a cryptocurrency wallet, or shortly a wallet. The electronic wallet is a blockchain application via which the device 110 may be in communication with the blockchain network 103, when online. Elec tronic wallet 111 may be any suitable distributed-ledger based wallet which stores one or more key pairs 112of a private key (privl) and a public key (publ). For example, the wallet may be a standalone wallet, or a shared wallet, or a hardware wallet. For the latter two cases, the different pieces forming the wallet are to be treated as one entity, the offline meaning that a piece usually sending signed trans actions to the blockchain network, is in an offline mode. The way how the private key, and a corresponding public key are retrieved/generated are known by a per son skilled in the art, and therefore there is no need to explain them in more detail herein. Further, the disclosed solutions do not affect to the key pairs, and their gen eration, and any known or future cryptographic technique may be used for the key pairs. The same applies to wallet addresses generated by the electronic wallet based on the public key, if the public key itself is not used as a wallet address. It should be appreciated that the device 110 may comprise more than one wallet 111, and the wallets may be for different cryptocurrencies, for example a Bitcoin wallet and one or more altcoin wallets for different altcoins, such as Litecoin and Ethereum. Further, it should be appreciated that the described solutions are not tied to any specific cryptocurrency. As explained in the beginning, the private key is used for signing transactions from the funds registered to a specific address. The specific address is based on the public key, or is the public key. The specific address is often called a wallet address. The wallet address is used for sending cryptocur rency from the funds and to funds in the wallet address.

The offline device 110 is configured to send a signed transaction, when it has no connection to the blockchain network 103, over a short-range connection to the online device 120. For that purpose the offline device comprises an offline sender unit (o-s-u) 113. The offline sender unit 113 may be part of the electronic wallet 111 (electronic wallet application), or an add-in or a plug-in to the electronic wallet 111. Naturally, two or more electronic wallets in a device 110 may share the same offline sender unit. Examples of functionalities of the offline sender unit are described below with Figure 3.

The online device 120 is configured to receive the signed transaction from the offline device 110 over the short-range connection 101. For that purpose the online device comprises an electronic wallet intermediary application 121. The electronic wallet intermediary application 121 is a blockchain application via which the device 120 may be in communication with the blockchain network 103. In the illustrated example, the electronic wallet intermediary application 121 com prises an offline receiver unit (o-r-u) 124 for performing the processing and stores, in the illustrated example, one or more wallet addresses (pub2-a) 121 or public keys to generate wallet addresses if the public key itself is not used as a wallet ad dress. Examples of other information that may be stored include one or more con ditions a transaction contents has to fulfill and a preset limit for received confirma tions. However, the electronic intermediary application 121 may be implemented without storing any information. The electronic wallet intermediary application 121 may be a standalone application for processing transactions received from any suitable distributed-ledger based wallet in another device. If the online device 120 comprises an electronic wallet, the offline receiver unit 124 may as well be part of the electronic wallet (electronic wallet application), or an add-in or a plug-in to the electronic wallet.

An electronic wallet (electronic wallet) in a device may comprise, even though not illustrated in Figure 1, both the offline receiver unit and the offline sender unit, either as separate unit or as a combined offline unit. Naturally, two or more electronic wallets in a device 110, 120 may share the same offline receiver unit and/or the same offline sender unit. If the online device 120 comprises a block- chain node (blockchain node application), the offline receiver unit 124 may be an add-in or a plug-in to the blockchain node, or configured to communicate with the blockchain node over an internal interface, which corresponds to external interface for wallets. Examples of functionalities of the offline receiver unit (the electronic wallet intermediary application) are described below with Figures 4 and 5.

The online device 120 may be a blockchain node, or, as in the example illustrated in Figure 1, connected over one or more public networks 102, for exam ple over a mobile communications network via Internet, to the blockchain network 103, as is known by one skilled in the art, and therefore there is no need to describe it in more detail herein.

The blockchain network 103 may comprise various blockchain nodes 130 configured to validate transactions, broadcast transactions to other nodes, and maintain the blockchain forming a distributed ledger, for example, as is known by one skilled in the art. The blockchain network 103 may be a peer-to-peer network that is private, consortium and/or public, and it may be implemented using any known or future blockchain technology. The nodes 130 may be consensus partici pants, which may validate a transaction (transaction data), and any other activity on the blockchain, by establishing consensus between the participants using any suitable consensus algorithms, and by adding a new ledger for the transaction to the blockchain. However, no changes are required to the blockchain and how a transaction is processed in the blockchain network 103, including the blockchain nodes 130, and therefore there is no need to describe the blockchain network in more detail herein.

Figure 2 illustrates an example of a content in a signed transaction. More precisely it illustrates some pieces of information a transaction 200 may com prise, as is known by one skilled in the art. It should be appreciated that any known or future transaction contents structure may be used, Figure 2 is just one example, and the described solutions require no changes to what the transaction comprises.

Referring to Figure 2, the transaction 200 comprises transaction con tents 210, also called a transaction message, and a signature 220. The transaction contents 210 comprises at least one or more inputs 211 and one or more outputs 212. An input 211 comprises at least a wallet address of the payer, i.e. an originat ing address wherein the funds are before the transaction. Usually the input 211 also comprises the amount of funds before the transaction. An output 212 com prises at least a wallet address of a payee and the amount of funds to be sent to the payee. In other words, the output 212 comprises a target address whereto the amount of funds are transferred in the transaction. Some cryptocurrencies also re quire that the remaining amount of funds (or remaining amount after fees to be paid in the blockchain network for carrying out the transaction are taken into ac count) are also listed as an output. An example of a payer is a buyer and an example of a payee is a seller.

The transaction contents 210 may comprise also other data, such as other blockchain tokens, additional information required for the transaction, and/or a hash calculated from other pieces of the contents (i.e. contents 210 with out the hash). Further, there may be any number of originating addresses and any number of target addresses for each originating address in one transaction. It should be appreciated that the transaction may be performed for other purposes than sending funds. In such a case the transaction contents 210 does not contain, as a transaction token (a blockchain token), the amount of funds but information required for the purpose, for example information for a smart contract.

The signed transaction also contains a signature 220. As described in the background portion, the signature may be generated by the electric wallet by inputting the private key corresponding to the originating address and the trans action contents as inputs to a cryptographic sign function, or by encrypting the hash calculated from other pieces of the contents by the private key. In other words, any known or future digital signature generation may be used to create the signature 220 to verify that the origin of the transaction is legitimate.

Below different examples are described assuming that a connection (a direct connection and a connection to blockchain network) exists, without describ ing any details. The details of the communication technology, including protocols used and authentication steps, if authentication is implemented, to establish a con nection, if establishment is required, are well known by persons skilled in the art, are irrelevant to the described examples, and no modifications are needed to them. Therefore, they need not to be discussed in more detail here. Further, for the sake of clarity, in the examples it is assumed that the transaction is from one originating address to one target address with one amount. It is a straight forward solution for one skilled in the art to implement the disclosed solution to transactions to and/or from several target addresses, and/or to different purposes than sending funds, based on the teachings below.

Figure 3 illustrates an example of a functionality of an offline device, i.e. a payer’s electronic wallet in an offline mode, and more precisely an example of a functionality of the offline sender unit the device comprises.

Referring to Figure 3, it is detected in step 301 that an offline transac tion is to take place. The detection may be based on the wallet receiving a user input "transaction" and the wallet detecting that there is no connection to the blockchain network. The reason may be that the device is in a mode in which packet data con nections are blocked, or for some other reason a connection establishment to the blockchain network fails. There may be also implementations that even though the connection to the blockchain network exists, the electric wallet offers offline trans action as an alternative, in which case the detection in step 301 may be based on receiving a user input "offline transaction".

Then information required to create a transaction, i.e. at least a target address and amount of funds (payment), is received in step 302. The information may be received by a user inputting the information to the offline device, or over the direct connection to an online device from the online device. For example, if the online device is a seller’s device, it may display the information on its screen and the offline device may read the information using an optical reader. It is also possi ble that the information is pre-stored to the offline device. For example, the user may have in advance made an Internet order, and received an electronic bill, or payment information, and have stored them to be able to pay later. Then a transac tion contents is created in step 303 using the received information and the princi ples described above. In the illustrated example the user of the offline device is then prompted in step 304 to accept the transaction, for example by displaying the transaction contents. In the illustrated example it is assumed that the user ac ceptance is received (step 304), and the transactions contents is signed in step 305, using the private key associated with the originating address, as explained above.

Basically the process described with step 302 to 305 is the same as would be a corresponding online process. However, since the process is for offline transactions, the signed transaction is sent in step 306, instead of sending it to the blockchain network, to the online device over the direct connection, i.e. over the short-range connection. For example, if the online device is the seller’s device, the signed transaction is sent in step 306 directly to the receiving wallet (at least in principle, when the online device comprises the wallet intermediary application but no wallet application).

Figures 4 and 5 illustrate examples of functionalities of an online device, and more precisely examples of functionalities of the offline receiver unit the online device comprises as the electronic wallet intermediary application, or as part of said application. In the illustrated examples it is assumed that the offline receiver unit knows the public key, or public keys required. Different ways to obtain the knowledge are known to a person skilled in the art, and therefore there is no need to disclose the ways in more detail.

Referring to Figure 4, as a preparatory functionality, for example when a user of an offline device enters a store (or any other point of sale) and says to a sale person using the online device that he/she wants to buy a specific item and wants to pay using a cryptocurrency but his/her device is currently an offline de vice. Therefore, in the illustrated example, the online device receives one or more user inputs to create a bill in step 401, and when the bill is created, at least the amount to be paid and the target address are displayed in step 402 on the screen of the online device so that the user of the offline device can input, or read it. Natu rally the information may be transferred over the direct connection without being displayed. Further, it may be that no steps 401 and 402 are performed. For exam ple, the user of the offline device may have obtained the information via another route, or the online device may be a point of sale terminal, or corresponding termi nal configured to retrieve information needed to create the bill, and to create the bill without any user inputs. (In such a case the information may be displayed to the user of the online device for information, or for confirmation). The information may contain one or more conditions set to the transaction contents to ensure that the wallet in the offline device creates a valid transaction.

When a signed transaction from an originating wallet in the offline de vice is received in step 403, in the illustrated example the offline receiver unit first verifies in step 404 the signature in the transaction to verify that the origin of the transaction is legitimate. For example, the public key and the signature may be in putted to a decrypt function (or any verify function), and if the output of the decrypt function is the same as the transaction contents, or its hash, the signature is veri fied.

If the signature is verified (step 405: yes), i.e. is an authentic signature, in the illustrated example, the transaction contents is verified in step 406. Depend ing on cryptocurrency used there may be different conditions a transaction con tents has to fulfill. For example, the amount of funds associated with the originating address has to be equal to the amounts of funds associated with the target ad dresses, one of which is the same as the originating address, when the fees to be paid to the blockchain network are taken into account. In another example, the amount of funds associated with the originating address has to be bigger than or equal to the amounts of funds associated with one or more target addresses, when the fees to be paid to the blockchain network are taken into account. Since the transaction is first received, before being sent to a node in the blockchain network, in the electronic wallet intermediary application, wallet-specific conditions may also be set. An example of such a condition is that the target addresses, excluding the originating address, are addresses stored to the electronic wallet intermediary application.

In the illustrated example, if the transaction contents fulfil the one or more conditions set for the contents, i.e. is verified (step 407: yes), the user of the online device is prompted in step 408 for acceptance of the transaction by display ing the transaction contents to the user. A further advantage of the feature is that the user (seller) may set further conditions for the transaction. Examples of such further conditions include a certain minimum fee to be included in the transaction, part of the funds to be sent to another target address, and that "Replace-By-Fee" flag is not set. In other words, any extra requirement set by the seller can be easily checked before the transaction undergoes the commitment procedure in the block- chain network, since the seller (user of the online device) sees the transactions con tents and can easily check it. (It should be appreciated that the transactions con tents can also be played to the user, and the displaying covers herein also playing.)

If a user approval is received (step 409), forwarding the signed transac tion to a node in the blockchain network is caused in step 410. A valid signed trans action will be broadcast to other nodes and committed to a blockchain. The node, and the whole blockchain network, processes the transaction as if it had been re ceived from the device which created the transaction. At the end, a valid transac tion will be stored to the ledger, the amount of cryptocurrency is sent from the funds in the buyer’s wallet address (originating address) to funds in the receiver’s wallet address (target address).

If the signature is not verified (step 405: no), the user is informed in step 411 that the signature is not an authentic one, for example by displaying a corre sponding text, or any text, like "not approved", and the received signed transaction is dropped. In other words, it will not be processed any further.

If the transaction contents is not verified (step 407: no), the user is in formed in step 412 correspondingly. The informing may include displaying the transaction contents, possibly showing differently those pieces that do not fulfill the conditions, and/or otherwise indicating one or more reasons why the contents is not verified, so that the user may help the user of the offline device to create a new, error-free transaction contents. However, the user may be informed without revealing the reason, for example by just display "not approved". In any case, the received signed transaction is dropped. If the user does not approve the transaction contents (step 409: no), the user’s disapproval is confirmed in step 413, for example by displaying a text "trans action cancelled", and the received signed transaction is dropped.

In the illustrated example, since the online device performs the verifi cation steps and the user is shown the content, the user may treat the transaction as a valid one immediately, without need to wait for confirmations in the block- chain network. Further, thanks to the online device performing the verification steps, non-valid transactions are filtered, or at least most of them, before they are forwarded to the blockchain network, so network resources are not used in vain.

In another example, before the user is prompted for acceptance in step 408, it is checked, whether the target address is one of the wallet addresses in the wallet intermediary application. If it is, the user is prompted, otherwise the process proceeds directly to step 410. In other words, the use is not prompted to check payments to other recipients.

In the example illustrated in Figure 5, the offline receiving unit is not configured to perform any verification steps, and the transaction process basically appears to the user of the online device as a conventional transaction process be tween online devices.

Referring to Figure 5, when a signed transaction from an originating wallet in an offline device is received in step 501, forwarding the signed transaction to a node in the blockchain network is caused in step 502, the step being similar to step 410. Then the number of received confirmations is monitored. As is known, consensus participants (nodes) in the blockchain network may notify an electric wallet of a successful write of the transaction to the blockchain by transmitting a confirmation, or the electric wallet may locate the transaction data written on blockchain. Both ways are described herein as receiving a confirmation.

Returning back to Figure 5, when a confirmation is received (located) in step 503, the number n of the received confirmation (set to zero at the latest when monitoring is started) is increased by one in step 504, and then it is checked in step 505 whether the number n is smaller than a preset limit. The preset limit may be any number. Further, instead of a preset limit the user may be prompted to provide the number for the limit, and the prompting may include displaying the preset limit stored as a default number.

If the number n is smaller than the preset limit (step 505: yes), the mon itoring continues (step 503). If the number is not smaller (step 505: no), the user of the online device is informed in step 506 that the funds have been transferred, i.e. the payment has been made, and the process is ended.

Naturally, if the transaction will not be verified, and the transaction will not be written to the blockchain, the user is may be informed on a non-valid trans action.

In other implementations, instead of, or in addition to, steps 505 and 506, after the number of received confirmation is increased in step 504, the num ber is displayed to the user, and the process may be ended in response to a user inputting a corresponding user input.

In further examples, between steps 501 and 502, the user may be prompted to accept the transactions contents (steps 408, 409) and/or verify the transaction contents (steps 406, 407) and/or verify the signature (steps 404, 405). Naturally, if no acceptance is received, or a verification is not passed, the signed transaction will be dropped. Further examples include performing only steps 501 and 502, i.e. receiving a signed transaction from another device and forwarding it to the node, or before forwarding verifying the signature (steps 404, 405) and/or verify the transaction contents (steps 406, 407).

Figure 6 illustrates an example of information exchange. It should be appreciated that the information exchange is a simplified example, only describing information content, not actual exchange of messages and protocols used for con veying the information content are not disclosed. As discussed above, any known or future protocol with corresponding messages may be used.

Referring to Figure 6, it starts when a payer, for example Alice, wants to pay her purchases to a payee, for example her nearest grocery shop. Therefore the wallet in the payer device receives user input 6-1, which indicates the intention to pay. In the illustrated example, it is assumed that Alice has pre-stored the target address in her device having the wallet, and the user input 6-1 includes the sum to be paid. However, it should be appreciated that the information may be retrieved from the payee’s device, for example from the wallet in the payee’s device, and the input may indicate the payee.

Since the wallet in the payer device has the information it needs, it cre ates, in step 6-2, and signs, in step 6-2, a transaction, as described above with steps 303 to 305 of Figure 3. Then, in step 6-3, the wallet detects that its mode is online, and therefore causes sending in message 6-4 the signed transaction to the block- chain network for commitment. In other words, nodes in the blockchain broadcast the signed transaction, verify the transaction and authenticity of the signature, and eventually the transaction is stored to a ledger, and the amount is sent from the funds in the payer’s wallet address to funds in the target address (message 6-5), and payee is informed in point 6-6 that the payment has been carried out success fully. Using the example of Alice and the grocery store, the point of sale in the gro cery store is informed on successful payment and Alice can go home with her pur chases.

Next time when Alice visits the grocery store, the wallet in the payer device receives user input 6-1’, which indicates the intention to pay. The user input 6-1’ differs in the example from the user input 6-1 only in the amount to be paid. Naturally, if the user input indicates the payee, the user input 6-1’ may contain an other payee, or the same payee, than the user input 6-1. The same payee may have the same target address (receiving address) or a different target address than the one used in the previous payment. A target address may be different than the target address in the previous payment even though the target address is for the same payee and created by the payee using the same private key, since in those imple mentations different derivations paths may be used in the address creation pro cess.

Since the wallet in the payer device has the information it needs, it cre ates, in step 6-2’, and signs, in step 6-2’, a transaction, as described above with steps 303 to 305 of Figure 3. Then, in step 6-7, the wallet detects that its mode is offline, for example because Alice has turned on offline mode, or Alice’s device is a prepaid device with no balance left. Because of the offline mode, the signed transaction is sent in message 6-8 to an intermediate wallet application (1WA) in the payee’s de vice. (Establishment of a short range connection over which message 6-8 is sent is not illustrated in Figure 6).

Depending on the implementation, the intermediate wallet application may perform in step 6-9 verifying the signature, as described above with step 404 in Figure 4, and/or may perform in step 6-9 verifying transaction contents in the transaction, as described above with step 406 in Figure 4, and/or display in step 6- 19 the transaction contents to a user, for example, for acceptance, as described above with step 408 in Figure 4. Further, the intermediate wallet application causes sending in message 6-10 the signed transaction to the blockchain network for commitment. The commitment is performed in the same way as described above. In other words, the blockchain network processes the transaction as if it had been received directly from the payer’s wallet. Eventually also this transaction is stored to the ledger, and the amount is sent from the funds in the payer’s wallet address to funds in the target address (message 6-5’), and payee is informed in point 6-6’ that the payment has been carried out successfully. Using the example of Alice and the grocery store, the point of sale in the grocery store is informed on successful payment and Alice can go home with her purchases even though her de vice was offline. If the intermediate application is configured to display in step 6-9 the transaction, the user may consider at that stage that there is a successful pay ment, and Alice can go home with her purchases even before the transaction has been stored to the ledger.

As is evident from the above, a secure protocol to facilitate transactions originating from offline devices without revealing the private keys and appearing to the blockchain network, especially to the ledger, as an offline device had been an online device, has been described. Further, if the electronic wallet intermediary ap plication in the online device forwarding the signed transaction, changes the amount, for example, the signature will not be verified, especially if the hash is used.

The secure protocol may be used for on-chain transactions and for off- chain transactions.

The steps, related functions, and information exchanges described above by means of Figures 3 to 6 are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one. For example, in a process based on Figure 3, the user may be prompted to accept the transaction (step 304), based on the received information, before the transaction content is created (step 303) and/or detection that the transaction is an offline transaction (step 301) may take place later (after step 302, or step 303, or step 304, or step 305) as long as it happens before the signed transaction is sent (step 306). Other functions can also be executed between them or within them, and other information may be sent. For example, in a process based on Figure 3, after the transaction has been signed (step 305), the user may be prompted to confirm the transaction, before it is send (step 306). Some of the steps or part of the steps or one or more pieces of information can also be left out or replaced by a corre sponding step, or part of the step, or one or more pieces of information. For exam ple, in a process based on Figure 4, if there are one or more conditions set to the transaction contents, and they are fulfilled (step 407: yes), the process may for ward the signed transaction (step 410) without prompting user for acceptance, i.e. steps 408, 409 and 413 may be left out.

The techniques and methods described herein may be implemented by various means so that an online device and/or an offline device configured to implement at least partly on what is disclosed above with any of Figures 1 to 5, including implementing one or more functions/operations described above with an example, for example by means of any of Figures 3 to 6, comprises not only prior art means, but also means for implementing the one or more functions/operations of a corresponding functionality described with an example, for example by means of any of Figures 3 to 6, and it may comprise separate means for each separate function/operation, or means may be configured to perform two or more func tions/operations. For example, one or more of the means and/or the offline sender unit, and/or the offline receiver unit, and/or the combined offline unit, described above may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the examples may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), radio-frequency circuits (RFICs), graphic pro cessing units (GPUs), processors, controllers, micro-controllers, microprocessors, logic gates, other electronic units designed to perform the functions described herein by means of Figures 3 to 6, or a combination thereof. For firmware or soft ware, the implementation can be carried out through modules of at least one chip- set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by pro cessors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, the memory unit can be communicatively cou pled to the processor via various means, as is known in the art. Additionally, the components of the offline device and/or the online device described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Figure 7 illustrates an apparatus 700 configured to carry out the func tions described above in connection with the online device and/or the offline send ing unit. Each apparatus 700 may comprise one or more processing circuitry, such as at least one processor 702, and at least one memory 703, including one or more algorithms 704, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to carry out any one of the exemplified functionalities of the online device, or the offline sending unit. The ap paratus 700 further comprises different interfaces 801, 801’, such as one or more interfaces 701 for communication, for example for short-range communication, possibly also for communication with one or more nodes in the blockchain net works and one or more user interfaces 701’ to user interaction. The one or more user interfaces 701’ may be any kind of a user interface, for example a screen, or other display, microphone and one or more loudspeakers for interaction with the user.

Figure 8 illustrates an apparatus 800 configured to carry out the func tions described above in connection with the online device and/or the offline re ceiver unit. Each apparatus 800 may comprise one or more processing circuitry, such as at least one processor 802, and at least one memory 803, including one or more algorithms 804, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus to carry out any one of the exem plified functionalities of the online device, or the offline receiver unit. The appa ratus 800 may further comprise different interfaces 801, 801’ such as two or more interfaces for communication, for example for short-range communication and for communication with one or more nodes in the blockchain networks, and one or more user interfaces 801’ to user interaction.

Referring to Figures 7 and 8, at least one of the processing circuitries in the apparatus 700, 800 is configured to provide the corresponding device function ality or the offline sender unit, and/or the offline receiver unit, and/or the com bined offline unit, or any corresponding unit/sub-unit, and to carry out functional ities, described above by means of any of Figures 3 to 6, by one or more circuitries.

The memory 704, 804 or part of it may be implemented using any suit able data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and sys tems, fixed memory and removable memory.

The one or more interfaces 701, 801 may comprise communication in terfaces comprising hardware and/or software for realizing communication con nectivity according to one or more communication protocols.

As used in this application, the term 'circuitry' refers to all of the follow ing: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and software (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a micropro cessor^), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of 'circuitry' applies to all uses of this term in this application.

In an embodiment, the at least one processor, the memory, and the com puter program code form processing means or comprises one or more computer program code portions for carrying out one or more operations of a device (unit) according to any one of the examples of Figures 3 to 6, or operations thereof.

Embodiments and/or examples as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments and/or examples of the methods described in connection with Fig ures 3 to 6 may be carried out by executing at least one portion of a computer pro gram comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carry ing the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The com puter program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunica tions signal, and software distribution package, for example. The computer pro gram medium may be a non-transitory medium. Coding of software for carrying out the examples as shown and described is well within the scope of a person of ordinary skill in the art.

Even though the invention has been described above with reference to examples according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment/exam ple. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a per son skilled in the art that the described examples may, but are not required to, be combined with other examples in various ways.

Claims

1. A computer implement method for blockchain-based transactions in a blockchain network, the method comprising:

storing, in an electronic wallet in a first device, at least a key pair com prising a public key and a private key;

creating, by the electronic wallet, transaction contents to send a trans action token in a first registered address in a blockchain network to a target ad dress in the blockchain network, wherein the first registered address is based on the public key;

signing, by the electronic wallet, the transaction contents by using the private key in the key pair;

detecting an offline mode for the electronic wallet; and

causing sending, by the electronic wallet, in response to the offline mode, the signed transaction to an electronic wallet intermediary application in a second device over a short-range connection.

2. A computer implemented method according to claim 1, further com prising:

detecting the offline mode in response to one of:

detecting that the first device cannot establish a connection to the blockchain network to confirm the transaction; and

a received user input indicating the offline mode.

3. A computer implemented method according to claim 1 or 2, wherein the transaction token is an amount of funds.

4. A computer implemented method according to claim 3, further com prising:

receiving, for the transaction contents, before creating the transaction contents, the target address and the amount from the second device over the short- range connection.

5. A computer implemented method for blockchain-based transactions in a blockchain network, the method comprising:

receiving, over a short-range connection, from an electronic wallet in a first device, in an electronic wallet intermediary application in a second device, a signed transaction created and signed by the electronic wallet, to send a transac tion token in a first registered address in a blockchain network to a target address in the blockchain network, wherein the transaction is signed by the electronic wal let in the first device and the first registered address is associated with the elec tronic wallet;

causing, by the electronic wallet intermediary application in the second device, forwarding the signed transaction to a node in the blockchain network to be broadcast to other nodes in the blockchain network and to be committed to a blockchain.

6. A method according to claim 5, further comprising:

displaying transaction contents in the signed transaction to a user of the second device for acceptance; and

causing the forwarding in response to receiving a user input accepting the transaction contents.

7. A method according to claim 5 or 6, further comprising: verifying, by the electronic wallet intermediary application, by using a public key associated with the first registered address, that the transaction is signed in the first electronic wallet by a private key corresponding to the public key; and

causing the forwarding only in response to a successful verification.

8. A method according to claim 5, 6 or 7, further comprising: verifying, by the electronic wallet intermediary application, that trans action contents in the signed transaction fulfils one or more conditions set to trans action contents; and

causing the forwarding only in response to a successful verification.

9. A method according to claim 5, 6, 7 or 8, further comprising:

monitoring, by the electronic wallet intermediary application, after causing the forwarding, the number of received confirmations of the transaction from the blockchain network; and

indicating, in response to the number exceeding a limit, to the user of the second device that the transaction has been confirmed.

10. A computer program product comprising program instructions which, when the program is executed by a computing device, cause the computing device to carry out the method of any of preceding claims.

11. A non-transitory computer-readable storage medium storing one or more instructions which, when executed by one or more processors, cause the one or more processors to carry out at least one of the methods of any of preceding claims.

12. A device comprising means for implementing a method according to any of claims 1 to 9.

13. A device comprising:

at least one interface for short-range connections to other devices; at least one interface for connecting to a blockchain network; at least one processor; and

at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the apparatus at least to perform:

providing an electronic wallet application; and

providing an intermediary wallet application,

wherein providing the intermediary wallet application comprises for warding, in response to receiving over the at least one interface for short-range connections to other devices, from an electronic wallet in another device, a signed transaction comprising a transaction token in a first registered address in the blockchain network to a first target address in the blockchain network, the re ceived signed transaction over the at least one interface for connecting to the block- chain network to a node in the blockchain network to be broadcast to other nodes in the blockchain network and to be committed to a blockchain,

wherein providing the electronic wallet application comprises storing at least a key pair comprising a public key and a private key, creating, in response to user input, transaction contents to send a transaction token in a second regis tered address in the blockchain network to a second target address in the block- chain network, wherein the second registered address is based on the public key; signing the transaction contents by using the private key in the key pair; and caus ing sending the signed transaction over the at least one interface for connecting to the blockchain network to the node in the blockchain network to be broadcast to the other nodes in the blockchain network and to be committed to the blockchain.

14. A device as claimed in claim 13, wherein the at least one memory and computer program code are configured to, with the at least one processor, cause the apparatus further to perform, when providing the intermediary wallet application:

causing sending, prior to receiving the signed transaction, over the at least one interface for short-range connections to other devices, to said another device at least the second registered address to be used as the first target address.

15. A device as claimed in claim 13 or 14, wherein the at least one memory and computer program code are configured to, with the at least one pro cessor, cause the apparatus further to perform, when providing the intermediary wallet application:

displaying, before forwarding, transaction contents in the received signed transaction to a user of the device for acceptance; and

16. A system comprising at least

a first device comprising an electronic wallet configured at least to im plement a method according to any of claims 1 to 4;

a second device according to claim 13, 14 or 15 or configured at least to implement a method according to any of claims 5 to 9; and

a blockchain network for committing signed transactions to a block- chain.