US11836720B2 - Infinitely scalable cryptocurrency system with fast, secure verification - Google Patents
Infinitely scalable cryptocurrency system with fast, secure verification Download PDFInfo
- Publication number
- US11836720B2 US11836720B2 US15/917,855 US201815917855A US11836720B2 US 11836720 B2 US11836720 B2 US 11836720B2 US 201815917855 A US201815917855 A US 201815917855A US 11836720 B2 US11836720 B2 US 11836720B2
- Authority
- US
- United States
- Prior art keywords
- blockchain
- sub
- block
- blockchains
- hash
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
- 238000012795 verification Methods 0.000 title description 3
- GNFTZDOKVXKIBK-UHFFFAOYSA-N 3-(2-methoxyethoxy)benzohydrazide Chemical compound COCCOC1=CC=CC(C(=O)NN)=C1 GNFTZDOKVXKIBK-UHFFFAOYSA-N 0.000 claims 2
- 238000000034 method Methods 0.000 abstract description 20
- 230000008859 change Effects 0.000 abstract description 6
- 235000008694 Humulus lupulus Nutrition 0.000 abstract description 5
- 230000005540 biological transmission Effects 0.000 abstract description 3
- 238000012546 transfer Methods 0.000 description 10
- 238000010200 validation analysis Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 9
- 238000012790 confirmation Methods 0.000 description 8
- 238000005065 mining Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 5
- 230000003466 anti-cipated effect Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000002860 competitive effect Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 206010016275 Fear Diseases 0.000 description 2
- 230000000052 comparative effect Effects 0.000 description 2
- 230000005611 electricity Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000000306 recurrent effect Effects 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 241000239290 Araneae Species 0.000 description 1
- ODCKICSDIPVTRM-UHFFFAOYSA-N [4-[2-hydroxy-3-(propan-2-ylazaniumyl)propoxy]naphthalen-1-yl] sulfate Chemical compound C1=CC=C2C(OCC(O)CNC(C)C)=CC=C(OS(O)(=O)=O)C2=C1 ODCKICSDIPVTRM-UHFFFAOYSA-N 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001902 propagating effect Effects 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- the first problem is scaling.
- Bitcoin the most established cryptocurrency system, and the one on which the specific numeric examples of problems below is based, is only capable of handling about 10 transactions per second.
- VISA can handle 10,000 transactions per second or more. If a cryptocurrency were to ever hope of rising to the level of useful global adoption of something like VISA, throughput and rate of ledger creation roughly 3 orders of magnitude higher would have to be achieved.
- the second problem related to the first, is the fact that to rigorously verify the validity of a claim of Bitcoin ownership, the entire blockchain must be traced, searched and compiled literally back to day and block one of the blockchain ledger. This data structure is currently in excess of 100 gigabytes, and already on the verge of being intractable. We will call this the “database size problem.”
- All cryptocurrencies are based on some implementation of a one way digital hashing function. It is a called a one way function because it is relatively easy to compute the output from the input, but as a practical matter it is impossible to compute the input from the output. Nor is it possible to predict the effect on the output of even a small change in the input, such as to control the output result.
- the process will start with the generation of a pair of digital keys, one private and one public. A particular message is then signed with the private key. Using the public key it can be proven that the message was signed with the private key.
- Hashes are also used in blockchain systems to make their sequential block ledgers immutable.
- a hash is computed of all the data in the previous block, including candidate transactions to be verified and committed to the running sequential ledger, and this hash is incorporated into the next block. But since no change can be made in a previous block without changing that hash in an unpredictable way, this could not be made to match the previous block hash value incorporated into the next block, and the ledger record of all transactions is considered immutable, usually by presuming that enough hashing power to recompute a series of blocks is not controlled by one entity.
- FIG. 1 is a schematic representation of a multilevel tree hierarchy of blockchains architecture according to the system of this invention.
- FIG. 2 is a flow chart illustrating the process for initiating a new blockchain.
- FIG. 3 is a flow chart illustrating the process for submitting and verifying a transaction.
- FIG. 4 is a breakout diagram of the segmenting in a representative nested propagation peer-to-peer network with a dividing number of 10 to accommodate 1,000 nodes.
- FIG. 5 is a flow chart illustrating the handling of messages by client nodes according to the hop count of the message in a representative 3 hop system.
- this disclosure teaches the creation of a multilevel tree hierarchy of blockchains. Under this novel system architecture we will first determine an optimum block size. Genesis of the first blockchain can initiate and proceed in the conventional manner, which we will call the top blockchain. But at any point that there are more transactions than would be optimum for a current blockchain, which we will call the “first limiting parameter,” based either on a target maximum block size or the number of accounts participating on the blockchain, a new sub-blockchain in a set of additional blockchains is initiated by the system, and a sub-ledger of a new series of transactions is kept there.
- “set” is defined as a non-negative whole number of blockchains, which before the first additional blockchain is initiated has a set size of zero, an empty set.
- the first sub-blockchain has more transactions to record than can be accommodated by the optimum block size
- another sub-blockchain is initiated in the same way.
- sub-sub-blockchains can be initiated in a like manner, and so on. In this way the set of additional blockchains can be thought of as being divided into successive sub-levels.
- a preferred embodiment would be to make it easy to identify where amidst these branched levels a particular local blockchain is positioned. Since digital data is conveniently represented in hexadecimal format, an optimum number of sub-blockchains to have directly under a blockchain above it in the tree hierarchy might be 15, the second limiting parameter in this case. Any other number could be used. But using the number 15 as our optimum branching parameter, this would provide for that many sub-blockchains one level below the top blockchain (sub-level 1), 225 sub-sub-blockchains two levels below the top blockchain (sub-level 2), and 3375 sub-sub-sub-blockchains three levels below the top blockchain (sub-level 3), for a total of as many as 3616 total blockchains using 3 sub-levels for this embodiment.
- each blockchain in a sub-level can be considered to be capable of having its own further sub-level under itself, and it is not strictly necessary to fill up all further sub-levels below the blockchains at one sub-level before one of the blockchains at one of the further sub-levels branches its own yet further sub-level. But in the most preferred embodiment all blockchains at one sub-level will fully branch before a “lower” sub-level in the set of all additional blockchains starts to populate.
- the system can maintain a sequence number of the last blockchain created (as distinguished from the sequence number of a block in a particular blockchain), and initiate a new one when required by a surplus of transactions to be logged, or by the adding of new accounts, based on an optimum number of participant devices on each blockchain. Note that in this case as the sequence numbers of the blockchains go up as we go to “lower” sub-levels.
- szTxn is the size of a single transaction record
- szTxnLdgr is the size of the transaction ledger section of a blockchain block
- actTxnRatio which we will derive empirically by algorithm 4, further below, is the average chance with respect to a particular block, derived from the experience of the network watching itself, of an average account needing to do a transaction that will change its balance or effect some other transaction of the blockchain associated with the client account.
- blckAcctsLimit (szTxnLdgr/szTxn)/actTxnRatio algorithm 1:
- a blockchain will split off a certain number of accounts for the new blockchain to start with, 201 , 202 , 203 . Doing this while the devices for moved accounts are online can provide that they can update their own blockchain associations. And as long as the public key associated with a particular client account is unique throughout the system, that account can always be found.
- each blockchain creates a new block every 10 minutes, which is the current target in the Bitcoin system. And let us also presume a top blockchain and 3 levels of sub-blockchains beneath it. In each case, the individual blockchains pass their last hash forward to the next block in their own blockchain for inclusion in it, in the previously known manner.
- FIG. 1 An algorithm for a process flow using these parameters is illustrated in FIG. 1 , where the numbers in the brackets represent the possible range of the hexadecimal sequence numbers, slightly discontinuous below sub-level 1, of the individual blockchains in a particular sub-level. It is convenient to interpret the least significant digit of a sequence number here as the horizontal position of a blockchain in a sub-level, with the remainder, after being right shifted one digit, being the sequence number of the blockchain it is directly under.
- the lowest level of blockchains do their next block validation at the 21 ⁇ 2 minute mark on a shared timeline.
- 103 and 104 represent the first and last blockchain in one of the lowest level sets of 15.
- the hashes of each of these blocks are shared with the blockchain one level above, 110 , up to 15 hashes in the example we have been discussing, and 109 for another one of lowest level sets of 15.
- “Sub Hash” in a block in FIG. 1 is a list array of the hashes being passed in this way to that block.
- each blockchain at the next blockchain level up do their next block in the chain hashes, including in these hashes the up to 15 hashes from the most recent round of hashes received from the blockchains one level below each of them.
- 105 and 106 represent the first and last blockchains in a set of 15 at this next level above
- 111 are each of these blockchains passing up their hashes up to the blockchains at the next level above themselves
- 112 is the same action for another one of the sets of 15 at the same level as 105 and 106 .
- each of the blockchains that are positioned one level below the top blockchain likewise do their next block in the blockchain hashes, including in this hash the up to 15 hashes from the blockchains below each of them, transmitting their own hashes to the top blockchain.
- 107 and 108 represent the first and last blockchains in the set of 15 one level below the top blockchain
- 113 is the action of each of these blockchains passing their latest hash up to the next block of the top blockchain
- 114 is the same action from the previous round.
- the top blockchain does its own next block in the blockchain hash, including the hash of the previous block, 101 , in its own blockchain in the new block, 102 , and including in just the same way as above the up to 15 hashes from the level of blockchains below it, as just mentioned.
- the top blockchain also sends its own signature hash, from block 102 , to each of the blockchains on the lowest level to be included in their next hash, via 116 , creating a recurrent circularity. And then the cycle of our sample preferred embodiment repeats. 115 represents this same hash pass down from the previous round.
- this system also strengthens the surety of the validation of the blocks via this inter-blockchain communication. So for example, the clients in the next local blockchain in the circular sequence can send a message to clients in the previous blockchain to inquire about what the consensus is about their latest validated block, and to return back the hash of that block. Once memorialized in the next block in the next blockchain at another level, this can then be relied on by the previous blockchain as immutable.
- Alice's account balance is then recomputed on her own associated blockchain, to be written as a data entry in the next block created on that blockchain, and it can be credited to Bob there if he is associated with the same blockchain, or a payment message can be exchanged with his own local blockchain, to be credited to his account address, acntAddr, in the next block in the cycle of that blockchain, 310 .
- Bob can get fast validation by getting a consensus of the nodes in Alice's blockchain, 306 . Otherwise, Bob can cancel his claim to the transaction, 307 .
- the signature of a transaction can incorporate into its hash to be signed the hash of, or other number from, a previous block in the blockchain, most optimally the last block in the blockchain. This would make it impossible for an attacker to tamper with any block in the blockchain in the future, for to do so would require faking the signature of every transaction in that block, where the attacker only knows the private key for generating his own.
- sigTxn is the signature of the transaction
- txnData is the transaction data
- prevBlckData is the number derived from the previous block
- sign( ) is a function to sign a number with an account's private key
- H( ) is a hash function to combine multiple inputs into one output of set length, which in one preferred embodiment might be 256 bits.
- sigTxn sign( H (prevBlckData,txnData)) algorithm 3:
- acntTxnRatio is the total number of accounts associated with the local blockchain
- numAcntChanges is the sum, over each such account, of the total number of blocks within the refresh period where the account balance was changed, with a minimum of one per account, to account for mandatory account balance roll forward
- blckInterval is the time between each new block validation in the local blockchain (10 minutes in our example above).
- acntTxnRatio (numAcntChanges/numAcntsBlock)/(rfshPeriod/blckInterval); algorithm 4:
- the bulk of one's cryptowealth could be associated with a device that is never connected online except to initiate an account.
- An individual could then generate a signed transaction from that device, and put it into the network from another device that is online, a payment self-transfer.
- This can also be done by having the offline device write a signed message to a transfer media, which can then be read by a device that is online, or the offline device can be constructed so that it can write to the online device but not be read by it.
- each active client device on the local blockchain broadcasts a message to the blockchain, including its public key on the blockchain, acntPubKey, a hash of, or other number from, the previous block in the local blockchain, prevBlckData, a second hash of that data together with their public key, plus a signature of that second hash, sigLottryMsg.
- sigLottryMsg sign( H (prevBlckData,acntPubKey)) algorithm 6:
- this agreed on time period starts just after a new block is validated, at which time its hash is first known, if that is the prevBlckData to be used, and ends at a receive cutoff time, shortly before the next block in the local blockchain is due to be validated.
- the lottery will be what we will call “autonomous,” defined as being able to be conducted collectively by whatever devices are active on the local blockchain, without an outside or central coordinator or administrator.
- the receive cutoff time after which no more proof of connectivity messages can be sent for that cycle, need only be a short period of elapsed time before the time for the next block to be validated, only long enough to sufficiently allow time for all such messages to propagate throughout the local blockchain network, after which any subsequent such messages are considered non-operative.
- the signature of the proof of connectivity message further proves the identity of the device. And we further note that any device trying to back alter any block would have to demonstrate it was a plausible candidate to have generated such a lottery message signature, or other unpredictable hash, that would have won such a proof of connectivity lottery, by the competitive criteria we have established. That is, its private key would have to be able to generate an extremely low number, if that was the comparative competitive method, when hashed by a function including a hash, or some other specified variable data, from the previous block.
- Participation in the proof of connectivity lottery also tends to ensure that the winner of the lottery is online and available to do the validation of the next block. If, however, that device fails to do so, after a short latency period the runner up in the lottery online can attempt to do so.
- whatever block is received by a client device as validated by the client device with the best number in the proof of connectivity lottery, by the exemplary comparative protocol we have been discussing, is considered the operating next block with no ambiguity.
- the block can be signed by the validating device, or its public key can be included in the data hashed, to create an additional back reference that can be checked by the next block.
- each transaction in the new block be hashed with the signature of the previous block, or some other specified number in that block, and then signed again by the device authorizing the transaction, again by algorithm 5.
- This combination of features will alone make even the top blockchain as immutable as any proof of work blockchain protocol. But we have already discussed how immutability up the blockchain hierarchy is enforced by incorporating the hashes of the blockchains one level below into the hashchain of the blockchain above, and having the top blockchain circle its hash back down to the lowest level.
- each device can opt in to make available its computing power for an external application, and further opt to limit the percentage of its available computing power to be so provided.
- This collective computing power than can then be sold, and participant devices can be periodically rewarded with new cryptocurrency created in their accounts, and that collective computing power can be sold for either the same cryptocurrency or exchanged for other currencies.
- This also acts as an additional incentive for individuals to leave their devices active, to be available for participating in the next block validation lottery, and to help administrate the operational overhead of the system. Selling this collective computing power for the cryptocurrency itself would tend to give our cryptocurrency an intrinsic value.
- devReward a credit in our same cryptocurrency to be periodically added to the balance of a device's account, according to the following algorithm 7, where devWork is the amount of computing work done by the device, totWork is the total work required by the computing job, and totReward is the compensation to the network in our cryptocurrency for completing the computing job.
- devReward totReward ⁇ (devWork/totWork) algorithm 7:
- a file to be stored can be divided into segments with enough redundancy so that the original data can be recreated intact from a sufficient number of pieces, providing for devices that might drop offline or fail.
- each client on the network must synchronize with an agreed global UTC time source when it first connects to the network.
- it must resynchronize on a regular periodic basis from that time point on, which might be a space of 24 hours.
- a client device For full participation to send and receive all messages in the local blockchain a client device must have participated in the previous proof of connectivity lottery, but it could still send a message, for example to authorize or verify a transaction, by sending a message to the local blockchain, asking to connect to devices already on the active ordered register, as we will further discuss shortly below.
- this active register will not only be ordered according to some competitive criteria, it will be of definite length and membership composition. That is, each node in the local blockchain will have the same working ordered register of currently active nodes to work from. In one embodiment this is achieved by requiring that proof of connectivity messages arrive within the message propagation time window, measured from an agreed lottery message sending cutoff time, sndLottryCutoff, for participating in the current lottery.
- each of those 10 primary clients will be obligated to repeat the process one segment level down. Since each primary client has the same ordered register which it will divide up in the same way, and since each of these primary clients already knows what first segment it lies in, it then connects to and forwards our message, incrementing the hop number, to one random secondary client in each of the 2 nd level segments, including its own, of that same 1st level segment, and remains connected. If it can't reach any of those clients it selects another.
- each secondary client On receiving our forwarded message, each secondary client, already knowing what 2nd level segment it resides in, completes the transmission process, by forwarding our message to each of the other clients nodes in that 2nd level segment, again incrementing the hop number. Each of these ultimate clients is obligated to confirm back to the secondary client that it has received the message. So the result options might be “could not reach,” “invalid” or “confirm.”
- each secondary client sends a message back to each primary client to confirm that it has delivered the messages to each of the clients in its own 2nd level segment.
- This confirmation can be signed by the each node below, and that signature can be passed through to the node above, to prove that the node has transmitted the message to the nodes below. Nodes that are not properly passing back confirmations can be flagged and discredited in the network.
- a primary client does not receive this confirmation message, or cannot connect to that secondary client at all, it selects another secondary client in the respective 2nd level segment, and sends the same message to that client, until it gets back a completion confirmation. If that other secondary client has already received the message, it will know from the hop number count it is obligated to act as a secondary client itself.
- the originating sender of the message will be looking for each primary client to confirm back that it has confirmation from all of its own secondary clients, otherwise it selects a different primary client from that 1st level segment at random, and sends the message again. Even if that particular client has received the message itself from another primary or secondary client, it will know from the hop number count that it is obligated to act as a client itself respective to the hop count in the same manner as above.
- a client node receives a message, 501 , it checks the hop count in the message, 502 . If the hop count is 1 it acts as a primary client, 503 , and forwards the message to random secondary clients in each 2nd level segment of its own 1st level segment, incrementing the hop count in the message, 504 . If the hop count is 2, it forwards the message to the other nodes in its own 2nd level segment, again incrementing the hop count. 505 , 506 . The nodes receiving this message with a hop count of 3 do not forward the message further in this embodiment.
- a hash of this ordered register can be published in the new block by the block validator. From this all nodes can affirm they are working off the same ordered register for that cycle, otherwise they can inquire from other nodes to fetch it.
- Additional hops might be provided for if required to extend to additional levels, at a small cost in additional propagation time. For such an example, 4 hops with a dividing number of 10 would reach 10,000 nodes in the same manner as above.
- each active device keeps a log of transactions pending to be incorporated into the next block.
- Alice wants to authorize a transaction with Bob, she signs a transaction for it, again referring to FIG. 3 , 301 . This can be sent directly by Alice to her own local blockchain, or sent to Bob for him to do this. If Bob does this, and Bob's client device is on a different blockchain, Bob then fetches a selection of primary clients for Alice's local blockchain and transmits the transaction to them, 303 . The message representing this transaction quickly traverses the local blockchain by our nested propagation method.
- each client node on Alice's blockchain attempts to verify the transaction, that Alice has enough account balance to cover the transaction in the case of a payment, including all previous transactions of Alice that the node has heard of, that the signature is valid, and passes a verification message back up the nested propagation network If Bob sent the message, he can thereby get a consensus of the active devices on the local blockchain as to whether Alice is good for the transaction, 306 , and by the nested propagation network this can happen as quickly as VISA currently authorizes transactions now.
- Alice attempts to double spend over the amount of her account balance by initiating two transactions at the same time, some proportion of the client nodes will report back that the transaction is no good, and Bob can respond accordingly, by rejecting the transaction. If Alice tried to double spend by sending two simultaneous cryptocurrency payment messages to different primary clients at the same time, at least some of the clients in the nested propagation network would invalidate it if her account balance was insufficient to cover both. In another preferred embodiment Bob can send an additional message back to the local blockchain canceling his claim on the transaction, again illustrated by FIG. 3 , 307 .
- any other transaction can be memorialized by the local blockchain.
- the contract can be recorded in both.
- the client software is signed with the private key of a developer entity.
- the developer entity can distribute the updated client through the network with an “activate on” time parameter associated with it. This can be validated by clients on the network from the signature as any other hash message, and installed and implemented at the appointed time. A modest hiatus in network activity at a relatively low usage time might be provided for to ease the transition.
- each message in the system can additionally carry the operating software version number being used. After the passage of the implementation time of the updated software, if a client running an older version tries to send a message to a client running the latest update, if the update is critical the message will not be acted on, but in any case a message is returned to that the first client that they must update.
- first limiting parameter and the second limiting parameter we set to numbers so high that they would never be reached, such that the system remained a single blockchain, either of the two innovations of 1) having the validator of each new block sign that block with their private key, or 2) having each transaction include in a hash of that transaction a number from a previous block, would alone produce a vast improvement in the immutability of that single blockchain.
Abstract
Description
blckAcctsLimit=(szTxnLdgr/szTxn)/actTxnRatio algorithm 1:
acntAddr=numBlckChain.“:”.acntPubKey algorithm 2:
sigTxn=sign(H(prevBlckData,txnData)) algorithm 3:
acntTxnRatio=(numAcntChanges/numAcntsBlock)/(rfshPeriod/blckInterval); algorithm 4:
sigTransaction=sign(II(prevBlckData,transData)) algorithm 5:
sigLottryMsg=sign(H(prevBlckData,acntPubKey)) algorithm 6:
devReward=totReward×(devWork/totWork) algorithm 7:
rcvLottryCutoff=sndLottryCuttoff+maxPropTime algorithm 8:
Claims (3)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/917,855 US11836720B2 (en) | 2018-03-12 | 2018-03-12 | Infinitely scalable cryptocurrency system with fast, secure verification |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/917,855 US11836720B2 (en) | 2018-03-12 | 2018-03-12 | Infinitely scalable cryptocurrency system with fast, secure verification |
Publications (2)
Publication Number | Publication Date |
---|---|
US20190279210A1 US20190279210A1 (en) | 2019-09-12 |
US11836720B2 true US11836720B2 (en) | 2023-12-05 |
Family
ID=67842648
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/917,855 Active 2039-05-11 US11836720B2 (en) | 2018-03-12 | 2018-03-12 | Infinitely scalable cryptocurrency system with fast, secure verification |
Country Status (1)
Country | Link |
---|---|
US (1) | US11836720B2 (en) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110311883B (en) * | 2018-03-27 | 2020-11-10 | 华为技术有限公司 | Identity management method, device, communication network and storage medium |
US10855448B2 (en) * | 2018-05-03 | 2020-12-01 | Honeywell International Inc. | Apparatus and method for using blockchains to establish trust between nodes in industrial control systems or other systems |
US11184171B2 (en) | 2018-05-24 | 2021-11-23 | Walmart Apollo, Llc | System and methods for multi-variant tracking |
US11122052B2 (en) * | 2018-05-30 | 2021-09-14 | International Business Machines Corporation | Sensitive information accessibility in blockchain |
US11836721B2 (en) * | 2018-06-29 | 2023-12-05 | Intel Corporation | Protection of information in an information exchange |
US11070360B2 (en) * | 2018-08-13 | 2021-07-20 | International Business Machines Corporation | Parallel transaction validation and block generation in a blockchain |
US10868667B2 (en) * | 2018-11-06 | 2020-12-15 | GM Global Technology Operations LLC | Blockchain enhanced V2X communication system and method |
US10928848B2 (en) * | 2018-11-28 | 2021-02-23 | International Business Machines Corporation | Distributed clock |
US11469881B2 (en) * | 2018-12-26 | 2022-10-11 | Korea Institute Of Science And Technology | Apparatus and method for forgery prevention of digital information |
US11177962B2 (en) * | 2019-02-05 | 2021-11-16 | Visa International Service Association | Optimizations for verification of interactions system and method |
US20220224534A1 (en) * | 2019-05-16 | 2022-07-14 | nChain Holdings Limited | Systems and methods for mining on a proof-of-work blockchain network |
US11165582B2 (en) * | 2019-05-20 | 2021-11-02 | Chia Network Inc. | Consensus layer architecture for maintaining security with reduced processing power dependency in untrusted decentralized computing platforms |
US11621973B2 (en) * | 2019-07-03 | 2023-04-04 | Battelle Memorial Institute | Blockchain cybersecurity audit platform |
KR20210041404A (en) * | 2019-10-07 | 2021-04-15 | 삼성전자주식회사 | Electronic device and method for blockchain address management thereof |
US11468044B2 (en) | 2019-11-25 | 2022-10-11 | Visa International Service Association | Optimizations for verification of interactions system and method using probability density functions |
US11522670B2 (en) | 2019-12-04 | 2022-12-06 | MaataData, Inc. | Pyramid construct with trusted score validation |
CN110943869B (en) * | 2019-12-16 | 2022-03-04 | 杭州复杂美科技有限公司 | Block consensus and broadcast method, equipment and storage medium |
US11381401B2 (en) | 2020-01-07 | 2022-07-05 | Seagate Technology Llc | Blockchain transaction forwarding |
US20230141331A1 (en) * | 2020-07-29 | 2023-05-11 | Dicella Sp. Z O.O. | A method and a system for securing data, especially data of biotechnological laboratories |
CN112541763A (en) * | 2020-12-11 | 2021-03-23 | 军工保密资格审查认证中心 | Block consensus approval method and device for block chain manager |
WO2024035849A1 (en) * | 2022-08-11 | 2024-02-15 | The Regents Of The University Of Colorado, A Body Corporate | Time-ordered cryptographic ledgers |
Citations (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160330034A1 (en) | 2015-05-07 | 2016-11-10 | Blockstream Corporation | Transferring ledger assets between blockchains via pegged sidechains |
US20160342977A1 (en) | 2015-05-20 | 2016-11-24 | Vennd.io Pty Ltd | Device, method and system for virtual asset transactions |
US20170046689A1 (en) * | 2015-07-14 | 2017-02-16 | Fmr Llc | Crypto Voting and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems |
US9608829B2 (en) | 2014-07-25 | 2017-03-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
US20170154331A1 (en) | 2015-11-30 | 2017-06-01 | ShapeShift | Systems and methods for improving security in blockchain-asset exchange |
US20170257358A1 (en) | 2016-03-04 | 2017-09-07 | ShoCard, Inc. | Method and System for Authenticated Login Using Static or Dynamic Codes |
US20170323392A1 (en) | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
US20170337534A1 (en) * | 2015-11-06 | 2017-11-23 | Cable Television Laboratories, Inc | Systems and methods for blockchain virtualization and scalability |
US20170344580A1 (en) | 2016-05-27 | 2017-11-30 | Mastercard International Incorporated | Method and system for transferring trust across block chain segments |
US20170366516A1 (en) | 2016-06-16 | 2017-12-21 | The Bank Of New York Mellon | Managing verifiable, cryptographically strong transactions |
US20180025435A1 (en) | 2016-07-22 | 2018-01-25 | Nec Europe Ltd. | Method for secure ledger distribution and computer system using secure distributed ledger technology |
US20180048469A1 (en) | 2016-05-23 | 2018-02-15 | Accenture Global Solutions Limited | Wrapped-up blockchain |
US20180165476A1 (en) * | 2016-12-09 | 2018-06-14 | International Business Machines Corporation | Interlocked blockchains to increase blockchain security |
US20180189333A1 (en) * | 2017-01-03 | 2018-07-05 | International Business Machines Corporation | Limiting blockchain size to optimize performance |
US20190050831A1 (en) * | 2017-08-03 | 2019-02-14 | Liquineq AG | System and method for multi-tiered distributed network transactional database |
US20190066068A1 (en) * | 2017-08-22 | 2019-02-28 | Sap Se | Transaction Platform Providing Unified Interaction with Multiple Heterogeneous Blockchains |
US20190123892A1 (en) * | 2017-10-24 | 2019-04-25 | 0Chain, LLC | Systems and methods of self-forking blockchain protocol |
WO2019081917A1 (en) * | 2017-10-24 | 2019-05-02 | Copa Fin Limited | Data storage and verification |
US20190190697A1 (en) * | 2017-12-20 | 2019-06-20 | International Business Machines Corporation | Blockchain lifecycle management |
US20190190896A1 (en) * | 2017-12-18 | 2019-06-20 | International Business Machines Corporation | Protecting sensitive data in a distributed ledger system using a blockchain channel hierarchy |
WO2019178300A1 (en) * | 2018-03-13 | 2019-09-19 | Blockpoint Systems Inc. | Relational blockchain database |
US20190349733A1 (en) * | 2016-12-30 | 2019-11-14 | Intel Corporation | DECENTRALIZED DATA STORAGE AND PROCESSING FOR IoT DEVICES |
US20200012809A1 (en) * | 2018-07-03 | 2020-01-09 | Tyson York Winarski | Distributed network for storing a redundant array of independent blockchain blocks |
US10541807B1 (en) * | 2019-01-18 | 2020-01-21 | Janssen Pharmaceutica Nv | System and method for healthcare security and interoperability |
-
2018
- 2018-03-12 US US15/917,855 patent/US11836720B2/en active Active
Patent Citations (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9608829B2 (en) | 2014-07-25 | 2017-03-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
US20160330034A1 (en) | 2015-05-07 | 2016-11-10 | Blockstream Corporation | Transferring ledger assets between blockchains via pegged sidechains |
US20160342977A1 (en) | 2015-05-20 | 2016-11-24 | Vennd.io Pty Ltd | Device, method and system for virtual asset transactions |
US20170046689A1 (en) * | 2015-07-14 | 2017-02-16 | Fmr Llc | Crypto Voting and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems |
US20170337534A1 (en) * | 2015-11-06 | 2017-11-23 | Cable Television Laboratories, Inc | Systems and methods for blockchain virtualization and scalability |
US20170154331A1 (en) | 2015-11-30 | 2017-06-01 | ShapeShift | Systems and methods for improving security in blockchain-asset exchange |
US20170257358A1 (en) | 2016-03-04 | 2017-09-07 | ShoCard, Inc. | Method and System for Authenticated Login Using Static or Dynamic Codes |
US20170323392A1 (en) | 2016-05-05 | 2017-11-09 | Lance Kasper | Consensus system for manipulation resistant digital record keeping |
US20180048469A1 (en) | 2016-05-23 | 2018-02-15 | Accenture Global Solutions Limited | Wrapped-up blockchain |
US20170344580A1 (en) | 2016-05-27 | 2017-11-30 | Mastercard International Incorporated | Method and system for transferring trust across block chain segments |
US20170366516A1 (en) | 2016-06-16 | 2017-12-21 | The Bank Of New York Mellon | Managing verifiable, cryptographically strong transactions |
US20180025435A1 (en) | 2016-07-22 | 2018-01-25 | Nec Europe Ltd. | Method for secure ledger distribution and computer system using secure distributed ledger technology |
US20180165476A1 (en) * | 2016-12-09 | 2018-06-14 | International Business Machines Corporation | Interlocked blockchains to increase blockchain security |
US20190349733A1 (en) * | 2016-12-30 | 2019-11-14 | Intel Corporation | DECENTRALIZED DATA STORAGE AND PROCESSING FOR IoT DEVICES |
US20180189333A1 (en) * | 2017-01-03 | 2018-07-05 | International Business Machines Corporation | Limiting blockchain size to optimize performance |
US20190050831A1 (en) * | 2017-08-03 | 2019-02-14 | Liquineq AG | System and method for multi-tiered distributed network transactional database |
US20190066068A1 (en) * | 2017-08-22 | 2019-02-28 | Sap Se | Transaction Platform Providing Unified Interaction with Multiple Heterogeneous Blockchains |
US20190123892A1 (en) * | 2017-10-24 | 2019-04-25 | 0Chain, LLC | Systems and methods of self-forking blockchain protocol |
WO2019081917A1 (en) * | 2017-10-24 | 2019-05-02 | Copa Fin Limited | Data storage and verification |
US20190190896A1 (en) * | 2017-12-18 | 2019-06-20 | International Business Machines Corporation | Protecting sensitive data in a distributed ledger system using a blockchain channel hierarchy |
US20190190697A1 (en) * | 2017-12-20 | 2019-06-20 | International Business Machines Corporation | Blockchain lifecycle management |
WO2019178300A1 (en) * | 2018-03-13 | 2019-09-19 | Blockpoint Systems Inc. | Relational blockchain database |
US20200012809A1 (en) * | 2018-07-03 | 2020-01-09 | Tyson York Winarski | Distributed network for storing a redundant array of independent blockchain blocks |
US10541807B1 (en) * | 2019-01-18 | 2020-01-21 | Janssen Pharmaceutica Nv | System and method for healthcare security and interoperability |
Non-Patent Citations (9)
Title |
---|
Block One (individual author unattributed), EOS.IO Technical White Paper [EDS}, Jun. 26, 2107, https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md. |
Buterin, Vitalik (original author), A Next-Generation Smart Contract and Decentralized Application Platform [ETHEREUM], Dec. 10, 2014 (original publication), https://github.com/ethereum/wiki/wiki/White-Paper (current version). |
Kiayias, Aggellos, et al., Non-Interactive Proofs of Proof-of-Work [CARDANO], Dec. 4, 2017, https://eprint.iacr.org/2017/963.pdf, p. 6, Fig. 1. |
Lamahieu, Colin, RalBlocks: A Feeless Distributed Cryptocurrency Network [NANO]. circa 2014, https://nano.org/en/whitepaper, Fig. 3. |
Mazieres. David, The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus [STELLAR], https://www.stellar.org/papers/stellar-consensus-protocol.pdf, circa 2014, p. 4, Section 3. |
Nakamoto, Satoshi (pseudonym), Bitcoin: A Peer-to-Peer Electronic Cash System [BITCOIN], Oct. 2008, https://bitcoin.org/bitcoin.pdf, p. 3, Section 4. |
neo.org (individual author unattributed), NeoContract White Paper [NEO], 2014-2017, http://docs.neo.org/en-us/sc/white-paper.html, Section 2.3.1. |
Popov, Sergeui, The Tangle [IOTA], Oct. 1, 2017, https://iota.org/IOTA_Whitepaper.pdf, Fig. 3. |
Schwartz, David, et al., The Ripple Protocol Consensus Algorithm [RIPPLE], 2014, https://ripple.com/files/ripple_consensus_whitepaper.pdf, p. 4. |
Also Published As
Publication number | Publication date |
---|---|
US20190279210A1 (en) | 2019-09-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11836720B2 (en) | Infinitely scalable cryptocurrency system with fast, secure verification | |
JP6986519B2 (en) | Distributed transaction propagation and validation system | |
Zaghloul et al. | Bitcoin and blockchain: Security and privacy | |
US11522706B2 (en) | Method and system for publicly verifiable proofs of retrievability in blockchains | |
Chowdhury | Inside blockchain, bitcoin, and cryptocurrencies | |
JP6355168B2 (en) | Block chain generation device, block chain generation method, block chain verification device, block chain verification method and program | |
JP6358658B2 (en) | Block chain generation device, block chain generation method, block chain verification device, block chain verification method and program | |
Vashchuk et al. | Pros and cons of consensus algorithm proof of stake. Difference in the network safety in proof of work and proof of stake | |
Kaur et al. | Scalability in blockchain: Challenges and solutions | |
JP7319961B2 (en) | Computer-implemented systems and methods related to binary blockchains forming a pair of coupled blockchains | |
Alzahrani et al. | A new product anti‐counterfeiting blockchain using a truly decentralized dynamic consensus protocol | |
CN110298641B (en) | Rule updating method and device for block chain, block chain node and network | |
WO2020139190A1 (en) | Hybrid blockchain architecture with computing pool | |
Severeijns | What is blockchain? How is it going to affect Business? | |
WO2022079431A1 (en) | Block reward management in blockchain | |
Boreiri et al. | A novel consensus protocol in blockchain network based on proof of activity protocol and game theory | |
Tran et al. | Blockchain in a nutshell | |
Dixit et al. | An overview of Blockchain technology: Architecture, consensus algorithm, and its challenges | |
Bharimalla et al. | ANN based block chain security threat mechanism | |
Amin et al. | Secured IOTA enabled crypto-platform with discretionary mining capabilities and miner nomination based on first-price sealed bid auction theory | |
Appelbaum | Consensus Mechanisms and Related Issues | |
Yen | The Oracle Problem: Unlocking the Potential of Blockchain | |
Lopp | Bitcoin’s security Model: A deep dive | |
Ruiz-Ogarrio | Mining Incentives In Proof-of-Work Blockchain Protocols | |
Semaan | A novel penalty system to limit profitability of selfish mining |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
STCC | Information on status: application revival |
Free format text: WITHDRAWN ABANDONMENT, AWAITING EXAMINER ACTION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: AWAITING RESPONSE FOR INFORMALITY, FEE DEFICIENCY OR CRF ACTION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: AWAITING TC RESP, ISSUE FEE PAYMENT RECEIVED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |