Computer-implemented systems and methods for determining or verifying a location

Abstract

A computer-implemented method is provided, the computer-implemented method comprising the steps of: broadcasting a request for location data; receiving location data from a plurality of nodes, the location data comprising a distance and a public key corresponding to an area near the node; selecting a common public key common to a set of the plurality of nodes; and requesting the set of nodes to participate in threshold secret sharing to obtain a cryptographic signature associated with the common public key. The method utilizes a blockchain for communication and verification of data, and includes using the cryptographic signature obtained to transfer control of a transaction.

Description

Technical Field

[0001] The present disclosure generally relates to methods for determining or verifying (authenticating) the location of a user, device, object, or entity, and more specifically to determining / authenticating the location using threshold secret sharing. The present disclosure is particularly suitable for, but not limited to, use with blockchain. Background Art

[0002] As used herein, the term "blockchain" covers all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations. The term "user" in this context may refer to a person or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation. Transactions include small programs embedded in their inputs and outputs, called scripts, which specify how and by whom the outputs of the transaction can be accessed. These scripts are written using a stack-based scripting language.

[0004] Digital entrepreneurs have begun to explore how to implement new systems using cryptographically secure systems and data that can be stored on blockchains. It would be very beneficial if blockchains could be used to automate tasks and processes. Such solutions would be able to leverage the advantages of blockchains (e.g., permanent and tamper-proof records of events, distributed processing, etc.), while their applications would be more widespread.

[0005] The Global Positioning System (GPS) is a satellite-based navigation system that provides geographic location and time information to receivers on Earth. GPS satellites orbit the Earth twice a day in precise orbits. Each satellite transmits a unique signal and orbital parameters that enable GPS devices to decode and calculate the satellite's precise position. GPS receivers use this information and trilateration to calculate the user's exact location. Essentially, a GPS receiver measures the distance to each satellite by the time it takes to receive the transmitted signal. By measuring the distance to more satellites, the receiver can determine the user's location and display that location electronically (https: / / www8.garmin.com / aboutGPS / ).

[0006] Despite its usefulness and successful integration into modern products and life, GPS does have some limitations. In addition to issues and interruptions caused by weather conditions and signals being blocked by skyscrapers and other buildings, GPS (at least the civilian version) does not have proof of origin or authentication features. This makes the system vulnerable to fraud, spoofing, jamming, and cyberattacks.

[0007] Despite its success, GPS does not provide authentication of its location data, meaning that for services that require a user's location, the user can "enter" location data without actually obtaining the data from the GPS satellite system. Essentially, this means that a user can easily claim to be at a certain location, providing GPS coordinates, despite the user not being at the proposed location.

[0008] FOAM is a proof-of-location protocol that aims to provide an alternative to centralized consumer mapping technologies and services (such as GPS) and service providers (such as Google and HERE). The builders describe FOAM as a protocol that "empowers an unlicensed and autonomous network of radio beacons that can provide secure location services independent of external centralized sources such as GPS through time synchronization" (https: / / foam.space / ). FOAM's proof-of-location utilizes regional anchors, which are land-based "nodes" that use radio technology to perform time synchronization and ultimately determine the user's location through trilateration. However, while described as a solution to certain limitations of GPS (such as spoofing), there is no obvious way in the described protocol to verify that the location provided by the user legitimately came from FOAM's regional anchors. Summary of the invention

[0009] Therefore, it is desirable to provide a method of authenticating a location. Such an improved solution has now been devised.

[0010] According to the present disclosure, a computer-implemented method may be provided. The computer-implemented method may be described as a method for determining and / or authenticating a location. The method may include the following steps:

[0011] broadcast a request for location data;

[0012] receiving respective location data from each of the plurality of nodes, the location data comprising at least one public key corresponding to respective at least one region adjacent to the node;

[0013] Selecting a common public key shared by a collection of multiple nodes; and

[0014] A collection of requesting nodes participates in threshold secret sharing (threshold key sharing) to obtain an encrypted signature associated with a common public key.

[0015] The request may be broadcast by the device or its user. The request may be broadcast to multiple fixed nodes within the broadcast range of the device or within a range selected by the user.

[0016] The advantage of this method is that a user of the method can determine his location and obtain a cryptographic signature confirming that the location is authentic without requiring the user or any other participant of the method to determine any cryptographic secrets or private keys, and the required level of security and trust in authentication is achieved through the use of threshold secret sharing.

[0017] Each location data may include a distance attribute, and the method may further include the step of sorting the public keys based on the distance attribute, and wherein the step of selecting a common public key shared by a set of multiple nodes is performed based on a result of the sorting.

[0018] The distance attribute may include a distance from the corresponding node. The sorting may include sorting the public keys in order of the distance.

[0019] The advantage of this operation is that it increases the likelihood of determining the exact location.

[0020] The step of broadcasting the request for location data may include broadcasting an identifier identifying the broadcaster.

[0021] The advantage of this is that the user's identity can be verified, thus increasing the security of the method.

[0022] The step of receiving the location data may include receiving, from each of the plurality of nodes, a public key associated with the respective at least one node.

[0023] This enables users to more easily identify the source of any information they receive from multiple nodes and, if desired, enables users to encrypt any further communications with a particular node.

[0024] The step of requesting the set of nodes to participate in threshold secret sharing to obtain an encrypted signature associated with a common public key may include providing data to be signed. The data to be signed may include: a message; a hash value of the message; and an identifier for identifying the broadcaster. The message itself may be a concatenation of the hash value of the message and the identifier.

[0025] This operation has the advantage that the data to be signed and the signature itself are linked to a specific user, making it possible to perform subsequent checks on the identity of the user, thus increasing the security of the method.

[0026] The method may also include the steps of: receiving a corresponding node signature associated with at least a public key of the node from at least one node; verifying at least one node signature; and determining whether to request the node to participate in threshold secret sharing based on a result of the verification.

[0027] This improves security for users by enabling them to determine whether to trust a particular node by detecting spoofing attempts.

[0028] The node signature may be associated with any of the message, a hash value of the message, an identifier for identifying the broadcaster, location data, and a node public key.

[0029] The method may further comprise the step of sending a share of the encrypted secret to at least one node.

[0030] The method may further comprise the step of relaying from the at least one node to the at least one further node the function value encrypted with the public key of the respective at least one further node.

[0031] The method may further comprise the steps of: receiving respective portions of an intermediate encrypted value from a plurality of nodes; merging the portions into the intermediate value; and sending the intermediate value to at least one further node.

[0032] The method may further include the steps of: receiving respective portions of the encrypted signature from the plurality of nodes; and merging the portions into a component of the encrypted signature.

[0033] Each of these steps involves the user in a communication that could have been performed between nodes, an operation that has the advantage of increasing the number of opportunities for confirming the relative position of the user and the nodes and updating the content of the communication between them, as well as enabling the user to check the results of the intermediate steps of the signature calculation.

[0034] The method may also include the step of redeeming the blockchain transaction by providing a cryptographic signature to the blockchain transaction. The blockchain transaction may include an identifier for identifying the broadcaster (ie, user) of the request.

[0035] The advantage of this operation is that blockchain provides a permanent, public and immutable record, enabling any interested party to verify the user's identity.

[0036] Additionally or alternatively, according to the present disclosure, there may be provided a computer-implemented method, the computer-implemented method comprising the following steps:

[0037] receiving a request for location data;

[0038] determining a distance attribute associated with the request;

[0039] sending location data, the location data comprising a distance attribute and at least one public key corresponding to the respective at least one neighboring area;

[0040] receiving a request to participate in threshold secret sharing to provide a cryptographic signature associated with a common public key; and

[0041] Collaborate with multiple nodes in threshold secret sharing to obtain cryptographic signatures.

[0042] A request for location data may originate from a device operated by a user seeking to prove their location, which user may be referred to as a nomad. The location data itself may be sent to nomad for receipt by nomad's device. A request to participate in secret sharing may originate from nomad's device. Once a cryptographic signature is obtained, it may be sent to nomad.

[0043] This operation has the advantage that the true location of the broadcaster of a request for location data is determined without requiring the broadcaster or any other participant in the method to determine any cryptographic secrets or private keys, and the required level of security and trust in authentication is achieved through the use of threshold secret sharing.

[0044] The method may also include the step of determining another distance attribute. The step of determining the distance attribute may include a time of flight measurement. The other distance attribute may be the distance between a user of the method (ie the first node) and another user (ie the second node).

[0045] This has the advantage of enabling a user to determine the accuracy of any subsequent calculations performed using the distance attribute, such as trilateration calculations, and has the further advantage of enabling a user to check another distance attribute against a previously obtained attribute to verify that the other user is authentic.

[0046] The step of receiving a request for location data may include receiving an identifier for a broadcaster of the request.

[0047] This operation has the advantage of enabling a user to verify the identity of the broadcaster, such as by enabling the user to compare the identifier to an entry in a table, a transaction in the blockchain's database of unspent transaction outputs, or a transaction on the blockchain.

[0048] The step of receiving a request to participate in threshold secret sharing to obtain an encrypted signature associated with a common public key may include receiving data to be signed. The data to be signed may include: a message; a hash value of the message; and an identifier for identifying the broadcaster.

[0049] This operation has the advantage that the data to be signed and the signature itself are linked to a specific broadcaster, making it possible to perform subsequent checks on the identity of the broadcaster, thus increasing the security of the method.

[0050] The step of sending the location data may also include sending a node public key. The node public key may be associated with the user (ie, the node) executing the method.

[0051] This has the advantage that the user sending the location data is identified, and in particular the identifier provides a means of encrypting subsequent communications which can only be deciphered by the intended recipient node.

[0052] The method may further comprise the step of sending to the broadcaster a node signature associated with at least a public key of the node.

[0053] This enables the broadcaster to verify communications from users, thus increasing the security of the method.

[0054] The node signature may also be associated with any of the message, a hash value of the message, an identifier for identifying the broadcaster, location data, and a node public key.

[0055] The advantage of this is that the validation is extended to verify any of the above data.

[0056] The method may further comprise the step of sending a share of the encrypted secret to the broadcaster.

[0057] The method may further comprise the step of sending to the broadcaster at least one function value calculated from a corresponding value associated with at least one node.

[0058] The method may further comprise the steps of sending a portion of the intermediate encrypted value to the broadcaster and receiving the intermediate value.

[0059] The method may further comprise the step of sending a portion of the encrypted signature to the broadcaster.

[0060] Each of these steps involves the broadcaster in a communication that could have been performed between nodes, an operation that has the advantage of increasing the number of opportunities for confirming the relative position of the broadcaster and the users and updating the content of the communications between them, as well as enabling the broadcaster to check the results of the intermediate steps of the signature calculation.

[0061] The method may also include the steps of receiving another location data associated with multiple nodes; performing trilateration to determine a calculated location of the broadcaster; comparing the calculated location with at least the location data; and determining whether to participate in threshold secret sharing based on a result of the comparison.

[0062] This enables the user to decline participation or cease participation in the method if the broadcaster moves outside of the user's desired range.

[0063] In all the above steps, the broadcaster can be understood as nomad.

[0064] Additionally or alternatively, according to the present disclosure, there may be provided a computer-implemented method, the computer-implemented method comprising:

[0065] Processor; and

[0066] A memory comprising executable instructions that, when executed by a processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0067] In addition or alternatively, according to the present disclosure, a non-transitory computer-readable storage medium may be provided, on which executable instructions are stored. When a processor of a computer system executes the executable instructions, the computer system at least performs an embodiment of the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] These and other aspects of the present disclosure will become apparent from and will be elucidated with reference to the embodiments described herein. Embodiments of the present disclosure will now be described by way of example only and with reference to the accompanying drawings, in which:

[0069] Figure 1 Displays geographic cells that divide a 2D plane into separate hexagons;

[0070] Figure 2 is a schematic diagram of the arrangement of the hexagonal anchors of the embodiment;

[0071] Figure 3 is a detailed schematic diagram of a hexagonal anchor group of an embodiment;

[0072] Figure 4 is a schematic diagram of a plurality of hexagonal anchor groups having a common hexagonal anchor vertex;

[0073] Figure 5 The allocation according to the embodiment is shown Figure 4 The key share of the vertex;

[0074] Figure 6 Shows from Figure 4 and Figure 5 The distance of the vertex to the hexagonal anchor in the hexagonal set of the embodiment;

[0075] Figure 7 FIG. 1 shows a method for confirming a vertex position according to an embodiment. Figures 4 to 6 Hexagonal anchor group;

[0076] Figure 8 The maximum separation between two vertices of a hexagon of given side length is shown;

[0077] Fig. 9 is a schematic diagram of the overlapping range of multiple hexagonal anchors according to an embodiment;

[0078] Fig.10 is a flow chart showing the steps of an embodiment;

[0079] Fig.11shows a ranking table of a user with respect to a plurality of hexagonal anchors and HexKeys according to an embodiment;

[0080] Fig.12 is a schematic diagram of the overlapping range of multiple hexagonal anchors of an embodiment;

[0081] Fig.13 is a schematic diagram of the geometric structure of an embodiment;

[0082] Fig.14 is a table showing the ranking of hexagonal anchors in the embodiment;

[0083] Fig.15 is a schematic diagram of communication between a user and a plurality of hexagonal anchors in an embodiment;

[0084] Fig.16 is a flow chart showing the steps of an embodiment;

[0085] Fig.17 is a flow chart showing the steps of an embodiment;

[0086] Fig.18 is a flow chart showing the steps of an embodiment;

[0087] Fig.19 is a schematic diagram of a blockchain submission channel of an embodiment; and

[0088] Fig. 20 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0089] In business, there are scenarios where the sender may want to restrict the receiver's access to resources or control the transaction unless the receiver is at or near a certain geographic location. Think of a taxi or self-driving car, where the driver or car does not take control of the transaction from the passenger unless the driver takes the passenger to where the passenger needs to go.

[0090] The advent of scripting languages ​​provides the opportunity to integrate advanced or complex conditions into transactions, enabling control of the transaction to be passed to the receiving party. In the case of user location, there is a danger that, while the criteria for unlocking the control may require user location, the receiving party could easily enter the requested location data without being at that particular location. "Location data" means any information that specifies a location, such as the location of a device requesting said data. Location data may include a distance attribute, which may include the distance from the nomad as determined by the device receiving said request.

