US20190044725A1 - Method and System for Securing a Blockchain with Proof-of-Transactions - Google Patents

Method and System for Securing a Blockchain with Proof-of-Transactions Download PDF

Info

Publication number
US20190044725A1
US20190044725A1 US16/052,974 US201816052974A US2019044725A1 US 20190044725 A1 US20190044725 A1 US 20190044725A1 US 201816052974 A US201816052974 A US 201816052974A US 2019044725 A1 US2019044725 A1 US 2019044725A1
Authority
US
United States
Prior art keywords
network
blockchain
block
nodes
golden ticket
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.)
Abandoned
Application number
US16/052,974
Other languages
English (en)
Inventor
David Begor Lancashire
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Proclus Technologies Ltd
Original Assignee
Proclus Technologies Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Proclus Technologies Ltd filed Critical Proclus Technologies Ltd
Priority to US16/052,974 priority Critical patent/US20190044725A1/en
Assigned to Proclus Technologies Limited reassignment Proclus Technologies Limited ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LANCASHIRE, DAVID BEGOR
Publication of US20190044725A1 publication Critical patent/US20190044725A1/en
Priority to US16/409,449 priority patent/US10594488B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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
    • 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/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/3825—Use of electronic signatures
    • 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • 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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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
    • H04L2209/38—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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 present disclosure relates, in general, to methods, systems, and apparatuses for implementing blockchain transactions, and, more particularly, to methods, systems, and apparatuses for securing a blockchain with proof-of-transactions.
  • current blockchain functionality is not scalable in terms of maintaining security and decentralization, including maintaining the associated bandwidth and connectivity that the decentralization provides.
  • FIG. 1 is a schematic diagram illustrating a blockchain system that may be secured using proof of transactions, in accordance with various embodiments.
  • FIGS. 2A and 2B are graphical diagrams illustrating cost versus time curves depicting required burn fees compared with total collected fees during regular operation and during a reorganization attack, as part of a blockchain system that may be secured using proof of transactions, in accordance with various embodiments.
  • FIG. 2C is a graphical diagram illustrating a curve showing the destruction of the money supply over time in a blockchain that has a burn fee but no mechanism for re-injecting the burned tokens back into the network.
  • FIG. 3A is a schematic diagram illustrating an example of a conventional block including a plurality of transactions and a coinbase.
  • FIG. 3B is a schematic diagram illustrating an example of a block including a plurality of transactions and a golden ticket, the block being part of a blockchain system, in accordance with various embodiments.
  • FIG. 4 is a schematic diagram illustrating a portion of a blockchain including a plurality of blocks, each block including a plurality of transactions and a golden ticket, the blockchain being part of a blockchain system, in accordance with various embodiments.
  • FIG. 5 is a block diagram illustrating distribution of burn fees and coinbase payout as part of a method for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • FIG. 6 is a block diagram illustrating paysplit voting and difficulty voting as part of another method for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • FIGS. 7A-7C are flow diagrams illustrating a method for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • FIGS. 8A and 8B are flow diagrams illustrating another method for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • FIG. 9 is a block diagram illustrating an exemplary computer or system hardware architecture, in accordance with various embodiments.
  • FIG. 10 is a block diagram illustrating a networked system of computers, computing systems, or system hardware architecture, which can be used in accordance with various embodiments.
  • Various embodiments provide tools and techniques for implementing blockchain transactions, and, more particularly, to methods, systems, and apparatuses for securing a blockchain with proof-of-transactions.
  • the various embodiments provide a method to secure a cryptocurrency that avoids a “free-rider” economic problem that affects many cryptocurrencies and hurts their ability to scale.
  • the embodiments described herein solve this problem by utilizing a new security method (namely, “proof-of-transactions”) based on a multi-player voting system that is not susceptible to this free-rider problem and allows a cryptocurrency network to divide its revenue between the set of nodes in the peer-to-peer network that provides bandwidth and connectivity and a separate set of nodes, the role of which is to safeguard the security of the system.
  • the various embodiments allow cryptocurrencies to increase the amount of data processed by the network in an economically-efficient manner. This permits the development of fundamentally new applications, including, but not limited to, secure but decentralized email services, peer-to-peer social networks, pay-to-play websites, secure data-routing networks, SSH-key registries that are safe from man-in-the-middle (“MITM”) attacks, and/or the like.
  • MITM man-in-the-middle
  • voting method described here can be generalized to divide payments between any number of classes of actors in a blockchain network, simply by extending the voting process so that all actors are required to vote to approve changes to network consensus, in the description below we focus on a system with only two types of nodes (namely, “nodes” and “miners”) as these best describe the current needs of blockchain systems. And our method has many unexpected virtues: allocating fees between these classes of nodes in a transparent way that responds in real-time to the market-driven demands of the applications on the network for more bandwidth or security respectively.
  • Various embodiments described herein, while embodying (in some cases) software products, computer-performed methods, and/or computer systems, represent tangible, concrete improvements to existing technological areas, including, without limitation, blockchain technology, and/or the like.
  • certain embodiments can improve the functioning of user equipment or systems themselves (e.g., blockchain network nodes, blockchain network infrastructure, etc.), for example, by utilizing a proof-of-transactions approach to address the “free-rider” issue that may exist in conventional blockchain systems, and/or the like.
  • a method might comprise embedding, by a first node among a plurality of nodes in a peer-to-peer blockchain network and into an unconfirmed transaction being propagated across said network for eventual inclusion in a block, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction takes as it propagates across the peer-to-peer blockchain network.
  • the method might further comprise validating, with a second node among the plurality of nodes, the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain.
  • each node among the plurality of nodes in the peer-to-peer blockchain network might be associated with a unique public/private key pair and a network address.
  • the unique public/private key pair might comprise a public key and a private key.
  • the network address of a node among the plurality of nodes might contain information derived from the unique public/private key pair of the node, and a cryptographic signature of the node might be generated by using the private key of the unique public/private key pair of the node to sign a network address of a subsequent node among the plurality of nodes to which the transaction is routed by the node.
  • the network address and the other network addresses might constitute a plurality of network addresses.
  • a network address associated with an originating node that originates the transaction might not be included in (or might be excluded from) the plurality of network addresses, based on a determination that information required to validate a cryptographic signature associated with the originating node is already included in the transaction.
  • the first node and the second node might be the same node. Alternatively, the first node and the second node might be different nodes.
  • the method might further comprise quantifying, by one or more third nodes among the plurality of nodes in the blockchain network and in accordance with a set of consensus rules of a blockchain, a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, wherein the burn fee is a cost denominated in a value of a token managed by the blockchain network; quantifying, by the one or more third nodes and in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, wherein the burn value is a figure denominated in a value of a token managed by the blockchain network; determining, with the one or more third nodes and in accordance with the set of consensus rules of the blockchain, whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block; and based on a determination that the sum of individual burn values of the one or more transactions that are
  • the burn fee might be algorithmically set by at least one computing system in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain.
  • a burn value of a transaction might comprise a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • the method might further comprise determining, with at least a majority of the plurality of nodes in the blockchain network, whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block; and based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, determining, with the at least a majority of the plurality of nodes in the blockchain network, that the block is valid and including, with the at least a majority of the plurality of nodes in the blockchain network, the block in a blockchain.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network, might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • the method might further comprise pruning, by one or more fourth nodes among the plurality of nodes within the blockchain network, transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain; calculating, by the one or more fourth nodes among the plurality of nodes within the blockchain network, a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned; and adjusting a monetary policy of the blockchain network so that the blockchain network will reintroduce the unspent tokens as tokens allocated in future blocks.
  • the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets.
  • a system might comprise a first node among a plurality of nodes in a peer-to-peer blockchain network and a second node among the plurality of nodes.
  • the first node might comprise at least one first processor and a first non-transitory computer readable medium communicatively coupled to the at least one first processor.
  • the first non-transitory computer readable medium might have stored thereon computer software comprising a first set of instructions that, when executed by the at least one first processor, causes the first node to: embed, into an unconfirmed transaction being propagated across said network for eventual inclusion in a block, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction takes as it propagates across the peer-to-peer blockchain network.
  • the second node might comprise at least one second processor and a second non-transitory computer readable medium communicatively coupled to the at least one second processor.
  • the second non-transitory computer readable medium might have stored thereon computer software comprising a second set of instructions that, when executed by the at least one second processor, causes the second node to: validate the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain.
  • the first node and the second node might be the same node. Alternatively, the first node and the second node might be different nodes.
  • a method might comprise embedding, by a first node among a plurality of nodes in a peer-to-peer blockchain network and into an unconfirmed transaction being propagated across said network for eventual inclusion in a block, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction takes as it propagates across the peer-to-peer blockchain network; validating, with a second node among the plurality of nodes, the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain; quantifying, by one or more third nodes among the plurality of nodes in the blockchain network and in accordance with a set of
  • a method might comprise quantifying, by one or more first nodes among a plurality of nodes in a blockchain network and in accordance with a set of consensus rules of a blockchain, a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, wherein the burn fee is a cost denominated in a value of a token managed by the blockchain network; quantifying, by the one or more first nodes and in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, wherein the burn value is a figure denominated in a value of a token managed by the blockchain network; determining, with the one or more first nodes and in accordance with the set of consensus rules of the blockchain, whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block; and based on a determination that the sum of individual burn values of the one or more transactions that
  • the burn fee might be algorithmically set by at least one computing system in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain.
  • a burn value of a transaction might comprise a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • the method might further comprise determining, with at least a majority of the plurality of nodes in the blockchain network, whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block; and based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, determining, with the at least a majority of the plurality of nodes in the blockchain network, that the block is valid and including, with the at least a majority of the plurality of nodes in the blockchain network, the block in a blockchain.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network, might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • a node among a plurality of nodes in a blockchain network comprising: at least one processor; and a non-transitory computer readable medium communicatively coupled to the at least one processor.
  • the non-transitory computer readable medium might have stored thereon computer software comprising a set of instructions that, when executed by the at least one processor, causes the node to: quantify, in accordance with a set of consensus rules of a blockchain, a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, wherein the burn fee is a cost denominated in a value of a token managed by the blockchain network; quantify, in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, wherein the burn value is a figure denominated in a value of a token managed by the blockchain network; determine, in accordance with the set of consensus rules of the blockchain, whether a sum of individual
  • the burn fee might be algorithmically set by at least one computing system in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain.
  • a burn value of a transaction might comprise a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network, might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • a method might comprise pruning, by one or more first nodes among the plurality of nodes within the blockchain network, transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain; calculating, by the one or more first nodes among the plurality of nodes within the blockchain network, a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned; and adjusting a monetary policy of the blockchain network so that the blockchain network will reintroduce the unspent tokens as tokens allocated in future blocks.
  • the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets.
  • a node among a plurality of nodes in a blockchain network comprising: at least one processor; and a non-transitory computer readable medium communicatively coupled to the at least one processor.
  • the non-transitory computer readable medium might have stored thereon computer software comprising a set of instructions that, when executed by the at least one processor, causes the node to: prune transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain; calculate a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned; and adjust a monetary policy of the blockchain network so that the blockchain network will reintroduce the unspent tokens as tokens allocated in future blocks.
  • the unspent tokens are reintroduced back into the blockchain network in a later block through use of golden tickets.
  • a method might comprise generating, by a first network node among a plurality of network nodes in a blockchain network, a golden ticket that contains a computational puzzle; generating, by a second network node among the plurality of network nodes in the blockchain network, a solution to the computational puzzle in the golden ticket, wherein the solution to the computational puzzle is used to select, in a manner that cannot be anticipated by the first network node generating the golden ticket, one or more network nodes among the plurality of network nodes in the blockchain network; and distributing blockchain tokens to the one or more network nodes that are selected using the solution to the computational puzzle in the golden ticket.
  • the first node and the second node might be the same node. Alternatively, the first node and the second node might be different nodes.
  • the golden ticket might be at least one of included in a block published for inclusion in a blockchain or automatically associated with the block. In some cases, the golden ticket might comprise a random number that is created using data associated with the block. In some instances, the random number might comprise a cryptographic hash of data content contained within the block. In some cases, the solution to the golden ticket might be included in a block immediately following the block in which the golden ticket is included was published. In some instances, any valid blockchain might contain one or more golden tickets, each of which may be solved only once.
  • a block might contain only one solution to any particular golden ticket.
  • a block might contain only one golden ticket.
  • a block might contain a solution to only one golden ticket.
  • a block might be considered to be invalid based on a determination that the block contains a golden ticket solution that is invalid.
  • the solution to the computational puzzle in the golden ticket might comprise a product of a computationally difficult challenge that is independently verifiable by other nodes in the blockchain network.
  • the solution to the computational puzzle in the golden ticket that is generated by the second network node might be generated based on a hash of data associated with the golden ticket that meets validity criteria as defined in consensus rules of the blockchain.
  • the solution to the computational puzzle in the golden ticket might be used to select one or more network nodes from a subset of network nodes among the plurality of network nodes in the blockchain network that are identified as being valuable routing nodes with regard to production of a block containing the golden ticket.
  • routing nodes might be determined to be valuable based at least in part on data from a list of active routing nodes recorded within chains of cryptographic signatures and addresses embedded within transactions that are contained in the block containing the golden ticket.
  • the list of active routing nodes might be restricted to network nodes that are recorded within chains of cryptographic signatures and addresses embedded within transactions that are included within the same block that contains a golden ticket.
  • a likelihood that the one or more network nodes are selected might be weighted according to a determination that the one or more network nodes are each perceived to contribute to health of the blockchain network as a whole, as measured based on consensus rules of the blockchain and using factors including at least one of a value of a transaction fee associated with each transaction or a burn value of a transaction.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated, minus any value tokens allocated to a network node that generates the block containing the golden ticket, and adjusted to be plus or minus another amount determined by consensus rules of the blockchain to maintain a consistent money supply.
  • tokens allocated through use of golden tickets might be split between one or more network nodes that have provided solutions to golden tickets (“lucky miners”) and one or more nodes selected by one or more solutions to the golden tickets (“lucky nodes”).
  • votes to adjust variables contained in one of a block, the golden ticket, or the solution might be used to adjust a value of consensus variables once the solution to the golden ticket is included in the block and tokens are allocated to the lucky node and lucky miner in the blockchain network.
  • distribution of the tokens split between lucky miners and lucky nodes might be determined by a paysplit variable managed according to consensus rules of the blockchain. In some cases, the paysplit variable might be adjusted to direct one of a greater proportion or a lesser proportion of the blockchain tokens being distributed to the one or more network nodes that are selected.
  • the method might further comprise embedding, within one of a block or a golden ticket, a variable that indicates whether to increase, to hold constant, or to decrease a value of the paysplit variable managed according to the consensus rules of the blockchain.
  • blocks that contain a vote of the block indicating one of to decrease or to increase a value of the paysplit variable might include only transactions that are consistent with the vote of the block indicating the one of to decrease or to increase the value of the paysplit variable.
  • the method might further comprise embedding, within a transaction, a variable that indicates whether to increase, to hold constant, or to decrease a value of the paysplit variable managed according to the consensus rules of the blockchain.
  • a difficulty level of the computational puzzle might be determined using a difficulty variable managed according to consensus rules of the blockchain.
  • the difficulty variable might be adjusted to make selection of which network nodes to provide eligible solutions one of more difficult or less difficult, wherein a higher difficulty corresponds to a reduced set of nodes that will be considered eligible to generate solutions under the consensus rules of the blockchain.
  • the method might further comprise embedding, within a solution to a golden ticket, a variable that indicates whether to increase, to hold constant, or to decrease a value of the difficulty variable managed according to the consensus rules of the blockchain.
  • the computational puzzle might establish a two-player chain, wherein the two-player chain established by the computational puzzles might be extended into a chain with an arbitrary number of participants, to perform at least one of providing additional randomness or splitting allocation of tokens into a finer distribution settling to more participants in the blockchain network.
  • the method might further comprise embedding, within one of a block or a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the block” or “vote of the golden ticket”).
  • blocks that contain a vote of the block indicating one of to decrease or to increase a value of the network consensus variable might include only transactions that are consistent with the vote of the block indicating the one of to decrease or to increase the value of the network consensus variable.
  • the method might further comprise embedding, within a solution to a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the golden ticket”).
  • the method might further comprise embedding, within a transaction, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the transaction”).
  • a system might comprise a first network node among a plurality of network nodes in a blockchain network, a second network node among the plurality of network nodes, and a computing system.
  • the first network node might comprise at least one first processor and a first non-transitory computer readable medium communicatively coupled to the at least one first processor.
  • the first non-transitory computer readable medium might have stored thereon computer software comprising a first set of instructions that, when executed by the at least one first processor, causes the first network node to: generate a golden ticket that contains a computational puzzle.
  • the second network node might comprise at least one second processor and a second non-transitory computer readable medium communicatively coupled to the at least one second processor.
  • the second non-transitory computer readable medium might have stored thereon computer software comprising a second set of instructions that, when executed by the at least one second processor, causes the second network node to: generate a solution to the computational puzzle in the golden ticket, wherein the solution to the computational puzzle is used to select, in a manner that cannot be anticipated by the first network node generating the golden ticket, one or more network nodes among the plurality of network nodes in the blockchain network.
  • the computing system might comprise at least one third processor and a third non-transitory computer readable medium communicatively coupled to the at least one third processor.
  • the third non-transitory computer readable medium might have stored thereon computer software comprising a third set of instructions that, when executed by the at least one third processor, causes the third network node to: distribute blockchain tokens to the one or more network nodes that are selected using the solution to the computational puzzle in the golden ticket.
  • FIGS. 1-9 illustrate some of the features of the method, system, and apparatus for implementing blockchain transactions, and, more particularly, to methods, systems, and apparatuses for securing a blockchain with proof-of-transactions, as referred to above.
  • the methods, systems, and apparatuses illustrated by FIGS. 1-9 refer to examples of different embodiments that include various components and steps, which can be considered alternatives or which can be used in conjunction with one another in the various embodiments.
  • the description of the illustrated methods, systems, and apparatuses shown in FIGS. 1-9 is provided for purposes of illustration and should not be considered to limit the scope of the different embodiments.
  • FIG. 1 is a schematic diagram illustrating a blockchain system 100 that may be secured using proof of transactions, in accordance with various embodiments.
  • system 100 might comprise a computing system 105 , which might include, without limitation, one of a processor on a user device, a network node, a high speed signing network card(s), a network interface device, a server computer, a cloud-based computing system, a distributed computing system, and/or the like.
  • System 100 might further comprise a plurality of nodes 110 and a plurality of peer data storage systems 115 1 - 115 X and 115 Y - 115 N (collectively, “peer data storage systems 115 ,” “data storage 115 ,” or the like), both distributed across a plurality of networks 120 a - 120 n (collectively, “networks 120 ” or the like).
  • peer data storage systems 115 data storage systems 115
  • data storage 115 data storage 115
  • distributed peer data storage systems #1 115 1 through #X 115 X might be disposed in one or more networks 120 a, while distributed peer data storage systems #Y 115 Y through #N 115 N might be disposed in one or more networks 120 n.
  • distributed peer data storage systems #X+1 115 X+1 through #Y-1 115 Y-1 (as well as other nodes 110 ) might be disposed in one or more networks 120 b through 120 n - 1 .
  • each distributed peer storage system 115 might comprise a database, and in some cases, a local server or local computing system that accesses the database in response to requests from external or remote computing systems (e.g., computing system 105 , nodes 110 , user devices, or the like).
  • computing system 105 might communicatively couple with one or more of the distributed peer data storage systems 115 in networks 120 via one or more networks 125 .
  • at least some of the plurality of nodes 110 might also be disposed in the one or more networks 125 .
  • System 100 might further comprise one or more user devices 130 a- 130 n and 135 a- 135 n (collectively, “user devices,” “user devices 130 ,” or “user devices 135 ,” or the like) disposed in one or more local area networks (“LANs”) 140 a - 140 n (collectively, “LANs 140 ” or the like).
  • the user devices might be associated with users who might initiate or participate in transactions 145 , which when validated or confirmed might be incorporated in one or more blocks in a blockchain.
  • a user associated with one of the user devices might participate in a three-party activity with a miner (which solves computational puzzles in the golden ticket) and a node (which provides bandwidth and connectivity for the transactions), by being provided with the capability to tag their transactions with an optional paysplit vote (which the system 100 or the network might require might only be included if the votes are aligned in the same direction rather than conflicting).
  • a miner which solves computational puzzles in the golden ticket
  • a node which provides bandwidth and connectivity for the transactions
  • networks 120 a - 120 n and 125 might each include, without limitation, one of a local area network (“LAN”), including, without limitation, a fiber network, an Ethernet network, a Token-RingTM network, and/or the like; a wide-area network (“WAN”); a wireless wide area network (“WWAN”); a virtual network, such as a virtual private network (“VPN”); the Internet; an intranet; an extranet; a public switched telephone network (“PSTN”); an infra-red network; a wireless network, including, without limitation, a network operating under any of the IEEE 802.11 suite of protocols, the BluetoothTM protocol known in the art, and/or any other wireless protocol; and/or any combination of these and/or other networks.
  • the network might include an access network of the service provider (e.g., an Internet service provider (“ISP”)).
  • the network might include a core network of the service provider and/or the Internet.
  • the plurality of nodes 110 might propagate an unconfirmed transaction 145 (among a plurality of transactions 145 ) across at least one of the one or more networks 120 a - 120 n and/or the network(s) 125 (collectively, “peer-to-peer blockchain network,” “blockchain network,” or “network,” or the like).
  • the computing system 105 or a first node 110 among the plurality of nodes 110 might embed, into the unconfirmed transaction 145 , a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes 110 in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction 145 takes as it propagates across the peer-to-peer blockchain network.
  • the computing system 105 or a second node 110 among the plurality of nodes 110 might validate the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain.
  • each node among the plurality of nodes 110 in the peer-to-peer blockchain network might be associated with a unique public/private key pair and a network address.
  • the unique public/private key pair might comprise a public key and a private key.
  • the network address of a node among the plurality of nodes 110 might contain information derived from the unique public/private key pair of the node (in some cases, the information is derived from the private key of the unique public/private key pair of the node, while in other cases (e.g., in some PKI systems with which the public key cannot necessarily be derived from the private, or the like), the information need not be derived from the private key itself), and a cryptographic signature of the node might be generated by using the private key of the unique public/private key pair of the node to sign a network address of a subsequent node among the plurality of nodes 110 to which the transaction is routed by the node.
  • the network address and the other network addresses might constitute a plurality of network addresses.
  • a network address associated with an originating node that originates the transaction might not be included in (or might be excluded from) the plurality of network addresses, based on a determination that information required to validate a cryptographic signature associated with the originating node is already included in the transaction.
  • a network address associated with the originating node might be included regardless of whether information required to validate a cryptographic signature associated with the originating node has already been included in the transaction.
  • the first node and the second node might be the same node. Alternatively, the first node and the second node might be different nodes.
  • the computing system 105 or one or more third nodes among the plurality of nodes 110 might quantify a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, in accordance with a set of consensus rules of a blockchain.
  • the burn fee might be a cost denominated in a value of a token managed by the blockchain network.
  • the computing system 105 or the one or more third nodes might quantify the value of one or more transactions being included in a candidate block by reducing it to a burn value, in accordance with the set of consensus rules of the blockchain.
  • the burn value might be a figure denominated in a value of a token managed by the blockchain network.
  • the computing system 105 or the one or more third nodes might determine whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, in accordance with the set of consensus rules of the blockchain. Based on a determination that the sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, the computing system 105 or the one or more third nodes might determine that the candidate block is valid according to the set of consensus rules of the blockchain.
  • the burn fee might be algorithmically set by at least one computing system 105 or at least one node among the plurality of nodes 110 in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain (as depicted in FIGS. 2A and 2B , which are further described below).
  • a burn value of a transaction might comprise a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • At least a majority of the plurality of nodes 110 in the blockchain network might determine whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block. Based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, the at least a majority of the plurality of nodes 110 in the blockchain network might determine that the block is valid and might include the block in a blockchain.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network, might be granted to a node among the plurality of nodes 110 that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • the computing system 105 or one or more fourth nodes among the plurality of nodes 110 within the blockchain network might prune all transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain, and might calculate a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned.
  • the computing system 105 or at least one node among the plurality of nodes 110 might adjust a monetary policy of the blockchain network so that the blockchain network would reintroduce (or recycle) the unspent tokens as tokens allocated in future blocks. In some cases, the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets.
  • the computing system 105 or a fifth node among the plurality of nodes 110 in the blockchain network might generate a golden ticket that contains a computational puzzle.
  • the computing system 105 or a sixth node among the plurality of nodes 110 in the blockchain network might generate a solution to the computational puzzle in the golden ticket, where the solution to the computational puzzle might be used to select one or more network nodes among the plurality of nodes 110 in the blockchain network, in a manner that cannot be anticipated by the computing system 105 or the fifth node generating the golden ticket.
  • the golden ticket might be at least one of included in a block published for inclusion in a blockchain or automatically associated with the block, and/or the like. In some cases, the golden ticket might include, without limitation, a random number that is created using data associated with the block.
  • the random number might comprise a cryptographic hash of data content contained within the block.
  • the solution to the golden ticket might be included in a block immediately following the block in which the golden ticket is included was published.
  • any valid blockchain might contain one or more golden tickets, each of which may be solved only once.
  • a block might contain only one solution to any particular golden ticket.
  • a block might contain only one golden ticket.
  • a block might contain a solution to only one golden ticket.
  • a block might be considered to be invalid based on a determination that the block contains a golden ticket solution that is invalid.
  • the solution to the computational puzzle in the golden ticket might comprise a product of a computationally difficult challenge that is independently verifiable by other nodes 110 in the blockchain network.
  • the solution to the computational puzzle in the golden ticket that is generated by the sixth node might be generated based on a hash of data associated with the golden ticket that meets validity criteria as defined in consensus rules of the blockchain.
  • the solution to the computational puzzle in the golden ticket might be used to select one or more network nodes from a subset of network nodes among the plurality of network nodes 110 in the blockchain network that are identified as being valuable routing nodes with regard to production of a block containing the golden ticket.
  • routing nodes might be determined to be valuable based at least in part on data from a list of active routing nodes recorded within chains of cryptographic signatures and addresses embedded within transactions that are contained in the block containing the golden ticket.
  • the list of active routing nodes might be restricted to network nodes 110 that are recorded within chains of cryptographic signatures and addresses embedded within transactions that are included within the same block that contains a golden ticket.
  • a likelihood that the one or more network nodes are selected might be weighted according to a determination that the one or more network nodes are each perceived to contribute to health of the blockchain network as a whole, as measured based on consensus rules of the blockchain and using factors including at least one of a value of a transaction fee associated with each transaction or a burn value of a transaction.
  • the computing system 105 or the sixth node among the plurality of nodes 110 in the blockchain network might broadcast the solution to the golden ticket throughout the blockchain network, the solution being included in a subsequent block that is produced and validated by the blockchain network.
  • the computing system 105 or a node among the plurality of nodes 110 might distribute blockchain tokens to the one or more network nodes that are selected using the solution to the computational puzzle in the golden ticket.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated, minus any value tokens allocated to a network node that generates the block containing the golden ticket, and adjusted to be plus or minus another amount determined by consensus rules of the blockchain to maintain a consistent money supply.
  • tokens allocated through use of golden tickets might be split between one or more network nodes that have provided solutions to golden tickets (“lucky miners”) and one or more nodes selected by one or more solutions to the golden tickets (“lucky nodes”).
  • distribution of the tokens split between lucky miners and lucky nodes might be determined by a paysplit variable managed according to consensus rules of the blockchain, while a difficulty level of the computational puzzle might be determined using a difficulty variable managed according to the consensus rules of the blockchain.
  • the difficulty variable might be adjusted to make selection of which network nodes to provide eligible solutions either more difficult or less difficult, where a higher difficulty corresponds to a reduced set of nodes that will be considered eligible to generate solutions under the consensus rules of the blockchain.
  • the computing system 105 or at least one of the nodes 110 might embed, within a solution to a golden ticket, a variable that indicates whether to increase, to hold constant, or to decrease a value of the difficulty variable managed according to the consensus rules of the blockchain.
  • the computational puzzle might establish a two-player chain, wherein the two-player chain established by the computational puzzles might be extended into a chain with an arbitrary number of participants, to perform at least one of providing additional randomness or splitting allocation of tokens into a finer distribution settling to more participants in the blockchain network.
  • the computing system 105 or at least one of the nodes 110 might embed, within one of a block or a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the block” or “vote of the golden ticket”).
  • blocks that contain a vote of the block indicating whether to decrease or to increase a value of the network consensus variable might include only transactions that are consistent with the vote of the block indicating whether to decrease or to increase the value of the network consensus variable.
  • the computing system 105 or at least one of the nodes 110 might embed, within a solution to a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the golden ticket”).
  • the computing system 105 or at least one of the nodes 110 might embed, within a transaction, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the transaction”).
  • users in the blockchain network of the various embodiments create transactions and broadcast them into a mesh grid that assembles these transactions into blocks and arranges these blocks into a sequential blockchain that represents the transaction history of the network, treating the longest chain at any time as the ledger of record.
  • the methods according to the various embodiments change the class of nodes that have the right to bundle transactions into blocks.
  • nodes are not necessarily the same as the nodes that handle the majority of the traffic in the peer-to-peer system. In both networks, the nodes that focus on earning revenue generally “specialize.”
  • the node that produces the block in our peer-to-peer network also includes a vote on whether to increase, decrease, or hold constant the share of the “burn fee” that will be distributed to “miners” as opposed to being distributed to the “nodes,” where “miners” herein refers to nodes that choose to solve computational puzzles and “nodes” refers to nodes that provide bandwidth and connectivity in the peer-to-peer network.
  • This vote over the distribution of income is referred to herein as the “paysplit vote.”
  • the consensus network determination of how fees are distributed is referred to herein as the “paysplit.”
  • miners examine the “golden tickets” (along with their paysplit votes) and choose for themselves which blocks they wish to support. If they decide they want to support a golden ticket, they must find a solution to a computationally difficult puzzle and share it with the rest of the network.
  • the computational puzzle that is selected for miners to solve includes, but is not limited to, the challenge of producing a public/private keypair that can sign a hash-value in a way that the resulting signature meets criteria that can be easily tested by the rest of the network.
  • Miners in some instances, are suggested to start with an SHA256 hash or the like of the contents of the golden ticket, with their challenge being appending to this hash their own public key and then signing the hash+key combination such that it produces a cryptographic signature (i.e., signing the results with their private key) where the final N digits in both the signature and the golden ticket hash value match, where N here is a consensus variable that is adjusted up or down by the network through a separate “difficulty vote” in a process that will be described shortly.
  • miners can publish the proof that they have found a solution into the network without providing the ability for other nodes or miners to steal it (since only the miner that found the proof has the necessary private key to create a valid signature, and since the public key is associated with the miner who found the solution). And yet all nodes can easily verify that the miner has indeed found a valid proof by simply checking the proffered signature against their public key.
  • Miner solutions to the golden ticket must include all of the information needed by third-parties to verify that the miner has solved the computational puzzle successfully, along with the previously mentioned second vote on whether to increase, decrease, or hold constant the difficulty of the computational puzzle itself (“difficulty vote”).
  • the “burn fee” contained in the golden ticket is released to the network, split between the miner that found the solution and (a randomly selected) one of the nodes that participates in the peer-to-peer network and that propagates transactions according to the consensus paysplit values.
  • a hash-value produced in the miner solution may be used as a random input to an algorithm that selects a node that was involved in propagating one of the transactions found in the previous block, and whose address or public key can be found in the path-history of the transaction (as described further below).
  • the logic of how and when fees are distributed is presented in FIG. 5 , which is further described below.
  • this dynamic creates a struggle between miners and nodes for the revenue created by the system, driving the network into a long-term equilibrium where revenue is distributed between the nodes in the peer-to-peer network and the miners “securing” the network according to the underlying economic costs of bandwidth and security provision.
  • the security of the network is increased as the network grows and transaction volume grows regardless of the activity of the miners.
  • the miners nonetheless play an important role in preventing attacks, for the higher they drive the difficulty of solving the “golden tickets,” the greater is the difficulty for any attacker to change the consensus paysplit and difficulty settings of the network in a way that will allow them to produce blocks at a faster pace than the main chain and thus launch a successful attack on it.
  • nodes sign transactions as they propagate through our network, creating an unforgeable history of the path each transaction that is included in the transaction and documents its transmission from its point of origin to its point of confirmation and inclusion in a block.
  • nodes are permitted to bundle any transaction in any block, but cannot use the fees paid by transactions against the “burn fee” they need to pay unless their own node can be found in the cryptographically signed transaction path for that specific transaction.
  • the rules may stipulate that nodes prefer blocks that have a higher initial burn fee than blocks that have a lower burn fee at any particular block depth (i.e., if two blocks share the same block ID but one has a higher burn fee, the latter becomes the preferred block).
  • the blockchain system or approach described herein (also referred to herein as the “Saito Network,” “Saito platform,” or the like) is a cryptocurrency platform for applications that need to send large amounts of data across the blockchain. You can use it today to build “unastroturfable” Internet forums, decentralized social networks, pay-to-play websites, distributed data-routing services, peer-to-peer email hosting, SSH-key registries that are secure from MITM attacks, and/or the like.
  • the Saito platform described herein is notable for its use of a disposable blockchain, a proof-of-transactions system that splits network fees between bandwidth and security providers, and an economic incentive structure that protects the network from sibyl attacks and ensures that even attackers with overwhelming influence in any sector cannot dictate the behavior of the network as a whole.
  • users in the blockchain network described herein create transactions and broadcast them into a mesh grid that assembles them into sequential blocks, treating the longest chain as the ledger of record. While all transactions support basic payment functionality, they also include a signed “message” field where data can be bundled and read by applications that sit atop the network.
  • nodes in the Saito Network create blocks to secure the fees associated with bundling transactions.
  • the cost of producing a block is not the arbitrary expenditure of “hash power” but rather a “burn fee” that is set algorithmically by the network.
  • this “burn fee” is set to a high value immediately after a block is found and decreases in stepwise fashion until it eventually hits zero, at which point any node on the network can produce a block free-of-charge.
  • the Saito Network automatically adjusts its “burn fee” upwards over time to keep block time constant as transaction volume grows.
  • One subtle benefit of this design is that attacking the network grows more expensive the more transactions it serves, essentially creating a virtuous cycle that encourages economic activity to concentrate on the most secure chain.
  • Another more subtle advantage of this approach is that by quantifying the costs of any attack, users and applications can gauge for themselves whether security is adequate or inadequate for their needs.
  • any network that relies upon nodes to “burn capital” to issue blocks will eventually run out of funds.
  • a node Every time a node produces a block, it collects what profit it can and bundles the remaining fees into a “golden ticket” that contains a computational puzzle for miners to solve, along with a vote on whether to increase, decrease, or hold constant the share of the burn fee that will ultimately be distributed to miners instead of randomly to one of the bandwidth-providing nodes in the network (“paysplit”).
  • Miners choose themselves whether to solve these golden tickets, but finding a solution is not enough, for should a miner succeed in solving one, it must propagate its solution back into the network as a fee-paying transaction for inclusion in the very next block. As part of this solution, the miner may also make a secondary vote on whether to increase, decrease or hold constant the difficulty of the computational puzzle.
  • miners prefer a high difficulty as that reduces the expected competition they face from their peers and thus lowers the expected transaction fee they need to pay to induce nodes to prefer their solution (i.e., increasing their “take-home” share of the burn-fee); nodes meanwhile prefer a low difficulty rate not only because inter-miner competition increases the fees paid to them (and speeds up the pace of block production in the process, further securing their own income) but also because easier golden tickets hold out the salivating prospect that nodes may be able to select between multiple solutions and even pick one that rewards them.
  • a golden ticket is solved by a miner and their solution is included by a node, the coinbase funds in the ticket are released to the two winners of the activity, and the votes over paysplit and difficulty take effect.
  • the Saito Network diverges from all existing cryptosystems. Strategically, the fact that votes in our network pass back and forth between nodes and miners, and require implicit approval from both groups to take effect, pushes us into a dynamic where nodes and miners must collude to protect their group interests (refusing to process the harmful votes of their counterparties) while using their own clout to promote friendly blocks. Yet collusion is difficult because both parties can also induce defection from the other side. Nodes can pad their golden ticket with extra funds to induce hashing support from renegade miners, while miners can propagate their solutions with higher fees to bribe support from nodes.
  • our two-player system will eventually reach equilibrium at the point where the security provided by miners is optimal given their relative costs of collusion, but we acknowledge that this level is arbitrary and may not reflect the amount of security (or bandwidth) desired by the applications on the network, something especially relevant given that our demand for security from miners decreases naturally as the volume of transactions grows.
  • we introduce a third party whose market preferences ensure we hit an optimal economic distribution of fees between nodes and miners.
  • This third party consists of the users who make up the network, and who are allowed by the network to tag their transactions with an optional paysplit vote. Should a user-originated transaction contain a paysplit vote, the system insists that it can only be included in a block that votes in the same direction. Users who choose to take sides in this ongoing struggle between nodes and miners thus sacrifice the reliability and speed of transaction confirmation but gain marginal influence over the direction of the network by increasing the flow of capital to the party that represents its interests in the central two-player system.
  • Miners are perhaps the most influential party at small scale but lose influence as the volume of transactions grows (adding a secondary level of security) and it becomes easier for nodes to collude (i.e., harder for miners to operate their own nodes). And while the user/application influence is arguably weakest at the beginning, it ultimately becomes the most powerful influence on the network. And yet even with any group at its apex, no particular group is ever fully ascendant, for any two players in our system can always collude to protect the network from the overweening influence of the third player.
  • blockchain security is not just about protecting users from reorganization attacks, it also implies censorship resistance. And in this field, even a successful attack on the network is not able to accomplish much beyond driving up the price of network token while amassing the resources for an attack on the network. Extremely wealthy attackers can burn cash to censor transactions, but they can do this in Bitcoin as well (by pricing out competing transactions). And even if an attack does overwrite a substantial portion of the blockchain, most of the transactions they overwrite can be almost immediately bundled onto the end of the winning chain by the nodes that initially published them, where they then add to the security of the now-longest chain.
  • FIGS. 2A and 2B are graphical diagrams illustrating cost versus time curves 200 and 200 ′ depicting required burn fees compared with total collected fees during regular operation and during a reorganization attack, as part of a blockchain system that may be secured using proof of transactions, in accordance with various embodiments.
  • FIG. 2C is a graphical diagram illustrating a curve showing the destruction of the money supply over time in a blockchain that has a burn fee but no mechanism for re-injecting the burned tokens back into the network.
  • FIG. 2A depicts how the “proof of transactions” approach described herein, which includes the implementation of a “burn fee,” works.
  • the Y-axis measures the “burn fee” that must be paid to produce a block in a blockchain
  • the X-axis measures the amount of time that has passed since the last block was produced.
  • the burn fee decreases in amount (as depicted by curve 205 in FIG. 2A ) while the number of transaction fees available to the blocks (and thus the total fees collected) increases (as depicted by curve 210 in FIG. 2A ).
  • the expected block time is approximately at the intersection between these two curves 205 and 210 (as depicted in FIG. 2A by the vertical dotted line), when it becomes profitable for nodes to issue blocks.
  • FIG. 2B depicts how the dynamics of the various embodiments cause attacks to the system (e.g., reorganization attacks or the like) to become expensive.
  • Attacking any blockchain requires producing more blocks in a set amount of time than can be produced by the rest of the network. This requires producing more blocks in the same period of time, or producing blocks at a faster pace.
  • FIG. 2B illustrates, given a fixed burn fee (i.e., a burn fee value along the curve 205 ), increasing the speed of block production might be achieved by shifting the supply curve 210 upwards (as shown by curve 215 ), which requires the attacker either to have access to more fee-paying transactions than the rest of the network combined or to create their own fake transactions that nonetheless pay real fees (e.g., spending capital, or the like).
  • FIG. 2C depicts an issue with creating a proof-of-transactions-based system that uses a burn fee to regulate the speed and cost of block production. That is, the security of the system depends on production of blocks by nodes being made costly. But, allowing nodes to burn capital to produce blocks commits the network to a long-term deflationary spiral that gradually destroys the economy. In time, the network runs out of money and economic activity collapses.
  • FIGS. 3B-7C illustrate how fee and coinbase distribution might be used to achieve this solution.
  • FIG. 3A is a schematic diagram illustrating an example 300 of a conventional block including a plurality of transactions and a coinbase.
  • FIG. 3 A depicts a schematic of the structure of a block 305 in a traditional blockchain, including a plurality of tokens 310 (each of which might represent a transaction, a message, or data, or the like) and a coinbase 315 .
  • the coinbase 315 which represents new money being injected into the economy, as well as implicitly representing the aggregate fees paid by the transactions in the block—is part of the block 305 itself and is rewarded to the node that produces it.
  • FIG. 3B depicts a block that incorporates features that address this issue.
  • FIG. 3B is a schematic diagram illustrating an example 300 ′ of a block including a plurality of transactions and a golden ticket, the block being part of a blockchain system (in some non-limiting embodiments, part of the blockchain system of FIG. 1 or the like), in accordance with various embodiments.
  • FIG. 3B depicts a schematic of the structure of a block 320 in a blockchain in accordance with the various embodiments.
  • the block 320 might include a plurality of tokens 325 (which is similar to tokens 310 ; each of which might represent a transaction, a message, or data, or the like) and a golden ticket 330 (which is distinct from the coinbase 315 ).
  • the funds are instead bundled into computational puzzles that must be solved by other entities in the network (e.g., miners) in order for the funds to be released.
  • This computational puzzle is referred to herein as a “golden ticket.”
  • FIG. 4 is a schematic diagram illustrating a portion of a blockchain 400 including a plurality of (consecutive) blocks 405 a - 405 c (collectively, “blocks 405 ” or the like), each block including a plurality of tokens 410 a, 410 b, or 410 c (collectively, “tokens 410 ” or the like) and a golden ticket 415 a, 415 b, or 415 c (collectively, “golden ticket 415 ” or the like), the blockchain 400 being part of a blockchain system (in some non-limiting embodiments, part of the blockchain system 100 of FIG. 1 or the like), in accordance with various embodiments.
  • the blocks 405 a - 405 c might be located at the beginning of the blockchain, located at the end of the blockchain, or disposed somewhere in between.
  • FIG. 4 illustrates how a golden ticket creates a two-player activity between a node and a miner.
  • Nodes produce blocks 405
  • miners solve the golden tickets 415 created by the nodes.
  • Other nodes subsequently include the solutions 420 a or 420 b (collectively, “golden ticket solutions 420 ,” “solutions 420 ,” or the like) to the golden tickets 415 into subsequent blocks—in some cases, as shown by golden ticket solution fields 425 b or 425 c (also 425 a; collectively, “golden ticket solution fields 425 ,” “solution fields 425 ,” or the like).
  • golden ticket solution fields 425 b or 425 c also 425 a; collectively, “golden ticket solution fields 425 ,” “solution fields 425 ,” or the like.
  • to create more fee competition between miners if difficulty levels are too low, only one solution to any golden ticket might be included in the blockchain.
  • FIG. 5 is a block diagram illustrating distribution of burn fees and coinbase payout as part of a method 500 for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • method 500 illustrates how the “burn fees” and optional “coinbase” that are locked into the “golden ticket” are distributed based on the independent choices of the nodes and miners in the system. Importantly, the funds that are locked into the golden ticket are only released to the winning node and the miner after the miner has solved the golden ticket and after the solution has been embedded or incorporated in the next block in the blockchain.
  • method 500 might include producing, with a node, a golden ticket (block 505 ).
  • Method 500 might further comprise determining whether a miner has solved the golden ticket (block 510 ). If not, the process returns to block 505 . If so, the process continues to block 515 , in which the method 500 might further comprise determining whether the solution is embedded or incorporated in the next block in the blockchain. If not, the process returns to block 505 .
  • the process continues to block 520 , in which the method 500 might comprise splitting (and distributing) the burn fee and coinbase payout to the miner that solved the golden ticket and a randomly selected node in the peer-to-peer network, in accordance with network consensus “paysplit.”
  • the randomly selected node might be a node selected from among a plurality of nodes within the peer-to-peer network that participate in propagating or relaying a transaction (that once confirmed or validated is included in a block of the blockchain), or the like.
  • FIG. 6 is a block diagram illustrating paysplit voting and difficulty voting as part of another method 600 for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • method 600 illustrates how voting dynamics of the various embodiments interact with the “golden ticket” system (i.e., how the network uses the “golden ticket” process to make collective decisions about changing the consensus “paysplit” and “difficulty” levels for the network as a whole).
  • method 600 might include producing, with a node, a golden ticket, the node making a “paysplit vote” (block 605 ).
  • the “paysplit vote” might be a choice by nodes whether to increase, to hold constant, or to decrease the share of the golden ticket reward allocated to miners.
  • Method 600 might further comprise determining whether a miner has solved the golden ticket (block 610 ). If not, the process returns to block 605 .
  • the process continues to block 615 , in which the method 600 might comprise broadcasting, with the miner, the solution, the miner making a “difficulty vote.”
  • the “difficulty vote” might be a choice by miners whether to increase, to hold constant, or to decrease the difficulty of the mining puzzle.
  • Method 600 might further comprise determining whether the solution is embedded or incorporated in the next block in the blockchain (block 620 ). If not, the process returns to block 605 . If so, the process continues to block 625 , in which the method 600 might comprise updating, with the network, paysplit and difficulty settings. The paysplit and difficulty votes only become effective and contribute to changing the consensus settings once they have been included in the solution to a golden ticket and incorporated in the blockchain.
  • users who initiate or participate in transactions might be provided with the ability to tag their transactions with an optional paysplit vote (either replacing the paysplit vote of the node or contributing to the paysplit vote of the node).
  • an average of the vote might be used to determine a resultant paysplit vote that determines how much of the paysplit goes to the miner who solves the golden ticket and how much goes to a randomly selected node that participates in propagation of the transactions.
  • FIGS. 7A-7C are flow diagrams illustrating a method 700 for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • Method 700 of FIG. 7A continues onto FIG. 7B following the circular marker denoted, “A,” which continues onto FIG. 7C following the circular marker denoted, “B.”
  • FIG. 7 can be implemented by or with (and, in some cases, are described below with respect to) the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 , respectively (or components thereof), such methods may also be implemented using any suitable hardware (or software) implementation.
  • each of the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 , respectively (or components thereof), can operate according to the method 700 illustrated by FIG. 7 (e.g., by executing instructions embodied on a computer readable medium), the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 can each also operate according to other modes of operation and/or perform other suitable procedures
  • method 700 at block 705 , might comprise embedding, by a first node among a plurality of nodes in a peer-to-peer blockchain network and into an unconfirmed transaction being propagated across said network for eventual inclusion in a block, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction takes as it propagates across the peer-to-peer blockchain network.
  • each node among the plurality of nodes in the peer-to-peer blockchain network might be associated with a unique public/private key pair and a network address.
  • the unique public/private key pair might include, without limitation, a public key and a private key.
  • the network address of a node among the plurality of nodes might contain information derived from the unique public/private key pair of the node, and a cryptographic signature of the node might be generated by using the private key of the unique public/private key pair of the node to sign a network address of a subsequent node among the plurality of nodes to which the transaction is routed by the node.
  • the network address and the other network addresses might constitute a plurality of network addresses.
  • a network address associated with an originating node that originates the transaction might not be included in the plurality of network addresses, based on a determination that information required to validate a cryptographic signature associated with the originating node is already included in the transaction.
  • the first node and the second node are the same node.
  • the first node and the second node might be different nodes within the blockchain network.
  • Method 700 might further comprise quantifying, by one or more second nodes among the plurality of nodes in the blockchain network and in accordance with a set of consensus rules of a blockchain, a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, where the burn fee is a cost denominated in a value of a token managed by the blockchain network (block 710 ) and quantifying, by the one or more second nodes and in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, where the burn value is a figure denominated in a value of a token managed by the blockchain network (block 715 ).
  • method 700 might comprise determining, with the one or more second nodes and in accordance with the set of consensus rules of the blockchain, whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block.
  • Method 700 might comprise, at block 725 , based on a determination that the sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, determining, with the one or more second nodes, that the candidate block is valid according to the set of consensus rules of the blockchain.
  • the burn fee might be algorithmically set by at least one computing system in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain.
  • a burn value of a transaction might include a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • Method 700 might continue onto the process at optional block 730 in FIG. 7B following the circular marker denoted, “A.”
  • method 700 might comprise determining, with at least a majority of the plurality of nodes in the blockchain network, whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block.
  • method 700 might comprise validating, with a third node among the plurality of nodes, the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain.
  • Method 700 might comprise, based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, determining, with the at least a majority of the plurality of nodes in the blockchain network, that the block is valid and including, with the at least a majority of the plurality of nodes in the blockchain network, the block in a blockchain.
  • method 700 might further comprise pruning, by one or more fourth nodes among the plurality of nodes within the blockchain network, transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain (optional block 745 ); calculating, by the one or more fourth nodes among the plurality of nodes within the blockchain network, a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned (optional block 750 ); and adjusting a monetary policy of the blockchain network so that the blockchain network will reintroduce the unspent tokens as tokens allocated in future blocks (optional block 755 ).
  • the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets.
  • Method 700 might continue onto the process at block 760 in FIG. 7C following the circular marker denoted, “B.”
  • method 700 might comprise generating, by a fifth node among the plurality of nodes in the blockchain network, a golden ticket that contains a computational puzzle.
  • Method 700 might further comprise generating, by a sixth node among the plurality of nodes in the blockchain network, a solution to the computational puzzle in the golden ticket, where the solution to the computational puzzle is used to select, in a manner that cannot be anticipated by the fifth node generating the golden ticket, one or more network nodes among the plurality of nodes in the blockchain network (block 765 ).
  • Method 700 might comprise broadcasting, by the sixth node, the solution to the golden ticket throughout the blockchain network, the solution being included in a subsequent block that is produced and validated by the blockchain network.
  • Method 700 might further comprise, at block 775 , distributing blockchain tokens to the one or more network nodes that are selected using the solution to the computational puzzle in the golden ticket.
  • the fifth node and the sixth node might be the same node. Alternatively, the fifth node and the sixth node might be different nodes.
  • the golden ticket might be at least one of included in a block published for inclusion in a blockchain or automatically associated with the block, or the like.
  • the golden ticket might comprise a random number that is created using data associated with the block.
  • the random number might comprise a cryptographic hash of data content contained within the block.
  • the solution to the golden ticket might be included in a block immediately following the block in which the golden ticket is included was published.
  • any valid blockchain might contain one or more golden tickets, each of which may be solved only once.
  • a block might contain only one solution to any particular golden ticket.
  • a block might contain only one golden ticket.
  • a block might contain a solution to only one golden ticket.
  • a block might be considered to be invalid based on a determination that the block contains a golden ticket solution that is invalid.
  • the solution to the computational puzzle in the golden ticket might comprise a product of a computationally difficult challenge that is independently verifiable by other nodes in the blockchain network.
  • the solution to the computational puzzle in the golden ticket that is generated by the sixth node might be generated based on a hash of data associated with the golden ticket that meets validity criteria as defined in consensus rules of the blockchain.
  • the solution to the computational puzzle in the golden ticket is used to select one or more network nodes from a subset of network nodes among the plurality of nodes in the blockchain network that are identified as being valuable routing nodes with regard to production of a block containing the golden ticket.
  • routing nodes might be determined to be valuable based at least in part on data from a list of active routing nodes recorded within chains of cryptographic signatures and addresses embedded within transactions that are contained in the block containing the golden ticket.
  • the list of active routing nodes might be restricted to network nodes that are recorded within chains of cryptographic signatures and addresses embedded within transactions that are included within the same block that contains a golden ticket.
  • a likelihood that the one or more network nodes are selected might be weighted according to a determination that the one or more network nodes are each perceived to contribute to health of the blockchain network as a whole, as measured based on consensus rules of the blockchain and using factors including at least one of a value of a transaction fee associated with each transaction or a burn value of a transaction.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated.
  • an amount of tokens allocated through use of golden tickets might be equivalent to transaction fees paid in a block containing a golden ticket that contains a computational puzzle to which a solution has been generated, minus any value tokens allocated to a network node that generates the block containing the golden ticket, and adjusted to be plus or minus another amount determined by consensus rules of the blockchain to maintain a consistent money supply.
  • tokens allocated through use of golden tickets might be split between one or more network nodes that have provided solutions to golden tickets (“lucky miners”) and one or more nodes selected by one or more solutions to the golden tickets (“lucky nodes”).
  • votes to adjust variables contained in one of a block, the golden ticket, or the solution might be used to adjust a value of consensus variables once the solution to the golden ticket is included in the block and tokens are allocated to the lucky node and lucky miner in the blockchain network.
  • distribution of the tokens split between lucky miners and lucky nodes might be determined by a paysplit variable managed according to consensus rules of the blockchain.
  • the paysplit variable might be adjusted to direct one of a greater proportion or a lesser proportion of the blockchain tokens being distributed to the one or more network nodes that are selected.
  • the method 700 might further comprise embedding, within one of a block or a golden ticket, a variable that indicates whether to increase, to hold constant, or to decrease a value of the paysplit variable managed according to the consensus rules of the blockchain.
  • blocks that contain a vote of the block indicating one of to decrease or to increase a value of the paysplit variable might include only transactions that are consistent with the vote of the block indicating the one of to decrease or to increase the value of the paysplit variable.
  • method 700 might further comprise embedding, within a transaction, a variable that indicates whether to increase, to hold constant, or to decrease a value of the paysplit variable managed according to the consensus rules of the blockchain.
  • a difficulty level of the computational puzzle might be determined using a difficulty variable managed according to consensus rules of the blockchain.
  • the difficulty variable might be adjusted to make selection of which network nodes to provide eligible solutions one of more difficult or less difficult, where a higher difficulty might correspond to a reduced set of nodes that will be considered eligible to generate solutions under the consensus rules of the blockchain.
  • method 700 might further comprise embedding, within a solution to a golden ticket, a variable that indicates whether to increase, to hold constant, or to decrease a value of the difficulty variable managed according to the consensus rules of the blockchain.
  • the computational puzzle might establish a two-player chain, where the two-player chain established by the computational puzzles might be extended into a chain with an arbitrary number of participants, to perform at least one of providing additional randomness or splitting allocation of tokens into a finer distribution settling to more participants in the blockchain network.
  • the method 700 might further comprise embedding, within one of a block or a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the block” or “vote of the golden ticket”).
  • blocks that contain a vote of the block indicating one of to decrease or to increase a value of the network consensus variable might include only transactions that are consistent with the vote of the block indicating the one of to decrease or to increase the value of the network consensus variable.
  • method 700 might further comprise embedding, within a solution to a golden ticket, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the golden ticket”).
  • method 700 might further comprise embedding, within a transaction, a variable that indicates whether to decrease, to hold constant, or to increase a value of a network consensus variable (“vote of the transaction”).
  • FIGS. 8A and 8B are flow diagrams illustrating another method 800 for securing a blockchain with proof-of-transactions, in accordance with various embodiments.
  • FIG. 8 can be implemented by or with (and, in some cases, are described below with respect to) the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 , respectively (or components thereof), such methods may also be implemented using any suitable hardware (or software) implementation.
  • each of the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 , respectively (or components thereof), can operate according to the method 800 illustrated by FIG. 8 (e.g., by executing instructions embodied on a computer readable medium), the systems, examples, or embodiments 100 , 200 , 200 ′, 200 ′′, 300 ′, 400 , 500 , and 600 of FIGS. 1, 2A, 2B, 2C, 3B, 4, 5, and 6 can each also operate according to other modes of operation and/or perform other suitable procedures
  • method 800 might comprise quantifying, by one or more first nodes among a plurality of nodes in a blockchain network and in accordance with a set of consensus rules of a blockchain, a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, where the burn fee is a cost denominated in a value of a token managed by the blockchain network (block 805 ) and quantifying, by the one or more first nodes and in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, where the burn value is a figure denominated in a value of a token managed by the blockchain network (block 810 ).
  • method 800 might comprise determining, with the one or more first nodes and in accordance with the set of consensus rules of the blockchain, whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block.
  • Method 800 might comprise, at block 820 , based on a determination that the sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, determining, with the one or more first nodes, that the candidate block is valid according to the set of consensus rules of the blockchain.
  • the burn fee might be algorithmically set by at least one computing system in the blockchain network.
  • a burn fee needed for production of a block might decrease over time in proportion to time elapsed since generation of a preceding block in the blockchain.
  • a burn value of a transaction might include a transaction fee paid by an originator of the transaction for inclusion of its transaction in the blockchain.
  • a burn value of a transaction might be adjusted depending on whether the transaction contains a valid chain of embedded cryptographic signatures establishing a route that the transaction has taken in its course of propagating across the blockchain network.
  • a burn value of a transaction might be adjusted downward depending on the number of hops that the transaction has made across the blockchain network, as measured by an embedded chain of cryptographic signatures contained within the transaction that document its course of transmission across the blockchain network.
  • the burn value of the transaction might be halved with each additional hop beyond a first hop that the transaction has made through the blockchain network from its point of origin to its point of inclusion in a block.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • method 800 might comprise determining, with at least a majority of the plurality of nodes in the blockchain network, whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block.
  • Method 800 at optional block 830 , might comprise, based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, determining, with the at least a majority of the plurality of nodes in the blockchain network, that the block is valid and including, with the at least a majority of the plurality of nodes in the blockchain network, the block in a blockchain.
  • method 800 might further comprise calculating, by the one or more second nodes among the plurality of nodes within the blockchain network, a value of all unspent tokens contained in all unpruned blocks preceding (optional block 835 ); adjusting a monetary policy of the blockchain network so that the blockchain network will reintroduce the unspent tokens as tokens allocated in future blocks (optional block 840 ); and pruning, by one or more second nodes among the plurality of nodes within the blockchain network, transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain (optional block 845 ).
  • the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets
  • FIG. 9 is a block diagram illustrating an exemplary computer or system hardware architecture, in accordance with various embodiments.
  • FIG. 9 provides a schematic illustration of one embodiment of a computer system 900 of the service provider system hardware that can perform the methods provided by various other embodiments, as described herein, and/or can perform the functions of computer or hardware system (i.e., computing system 105 , nodes 110 , user devices 130 a - 130 n and 135 a - 135 n, etc.), as described above.
  • FIG. 9 is meant only to provide a generalized illustration of various components, of which one or more (or none) of each may be utilized as appropriate.
  • FIG. 9 therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner.
  • the computer or hardware system 900 which might represent an embodiment of the computer or hardware system (i.e., computing system 105 , nodes 110 , user devices 130 a - 130 n and 135 a - 135 n, etc.), described above with respect to FIGS. 1-8 —is shown comprising hardware elements that can be electrically coupled via a bus 905 (or may otherwise be in communication, as appropriate).
  • the hardware elements may include one or more processors 910 , including, without limitation, one or more general-purpose processors and/or one or more special-purpose processors (such as microprocessors, digital signal processing chips, graphics acceleration processors, and/or the like); one or more input devices 915 , which can include, without limitation, a mouse, a keyboard, and/or the like; and one or more output devices 920 , which can include, without limitation, a display device, a printer, and/or the like.
  • processors 910 including, without limitation, one or more general-purpose processors and/or one or more special-purpose processors (such as microprocessors, digital signal processing chips, graphics acceleration processors, and/or the like)
  • input devices 915 which can include, without limitation, a mouse, a keyboard, and/or the like
  • output devices 920 which can include, without limitation, a display device, a printer, and/or the like.
  • the computer or hardware system 900 may further include (and/or be in communication with) one or more storage devices 925 , which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable, and/or the like.
  • RAM random access memory
  • ROM read-only memory
  • Such storage devices may be configured to implement any appropriate data stores, including, without limitation, various file systems, database structures, and/or the like.
  • the computer or hardware system 900 might also include a communications subsystem 930 , which can include, without limitation, a modem, a network card (wireless or wired), an infra-red communication device, a wireless communication device and/or chipset (such as a BluetoothTM device, an 802.11 device, a WiFi device, a WiMax device, a WWAN device, cellular communication facilities, etc.), and/or the like.
  • the communications subsystem 930 may permit data to be exchanged with a network (such as the network described below, to name one example), with other computer or hardware systems, and/or with any other devices described herein.
  • the computer or hardware system 900 will further comprise a working memory 935 , which can include a RAM or ROM device, as described above.
  • the computer or hardware system 900 also may comprise software elements, shown as being currently located within the working memory 935 , including an operating system 940 , device drivers, executable libraries, and/or other code, such as one or more application programs 945 , which may comprise computer programs provided by various embodiments (including, without limitation, hypervisors, VMs, and the like), and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein.
  • one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a computer (or other device), in particular a general purpose computer, to perform one or more operations in accordance with the described methods.
  • a set of these instructions and/or code might be encoded and/or stored on a computer readable medium, in particular, a non-transitory computer readable storage medium, such as the storage device(s) 925 described above.
  • the storage medium might be incorporated within a computer system, such as the system 900 .
  • the storage medium might be separate from a computer system (i.e., a removable medium, such as a compact disc, etc.), and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a computer such as a general purpose computer with the instructions/code stored thereon.
  • These instructions might take the form of executable code, which is executable by the computer or hardware system 900 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer or hardware system 900 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code.
  • some embodiments may employ a computer or hardware system (such as the computer or hardware system 900 ) to perform methods in accordance with various embodiments of the invention.
  • some or all of the procedures of such methods are performed by the computer or hardware system 900 in response to processor 910 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 940 and/or other code, such as an application program 945 ) contained in the working memory 935 .
  • Such instructions may be read into the working memory 935 from another computer readable medium, such as one or more of the storage device(s) 925 .
  • execution of the sequences of instructions contained in the working memory 935 might cause the processor(s) 910 to perform one or more procedures of the methods described herein.
  • machine readable medium and “computer readable medium,” as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion.
  • various computer readable media might be involved in providing instructions/code to processor(s) 910 for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals).
  • a computer readable medium is a non-transitory, physical, and/or tangible storage medium.
  • a computer readable medium may take many forms, including, but not limited to, non-volatile media, volatile media, or the like.
  • Non-volatile media includes, for example, optical and/or magnetic disks, such as the storage device(s) 925 .
  • Volatile media includes, without limitation, dynamic memory, such as the working memory 935 .
  • a computer readable medium may take the form of transmission media, which includes, without limitation, coaxial cables, copper wire, and fiber optics, including the wires that comprise the bus 905 , as well as the various components of the communication subsystem 930 (and/or the media by which the communications subsystem 930 provides communication with other devices).
  • transmission media can also take the form of waves (including without limitation radio, acoustic, and/or light waves, such as those generated during radio-wave and infra-red data communications).
  • Common forms of physical and/or tangible computer readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.
  • Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to the processor(s) 910 for execution.
  • the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer.
  • a remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer or hardware system 900 .
  • These signals which might be in the form of electromagnetic signals, acoustic signals, optical signals, and/or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with various embodiments of the invention.
  • the communications subsystem 930 (and/or components thereof) generally will receive the signals, and the bus 905 then might carry the signals (and/or the data, instructions, etc. carried by the signals) to the working memory 935 , from which the processor(s) 905 retrieves and executes the instructions.
  • the instructions received by the working memory 935 may optionally be stored on a storage device 925 either before or after execution by the processor(s) 910 .
  • FIG. 10 illustrates a schematic diagram of a system 1000 that can be used in accordance with one set of embodiments.
  • the system 1000 can include one or more user computers, user devices, or customer devices 1005 .
  • a user computer, user device, or customer device 1005 can be a general purpose personal computer (including, merely by way of example, desktop computers, tablet computers, laptop computers, handheld computers, and the like, running any appropriate operating system, several of which are available from vendors such as Apple, Microsoft Corp., and the like), cloud computing devices, a server(s), and/or a workstation computer(s) running any of a variety of commercially-available UNIXTM or UNIX-like operating systems.
  • a user computer, user device, or customer device 1005 can also have any of a variety of applications, including one or more applications configured to perform methods provided by various embodiments (as described above, for example), as well as one or more office applications, database client and/or server applications, and/or web browser applications.
  • a user computer, user device, or customer device 1005 can be any other electronic device, such as a thin-client computer, Internet-enabled mobile telephone, and/or personal digital assistant, capable of communicating via a network (e.g., the network(s) 1010 described below) and/or of displaying and navigating web pages or other types of electronic documents.
  • a network e.g., the network(s) 1010 described below
  • the exemplary system 1000 is shown with two user computers, user devices, or customer devices 1005 , any number of user computers, user devices, or customer devices can be supported.
  • Certain embodiments operate in a networked environment, which can include a network(s) 1010 .
  • the network(s) 1010 can be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available (and/or free or proprietary) protocols, including, without limitation, TCP/IP, SNATM, IPXTM, AppleTalkTM, and the like.
  • the network(s) 1010 (similar to network(s) 120 a - 120 n, 125 , and 140 a - 140 n of FIG.
  • LAN local area network
  • WAN wide-area network
  • WWAN wireless wide area network
  • VPN virtual private network
  • PSTN public switched telephone network
  • PSTN public switched telephone network
  • a wireless network including, without limitation, a network operating under any of the IEEE 802.11 suite of protocols, the BluetoothTM protocol known in the art, and/or any other wireless protocol; and/or any combination of these and/or other networks.
  • the network might include an access network of the service provider (e.g., an Internet service provider (“ISP”)).
  • ISP Internet service provider
  • the network might include a core network of the service provider, and/or the Internet.
  • Embodiments can also include one or more server computers 1015 .
  • Each of the server computers 1015 may be configured with an operating system, including, without limitation, any of those discussed above, as well as any commercially (or freely) available server operating systems.
  • Each of the servers 1015 may also be running one or more applications, which can be configured to provide services to one or more clients 1005 and/or other servers 1015 .
  • one of the servers 1015 might be a data server, a web server, a cloud computing device(s), or the like, as described above.
  • the data server might include (or be in communication with) a web server, which can be used, merely by way of example, to process requests for web pages or other electronic documents from user computers 1005 .
  • the web server can also run a variety of server applications, including HTTP servers, FTP servers, CGI servers, database servers, Java servers, and the like.
  • the web server may be configured to serve web pages that can be operated within a web browser on one or more of the user computers 1005 to perform methods of the invention.
  • the server computers 1015 might include one or more application servers, which can be configured with one or more applications accessible by a client running on one or more of the client computers 1005 and/or other servers 1015 .
  • the server(s) 1015 can be one or more general purpose computers capable of executing programs or scripts in response to the user computers 1005 and/or other servers 1015 , including, without limitation, web applications (which might, in some cases, be configured to perform methods provided by various embodiments).
  • a web application can be implemented as one or more scripts or programs written in any suitable programming language, such as JavaTM, C, C#TM or C++, and/or any scripting language, such as Perl, Python, or TCL, as well as combinations of any programming and/or scripting languages.
  • the application server(s) can also include database servers, including, without limitation, those commercially available from OracleTM, MicrosoftTM, SybaseTM, IBMTM, and the like, which can process requests from clients (including, depending on the configuration, dedicated database clients, API clients, web browsers, etc.) running on a user computer, user device, or customer device 1005 and/or another server 1015 .
  • an application server can perform one or more of the processes for implementing blockchain transactions, and, more particularly, to methods, systems, and apparatuses for securing a blockchain with proof-of-transactions, as described in detail above.
  • Data provided by an application server may be formatted as one or more web pages (comprising HTML, JavaScript, etc., for example) and/or may be forwarded to a user computer 1005 via a web server (as described above, for example).
  • a web server might receive web page requests and/or input data from a user computer 1005 and/or forward the web page requests and/or input data to an application server.
  • a web server may be integrated with an application server.
  • one or more servers 1015 can function as a file server and/or can include one or more of the files (e.g., application code, data files, etc.) necessary to implement various disclosed methods, incorporated by an application running on a user computer 1005 and/or another server 1015 .
  • a file server can include all necessary files, allowing such an application to be invoked remotely by a user computer, user device, or customer device 1005 and/or server 1015 .
  • the system can include one or more databases 1020 a - 1020 n (collectively, “databases 1020 ”).
  • databases 1020 The location of each of the databases 1020 is discretionary: merely by way of example, a database 1020 a might reside on a storage medium local to (and/or resident in) a server 1015 a (and/or a user computer, user device, or customer device 1005 ).
  • a database 1020 n can be remote from any or all of the computers 1005 , 1015 , so long as it can be in communication (e.g., via the network 1010 ) with one or more of these.
  • a database 1020 can reside in a storage-area network (“SAN”) familiar to those skilled in the art. (Likewise, any necessary files for performing the functions attributed to the computers 1005 , 1015 can be stored locally on the respective computer and/or remotely, as appropriate.)
  • the database 1020 can be a relational database, such as an Oracle database, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.
  • the database might be controlled and/or maintained by a database server, as described above, for example.
  • system 1000 might further comprise a computing system 1025 (similar to computing system 105 of FIG. 1 , or the like), one or more nodes 1030 a- 1030 n (collectively, “nodes 1030 ” or the like; similar to nodes 110 of FIG. 1 , or the like), network(s) 1035 (similar to network(s) 120 a - 120 n or 125 of FIG. 1 , or the like), one or more peer data storage systems 1040 (similar to peer data storage systems #1-#N 115 1 - 115 N of FIG. 1 , or the like), and/or the like.
  • a computing system 1025 similar to computing system 105 of FIG. 1 , or the like
  • nodes 1030 a- 1030 n collectively, “nodes 1030 ” or the like; similar to nodes 110 of FIG. 1 , or the like
  • network(s) 1035 similar to network(s) 120 a - 120 n or 125 of FIG. 1 , or the like
  • the plurality of nodes 1030 might propagate an unconfirmed transaction across at least one of the networks 1035 .
  • the computing system 1025 or a first node 1030 a among the plurality of nodes 1030 might embed, into the unconfirmed transaction, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network to create a chain of signatures that constitutes an independently-verifiable and unforgeable record of a routing path that the unconfirmed transaction takes as it propagates across the peer-to-peer blockchain network.
  • the computing system 1025 or a second node 1030 b (not shown) among the plurality of nodes 1030 might validate the chain of signatures embedded in the transactions included in a block of a blockchain to confirm that the block itself is valid in accordance with a set of consensus rules of the blockchain.
  • the computing system 1025 or one or more third nodes 1030 c (not shown) among the plurality of nodes 1030 might quantify a level of difficulty associated with producing a valid candidate block by reducing it to a burn fee, in accordance with a set of consensus rules of a blockchain.
  • the burn fee might be a cost denominated in a value of a token managed by the blockchain network.
  • the computing system 1025 or one or more third nodes 1030 c might quantify the value of one or more transactions being included in a candidate block by reducing it to a burn value, in accordance with the set of consensus rules of the blockchain.
  • the burn value might be a figure denominated in a value of a token managed by the blockchain network.
  • the computing system 1025 or one or more third nodes 1030 c might determine whether a sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, in accordance with the set of consensus rules of the blockchain. Based on a determination that the sum of individual burn values of the one or more transactions that are included in the candidate block is equal to or greater than the burn fee of the candidate block, the computing system 1025 or one or more third nodes 1030 c might determine that the candidate block is valid according to the set of consensus rules of the blockchain.
  • At least a majority of the plurality of nodes 1030 in the blockchain network 1035 might determine whether aggregate burn values of the transactions included in a block are sufficient to pay for the burn fee required for production of a block. Based on a determination that the aggregate burn values of the transactions included in the block are sufficient to pay for the burn fee required for the production of the block, the at least a majority of the plurality of nodes 1030 might determine that the block is valid and might include the block in a blockchain.
  • At least a portion of a difference in value between a burn value of a transaction included in a block and a burn fee needed to produce a block, as measured in the value of the token managed by the blockchain network, might be granted to a node among the plurality of nodes that produces the block as a form of payment for producing the block.
  • at least a portion of the burn value of the one or more transactions included in the candidate block might be removed from circulation and not transferred to a node that produced the candidate block.
  • the computing system 1025 or one or more fourth nodes 1030 d (not shown) among the plurality of nodes 1030 within the blockchain network 1035 might prune transaction slips in blocks in a blockchain preceding an arbitrary block identified according to consensus rules of the blockchain, and might calculate a value of all unspent tokens contained in all unpruned blocks preceding and including the last block being pruned.
  • the computing system 1025 or at least one node among the plurality of nodes 1030 might adjust a monetary policy of the blockchain network so that the blockchain network would reintroduce the unspent tokens as tokens allocated in future blocks. In some cases, the unspent tokens might be reintroduced back into the blockchain network in a later block through use of golden tickets.
  • the computing system 1025 or a fifth node 1030 e (not shown) among the plurality of nodes 1030 in the blockchain network might generate a golden ticket that contains a computational puzzle.
  • the computing system 1025 or a sixth node 1030 f (not shown) among the plurality of nodes 1030 in the blockchain network might generate a solution to the computational puzzle in the golden ticket, where the solution to the computational puzzle might be used to select one or more network nodes among the plurality of nodes 1030 in the blockchain network, in a manner that cannot be anticipated by the computing system 1025 or the fifth node 1030 e generating the golden ticket.
  • At least two of the first node 1030 a, the second node 1030 b, the third node 1030 c, the fourth node 1030 d, the fifth node 1030 e, the sixth node 1030 f, and/or the computing system 1025 might be the same node.
  • the first node 1030 a, the second node 1030 b, the third node 1030 c, the fourth node 1030 d, the fifth node 1030 e, the sixth node 1030 f, and/or the computing system 1025 might be different nodes.
  • the golden ticket might be at least one of included in a block published for inclusion in a blockchain or automatically associated with the block, and/or the like.
  • the golden ticket might include, without limitation, a random number that is created using data associated with the block.
  • the random number might comprise a cryptographic hash of data content contained within the block.
  • the solution to the golden ticket might be included in a block immediately following the block in which the golden ticket is included was published.
  • any valid blockchain might contain one or more golden tickets, each of which may be solved only once.
  • nodes can be considered “computer nodes,” “lucky miners” can be considered “solution-providing miners,” “lucky nodes” can be considered “solution-selected nodes,” a “vote of the block” can be considered a “variable embedded in the block,” a “vote of the golden ticket” can be considered a “variable embedded in the golden ticket,” a “vote of the transaction” can be considered a “variable embedded in the transaction,” and a “golden ticket” can be considered a data structure containing a computational puzzle to be solved by solution-providing miners, the solution being used to select network nodes in the blockchain as described above.
  • One aspect provides a computer readable medium comprising computer executable instructions which, when executed by a computer, cause the computer to perform the method of any of the accompanying method claims or a relevant part of the method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
US16/052,974 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions Abandoned US20190044725A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/052,974 US20190044725A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions
US16/409,449 US10594488B2 (en) 2017-08-05 2019-05-10 Method and system for implementing automatic transaction rebroadcasting for transient blockchains

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762541657P 2017-08-05 2017-08-05
US16/052,974 US20190044725A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/052,944 Continuation-In-Part US20190043024A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions

Publications (1)

Publication Number Publication Date
US20190044725A1 true US20190044725A1 (en) 2019-02-07

Family

ID=65230103

Family Applications (5)

Application Number Title Priority Date Filing Date
US16/052,912 Active US10230530B2 (en) 2017-08-05 2018-08-02 Method and system for securing a blockchain with proof-of-transactions
US16/052,944 Abandoned US20190043024A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions
US16/052,974 Abandoned US20190044725A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions
US16/249,514 Active US10574464B2 (en) 2017-08-05 2019-01-16 Method and system for securing a blockchain with proof-of-transactions
US16/279,631 Abandoned US20190182048A1 (en) 2017-08-05 2019-02-19 Method and System for Securing a Blockchain with Proof-of-Transactions

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US16/052,912 Active US10230530B2 (en) 2017-08-05 2018-08-02 Method and system for securing a blockchain with proof-of-transactions
US16/052,944 Abandoned US20190043024A1 (en) 2017-08-05 2018-08-02 Method and System for Securing a Blockchain with Proof-of-Transactions

Family Applications After (2)

Application Number Title Priority Date Filing Date
US16/249,514 Active US10574464B2 (en) 2017-08-05 2019-01-16 Method and system for securing a blockchain with proof-of-transactions
US16/279,631 Abandoned US20190182048A1 (en) 2017-08-05 2019-02-19 Method and System for Securing a Blockchain with Proof-of-Transactions

Country Status (4)

Country Link
US (5) US10230530B2 (de)
EP (1) EP3662636B1 (de)
CN (3) CN110914852A (de)
WO (3) WO2019029430A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10574464B2 (en) 2017-08-05 2020-02-25 Proclus Technologies Limited Method and system for securing a blockchain with proof-of-transactions
CN110855475A (zh) * 2019-10-25 2020-02-28 昆明理工大学 一种基于区块链的共识资源切片方法
US10594488B2 (en) 2017-08-05 2020-03-17 Proclus Technologies Limited Method and system for implementing automatic transaction rebroadcasting for transient blockchains
US20220239508A1 (en) * 2020-06-03 2022-07-28 Tencent Technology (Shenzhen) Company Limited Blockchain message processing method and apparatus, computer, and readable storage medium
WO2023104488A1 (en) * 2021-12-08 2023-06-15 British Telecommunications Public Limited Company Network path verification
US11949795B2 (en) 2021-08-27 2024-04-02 Bank Of America Corporation System for tracking resources using non-fungible tokens

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10778659B2 (en) * 2012-05-24 2020-09-15 Smart Security Systems Llc System and method for protecting communications
US11871485B2 (en) * 2017-08-09 2024-01-09 Visa International Service Association Verification of interactions system and method
US11251975B1 (en) * 2017-09-27 2022-02-15 Seagate Technology Llc Block chain based trusted security infrastructure
US11165862B2 (en) * 2017-10-24 2021-11-02 0Chain, LLC Systems and methods of blockchain platform for distributed applications
US11606190B2 (en) * 2017-12-26 2023-03-14 Akamai Technologies, Inc. High performance distributed system of record with cryptographic service support
US11271717B2 (en) 2018-02-21 2022-03-08 Thunder Token Inc. Blockchain consensus methods and systems
US10630463B2 (en) * 2018-02-26 2020-04-21 Ca, Inc. Meta block chain
US12093908B2 (en) * 2018-03-22 2024-09-17 NEC Laboratories Europe GmbH System and method for secure transaction verification in a distributed ledger system
GB201805633D0 (en) * 2018-04-05 2018-05-23 Nchain Holdings Ltd Computer implemented method and system
US11262450B1 (en) * 2018-05-10 2022-03-01 Government Of The United States, As Represented By The Secretary Of The Air Force Receive only ionosonde using broadband emissions as signals of opportunity
CN111783114B (zh) 2018-08-06 2024-04-02 创新先进技术有限公司 区块链交易方法及装置、电子设备
US10548022B1 (en) * 2018-08-28 2020-01-28 Ca, Inc. Distributed ledger for wireless channel assignment
CN109359974B (zh) * 2018-08-30 2020-10-30 创新先进技术有限公司 区块链交易方法及装置、电子设备
US20200082398A1 (en) * 2018-09-07 2020-03-12 Nebulas IO Limited Proof-of-Devotion Blockchain Consensus Algorithm
JP6522842B1 (ja) * 2018-10-05 2019-05-29 さくら情報システム株式会社 情報処理装置、方法及びプログラム
US11036395B2 (en) 2018-10-18 2021-06-15 Nec Corporation Secure and transparent pruning for blockchains
US12039529B1 (en) 2018-11-21 2024-07-16 Platinum Digital Inc. Closed loop blockchain gateway system
BR112019010751B1 (pt) * 2018-12-29 2022-05-24 Advanced New Technologies Co., Ltd Método de proteção de informação implementado por computador, sistema de proteção de informação e mídia de armazenamento não transitória legível por computador
US11875400B2 (en) * 2019-01-31 2024-01-16 Salesforce, Inc. Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (DLT)
DE102019202624A1 (de) * 2019-02-27 2020-08-27 Siemens Mobility GmbH Verfahren zur Verarbeitung wenigstens einer Information in einer sicherheitstechnischen Anlage
TWI699986B (zh) * 2019-03-14 2020-07-21 柯賓漢數位金融科技有限公司 區塊鏈產生方法及系統
US10939405B1 (en) * 2019-04-08 2021-03-02 Helium Systems, Inc. Systems and methods for implementing permissionless network consensus using blockchain
GB2583770A (en) * 2019-05-10 2020-11-11 Nchain Holdings Ltd Methods and devices for registering and authenticating miner identity in a blockchain network
GB201907396D0 (en) 2019-05-24 2019-07-10 Nchain Holdings Ltd Hash function attacks
GB201907394D0 (en) * 2019-05-24 2019-07-10 Nchain Holdings Ltd Knowledge proof
GB2584154A (en) 2019-05-24 2020-11-25 Nchain Holdings Ltd Knowledge proof
US11157899B1 (en) 2019-05-28 2021-10-26 Hiro Systems Pbc System and method for bootstrapping a separate proof of work chain
US11501269B1 (en) * 2019-05-28 2022-11-15 Hiro Systems Pbc Decentralized fair mining pools
US11290280B1 (en) 2019-05-28 2022-03-29 Hiro Systems Pbc Cryptocurrency mining using a single-leader election algorithm
US11354629B1 (en) * 2019-05-28 2022-06-07 Hiro Systems Pbc Controlling initiation of a blockchain election using a burn quota
CN110224813B (zh) * 2019-06-17 2021-02-09 北京瑞策科技有限公司 基于区块链的出块方法及装置
CN110247773B (zh) * 2019-06-17 2020-12-25 北京瑞策科技有限公司 在区块链上的打包方法及装置
CN112689848B (zh) * 2019-06-28 2024-06-11 深圳市网心科技有限公司 一种区块链数据的共识方法及相关设备
CN111095218B (zh) * 2019-08-01 2022-01-11 创新先进技术有限公司 基于纠错编码存储共享的区块链数据的方法、系统及装置
US11057188B2 (en) * 2019-08-19 2021-07-06 International Business Machines Corporation Database service token
CN110991622B (zh) * 2019-08-22 2021-06-04 腾讯科技（深圳）有限公司 基于区块链网络的机器学习模型处理方法及节点
US11165787B2 (en) * 2019-08-26 2021-11-02 Bank Of America Corporation System for authorization of electronic data access and processing functions within a distributed server network
CN110705773A (zh) * 2019-09-26 2020-01-17 郑珂威 一种利用区块链共识算力实现优化运算的系统
BR112022005694A2 (pt) 2019-09-27 2022-06-21 Schvey Inc D/B/A Axoni Redução de registros em armazenadores de dados que evidenciam violação
CN110690999B (zh) * 2019-10-11 2021-06-11 腾讯科技（深圳）有限公司 基于区块链的带宽分配方法、装置、设备及存储介质
US10956204B1 (en) 2019-10-14 2021-03-23 International Business Machines Corporation Free-riding node identification for blockchain
US11483162B1 (en) 2019-12-18 2022-10-25 Wells Fargo Bank, N.A. Security settlement using group signatures
CN111242630A (zh) * 2019-12-19 2020-06-05 广州宏算信息科技有限公司 一种基于区块链的结算方法、装置及存储介质
SG10201912999VA (en) * 2019-12-23 2020-09-29 Islamic Res And Training Institute Method and System for Transaction Validation in a Distributed Computing System
CN111277627B (zh) * 2020-01-08 2022-04-01 深圳讴谱科技有限公司 一种基于贡献量权重证明共识机制的方法
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
CN112383473B (zh) * 2020-06-12 2023-02-07 支付宝(杭州)信息技术有限公司 辅助区块链网络中的节点建立p2p直连的方法
US11671240B2 (en) * 2020-06-26 2023-06-06 Microsoft Technology Licensing, Llc Data access control with a confidential blockchain network
CN111522822A (zh) 2020-07-03 2020-08-11 支付宝(杭州)信息技术有限公司 一种区块链共识方法、装置及电子设备
JP7251035B2 (ja) * 2020-07-30 2023-04-04 ダッパー ラボ インコーポレイテッド 機密知識の特殊な証明を提供するシステムおよび方法
CN111813795B (zh) 2020-08-28 2020-12-04 支付宝(杭州)信息技术有限公司 在区块链网络中确认交易的方法及装置
CN111901254B (zh) * 2020-09-28 2021-01-08 北京百度网讯科技有限公司 全节点的带宽分配方法、装置、电子设备以及存储介质
US11924355B2 (en) * 2020-10-08 2024-03-05 Chia Network Inc. Methods for grinding-resistant consensus in a proof-of-space-based blockchain
CN112434341B (zh) * 2020-11-02 2023-07-11 迅鳐成都科技有限公司 一种防业务篡改的区块链轻节点数据采集方法及装置
CN112733198B (zh) * 2020-11-02 2023-06-13 迅鳐成都科技有限公司 一种区块链轻节点数据采集方法及装置
CN113452747B (zh) * 2021-05-13 2022-12-16 西安电子科技大学 可扩展和安全的共识方法、系统、存储介质、智能终端
EP4117229A1 (de) * 2021-07-05 2023-01-11 Bull SAS Verfahren zur erkennung von anomalien in einem blockchain-netzwerk und blockchain-netzwerk zur durchführung eines solchen verfahrens
US11811944B2 (en) 2021-07-15 2023-11-07 Bank Of America Corporation Electronic system for resource origination tracking
US11985256B2 (en) 2021-07-22 2024-05-14 Bank Of America Corporation Electronic system for automatic provisioning of limited-transferability electronic digital certificates associated with events
CN113630775A (zh) * 2021-07-26 2021-11-09 一汽奔腾轿车有限公司 一种智能网联汽车安全通信系统及方法
US12015602B2 (en) 2021-08-16 2024-06-18 Bank Of America Corporation Information security system and method for secure data transmission among user profiles using a blockchain network
US11962703B2 (en) * 2022-02-08 2024-04-16 International Business Machines Corporation Cooperative session orchestration

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8337765B2 (en) 2005-08-26 2012-12-25 Honeywell International Inc. Electrocatalytically induced propellant decomposition
US20080264372A1 (en) 2007-03-19 2008-10-30 Sisk David B Two-stage ignition system
US9898782B1 (en) * 2013-06-28 2018-02-20 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US20160012465A1 (en) 2014-02-08 2016-01-14 Jeffrey A. Sharp System and method for distributing, receiving, and using funds or credits and apparatus thereof
WO2016007904A1 (en) * 2014-07-11 2016-01-14 Ribbit.me! USA Inc. Distributed ledger protocol to incentivize transactional and non-transactional commerce
US9608829B2 (en) * 2014-07-25 2017-03-28 Blockchain Technologies Corporation System and method for creating a multi-branched blockchain with configurable protocol rules
US9952908B2 (en) 2014-09-11 2018-04-24 Cisco Technology, Inc. Crowd sourced cloud computing
US20160098723A1 (en) * 2014-10-01 2016-04-07 The Filing Cabinet, LLC System and method for block-chain verification of goods
US10664923B2 (en) 2015-03-13 2020-05-26 Gyft, Inc. System and method for establishing a public ledger for gift card transactions
US20160283920A1 (en) 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
AU2016242888A1 (en) 2015-03-31 2017-11-16 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
US20160358161A1 (en) * 2015-06-05 2016-12-08 Peertracks Inc. Systems and methods for an online music marketplace
CN106296184A (zh) 2015-06-05 2017-01-04 地气股份有限公司 电子货币管理方法及电子货币系统
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
US20170109955A1 (en) 2015-10-20 2017-04-20 Follow My Vote, Inc. Blockchain electronic voting system and method
US20180331832A1 (en) 2015-11-05 2018-11-15 Allen Pulsifer Cryptographic Transactions System
CN105931052A (zh) * 2016-04-21 2016-09-07 四川大学 一种基于区块链多因子交叉验证的虚拟货币交易验证方法
CN105975868A (zh) * 2016-04-29 2016-09-28 杭州云象网络技术有限公司 一种基于区块链的证据保全方法及装置
CN105959307A (zh) * 2016-06-30 2016-09-21 中国科学院计算技术研究所 基于区块链技术的存在证明及认证服务方法及系统
US10417217B2 (en) 2016-08-05 2019-09-17 Chicago Mercantile Exchange Inc. Systems and methods for blockchain rule synchronization
US10291627B2 (en) 2016-10-17 2019-05-14 Arm Ltd. Blockchain mining using trusted nodes
CN106503589A (zh) * 2016-10-26 2017-03-15 北京瑞卓喜投科技发展有限公司 区块链交易信息正确性的校验方法、装置及系统
EP3454519B1 (de) * 2016-12-23 2021-07-21 CloudMinds (Shanghai) Robotics Co., Ltd. Blockerzeugungsverfahren und -vorrichtung und blockkettennetzwerk
CN106843774B (zh) 2017-02-24 2017-12-26 合肥工业大学 一种基于区块链的智能合约的众包构建方法
CA3055829A1 (en) 2017-03-08 2018-09-13 Ip Oversight Corporation System and method for creating commodity asset-secured tokens from reserves
CN106952124A (zh) 2017-03-16 2017-07-14 北京牛链科技有限公司 基于分布式记账的电子发票管理系统和方法
US10230530B2 (en) 2017-08-05 2019-03-12 Proclus Technologies Limited Method and system for securing a blockchain with proof-of-transactions
US10594488B2 (en) 2017-08-05 2020-03-17 Proclus Technologies Limited Method and system for implementing automatic transaction rebroadcasting for transient blockchains

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10574464B2 (en) 2017-08-05 2020-02-25 Proclus Technologies Limited Method and system for securing a blockchain with proof-of-transactions
US10594488B2 (en) 2017-08-05 2020-03-17 Proclus Technologies Limited Method and system for implementing automatic transaction rebroadcasting for transient blockchains
CN110855475A (zh) * 2019-10-25 2020-02-28 昆明理工大学 一种基于区块链的共识资源切片方法
US20220239508A1 (en) * 2020-06-03 2022-07-28 Tencent Technology (Shenzhen) Company Limited Blockchain message processing method and apparatus, computer, and readable storage medium
US11949795B2 (en) 2021-08-27 2024-04-02 Bank Of America Corporation System for tracking resources using non-fungible tokens
WO2023104488A1 (en) * 2021-12-08 2023-06-15 British Telecommunications Public Limited Company Network path verification

Also Published As

Publication number Publication date
WO2019029429A1 (en) 2019-02-14
CN110914850A (zh) 2020-03-24
WO2019029430A1 (en) 2019-02-14
US10574464B2 (en) 2020-02-25
CN110959281B (zh) 2022-03-22
US20190043024A1 (en) 2019-02-07
US20190182048A1 (en) 2019-06-13
CN110914852A (zh) 2020-03-24
EP3662636A4 (de) 2020-12-30
US20190044734A1 (en) 2019-02-07
CN110959281A (zh) 2020-04-03
US20190149336A1 (en) 2019-05-16
WO2019029431A1 (en) 2019-02-14
EP3662636B1 (de) 2022-07-20
EP3662636A1 (de) 2020-06-10
US10230530B2 (en) 2019-03-12

Similar Documents

Publication Publication Date Title
US10574464B2 (en) Method and system for securing a blockchain with proof-of-transactions
US10594488B2 (en) Method and system for implementing automatic transaction rebroadcasting for transient blockchains
CN110270097B (zh) 安全的分散式视频游戏交易平台
US20210320972A1 (en) Free storage protocol for blockchain platform
US11468431B2 (en) System and method for authorizing blockchain network transactions
KR102646102B1 (ko) 복수의 사용자들 간에 게임을 진행하여 게임 결과를 기록하기 위한 장치, 방법 컴퓨터 프로그램
JP6358658B2 (ja) ブロックチェーン生成装置、ブロックチェーン生成方法、ブロックチェーン検証装置、ブロックチェーン検証方法およびプログラム
US20180276626A1 (en) Blockchain systems and methods
JP6355168B2 (ja) ブロックチェーン生成装置、ブロックチェーン生成方法、ブロックチェーン検証装置、ブロックチェーン検証方法およびプログラム
US9579561B2 (en) Allowing interactive post of an online game within a social network
Sattath On the insecurity of quantum Bitcoin mining
Wang et al. An analytic evaluation for the impact of uncle blocks by selfish and stubborn mining in an imperfect Ethereum network
JP2024099823A (ja) ブロックチェーン・トランザクションを検証するプロトコル
KR20210068379A (ko) 게임에서 리그를 개최하는 방법
Ke et al. Ibwh: an intermittent block withholding attack with optimal mining reward rate
CN114344913A (zh) 一种游戏数据处理方法、装置、设备以及可读存储介质
JP2024037952A (ja) ゲームシステム、サーバ、プログラム、抽選イベント実行方法
WO2020229884A1 (en) Method and system for implementing automatic transaction rebroadcasting for transient blockchains
Sharma et al. Evaluating blockchain protocols with abusive modeling
Anderson et al. Reconciling Multiple Objectives–Politics or Markets?

Legal Events

Date Code Title Description
STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

AS Assignment

Owner name: PROCLUS TECHNOLOGIES LIMITED, CHINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LANCASHIRE, DAVID BEGOR;REEL/FRAME:047377/0342

Effective date: 20180728

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: 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: NON FINAL ACTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION