Abstract: Blockchain environments may mix-and-match different encryption, difficulty, and/or proof-of-work schemes when mining blockchain transactions. Each encryption, difficulty, and/or proof-of-work scheme may be separate, stand-alone programs, files, or third-party services. Blockchain miners may be agnostic to a particular coin's or network's encryption, difficulty, and/or proof-of-work schemes, thus allowing any blockchain miner to process or mine data in multiple blockchains. GPUs, ASICs, and other specialized processing hardware components may be deterred by forcing cache misses, cache latencies, and processor stalls. Hashing, difficulty, and/or proof-of-work schemes require less programming code, consume less storage space/usage in bytes, and execute faster. Blockchain mining schemes may further randomize byte or memory block access, further improve cryptographic security.

Abstract: Blockchain environments may mix-and-match different encryption, difficulty, and/or proof-of-work schemes when mining blockchain transactions. Each encryption, difficulty, and/or proof-of-work scheme may be separate, stand-alone programs, files, or third-party services. Blockchain miners may be agnostic to a particular coin's or network's encryption, difficulty, and/or proof-of-work schemes, thus allowing any blockchain miner to process or mine data in multiple blockchains. GPUs, ASICs, and other specialized processing hardware components may be deterred by forcing cache misses, cache latencies, and processor stalls. Hashing, difficulty, and/or proof-of-work schemes require less programming code, consume less storage space/usage in bytes, and execute faster. Blockchain mining schemes may further randomize byte or memory block access, further improve cryptographic security.

Abstract: Hardware and software resources are load balanced when processing multiple blockchains. As more and more entities (whether public or private) are expected to generate their own blockchains for verification, a server or other resource in a blockchain environment may be over utilized. For example, as banks, websites, and retailers issue their own private cryptocoinage, the number of financial transactions may clog or hog networking and/or hardware resources. A blockchain load balancing mechanism thus allocates resources among the multiple blockchains.

Abstract: Authentication of electronic document is based on multiple digital signatures incorporated into a blockchain. Structured data, metadata, and instructions may be hashed to generate the multiple digital signatures for distribution via the blockchain. Any peer receiving the blockchain may then verify an authenticity of an electronic document based on any one or more of the multiple digital signatures incorporated into the blockchain.

Abstract: Blockchain environments may mix-and-match different encryption, difficulty, and/or proof-of-work schemes when mining blockchain transactions. Each encryption, difficulty, and/or proof-of-work scheme may be separate, stand-alone programs, files, or third-party services. Blockchain miners may be agnostic to a particular coin's or network's encryption, difficulty, and/or proof-of-work schemes, thus allowing any blockchain miner to process or mine data in multiple blockchains. GPUs, ASICs, and other specialized processing hardware components may be deterred by forcing cache misses, cache latencies, and processor stalls. Hashing, difficulty, and/or proof-of-work schemes require less programming code, consume less storage space/usage in bytes, and execute faster. Blockchain mining schemes may further randomize byte or memory block access, further improve cryptographic security.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a table identifier in a blockchain. Because there may be many digital contracts offered as virtual services, the table identifier uniquely identifies a particular decision table and/or the digital contract offered by a virtual machine, vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the decision table and/or the digital contract. The blockchain need only include or specify the table identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a blockchain. Because there may be many digital contracts offered as virtual services, the contract identifier uniquely identifies a particular decision table and/or the digital contract offered by a virtual machine, vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the decision table and/or the digital contract. The blockchain need only include or specify the contract identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.

Abstract: Blockchain environments may mix-and-match different encryption, difficulty, and/or proof-of-work schemes when mining blockchain transactions. Each encryption, difficulty, and/or proof-of-work scheme may be separate, stand-alone programs, files, or third-party services. Blockchain miners may be agnostic to a particular coin's or network's encryption, difficulty, and/or proof-of-work schemes, thus allowing any blockchain miner to process or mine data in multiple blockchains. GPUs, ASICs, and other specialized processing hardware components may be deterred by forcing cache misses, cache latencies, and processor stalls. Hashing, difficulty, and/or proof-of-work schemes require less programming code, consume less storage space/usage in bytes, and execute faster. Blockchain mining schemes may further randomize byte or memory block access, further improve cryptographic security.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a contract identifier in a blockchain. Because there may be many digital contracts offered as virtual services, the contract identifier uniquely identifies a particular digital contract offered by a virtual machine, vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the digital contract. The blockchain need only include or specify the contract identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a contract identifier in a blockchain. Because there may be many digital contracts offered as virtual services, the contract identifier uniquely identifies a particular digital contract offered by a virtual machine, vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the digital contract. The blockchain need only include or specify the contract identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.

Abstract: Some embodiments described herein relate to a computer implemented method that includes performing a first work step associated with a first activity and with a first data product and performing a second work step associated with a second activity and associated with a second data product. A first chain of trust between the first work step and the second work step can be defined by defining a second manifest document that is associated with the second data product and that references a first manifest document associated with the first data product. An immutable data structure representing a second chain of trust independent of the first chain of trust can be defined by submitting the first manifest document and the second manifest document to a distributed ledger for validation.

Abstract: A personal blockchain is generated as a cloud-based software service in a blockchain environment. The personal blockchain immutably archives usage of any device, perhaps as requested by a user. However, some of the usage may be authorized for public disclosure, while other usage may be designated as private and restricted from public disclosure. The public disclosure may permit public ledgering by still other blockchains, thus providing two-way public/private ledgering for improved record keeping. Private usage, though, may only be documented by the personal blockchain.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a contract identifier in a blockchain. Because there may be many digital contracts offered as virtual services, the contract identifier uniquely identifies a particular digital contract offered by a virtual machine, vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the digital contract. The blockchain need only include or specify the contract identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.

Abstract: A federated-data-room server manages information about a collection of electronic documents residing elsewhere (under different organizational/customer control). The server can anchor documents to a blockchain, record usage history of each document, and provide access to the documents for authorized users. As a result, the federated-data-room server operates on customers' data, while leaving the data in control of the customers. At the same time, the federated-data-room server provides data access and enables traceability via blockchain recordation of document identifiers and document hash values.

Abstract: A personal blockchain is generated as a cloud-based software service in a blockchain environment. The personal blockchain immutably archives usage of any device, perhaps as requested by a user. However, some of the usage may be authorized for public disclosure, while other usage may be designated as private and restricted from public disclosure. The public disclosure may permit public ledgering by still other blockchains, thus providing two-way public/private ledgering for improved record keeping. Private usage, though, may only be documented by the personal blockchain.

Abstract: Auditing of mortgage documents is faster and simpler. An electronic mortgage application often contains or references a collection of many separate electronic mortgage documents. Electronic data representing an original version of an electronic mortgage document and its current version may be hashed to generate digital signatures. Any auditor may then quickly compare the digital signatures. If the digital signatures match, then the audit reveals that the electronic mortgage document has not changed since its creation. However, if the digital signatures do not match, then the electronic mortgage document has changed since its creation. The auditor may thus flag the electronic mortgage document for additional auditing processes.

Abstract: Hardware and software resources are load balanced when processing multiple blockchains. As more and more entities (whether public or private) are expected to generate their own blockchains for verification, a server or other resource in a blockchain environment may be over utilized. For example, as banks, websites, and retailers issue their own private cryptocoinage, the number of financial transactions may clog or hog networking and/or hardware resources. A blockchain load balancing mechanism thus allocates resources among the multiple blockchains.

Abstract: A blockchain system organized around digital identities and their accounts. Each account is treated as an independent blockchain and managed as a continuously growing Stateful Merkle Tree, while the blocks are treated as temporal synchronization points for all the chains in the system. Indexing of transactions in each block allows the system to operate at more than one synchronization level (frequency).

Abstract: A blockchain system has an identity-based blockchain account including a primary chain, a secondary chain, and at least one key book applying to the account, the at least one key book having a key page. The system includes: a hardware processor; and a memory device storing instructions. When the instructions are executed by the processor, they cause the processor to: record a multi-signature transaction originating from the account in the secondary chain: associate the transaction with the key page of the at least one key book, the key page including (i) a signature-authorization rule, and (ii) a plurality of keys corresponding to a plurality of transaction authorizers; record, in the secondary chain, an authorization of the transaction from a transaction authorizer of the plurality of transaction authorizers; and once a number of authorizations recorded on the secondary chain satisfies the signature-authorization rule, record the transaction on the primary chain for execution.

Abstract: Digital or “smart” contracts execute in a blockchain environment. Any entity (whether public or private) may specify a digital contract via a contract identifier in a blockchain. Because there may be many digital contracts offered as services, the contract identifier uniquely identifies a particular digital contract offered by a vendor or supplier. The blockchain is thus not burdened with the programming code that is required to execute the digital contract. The blockchain need only include or specify the contract identifier (and perhaps one or more contractual parameters), thus greatly simplifying the blockchain and reducing its size (in bytes) and processing requirements.