[0091] A system is described herein in connection with a geospatial protocol for integrating geographic standards into transactions. The solution includes the use of threshold signatures generated by nodes located at predetermined geographic locations, wherein the collaboratively generated digital signature serves as proof of the user's location. From here on, a "node" refers to an electronic device having at least a processor and a memory and capable of receiving and transmitting digital information, performing computations, and preferably capable of interacting with a blockchain.

[0092] The scripting language gives users the flexibility to create transaction redemption criteria. The available opcodes provide the ability to build criteria from the simplicity of sending a public key to more complex "smart contract" type conditions.

[0093] In order for a transaction to be successfully submitted to the blockchain, the sender must include the required data in the input script of the recipient's transaction. This includes signatures and other alphanumeric content. In some cases, the correctness of the data can be assessed by the opcodes within the sender's output script, however, while the data is "correct", there is the additional question of whether the data included in the script is "legal".

[0094] Given that the data must be correct for the script to be successfully executed, “legitimacy” in this context involves the question of whether the correct actions were taken to obtain the data and whether the data was obtained from a verified source.

[0095] An example of the data problem mentioned previously is a location-based application that may rely on coordinates or other spatial representation type data; it may require that the recipient be at a specific location in order to receive payment. In order to receive their payment, the recipient may provide their coordinate data in the script, but knowing these coordinates does not necessarily mean that the recipient (also known as the nomad) is at the specified location. What is desired is confirmation that the nomad is at the specified location.

[0096] This paper discloses a Proof of Location CErtification System (PLaCES) protocol, which provides a method to achieve nomad geospatial location authentication of transactions. The authentication of nomad location is represented by an ECDSA digital signature, and the proposed protocol is designed to ensure (at least with high probability) that the nomad is or was at or near a specific location to obtain a signature. A Threshold Signature Scheme (TSS) is used to reach a satisfactory level of consensus on the location. Anchor points at the vertices of the hexagons of the hexagonal grid plane cooperate with each other to produce a signature, as described in detail below.

[0097] Threshold Secret Sharing (TSS) is a cryptographic mechanism that partitions a private key into key shares, where the private key can be reconstructed with the cooperation of at least a threshold number of share holders.

[0098] The PLACES protocol addresses the authentication limitations of GPS because users of the protocol are able to have a high degree of assurance that geolocation data comes from a verified source.

[0099] Within the PLaCES protocol, to authenticate their location, nomads obtain a digital signature corresponding to that location, more specifically, a digital signature of a point on the elliptic curve.

[0100] It is expected that nodes executing the protocol (called hexagonal anchor nodes and described in detail below) can verify that they have obtained the correct secret shares. For key share verification, a publicly verifiable secret sharing (PVSS) scheme can be adopted, which allows a node to verify its own share and the shares of other nodes.

[0101] The PLACES protocol provides blockchain services and other systems that require and / or expect to authenticate the location of users to authenticate nomad locations. Nomads are individuals who are asked to provide their location and are users of the protocol.

[0102] In the PLaCES protocol, authentication of a nomad's location is achieved by generating a digital signature. This signature is constructed when a sufficient number of participating HexAnchors agree that the nomad meets certain criteria (such as location and / or distance conditions).

[0103] While GPS and FOAM locations are based on latitude and longitude, the PLaCES protocol is designed for an agreed-upon set of discrete geographic units (e.g., zip codes). The physical area covered by PLaCES is subdivided or tessellated into these discrete geographic units. A "tessellation" is "an arrangement of shapes that fit closely together, especially an arrangement of polygons in a repeating pattern without gaps or overlaps" (https: / / en.oxforddictionaries.com / definition / tessellation). Each geographic unit is preferably in the shape of a regular hexagon (a 6-sided polygon), although other shapes (regular and irregular) are entirely possible. From here on, PLaCES is described with reference to hexagonal geographic units.

[0104] The surface area of ​​each polygon (or the corresponding length of each edge) will depend on a combination of the level of location granularity required, the strength of the radio signals from the hexagonal anchors, cost, and logistical issues.

[0105] Each hexagon in the 2-dimensional plane is assigned an identifier. Each identifier (called a HexKey for our purposes) is or represents an Elliptic Curve (EC) public key. The EC public key P is such that

[0106] P=pG

[0107] Where G is the base point or generator point on the elliptic curve and p is the private key.

[0108] A nomad that wants to prove its location needs to obtain a signature corresponding to its location, where the location is the hexagon that the nomad is in, and the signature is a signature created using the private key of the corresponding hexagon key (HexKey).

[0109] For example, Figure 2 The nomad in is at a location bound to a public key N = nG. In order for the nomad to prove that they are at that location, the nomad must generate a digital signature based on the private key n.

[0110] It is important to note that neither nomad nor anyone else has this private key, or indeed any other private key for any HexKey of the aircraft. This improves the security of the protocol because no single actor or user is able to generate a HexKey signature.

[0111] Hexagonal anchors are the names of nodes located at the vertices of the hexagon. In this paper, the numbering convention is refers to a hexagonal anchor, where A is the HexKey and i is the index of the node position in the hexagon. Note that this convention defines the anchor point at the top of the hexagon as index i=1, and the index increases in a clockwise direction, such as Figure 3 shown.

[0112] Being located at the vertex of a hexagon means that, unless the anchor point is located at the outer edge of the 2D plane, the anchor point is located at the vertex of at least three hexagons. These three hexagons are three regions close to or adjacent to the anchor point and are referred to as the hexagonal set of the anchor point. It should be understood that a node is considered to be close to or adjacent to a region such as a hexagon if there are no other nodes closer to the region than the node. For example, Figure 4 Three hexagons (A, B, C) in the hexagonal set of the centrally located hexagonal anchor are shown. Note that the hexagonal anchors can be labeled in three different ways, such as

[0113] Each hexagonal anchor has a unique ID. This is to distinguish the hexagonal anchors. This unique ID is The labels are separate and isolated. This unique ID can be in the form of a public key or an address.

[0114] Each anchor is physically stationary. This means that the anchor does not physically move. While accidents and malicious actors may attempt to physically displace nodes, the PLaCES protocol employs measures to mitigate and / or identify misplaced anchors.

[0115] Each anchor has the ability to send and receive data, such as in the form of radio waves, to and from at least all other anchors found in the hexagonal set of anchors. These radio signals will also be used to determine the distance between anchors or nomads.

[0116] Each anchor is able to perform clock synchronization with other anchors in the hexagonal set via the anchor's radio transceiver or otherwise. PLaCES provides the ability for a hexagonal anchor to determine the distance to another hexagonal anchor. In order to successfully complete this operation, the clock of each anchor is synchronizable.

[0117] Each anchor has the ability to send and receive data, such as in the form of radio waves, to and from specially designed equipment owned by a nomad located within any hexagon of the anchor's hexagonal set.

[0118] Each anchor is also a node in the blockchain network or has access to the blockchain network, i.e. each hexagonal anchor has access to the blockchain or at least the UTXO set.

[0119] Central to PLACES’s ability to authenticate nomad locations is its use of threshold secret sharing (TSS). TSS involves “dividing” a private key x into multiple key shares {x i :i∈[1,n]}. The private key can be reconstructed using only a sufficient number of key shares corresponding to meeting or exceeding the threshold of the scheme. In the case of using the Shamir polynomial method, for a polynomial of order t, t+1 of the n key shares are required to determine the private key x.

[0120] By utilizing a sufficient number of x i Key shares can generate an ECDSA digital signature based on the private key x. In this case, if the polynomial is of order t, then t=2t+1 of the n key shares are needed to generate the digital signature corresponding to the private key. This can be done without any of the participants revealing their personal key shares.

[0121] As mentioned previously, in the PLaCES protocol, each hexagon is assigned a HexKey (EC public key) P = pG. For the corresponding private key p, each hexagon anchor are assigned key shares p iConsidering that the hexagonal anchors are vertices of at most three hexagons, each anchor point can be assigned at most three different key shares, each corresponding to a different hexagon. For example, in Figure 5 , the hexagonal anchor (shown in the center) owns key share a3 for hexagon A, key share b5 for hexagon B, and key share c1 for hexagon C.

[0122] The "division" and / or distribution of the key shares of the HexKey can be done in two ways, as follows:

[0123] - Have a "dealer who knows private key x" create key shares and securely communicate those key shares to each participant, or

[0124] -Adopt a no-dealer solution where each party creates its own share of the key and no party knows the value of the private key x.

[0125] In the PLaCES protocol, any of the key share distribution methods can be used, keeping in mind that each method has its advantages and disadvantages as indicated in the following table.

[0126]

[0127] In the case of a dealer-based option, the trusted supervisory authority can distribute key shares not only to the hexagonal anchors of a hexagon, but to all hexagonal anchors. Alternatively, each hexagon can have its own trusted authority that distributes key shares only for that hexagon.

[0128] Where the dealerless option is used, the hexagon anchors of a hexagon collaborate to generate a key share of the private key of that hexagon.

[0129] There is a setup phase where the hexagonal anchors are placed at their respective locations according to the grid topology. Due to the physical aspects of this positioning, each hexagonal anchor may not be placed exactly at a location corresponding to a vertex of the grid topology. This may be due to topographical or logistical issues. However, small deviations of the hexagonal anchors from their proposed locations do not affect the effectiveness of the PLaCES protocol. Once the final locations of the hexagonal anchors are known, each hexagonal anchor He knows that he The distance between all other hex anchors in the hex set. For instructions on how to do this, see Figure 6 . Please note that in addition to the hexagonal anchor Be informed of the distance to other hexagonal anchors (y ij ) is how much, the anchor point You can confirm for yourself that these anchors are actually at the specified distance. This "Confirmation of Distance" (CoD) process can be performed not only at the initial setup of the anchors, but also at any time decided by each anchor.

[0130] Using a transceiver such as a radio transceiver, the hexagonal anchor is based on the time it takes to send a signal and receive a response signal. Can determine another distance from itself. Considering The exact location of the device may not be known accurately at the outset, and weather conditions or other factors may affect radio signals, so it is neither expected nor required to The "on paper" distance of is exactly the same as the "real world" value, except that y ij The real-world value of is within a certain range. For example, if the hexagonal anchor On paper, with If the distance is 100m, can choose a margin of error that he is willing to accept As a real-world distance, for example, y ij =(100±5)m.

[0131] Note that the anchor point Unable to determine the anchor point The exact position of ij . There are only distance values, which means Only anchor points can be determined Located at radius y ij To determine the anchor point The position of the anchor point requires the distance between the anchor point and at least three anchor points. The distance to each of the three honest anchors is correct, then The position is considered correct.

[0132] In order to generate a signature confirming that a nomad is at a certain location, a sufficient number of hexagonal anchors need to cooperate. Since hexagonal anchors can perform checks individually and at any time to determine whether any or every other cooperating anchor is at the required distance, if an anchor For the measured to any other collaborative anchor point If the distance is not satisfactory, the hexagonal anchor May refuse to generate digital signatures for nomad.

[0133] Figure 7Three anchors are shown performing distance checks on the anchor of interest at the lowest point of the hexagon. Note that each anchor checks if the anchor of interest falls between two circles. The two circles of the anchor are the upper and lower bounds of the expected distance from the anchor of interest. If all anchors are happy that the anchor of interest falls within their circle pair, then the anchor of interest can be accepted as being within the boundaries of the correct location.

[0134] A hexagonal anchor is able to detect a nomad anywhere in the area covered by the anchor's hexagonal set. This, in addition to being able to determine the distances of other anchors from itself, means that the radio signal strength of any hexagonal anchor is sufficient to reach the farthest vertex in any anchor's hexagonal set. Since the geographic unit for this example is a regular hexagon with side length l, this distance is 2l (see Figure 8 ). The range of anchor points is as follows Fig. 9 shown.

[0135] The nomad has a device that can broadcast and receive data, preferably in the form of radio signals. The range of this device is sufficient to send and receive signals and / or messages to nearby hexagonal anchors. Similar to the hexagonal anchors themselves, the minimum range of the nomad's beacon device is preferably 21.

[0136] The device can be a dedicated device or a multi-function device that includes radio functionality, such as a smartphone or tablet. The device contains a mechanism that provides a unique identity for the device, such as a SIM card in a mobile phone. Communications from such a device are difficult to forge or spoof.

[0137] Establish a threshold for the key shares. This threshold represents the minimum number of hexagonal anchors required to form a consensus on the location of the nomad (and thus the location of the anchors). Given that at least three anchors are required to determine the location of the anchor in the 3D volume, i.e. to successfully compute the trilateration calculation, the threshold (always denoted as τ) should be at least four.

[0138] If τ ≥ 4 anchors are satisfied for one of them, i.e. the location of the nomad satisfies the distance and / or location criteria (and preferably also satisfies the distances of all other anchors in the hexagon), then that anchor selection contributes to the generation of a signature proving the location of the nomad. If τ ≥ 4 anchors are satisfied, then they can collaborate and successfully generate a digital signature for the hexagon's HexKey.

[0139] The steps nomad takes to determine its location are described below. Note that for simplicity purposes, the term nomad and its device are used interchangeably.

[0140] 1. The nomad broadcasts a signal at a certain location, announcing that it is attempting to establish its location. This broadcast includes the unique identifier of the device / nomad being generated (e.g., SIM card).

[0141] 2. One or more hexagonal anchors receive this signal.

[0142] 3. Each hexagonal anchor that receives this signal performs a calculation to determine the distance between the nomad and the hexagonal anchor by transmitting a radio signal to the nomad and receiving a radio signal from the nomad. This may include one or more RF (radio frequency) calculations such as time of flight calculations, which may involve transmitting some unique data from a first transceiver A and having the data transmitted back from a second transceiver B to transceiver A, and then measuring the time taken for the round trip. The distance between the two transceivers can then be calculated. In addition or alternatively, other time of flight solutions may be used, including the use of phase difference.

[0143] 4. If the distance between the nomad and the hexagonal anchor is within 2l, the anchor emits the following to the nomad:

[0144] a. The three HexKeys of the hexagon that the hexagonal anchor is responsible for,

[0145] b. The distance between the hexagonal anchor and the nomad,

[0146] c. the public key of the hexagonal anchor, and

[0147] d. Any other information required for a two-way communication channel between Nomad and the Hexagon Anchor.

[0148] 5. Nomad will create a list of the responsive hexagonal anchors in order from nearest to farthest.

[0149] 6. Starting from the nearest anchor, nomad traverses the list until it reaches the first τ unique anchors responsible for a public HexKey. A public HexKey is a public key common to a set of multiple anchors. In this example, τ=5.

[0150] 7. Then, nomad asks these τ anchors to generate digital signatures for this public HexKey on his behalf.

[0151] 8. A collection of τ anchors collaborate to produce this signature. In this case, nomad can participate in the relaying of data between anchors and / or the processing of data received from anchors before obtaining a complete signature.

[0152] Fig.10 The flowchart shows the sequence of actions involved in establishing the location of nomad.

[0153] In addition to steps 5 and 6 above, nomad can use other methods to determine his location, such as:

[0154] Consider that nomad receives the distance information shown in Table 1.

[0155]

[0156] Table 1

[0157] Nomad can then perform the following steps instead of steps 5 and 6 above:

[0158] 9. Identify unique sets of hexagons represented in the set of hexagons. For example, H, M, N, I, O, S, T, B, G, X;

[0159] 10. Select the maximum integer value t≤6 such that at least 2 hexagons have t instances represented by hexagonal anchors, for example, t=3;

[0160] 11. For each unique hexagon represented at least t times, select t instances of its respective representation (e.g., in the case of hexagon N, these instances are shown in Table 2 below, and in the case of hexagon S, these instances are shown in Table 3 below);

[0161]

[0162] 12. For each hexagon represented by at least t anchors, nomad / device then computes the average distance between the set of corresponding hexagonal anchors and nomad. For example, the average value of S is And the average value of N is and

[0163] 13. Then, the hexagon with the lowest average distance is selected as the closest hexagon. In this example, nomad decides that he is in hexagon N. Nomad then continues with step 7 above.

[0164] In this section, consider examples of where nomads might be and what decisions they make about their locations.

[0165] Scenario 1.

[0166] For scenario 1, consider Fig.11 where the nomad is more or less in the center of the hexagon. The closest anchors are those that define the hexagon where the nomad is located. Each anchor is approximately l away. Therefore, if at least τ anchors respond to the location request, then the shared HexKey of these τ anchors will eventually become the determining nomad location.

[0167] Consider anchors 1, 2, 3, 4, 5, and 6 responding to nomad's request to establish a location. Of these, the first τ = 5 anchors in the sorted list shown that share a common HexKey are anchors 1, 2, 3, 4, and 5. This common HexKey is N, and upon nomad's request, the same set of anchors will then collaborate to produce a digital signature of public key N.

[0168] Scenario 2.

[0169] For scenario 2, consider Fig.12 , where nomad is in hexagon T, and nomad is able to generate a digital signature for another hexagon N. The following question can be asked: "What is the probability that nomad (intentionally or accidentally) generates a digital signature for a hexagon in which nomad is not?"

[0170] That is, can a nomad in hexagon T produce a signature for the adjacent hexagon N? Fig.12 Seven lettered regions are shown, labeled a to g. Considering that the area covered by the circle represents the range of anchors (hexagon N) that are allowed to be nomad signatures, the lettered regions of hexagon T represent the regions where these ranges overlap. For example, region a represents the region covered by anchors 3 and 4, region b is covered by anchors 3, 4, and 5, and region g is covered by all anchors 1 to 6. Therefore, the number of range overlaps is the number of hexagonal anchors that can be used for digital signatures.

[0171] Note that the geometry (overall hexagonal shape and proportional area) of each of these letter regions is identical to any other adjacent (N and T) hexagonal pair.

[0172] Table 4 below shows the overlap of hexagonal anchors in the letter regions of the example, where the threshold τ=5.

[0173]

[0174] Table 4: Overlapping range

[0175] If nomad is within certain positions of hexagon T, a digital signature can be generated for hexagon N.

[0176] If the threshold τ is set to 5 anchor points, the regions in hexagon T that can produce a signature for hexagon N are letter regions e, g, and f, and these regions are close to the border of hexagon N. This “buffer zone” may be acceptable, depending on the context and environment of knowing the nomad locations.

[0177] Note that this ability to generate signatures even when not inside the hexagon is a concern for malicious nomads, who will be able to claim that they are not inside the hexagon by generating signatures using overlapping contributions from these τ anchors.

[0178] Honest nomads in hexagon T are able to determine their correct location based on their hexagon because nomads will not only receive responses from anchors in hexagon N, but also receive communications from anchors in hexagon T. Assuming all anchors are operational, then in the sorted list, nomads will reach τ anchors in hexagon T before reaching τ anchors in hexagon N.

[0179] consider Fig.13 , Fig.13 Two adjacent generic hexagons (N and T) are shown. Note that the surrounding hexagons (not shown) are assumed to have Fig.12 The name shown. Fig.13 shows how nomads that are in hexagon T but within at least τ anchors of N are classified as being in T. If τ ≥ 4, this would refer to regions e, f, and / or g, as shown in Table 4.

[0180] according to Fig.13 , it should be noted that the mirror image counterpart in the hexagon N is In contrast, the nomad in T is always closest to the anchor point in the hexagonal T. Also note that the two hexagons (N and T) share the same anchor point and

[0181] Anchor points (and their associated hexagonal sets) are Fig.14 . Keeping in mind that both hexagons will have two shared anchor points in common, note that nomad reaches the τ anchor points with common hexagon T as its hexagonal set element before reaching the τ anchor points with common hexagon N. This is because of the following facts (besides the shared anchor points):

[0182] - For mirrored anchors, an anchor in T will always be closer to nomad than the corresponding anchor in N.

[0183] - No other anchor has both N and T in their respective hex sets.

[0184] refer to Fig.14 , noting that in the sorted list, nomad will reach τ anchors with hexagon T before reaching τ anchors with hexagon N. Note that in Fig.14In , the closest / farthest labels only apply to intra-mirror anchor pairs, not inter-mirror anchor pairs. Also note that although in Fig.14 , but the other anchor in the pair is not necessarily the direct successor in the sorted list of all anchors (because this involves distance).

[0185] We will now describe the generation of a digital (ECDSA) signature representing an authenticated nomad, where the set of τ anchor points required to generate the signature is and:

[0186] - nomad has its position / hexagon determined as described above (e.g., hexagon N);

[0187] - All hexagon anchors have received and verified the key shares of the hexagons of their respective hexagon sets (specifically hexagon N). This key share verification can be done using the verification scheme described previously; and

[0188] -Nomad and Anchor Communications with the nomad may include an embedded unique identifier for the nomad, such as a number tied to a physical mobile sim card. The inclusion of the sim card identifier information in communications is preferably not performed by the nomad themselves, but rather by their device employing the PLaCES protocol. For example, a user making a phone call does not enter their personal phone number, but a cell tower is able to identify that the phone call is coming from that specific phone based on the information contained within the sim card. It is difficult for nomads to alter information embedded via the sim card (such as the nomadID) in their communications with the hexagonal anchor, which contributes to the security of the PLaCES protocol.

[0189] Once all hexagonal anchors have verified all of their key shares (e.g., using the PVSS method described above), a process is initiated to determine which anchors are involved in the collaboration to produce the digital signature. Once completed, the anchors then initiate the collaborative process to produce the signature. As mentioned above, the signature is derived by using a threshold signature scheme.

[0190] Recall that, according to the sorted list of anchors, where anchors are ranked by proximity to the nomad, the first hexagon shared by at least τ anchors is considered the location of the nomad. Therefore, these τ anchors are used to create a signature that confirms the location of the nomad.

[0191] For the moment, let's assume that nomad is trying to prove that they are in hexagon N:

[0192] 1. Nomad sends a request to each of the τ anchors, asking them to participate in the signature collaboration of hexagon N. This communication with each node can be done simultaneously;

[0193] 2. With each anchor point The communication includes the hexagonal public key N, and at least one hash value of the message m that nomad wants to sign. Alternatively or in addition, the message itself may be sent;

[0194] 3. Each anchor checks the blockchain to determine if the ID of the specified nomad (nomadID) in the transaction is the same as that contained in the nomad’s communication and / or is the same as the nomadID in message m, which may be submitted by other users;

[0195] 4. Each of the τ anchor points Upon receiving a request, a check can be performed to confirm that nomad is within the requested range;

[0196] 5. If nomad is in range and nomadID matches, then the anchor Create (and possibly save in its internal memory) a vector The vector contains the following data:

[0197] <P i ,sig,N,H(m),timestamp,distance,nomadID>,

[0198] in:

[0199] aP i It is an anchor point The public key (personal key, different from HexKey);

[0200] bH(m) is the hash value of the message or transaction to be signed;

[0201] c. Distance is the distance between nomad and anchor point;

[0202] d. The timestamp is The time to confirm the distance of the nomad; and

[0203] e. The signature is a digital signature based on the public key P of the hash value of "at least the concatenation of H(m), N, timestamp, distance and nomadID" i ;

[0204] 6. Each anchor point Put their vector Send to nomad;

[0205] 7. nomad adds each of these vectors to the list LV; and

[0206] 8. If the list contains vectors with valid signatures from at least τ anchor points, then these anchor points are selected to collaborate in producing a digital signature corresponding to the position.

[0207] The advantage of including the nomadID as a value in the message to be signed is that, in the case where the message is a transaction, the nomadID is stored in the transaction via the opcode OP_RETURN and is immutably and publicly stored on the blockchain.

[0208] In situations where privacy of nomad messages is desired, nomads may choose to send only the hash of their messages to anchors. However, the signature produced by the anchor collaboration will be the signature of the hash of the message combined with nomadID, i.e. H(H(m), nomadID).

[0209] The reason for including the identifier in the message m is so that the Hexagon Anchor can then check that the intended physical device that Nomad is communicating from corresponds to the stipulated identifier on the blockchain.

[0210] Note that the specification of the identifier may be done in another user's transaction (the other user is the user who requires the recipient to be at a specific location to redeem the submitted transaction). The specified identifier may be stored in the OP_RETURN of the other user's transaction or elsewhere.

[0211] The blockchain provides a record of transactions and provisioning identifiers / nomadIDs that is public and immutable. Hexagon anchors can check the blockchain to determine what the provisioning nomadID was when asked to collaborate on signing a message / transaction, or at an arbitrary chosen time.

[0212] Now that the set of τ hexagonal anchors have agreed to participate in the signing collaboration of hexagon N, the anchors can generate the signature. As mentioned above, this collaborative signing process uses the threshold signature scheme described above and is described in detail below.

[0213] The ECDSA signature is a pair (r,s), where

[0214] r=x1 mod nwhere (x1,y1)=k×G

[0215] s=k -1 (m+xr)mod n

[0216] And x is the private key.

[0217] The process of generating an ECDSA signature is listed below.

[0218]

[0219] Table 5: Signature generation steps

[0220] Optionally, when generating a signature, the hexagonal anchor does not directly interact with other anchors but communicates through the nomad. The advantage of this operation is that in each communication between the anchor and the nomad, the anchor is provided with more opportunities to confirm that the nomad is within the scope of the requirements of the anchor. If at any time the nomad is not within the scope of the requirements of a specific hexagonal anchor, that hexagonal anchor can abort the signature process by ceasing to cooperate in generating the signature. Considering efficiency and other issues, each anchor does not have to perform such a distance check at every opportunity. Each anchor has the ability to choose when to check the distance according to its respective situation.

[0221] Each step in Table 5 is now described according to how the nomad is included when performing these steps.

[0222] Step 1: A group π of τ = 2t + 1 anchors uses dealerless secret sharing to compute a share k i , which is a random number. The process is as Fig.16 shown.

[0223] Step 1 is to distribute shares of a temporary key k, which is a randomly generated number and will be used to compute the ECDSA signature. The ECDSA signature is a pair (r, s), where k satisfies 0 < k < q, and q is the order of the subgroup, r = x1 mod n with k × G = (x1, y1) and s = k -1 (m + xr) mod n.

[0224] Based on the above dealerless-based key share distribution, the following steps are performed. Assume that the nomad has a list LV containing at least τ vectors, then

[0225] 1. The nomad sends the list LV and the x-value x i to each hexagonal anchor, and each anchor is assigned to a polynomial on which they find their share k i (with a random value k). In some cases, it may not be necessary to send these x-values, and it can be assumed that the anchor will use i as their x i , such as at 3, which will be the x-value for the anchor . Note that x i can be regarded as a share part of the encrypted secret k.

[0226] 2. When receiving LV, each anchor will verify the sigs in each vector, and the "specified nomadID in m" matches the "embedded nomadID in the communication" and / or matches the "specified identifier in the payer transaction found in the blockchain".

[0227] 3. Anchor Verify that nomad is within the required range as follows:

[0228] a. First, the anchor point Using a collection from LV The distance and timestamp values ​​of at least three random vectors are used to perform trilateration calculations. This makes the anchor point A more refined understanding of where nomads might be located within hexagon N.

[0229] b. Second, if necessary, the anchor can execute a function to recalculate its distance to the nomad. Reasons for doing this may include inconsistencies in the trilateration calculations using the vector data, or inconsistencies in the time that has passed since the last communication with the anchor.

[0230] 4. If the anchor does not satisfy that nomad is in the required area, the anchor will exit the signature generation process, otherwise the anchor will continue with the next steps.

[0231] 5. Then, the anchor point Generates a random polynomial f(x) of level t.

[0232] 6. Anchor Send nomad his vector An updated version of . An “updated” version contains the new distances and their corresponding timestamps obtained from the new distance verification.

[0233] 7. Nomad with any new The value updates the LV.

[0234] 8. Anchor point The polynomial f i (x j ) mod n, each of the other players’ points (y-values) are sent secretly to nomad. These points are “secret” because each one uses the public key P of the intended anchor. j :j≠i is encrypted separately. The y-value can be called the function value.

[0235] 9. Nomad transfers the points to the expected anchor points one by one

[0236] 10. Each anchor point All the f1(x i ),f2(x i ),…f τ (x i ) add together to form their share,

[0237]

[0238] with a random value k.

[0239] Step 2: The subgroup π′ of t+1 players joins the collaboration to generate k×G=(x1,y1) using secret sharing. The value r=x1 mod n is broadcast to the entire group. Fig.17 shown.

[0240] In step 2, the collaborating anchors generate an EC public key r = kG without revealing their respective k i The share has a random value k. Note that not all τ = 2t + 1 anchors need to participate in generating kG, only π′ = t + 1 anchors need to participate. The multiplication required to generate the public key is based on the secret sharing described above. Perform the following steps:

[0241] 11. nomad selects the π′ hexagonal anchor from LV as the anchor point to participate.

[0242] 12. Nomad sends requests to these anchors, asking them to participate with the current version of LV.

[0243] 13. Upon receiving the LV, each anchor verifies the signature in each vector and that the specified nomadID in m matches the embedded nomadID found in the communication.

[0244] 14.π′ Anchor Points Each of the anchor verifies that nomad is in range. This can be done using trilateration and distance calculations as previously described in step 1. It is optional for the anchor to calculate the distance between itself and the node.

[0245] 15. Each anchor point Calculate their part b i,π′ k i ×G, where b is the interpolation factor. These parts can be considered as parts of the encrypted signature.

[0246] 16. Each anchor point Their parts and their vectors Any updated versions of are sent to nomad.

[0247] 17.nomad adds or combines each part to produce:

[0248]

[0249] where kG can be considered as a component of the signature, since r = x1 mod n is a component of the signature (r, s) and can be directly and easily derived from kG.

[0250] 18. nomad sends at least r = x1 mod n to all participating hexagonal anchors.

[0251] 19. Nomad receives any new The value updates the LV.

[0252] Step 3: The group π of τ=2t+1 anchor points uses the secure inverse to calculate k -1 mod n. Each share is called k i -1 The process is as follows Fig.18 shown.

[0253] To compute s when determining an ECDSA signature, the inverse of k is required. However, the value of k is unknown to any participant. -1 (or k). Instead, each hexagonal anchor calculates and uses their share when creating a portion of the signature Since this process involves multiplication of secret shares, the group π consists of π = 2t + 1 players who collaborate to compute k -1 The share in mod n.

[0254] To obtain their share of the inverse, perform the following steps:

[0255] 20.Nomad initiates sending LV and generates The process of requesting a share.

[0256] 21. Upon receiving the LV, each anchor verifies the signature in each vector and that the specified nomadID in m matches the embedded nomadID found in the communication.

[0257] 22.π anchor points Each of these verifies that nomad is in range. This verification can be performed using the same secondary distance check as in steps 1 and 2.

[0258] 23. Anchor and Nomad use trader-free secret allocation to calculate share c i , where the share is a random number. This is done in the same way as in step 1.

[0259] 24. Each anchor point Calculate part b i,π k i c i mod n and send this to nomad.

[0260] 25.nomad adds each part together to produce:

[0261]

[0262] kc can be considered an intermediate encrypted value, since it is not part of the signature, but is used in the process of securely computing a part of the signature. i,π k i c i mod n may be referred to as part of the intermediate encrypted value.

[0263] 26.nomad sends the value kc to each anchor.

[0264] 27. Each anchor point Compute multiplicative inverse (kc mod n) -1 mod n=k -1 c -1 mod n

[0265] 28. Each anchor point Calculate the second part k -1 c -1 ×c i mod n.

[0266] This is the inverse value k -1 The share of this anchor

[0267] Step 4: Each anchor point of group π Calculation part b i,π k i -1 (m+x i r) mod n, where m is the information being signed (e.g., an encrypted transaction).

[0268] Now each hexagonal anchor has inverse k -1 Their k i -1 The shares, and then each anchor computes their part in the ECDSA signature.

[0269] 29. Each anchor point Calculate their portion of the signature.

[0270] b i，π k i -1 (m+x i r)mod n

[0271] 30. Anchors send their parts to nomad.

[0272] Step 5: The group collaborates to add their parts, providing the required ECDSA signature for s:

[0273] nomad is now responsible for adding all parts from the set of τ=2t+1 anchors to produce s of the ECDSA signature (r,s).

[0274] 31. Nomad sums or combines all the parts to produce s, another component of the signature, as follows:

[0275]

[0276] 32. Nomad now has a valid signature (r,s), confirming that nomad's position is inside the hexagon N. Recall that nomad already knew r from step 2.

[0277] 33. Nomad can now use digital signatures for required services, such as blockchain transactions that require confirmation of nomad’s location.

[0278] Note that verification of the key shares utilized when generating the signature can be performed using the PVSS verification scheme described above. If communication between anchors is necessary, this can be done with nomad acting as a middleman.

[0279] Given that the output of a successful execution of the Proof of Location (PoL) protocol is a digitally signed ECDSA, PLaCES can be used in conjunction with transactions without changing anything about their respective protocols (opcodes or otherwise). All that is required is to include in the output script of the transaction TrA <scriptpubkey>Add a requirement for a digital signature of the hexagon's public key (e.g., N) as an input script to another transaction TrB <scriptsig>Part of the conditions for accessing TrA's coin.

[0280] While in theory only the signatures of the hexagon N may be required, given that the transaction may be for a specific person / entity, the criteria to be met for accessing the token may be based on the public key of the hexagon and the entity's public key P. This can be represented in script as an m-of-n multisig transaction, as shown below, and in Fig.19 A schematic illustration is given in FIG.

[0281]

[0282] When combined with the nTimeLock value of a transaction, embodiments of the present disclosure can include time criteria in addition to location criteria. For example, an airline might run a program where they promise to provide customers with a discount if a flight does not get a passenger to where they need to be by a certain time. This type of agreement can be implemented using a submission channel. This is a payment channel that contains three transactions: Submit T C , pay T P and the discount T in this example D trade.

[0283] Submit transaction T C The customer creates and holds token x, which is the cost of the good / service (ticket).

[0284] Escrow funds can only be used after providing any of the following conditions:

[0285] 1. Customer signature σ(C) and airline signature σ(A)

[0286] or

[0287] 2. Location signature σ(N) and airline signature σ(A)

[0288] Please note that the submitted transaction may contain a record of the nomadID (the aircraft's unique sim card).

[0289] Payment TransactionT P is the transaction used by airline A to collect their full payment for x. In this transaction, the passenger’s PLaCES signature σ(N) of the intended destination hexagon and the airline’s signature σ(A) are required.

[0290] Hexagonal anchors participating in the generation of σ(N) can refer to the blockchain to verify that the stipulated nomadID of the submitted transaction is the same as the one embedded in the communication from the nomad / aircraft to the anchor.

[0291] Discount Deals D is a nTimeLocked transaction that transfers a total amount d to customer C from the x escrow funds that submitted the transaction, and xd to the airline. d is the discount amount that the passenger received.

[0292] Note that the discount transaction is nTimeLocked meaning that the discount transaction cannot be successfully submitted to the blockchain before a certain point in time (which can be defined in terms of UNIX time or block height). This means that if the plane does not arrive at the location before a certain deadline, the customer can submit the discount transaction and retrieve d for themselves.

[0293] Now go to Fig. 20 , provides an illustrative simplified block diagram of a computing device 2600 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any of the systems shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig. 20 As shown, computing device 2600 may include one or more processors with one or more levels of cache and a memory controller (collectively referred to as 2602), which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a permanent memory 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks described in the present disclosure. Processor 2602 may be used to provide the steps or functions of any embodiment described in the present disclosure.

[0294] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0295] The bus subsystem 2604 may provide a mechanism for enabling the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

[0296] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can serve as an interface for receiving data from the computing device 2600 and transmitting data to other systems. For example, the network interface subsystem 2616 can enable a data technician to connect the device to a network, so that the data technician can send data to the device and receive data from the device at a remote location (e.g., a data center).

[0297] The user interface input devices 2612 may include one or more user input devices, such as a keyboard; a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touch screen included in a display; an audio input device, such as a voice recognition system, a microphone; and other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to the computing device 2600.

[0298] One or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display (e.g., an audio output device, etc.). The display subsystem may be a cathode ray tube (CRT), a flat panel device (e.g., a liquid crystal display (LCD)), a light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. For example, one or more user interface output devices 2614 may be used to present a user interface to facilitate user interaction with an application that performs the described processes and variations therein (when such interaction may be appropriate).

[0299] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that may provide the functionality of at least one embodiment of the present disclosure. When executed by one or more processors, an application (program, code module, instruction) may provide the functionality of one or more embodiments of the present disclosure and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage 2610 may provide permanent (non-volatile) storage for programs and data, and may include flash memory, one or more solid-state drives, one or more magnetic hard drives, one or more floppy disk drives with associated removable media, one or more optical drives with associated removable media (e.g., CD-ROM or DVD or Blu-ray), and other similar storage media. Such programs and data may include programs for executing the steps of one or more embodiments as described in the present disclosure and data associated with transactions and blocks described in the present disclosure.

[0300] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted via the port that connects the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, Fig. 20 The depiction of computing device 2600 is intended only to illustrate a specific example of a preferred embodiment of the device. Fig. 20 There are many other configurations with more or fewer components of the systems shown.

[0301] It should be noted that the above embodiments illustrate rather than limit the present disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present disclosure. In the claims, any figure marks in brackets shall not be interpreted as limiting the claims. The words "comprises" and the like do not exclude the presence of elements or steps other than those listed as a whole in any claim or in the specification. In this specification, "comprises" means "includes" or "consists of...". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present disclosure may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.< / scriptsig> < / scriptpubkey>

Claims

1. A computer-implemented method, the computer-implemented method comprising the following steps: By a broadcaster, broadcasting a signal, the signal comprising a request for location data; receiving corresponding location data from each of a plurality of nodes, the plurality of nodes being nodes that receive the signal and determine to be within a predetermined distance from the broadcaster, the location data comprising a plurality of public keys corresponding to a corresponding plurality of regions adjacent to the node; Based on the location data, selecting a common public key, the common public key being the public key common to a set of the plurality of nodes; as well as The set of the plurality of nodes is requested to participate in threshold secret sharing to obtain an encrypted signature associated with the common public key, wherein each of the plurality of nodes has a corresponding plurality of private key shares corresponding to the plurality of public keys, and the encrypted signature is obtained by a threshold number of the private key shares.

2. The method according to claim 1, wherein the location data further includes a distance attribute, and further includes a step of sorting the public keys based on the distance attribute, wherein the step of selecting a common public key shared by the set of the plurality of nodes is performed based on a result of the sorting.

3. The method of claim 2, wherein the distance attribute comprises a distance from the corresponding node to an origin of the request and the sorting comprises sorting the public keys in order of the distance.

4. A method according to claim 1, wherein the step of broadcasting a request for location data includes broadcasting an identifier for identifying the broadcaster, and / or wherein the step of receiving location data also includes receiving a public key associated with a corresponding at least one node from each of the multiple nodes.

5. The method of claim 1, wherein the step of requesting the set of nodes to participate in threshold secret sharing to obtain an encrypted signature associated with the common public key comprises providing data to be signed.

6. The method of claim 5, wherein the data to be signed comprises at least one of: (i) a message; (ii) a hash value of the message; and (iii) an identifier for identifying the broadcaster.

7. The method according to claim 1, further comprising the steps of: receiving, from at least one node, a corresponding node signature associated with a public key of the node; verifying the node signature; And determining whether to request the node to participate in threshold secret sharing based on the result of the verification.

8. The method of claim 7, wherein the node signature is further associated with at least one of: (i) a message; (ii) a hash value of the message; (iii) an identifier for identifying the broadcaster; (iv) the location data; and (v) the public key of the node.

9. The method of claim 1, comprising at least one of the following steps: (i) sending a share of an encrypted secret to at least one node; (ii) relaying a function value from at least one node to at least one other node, the function value being encrypted with a public key of the corresponding at least one other node; (iii) receiving respective portions of an intermediate encrypted value from the plurality of nodes, combining the portions into the intermediate encrypted value, and sending the intermediate encrypted value to at least one further node; (iv) receiving respective portions of the cryptographic signature from the plurality of nodes and combining the portions into components of the cryptographic signature; and (v) redeeming the blockchain transaction by providing the cryptographic signature to the blockchain transaction.

10. A computer-implemented method, the computer-implemented method comprising the following steps: At a node, receiving a signal from a broadcaster, the signal including a request for location data; determining a distance attribute associated with the request; as a result of receiving the signal and determining that the broadcaster is within a predetermined distance of the node, transmitting, from the node, the location data, the location data including the distance attribute and a plurality of public keys corresponding to a respective plurality of regions adjacent to the node; receiving a request to participate in threshold secret sharing to provide a cryptographic signature associated with a common public key; and collaborating with a plurality of nodes in threshold secret sharing to obtain the cryptographic signature; wherein the common public key is the public key shared by the set of nodes and is selected based on the location data; The nodes have corresponding multiple private key shares corresponding to the multiple public keys, and the encrypted signature is obtained by a threshold number of the private key shares of the multiple nodes.

11. The method of claim 10, further comprising the step of determining another distance attribute.

12. The method of claim 10, wherein the step of determining a distance attribute comprises a time of flight measurement; and / or wherein the step of receiving a request for location data comprises receiving an identifier identifying a broadcaster of the request.

13. The method of claim 10, wherein the step of receiving a request to participate in threshold secret sharing to obtain an encrypted signature associated with a common public key comprises receiving data to be signed.

14. The method of claim 13, wherein the data to be signed comprises at least one of: (i) a message; (ii) a hash value of the message; and (iii) an identifier for identifying the broadcaster.

15. The method of claim 10, wherein the step of sending location data further comprises sending a node public key.

16. The method of claim 10, further comprising the step of sending a node signature associated with at least a node public key to the broadcaster.

17. A method according to claim 16, wherein the node signature is also associated with at least one of the following: (i) a message; (ii) a hash value of the message; (iii) an identifier for identifying the broadcaster; (iv) the location data; and (v) the node public key.

18. The method according to claim 10 further includes at least one of the following steps: (i) sending a share of the encrypted secret to the broadcaster; (ii) sending at least one function value calculated based on a corresponding value associated with at least one node to the broadcaster; (iii) sending a portion of an intermediate encrypted value to the broadcaster and receiving the intermediate encrypted value; (iv) sending a portion of the encrypted signature to the broadcaster; and (v) receiving another location data associated with multiple nodes from the broadcaster, performing a trilateral measurement calculation to determine the calculated location of the broadcaster, comparing the calculated location with at least the location data, and determining whether to participate in the threshold secret sharing based on the result of the comparison.

19. A computer-implemented system comprising: processor; as well as A memory comprising executable instructions, wherein when the processor executes the executable instructions, the system is caused to perform the computer-implemented method according to any one of claims 1 to 18.

20. A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein when a processor of a computer system executes the executable instructions, the computer system is caused to at least perform the method according to any one of claims 1 to 18.

Images