[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN115119531A - 使用区块链事务的多因素认证 - Google Patents

使用区块链事务的多因素认证 Download PDF

Info

Publication number
CN115119531A
CN115119531A CN202080079328.0A CN202080079328A CN115119531A CN 115119531 A CN115119531 A CN 115119531A CN 202080079328 A CN202080079328 A CN 202080079328A CN 115119531 A CN115119531 A CN 115119531A
Authority
CN
China
Prior art keywords
transaction
party
blockchain
public key
message
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.)
Pending
Application number
CN202080079328.0A
Other languages
English (en)
Inventor
丹尼尔·约瑟夫
克雷格·史蒂文·赖特
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.)
Blockchain Licensing Jsc
Original Assignee
Blockchain Licensing Jsc
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 Blockchain Licensing Jsc filed Critical Blockchain Licensing Jsc
Publication of CN115119531A publication Critical patent/CN115119531A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/321—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 a third party or a trusted authority
    • 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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/3218—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—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 proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • 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/3271—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 challenge-response
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种提供凭证以使第二当事方能够验证第一当事方身份的方法。第一当事方与向第三当事方注册的第一公钥相关联。将一个或更多个第一凭证提供给第二当事方。获得请求事务，该请求事务包括a)包括了基于第三当事方的相应私钥生成的签章的输入，以及b)锁定于第一当事方的第二公钥的输出。第二公钥基于第一公钥。第二公钥基于第一公钥。生成确认事务，该确认事务包括引用了请求事务的输出的输入以及基于与第一当事方的第二公钥相对应的私钥生成的签章。将确认事务传输到区块链网络的各节点以便被包含在区块链中。

Description

使用区块链事务的多因素认证
技术领域
本公开涉及使用区块链事务来验证当事方身份的方法。
背景技术
区块链是指分布式数据结构的一种形式，其中区块链的副本维护在对等(P2P)网络中的多个节点中的每一个节点处。区块链包括数据块的链，其中每个区块包括一个或更多个事务(transaction)。每个事务可以按顺序往回指向先前事务，每个事务可以跨越一个或更多个区块。事务可以通过被称为“挖矿”的过程来提交至网络以被包含在新的区块中，该过程涉及多个挖矿节点中的每一个竞争执行“工作证明”，即基于等待被包含在区块中的待处理事务矿池而解决密码难题。
传统上，区块链中的事务用于传递数字资产，即充当价值存储的数据。但是，也能够利用区块链在区块链之上堆加附加功能。例如，区块链协议可以允许在事务的输出中存储额外的用户数据。现代区块链正在增加可存储在单个事务中的最大数据容量，从而能够合并更复杂的数据。例如，这可用于在区块链中存储电子文件，甚至是音频或视频数据。
网络中的每个节点都可以具有如下三种作用中的任一种、两种或全部：转发、挖矿和存储。转发节点将事务传播遍布于网络各节点。挖矿节点将事务挖掘成块。存储节点分别存储区块链中它们各自挖掘的区块的副本。为了将事务记录在区块链中，当事方将事务发送到网络的节点之一以待传播。接收事务的挖矿节点可能会竞相将该事务挖掘成新区块。每个节点均配置为遵守相同的节点协议，该协议将包括一个或更多个事务有效条件。无效的事务不会被传播也不会被挖掘成区块。假设事务经过验证并因此被区块链接受，额外的用户数据将由此作为不可变的公共记录保留在P2P网络中的每个节点上。
多因素认证(MFA)越来越多地被引入到需要对寻求访问系统的个人或实体进行验证的各种系统中。例如，当尝试访问在线银行账户时，可能会使用MFA。MFA是一种验证协议，其中要求需要访问系统的实体提供通常根据独立的凭据类别的多种认证方法。通常，第一因素是密码，而另一因素的范围可以从生物特征数据到SMS文本。预计这些MFA方案将为使用它们的系统提供更高级别的安全性。
发明内容
双因素认证(2FA)是指一种类型的MFA，其中要求有两种不同形式的凭证来验证或认证用户的身份。针对2FA，通常使用SMS文本。在这种实施方式中，在提交密码后，向用户发送包含了特定代码的SMS文本。然后，用户使用此代码作为第二认证因素。这种系统安全的前提是恶意行为者(除了目标者的密码以外)不太可能访问其目标者的SMS电话和/或文本。
然而，尽管将2FA纳入验证协议的情况有所增加，但此类2FA设计中仍存在问题和漏洞。例如，SIM交换时机允许攻击者窃取目标者的电话号码，这意味着能够截取SMS消息从而获得验证码。
因此，需要一种改进的、更安全的协议来解决当前的多因素认证问题，特别是一种不易被试图窃取个人身份的攻击者拦截认证码的协议。
根据本文公开的一个方面，提供了一种提供凭证以使第二当事方能够验证第一当事方的身份的方法，其中第一当事方与第一公钥相关联，其中向第三当事方注册第一公钥，其中该方法包括：向第二当事方提供一个或更多个第一凭证；获得请求事务，所述请求事务是已经传输到区块链网络的一个或更多个节点的区块链事务，并且包括a)包括了基于第三当事方的相应私钥生成的签章的输入以及b)锁定于第一当事方的第二公钥的输出，其中第二公钥基于第一公钥；生成确认事务，所述确认事务是区块链事务，其包括引用了请求事务的输出的输入以及基于与第一当事方的第二公钥相对应的私钥生成的签章；并且，促使确认事务被传输到区块链网络的一个或更多个节点以被包含在区块链中。
由于公钥-私钥对的密码学性质，只有有权访问正确私钥的当事方才能生成签章，所述签章能够通过在第三当事方注册的相应公钥来验证。因此，经签章的确认事务充当可用于验证第一当事方的身份的另一(例如第二)凭证(或认证因素)。由于请求事务具有锁定于已注册的公钥的输出，因此只有第一当事方可以生成能解锁(即花费)该输出的事务(确认事务)。由此，任何当事方都能通过核查第一当事方是否生成了确认事务来验证第一当事方的身份。如果当事方无法生成确认事务，则他们无法访问正确的私钥，因此他们不是第一当事方。
注意，为了向第三当事方注册他们的公钥，第一当事方不需要共享他们的私钥(因此使用了“私”这个字)。事实上，第一当事方永远不需要与任何其他当事方共享他们的私钥。因此，所提供的方法不依赖于共享任何认证码等，从而抵制了攻击者截取这些代码并使用它们来不正当地将其自己识别为第一当事方的机会。
该方法可以用作2FA协议的一部分，其中经签章的确认事务是第二凭证(或认证因素)。然而，更一般地，该方法可以用作任何MFA协议，其中经签章的确认事务作为第n个凭证。
作为说明性示例，用户(第一当事方)可以是商家(第二当事方)的客户，并且可能已经向他们的银行(第三当事方)注册了他们的公钥。当尝试从商家购买时，客户向商家提供第一凭证，例如信用卡信息、姓名和地址、联系电话等。商家可以要求银行验证用户的身份，由此银行会生成能支付给第一当事方注册的公钥的请求事务。公钥可以注册为银行的“了解你的客户”(KYC)协议的一部分。用户例如通过扫描区块链，获取该请求事务，然后生成经签章的确认事务。银行看到确认事务已被只有第一当事方(如果他们拥有与注册的公钥相对应的私钥的话)能生成的签章所签署，则通知商家其正在处理的用户确实是第一当事方。然后，商家和用户可以继续他们的事务，例如购买商品或服务。
作为另一示例，用户(第一当事方)可能正在试图访问他们的、由在线供应商(第二当事方)托管的电子邮件账户。用户首先提供他们的用户名和密码，作为响应，请求事务被提交到区块链网络的各节点。该请求事务可以由在线供应商(在这种情况下第三当事方就是第二当事方)或受信任的第三当事方来生成。当生成了经签章的确认事务时，用户将被授予访问其电子邮件账户的权限。
根据本文公开的另一方面，提供了一种用于验证第一当事方的身份的方法，其中第一当事方与第一公钥相关联，其中第一公钥向第三当事方进行注册，并且其中该方法包括：接收用于验证第一当事方身份的请求；生成请求事务，该请求事务是区块链事务，其包括a)包括了基于第三当事方的相应私钥生成的签章的输入以及b)锁定于第一当事方的第二公钥的输出，其中第二公钥基于第一公钥；促使请求事务被传输到区块链网络的一个或更多个节点以便被包含在区块链中；以及确定确认事务是否已被传输到区块链网络的一个或更多个节点以便被包含在区块链中，该确认事务是区块链事务，其包括引用了请求事务的输出的输入以及基于与第一当事方的第二公钥相对应的私钥而生成的签章。
如上所述，请求事务的输出被锁定于所注册的公钥。例如，该输出可以是“支付公钥哈希”(P2PKH)输出，这要求花费事务的输入包含有注册的公钥和使用与注册的公钥相对应的私钥生成的签章。只有第一当事方才知道要正确生成这种输入所需的私钥。因此，当事方(例如第二当事方或第三当事方)能通过确定是否已经将花费了请求事务的确认事务提交到区块链网络来验证被报告成第一当事方的用户的身份。注意，如下文将讨论的，为了验证第一当事方的身份，请求事务和确认事务都不必记录在区块链中。
在某些情况下，第二当事方可以使用独立的第三当事方(例如受信任的第三当事方)作为协议的一部分来验证当事方的身份。在其他情况下，第二当事方本身可以是供第一当事方注册公钥的第三当事方。
附图说明
为了帮助理解本公开的实施例并且展示如何对这些实施例加以实施，仅以示例的方式对附图进行参考，其中：
图1是用于实现区块链的系统的示意框图；
图2示意性地示出了可记录在区块链中的事务的若干示例；
图3是用于实现区块链的另一系统的示意框图；
图4是根据基于输出模型的节点协议来处理事务的一短节点软件的示意框图；
图5是使用区块链事务来验证当事方身份的系统的示意框图；
图6是使用区块链事务来验证当事人身份的另一系统的示意框图；
图7是使用从区块链获得的区块链事务来验证当事方身份的示例性方法的序列图；
图8是使用从区块链获得的区块链事务来验证当事方身份的另一示例性方法的序列图；
图9是用于使用从事务的内存矿池(mempool)获得的区块链事务来验证当事方身份的示例性方法的序列图；
图10示意性地示出了内存矿池中的未确认事务链；
图11示意性地示出了对内存矿池中事务的双花尝试；和
图12示意性地示出了内存矿池如何充当通信介质。
具体实施方式
示例系统概述
图1总体上示出了用于实现区块链150的示例性系统100。系统100包括分组交换网络101，其通常是广域网，例如因特网。分组交换网络101包括布置成在分组交换网络101内形成对等(P2P)覆盖网络106的多个节点104。每个节点104包括一对等方的计算机设备，节点104中的不同计算机设备属于不同的对等方。每个节点104包括处理装置，该处理装置包括一个或更多个处理器，例如，一个或更多个中央处理单元(CPU)、加速器处理器、专用处理器和/或现场可编程门阵列(FPGA)。每个节点还包括存储器，即非暂时性计算机可读介质或媒介形式的计算机可读存储器。存储器可以包括采用一种或更多种存储介质的一个或更多个存储单元，例如，诸如硬盘的磁介质；诸如固态驱动器(SSD)、闪存或EEPROM的电子介质；和/或诸如光盘驱动器的光学介质。
区块链150包括数据块151的链，其中区块链150的各个副本被维护在P2P网络160的多个节点的每一节点处。链中的每个区块151包括一个或更多个事务152，其中事务在本上下文中是指一种数据结构。数据结构的性质将取决于用作事务模型或方案一部分的事务协议的类型。给定的区块链通常会自始至终使用一种特定的事务协议。在一种常见类型的事务协议中，每个事务152的数据结构包括至少一个输入和至少一个输出。每个输出指定了表示属于用户103的数字资产的数量的数额，该用户103的输出被密码锁定(需要该用户的签章以进行解锁并由此进行兑现或花费)。每个输入往回指向先前事务152的输出，由此链接各事务。
节点104中的至少若干个承担用于转发并由此传播事务152的转发节点104F的作用。节点104中的至少若干个承担用于挖掘区块151的矿工104M的作用。节点104中的至少若干个承担存储节点104S(有时也称为“完整副本”节点)的作用，其中每一个均将相同区块链150的相应副本存储在它们各自的存储器中。每个矿工节点104M还维护等待挖掘成区块151的事务152的矿池154。给定的节点104可以是转发节点104、矿工104M、存储节点104S或它们中的两种或全部的任意组合。
在给定的当前事务152j中，(每个)输入包括引用事务序列中的先前事务152i的输出的指针，该指针指定该输出将在当前事务152j中被兑现或“花费”。一般而言，先前事务可以是矿池154或任何区块151中的任何事务。先前事务152i不一定在当前事务152j被创建时或甚至发送到网络106时就存在，但是先前事务152i将需要存在并经过验证才能使当前事务有效。因此，此处的“前一”指的是通过指针链接的逻辑序列中的前驱，不一定是按时间顺序创建时间或发送时间，因此不必排除未按顺序创建或发送的事务152i，152j(参见下面关于孤儿事务的讨论)。先前事务152i可以同样被称为先行事务或在先事务。
当前事务152j的输入还包括将先前事务152i的输出锁定了的用户103a的签章。反过来，可以将当前事务152j的输出加密锁定给新用户103b。当前事务152j因此能够将定义在先前事务152i的输入中的数额随着定义在当前事务152j的输出中而转移给新用户103b。在某些情况下，事务152可以具有多个输出以在多个用户(其中之一可以是原始用户103a，以便给予改变)之间分配输入数额。在某些情况下，一个事务也可以具有多个输入以便将来自一个或更多个先前事务的多个输出的数额收集到一起，并重新分配到当前事务的一个或更多个输出。
以上可以称为“基于输出”的事务协议，有时也称为未花费事务输出(UTXO)类型的协议(其中将输出称为UTXO)。用户的总余额并未定义在区块链中存储的任何一个数字中，而是该用户需要特定的“钱包”应用程序105来整理该用户的分散在区块链151中的许多不同事务152中的所有UTXO的值。
另一种类型的事务协议可以称为“基于账户”的协议，作为基于账户的事务模型的一部分。在基于账户的情况下，每个事务并不通过往回参考过去事务序列中先前事务的UTXO来定义要转移的数额，而是通过参考绝对账户余额来定义要转移的数额。所有账户的当前状态由矿工相对于区块链而单独存储，并持续更新。在这样的系统中，使用账户的运行事务记录(也称为“头寸”)对事务进行排序。该值由发送方作为其加密签章的一部分进行签章，并作为事务参考计算的一部分进行哈希处理。此外，可选的数据字段也可以签署事务。该数据字段可以往回指向先前事务，例如当先前事务ID包含在该数据字段中时。
使用任一类型的事务协议，当用户103希望制定新事务152j时，他/她将新事务从他/她的计算机终端102发送到P2P网络106的节点104之一(现在通常为服务器或数据中心，但原则上也可以是其他用户终端)。该节点104根据在每个节点104处应用的节点协议来检查该事务是否有效。节点协议的详情将对应于所讨论的区块链150中使用的事务协议的类型，一起形成整体事务模式。节点协议通常要求节点104检查新事务152j中的加密签章是否与预期签章相匹配，所述预期签章取决于事务152的有序序列中的先前事务152i。在基于输出的情况下，这可以包括检查新事务152j的输入中包括的用户加密签章与新事务所花费的先前事务152i的输出中定义的条件相匹配，其中该条件通常包括至少检查新事务152j的输入中的加密签章解锁了新事务的输入所指向的先前事务152i的输出。在一些事务协议中，该条件可以至少部分地由包括在输入和/或输出中的自定义脚本来定义。备选的，它可能只是单独由节点协议来确定，或者可能由这些组合来确定。无论哪种方式，如果新事务152j有效，则当前节点将其转发到P2P网络106中的一个或更多个其他节点104。这些节点104中的至少若干个还充当转发节点104F，根据相同的节点协议而应用相同的测试，由此将新事务152j转发到一个或更多个另外的节点104，以此类推。以这种方式，新事务被传播遍布于节点104的网络。
在基于输出的模型中，根据节点协议，给定输出(例如UTXO)是否被花费的定义是取决于它是否尚未被另一向前事务152j的输入所有效兑现。事务有效的另一条件是它试图花费或兑现的先前事务152i的输出尚未被另一有效事务所花费/兑现。同样，如果无效，则事务152j将不会传播或记录在区块链中。这防止了双重花费，即支出者试图多次花费同一事务的输出。另一方面，基于账户的模型通过维持账户余额来防止双重花费。再次，由于存在已定义好的事务顺序，所以账户余额在任何时候都只有单一定义的状态。
除了验证之外，节点104M中的至少若干个还竞相在所谓的挖矿过程中成为第一个创建事务区块的节点，这由“工作证明”来强化。在挖矿节点104M处，将新事务添加到区块中尚未出现的有效事务的矿池中。然后，矿工们通过尝试解决密码难题，竞相从事务矿池154组装事务152的新的有效区块151。通常这包括搜索“nonce”值，使得当nonce与事务矿池154j级联并且经过哈希处理时哈希的输出满足预定条件。例如。预定条件可以是哈希的输出具有某个预定数量的前导零。哈希函数的特性是它相对于输入而言具有具有不可预测的输出。因此，这种搜索只能通过蛮力来执行，以致于在试图解决难题的每个节点104M处消耗大量的处理资源。
解决了难题的第一矿工节点104M向网络106宣布这个解，从而通过提供解来证明该解能够由网络中的其他节点104轻松核验出来(一旦给出哈希的解，就可以直接核验出该解促使哈希的输出满足了条件)。然后，基于已经在每个此类节点处核验过获胜者宣布的解，获胜者解决难题所标的的事务矿池154被充当存储节点104S的至少若干个节点104记录为区块链150中的新区块151。区块指针155也被分配给新区块151n，该新区块151n往回指向链中先前创建的区块151n-1。由于创建新区块151需要大量的努力，所以工作证明有助于降低双重花费的风险，并且由于任何包含双重花费的区块都可能被其他节点104拒绝，因此鼓励了挖矿节点104M不允许将双重花费包含在它们的区块中。一旦创建，区块151就不能被修改，因为它在P2P网络106中的每个存储节点104S处被根据相同的协议进行识别和维护。区块指针155还对各区块151施加顺序。由于事务152被记录在P2P网络106中每个存储节点104S处的有序区块中，因此这提供了事务的不可变公共分类账。
注意，竞相在任何给定时间去解决难题的不同的矿工104M可以在任何给定时间基于未挖掘事务矿池154的不同快照来这样做，这取决于他们何时开始搜索解。无论谁解决了他们各自的难题，都能够首先定义下一个新区块151n中包括哪些事务152，并且更新当前的未挖掘事务矿池154。然后，矿工104M继续竞相从新定义的未完成矿池154中创建区块，以此类推。还存在一种解决可能出现的“分叉”的协议，即两个矿工104M在很短的时间内解决了彼此的难题，使得区块链的冲突视图得以传播。简而言之，无论叉子的哪个齿长得最长，都会成为最终的区块链150。
在大多数区块链中，获胜矿工104M会被自动奖励一种特殊类型的新事务，该事务会凭空创造新数量的数字资产(与将一定数量的数字资产从一个用户转移到另一用户的正常事务相反)。因此，获胜节点被称为“挖掘”了一定数量的数字资产。这种特殊类型的事务有时被称为“创始”事务。它自动形成新区块151n的一部分。该奖励激励矿工104M参与工作证明竞赛。通常，常规(非创始)事务152还在其输出之一中指定了附加事务费用，以进一步奖励创建了包含该事务的区块151n的获胜矿工104M。
由于挖矿中涉及到了计算资源，通常至少每个矿工节点104M采用包括了一个或更多个物理服务器单元的服务器的形式，或者甚至是整个数据中心的形式。每个转发节点104M和/或存储节点104S也可以采用服务器或数据中心的形式。然而，原则上任何给定节点104均可以采取用户终端或联网在一起的一组用户终端的形式。
每个节点104的存储器存储有被配置为运行在节点104的处理装置上的软件，以便执行其各自的一种或更多种作用并根据节点协议处理事务152。应当理解，这里归属于节点104的任何动作均可由运行在相应计算机设备的处理装置上是软件来执行。此外，此处使用的术语“区块链”是泛指技术种类的通用术语，并不限于任何特定的专有区块链、协议或服务。
同样，连接到网络101的是扮演消费用户角色的多个当事方103中的每一方的计算机设备102。这些当事方在事务中充当支付方和收受方，但不一定代表其他方参与挖矿或传播事务。他们不一定运行挖矿协议。出于说明目的，示出了两个当事方103和它们各自的设备102：第一当事方103a和他/她自己的计算机设备102a，以及第二当事方103b和他/她自己的计算机设备102b。应当理解，更多这样的当事方103和他们各自的计算机设备102都可以存在并参与到系统中，但是为了方便起见，他们没有被示出。每一当事方103均可以是个人或组织。仅作为说明，第一当事方103a在本文中被称为爱丽丝(Alice)，而第二当事方103b被称为鲍勃(Bob)，但是应当理解这并非是限制性的，并且本文中对Alice或Bob的任何引用均可以替换为“第一当事方”和“第二当事方”。
每一当事方103的计算机设备102均包括各自的处理装置，该处理装置包括一个或更多个处理器，例如一个或更多个CPU、GPU、其他加速器处理器、专用处理器和/或FPGA。每一当事方103的计算机设备102还包括存储器，即非暂时性计算机可读介质或媒介形式的计算机可读存储器。该存储器可以包括一个或更多个存储器单元，该存储器单元采用一种或更多种存储介质，例如，诸如硬盘的磁介质；诸如SSD、闪存或EEPROM的电子介质；和/或诸如光盘驱动器的光学介质。每一当事方103的计算机设备102上的存储器存储有包括了被布置成运行在处理装置上的至少一个客户端应用程序105的相应实例的软件。应当理解，本文中归属于给定当事方103的任何动作都可以使用运行在相应计算机设备102的处理装置上的软件来执行。每一当事方103的计算机设备102包括至少一个用户终端，例如台式机或笔记本电脑、平板电脑、智能手机或可穿戴设备(如智能手表)。给定当事方103的计算机设备102还可以包括一个或更多个其他联网资源，例如通过用户终端访问的云计算资源。
客户端应用程序或软件105可以初始地通过合适的计算机可读存储介质或媒介来提供给任何给定当事方103的计算机设备102，例如从服务器下载，或者通过可移动存储设备来提供，例如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、磁性软盘或磁带、光盘(如CD或DVDROM)或可移动光驱动器等。
客户端应用程序105至少包括“钱包”功能。这具有两个主要功能。其中之一是使相应的用户当事方103能够创建、签署和发送待被传播遍布于节点104网络并由此包括在区块链150中的事务152。另一功能是往回向相应的当事方报告他或她目前拥有的数字资产的数额。在基于输出的系统中，该第二功能包括整理定义在属于相关当事方的、分散在整个区块链150中的各种事务152的输出中的数额。
每个计算机设备102上的客户端应用程序105的实例可操作地耦接于P2P网络106的转发节点104F中的至少一个。这使得客户端105的钱包功能能够将事务152发送到网络106。客户端105还能够联系一个、若干个或所有存储节点104，以便向区块链150查询相应当事方103为收受方的任何事务(或者实际上查看区块链150中的其他当事方的事务，因为在实施例中区块链150是一种凭借公共可见性来提供对部分事务的信任的公共设施)。每个计算机设备102上的钱包功能均被配置为根据事务协议制定和发送事务152。每个节点104运行被配置为根据节点协议验证事务152的软件，并且在作为转发节点104F的情况下，每个节点104转发事务152以便将其传播遍布于网络106。事务协议和节点协议彼此对应，给定的事务协议与给定的节点协议一起实现给定的事务模型。相同的事务协议用于区块链150中的所有事务152(尽管事务协议可以允许不同的事务子类型存在于其中)。网络106中的所有节点104都使用相同的节点协议(尽管它可以根据针对事务子类型定义的规则以不同的方式处理不同的事务子类型，并且不同的节点可以承担不同的作用并因此实现协议的不同相应方面)。
如所提到的，区块链150包括区块151的链，其中每个区块151包括一组已经由如前所述的工作证明过程所创建的一个或更多个事务152。每个区块151还包括往回指向链中先前创建的区块151的区块指针155，以便定义区块151的顺序。区块链150还包括等待被包括到经历工作证明过程的新区块中的有效事务的矿池154。每个事务152(并非创始事务)包括往回指向先前事务的指针，以便定义事务序列的顺序(注意：事务152的序列允许分支)。区块151的链一直往回到创始区块(Gb)153，创始区块是链中的第一个区块。链150早期的一个或更多个原始事务152指向创始区块153，而不是指向先前事务。
当给定当事方103，即Alice，希望发送新事务152j以将其包括在区块链150中时，她(使用她的客户端应用程序105中的钱包功能)根据相关事务协议制定新事务。然后，她从客户端应用程序105将事务152发送到她所连接的一个或更多个转发节点104F之一。例如，这可能是与Alice的计算机102最接近或最佳连接的转发节点104F。当任何给定节点104接收到新事务152j时，它会根据节点协议及其各自的作用来对该新事务进行处理。这包括首先检查新接收的事务152j是否满足“有效”的特定条件，稍后将对其示例进行更详细地讨论。在一些事务协议中，用于验证的条件可通过事务152中包含的脚本在每个事务的基础上来配置。备选的，该条件可能简单地是节点协议的内置特征，或者由脚本和节点协议的组合来定义。
在新接收到的事务152j通过测试被认为有效的条件下(即，“已验证”条件下)，任何接收到事务152j的存储节点104S都将把新的已验证事务152添加到维护在该节点104S处的区块链150副本的矿池154中。此外，任何接收到事务152j的转发节点104F都会将已验证的事务152向前传播到P2P网络106中的一个或更多个其他节点104。由于每个转发节点104F应用相同的协议，因此假设事务152j是有效的，这意味着它将很快传播遍布于P2P网络106。
一旦被允许进入维护在一个或更多个存储节点104处的区块链150副本的矿池154中，矿工节点104M将开始竞争解决关于包括了新事务152在内的最新版本的矿池154的工作量证明难题(其他矿工104M可能仍在尝试基于旧版本的矿池154来解决难题，但无论谁首先达成都将定义下一个新区块151在哪里结束以及新矿池154在哪里开始，并且最终将会有人解决矿池154中包括有Alice的事务152j的那一部分)。一旦包括有新事务152j的矿池154的工作量证明被完成，该新事务就不可改变地成为区块链150中的区块151之一的一部分。每个事务152包括有往回指向较早事务的指针，由此事务的顺序也被不可改变地记录下来。
基于UTXO的模型
图2示出了事务协议的示例。这是基于UTXO的协议的示例。事务152(缩写为“Tx”)是区块链150的基本数据结构(每个区块151包括一个或更多个事务152)。下面将通过参考基于输出或基于“UTXO”的协议来进行描述。然而，所有可能的实施例不限于此。
在基于UTXO的模型中，每个事务(“Tx”)152包括具有一个或更多个输入202和一个或更多个输出203的数据结构。每个输出203可以包括未花费事务输出(UTXO)，其可被使用作另一新事务的输入202的源(如果UTXO尚未被兑现)。UTXO指定了数字资产的数额(价值存储)。除其他信息外，它还可以包含其所来自的事务的事务ID。事务数据结构还可以包括标头201，所述标头可以包括输入字段202和输出字段203的大小的指示符。标头201还可以包括事务的ID。在实施例中，事务ID是事务数据(不包括事务ID本身)的哈希，并且存储在提交给矿工104M的原始事务152的标头201中。
注意，虽然图2中的每个输出都显示为UTXO，但事务可以附加地或备选地包括一个或更多个不可花费的事务输出。
假设Alice 103a希望创建用于将一定数额的相关数字资产转移给Bob103b的事务152j。在图2中，Alice的新事务152j标记为“TX1”。该新事务提取在序列中先前事务152i的输出203中锁定给Alice的一定数额的数字资产，并将其中的至少一部分转移给Bob。先前事务152i在图2中标记为“TX0”。TX0和TX1只是任意的标签。它们不一定意味着TX0是区块链151中的第一个事务，也不一定意味着TX1是矿池154中的紧接的下一事务。TX1可以往回指向仍然具有锁定给Alice的未花费输出203的任何先前(即先辈)事务。
在Alice创建她的新事务TX1时，或至少在她将其发送到网络106时，先前事务TX0可以已经被验证过并包含在区块链150中。它那时可能已经包含在区块151之一中，或者它可能仍在矿池154中等待，这种情况下它将很快包含在新的区块151中。备选的，可以创建TX0和TX1并一起发送到网络102，或者如果节点协议允许缓冲“孤儿”事务，则甚至可以在TX1之后发送TX0。在关于事务序列的上下文背景中使用的术语“先前”和“在后”是指由事务中的特定事务指针定义的序列中的事务顺序(哪个事务往回指向哪个其他事务，等等)。它们可被等同地替换为“前身”和“后继”，或“先辈”和“后代”，“父”和“子”等。这并不一定意指它们被创建、发送到网络106或到达任何给定节点104的顺序。然而，指向先前事务(先辈事务或“父”事务)的在后事务(后代事务或“子”事务”)除非父事务被验证否则将不会被验证。在其父事务之前到达节点104的子事务被视为孤儿事务。根据节点协议和/或矿工行为，该孤儿事务可以被丢弃或缓冲一段时间以等待父事务。
先前事务TX0的一个或更多个输出203之一包括特定的UTXO，这里标记为UTXO0。每个UTXO包括指定了由该UTXO表示的数字资产数额的值，以及锁定脚本，所述锁定脚本定义了在后事务的输入202中的解锁脚本所必须满足的条件以便对在后事务进行验证并由此成功兑现UTXO。通常，锁定脚本会将数额锁定给特定的当事方(包含了该数额的事务的受益方)。既，锁定脚本定义了解锁条件，其通常包括如下条件：在后事务的输入中的解锁脚本包括有已锁定先前事务的当事方的加密签章。
锁定脚本(又名scriptPubKey)是用可被节点协议识别的领域专用语言编写的一段代码。这种语言的特定示例称为“Script”(大写字母S)。锁定脚本指定要花费事务输出203所需要的信息，例如要求Alice的签章。锁定脚本出现在各事务的输出中。解锁脚本(又名scriptSig)是用领域专用语言编写的、提供了满足锁定脚本标准所需的信息的一段代码。例如，它可以包含有Bob的签章。解锁脚本出现在各事务的输入202中。
因此，在所示示例中，TX0的输出203中的UTXO0包括锁定脚本[Checksig PA]，该脚本需要Alice的签章Sig PA以便兑现UTXO0(严格地说，是为了使尝试兑现UTXO0的在后事务有效)。[Checksig PA]]包含来自Alice的公钥-私钥对的公钥PA。TX1的输入202包括往回指向TX1的指针(例如，通过其事务ID TXID0，在各实施例中事务ID是整个事务TX0的哈希)。TX1的输入202包括用于标识出TX0内的UTXO0的索引，以在TX0的任何其他可能输出中将其标识处理。TX1的输入202还包括解锁脚本<Sig PA>，其包括Alice的加密签章，该签章由Alice将她的私钥从钥对中应用到预定义的数据部分(密码学中有时称为“消息”)来创建。Alice需要对哪些数据(或“消息”)进行签署以提供有效签章可以由锁定脚本、节点协议或这些的组合来定义。
当新事务TX1到达节点104处时，节点应用节点协议。这包括一起运行锁定脚本和解锁脚本以核验解锁脚本是否满足锁定脚本中定义的条件(该条件可以包括一个或更多个标准)。在各实施例中，这涉及到对两个脚本级联：
<Sig PA><PA>||[Checksig PA]
其中，“||”表示级联，“<...>”表示将数据放在堆栈上，“[...]”是解锁脚本(在本示例中为基于堆栈的语言)所包含的函数。等效地，各脚本可以使用公共堆栈一个接一个地运行，而不将各脚本级联。无论哪种方式，当一起运行时，各脚本使用Alice的公钥PA(包含在TX0输出中的锁定脚本中)来认证：TX1的输入中的锁定脚本包含了Alice对预期数据部分的签章。预期数据部分本身(“消息”)也需要包含在TX0中以执行此认证。在各实施例中，签章数据包括整个TX0(由于它已经是固有存在的，因此不需要包括单独的元素来明文指定出数据的签章部分)。
本领域技术人员将熟知通过公私密码术进行认证的细节。基本上，如果Alice通过用她的私钥、给定的Alice公钥和明文消息(未加密的消息)加密消息来签署该消息，则另一实体(例如节点104)能够认证出：该消息的加密版本一定是由Alice签署过的。签署通常包括对消息进行哈希处理，对哈希进行签署，并将其标记到消息的明文版本上作为签章，从而使任何公钥持有者都能够对签章进行认证。
如果TX1中的解锁脚本满足TX0的锁定脚本中指定的一个或更多个条件(如示例所示那样，如果Alice的签章提供在TX1中并被认证)，则节点104认为TX1有效。如果节点是挖矿节点104M，这意味着该节点将把事务TX1添加到等待工作证明的事务矿池154中。如果节点是转发节点104F，该节点将把事务TX1转发到网络106中的一个或更多个其他节点104，以使得事务TX1传播遍布于网络中。一旦TX1已被验证并被包含到区块链150中，这将来自TX0的UTXO0定义为已花费。注意，TX1只有在花费未花费的事务输出203时才有效。如果TX1试图花费已被另一事务152花费掉的输出，那么即使满足所有其他条件，TX1也将是无效的。因此，节点104还需要检查先前事务TX0中引用的UTXO是否已经被花费了(已经构成了对另一有效事务的有效输入)。这就是为什么区块链150对各事务152施加规定顺序很重要的一个原因。实际上，给定节点104可以维护单独的数据库，该数据库标记了哪些事务152中的哪些UTXO 203已经被花费了，但最终定义UTXO已经被花费与否的是：它已经构成了区块链150中另一有效事务的有效输入。
注意，在基于UTXO的事务模型中，给定的UTXO需要作为一个整体来被花费。它不能“留下”UTXO中定义的数额的一小部分而花费掉另一部分。然而，来自UTXO的数额能够在下一个事务的多个输出之间分配。例如，TX0中的UTXO0中定义的数额能够在TX1中的多个UTXO之间拆分。因此，如果Alice不想给Bob UTXO0中定义的所有数额，她可以使用差额来以TX1的第二个输出给自己找零或者支付给另一当事方。
在实践中，Alice通常还需要为获胜矿工支出费用，因为现在仅靠创始事务的奖励通常不足以激励挖矿。如果Alice不支出矿工费用，则TX0可能会被矿工节点104M拒绝，因此尽管在技术上是有效的，事务TX0仍然不会被传播并包含在区块链150中(如果矿工们不想，矿工协议不强制矿工104M接受事务152)。在某些协议中，挖矿费不需要有自己单独的输出203(即，不需要单独的UTXO)。相反，各输入202指向的总数额与给定事务152的各输出203中指定的总数额之间的任何差值都会自动提供给获胜矿工104。例如，假设指向UTXO0的指针是TX1的唯一输入，并且TX1只有一个输出UTXO1。如果UTXO0中指定的数字资产数额大于UTXO1中指定的数额，则差额自动给到获胜矿工104M。然而，备选地或附加地，不一定排除矿工费用可能被明确指定在事务152的各UTXO 203之一中的情况。
还要注意，如果给定事务152的所有输出203中指定的总数额大于由其所有输入202指向的总数额，那么这是大多数事务模型中的另一种无效原因。因此，此类事务不会被传播或挖掘成区块151。
Alice和Bob的数字资产由在区块链150中任何地方的任何事务152中锁定给他们的未花费UTXO构成。因此，通常，给定当事方103的资产分散遍布于整个区块链150中各种事务152的UTXO中。区块链150中没有任何地方存储有用于定义给定当事方103的总余额的数字。客户端应用程序105中钱包功能的作用是将锁定到相应当事方的、尚未在另一在后事务中花费掉的所有各种UTXO的值整理到一起。这一点可以通过查询存储在任何存储节点104S(例如，最接近或最佳连接到相应当事方的计算机设备102的存储节点104S)上的区块链150的副本来做到。
注意，脚本代码通常以示意的方式表示(即不是确切的语言)。例如，可以用[Checksig PA]来表示[Checksig PA]＝OP_DUP OP_HASH160<H(Pa)>OP_EQUALVERIFY OP_CHECKSIG。“OP_...”指的是脚本语言的特定操作码。OP_CHECKSIG(也称为“Checksig”)是脚本操作码，其接受两个输入(签章和公钥)并使用椭圆曲线数字签章算法(ECDSA)来验证签章的有效性。在运行时，任何出现的签章(“sig”)都会从脚本中删除，但附加要求(例如哈希难题)仍保留在由“sig”输入所验证的事务中。作为另一示例，OP_RETURN是脚本语言中用于创建事务的不可花费输出的操作码，该输出能够存储事务中的元数据，从而将元数据不可变地记录在区块链150中。例如，元数据可以包括希望存储在区块链中的文件。
签章PA是数字签章。在各实施例中，这基于使用了椭圆曲线secp256k1的ECDSA。数字签章对一片特定数据进签署。在各实施例中，对于给定的事务，签章将签署事务输入的一部分以及事务输出的全部或部分。签署的各输出的特定部分由SIGHASH标志来决定。SIGHASH标志是包含在签章末尾的4字节代码，用于选择对哪些输出进行签署(并因此在签署时被确定)。
锁定脚本有时称为“scriptPubKey”，指的是锁定脚本包括有锁定了相应事务的当事方的公钥的事实。解锁脚本有时称为“scriptSig”，指的是锁定脚本提供了相应签章的事实。然而，更一般地，在区块链150的所有应用中，要兑现UTXO的条件包括对签章进行认证的做法并不是必需的。更一般地，脚本语言可用于定义任何一个或更多个条件。因此，可以首选更一般性的术语“锁定脚本”和“解锁脚本”。
可选侧信道
图3示出了用于实现区块链150的另一系统100。系统100相对于图1所描述的系统基本相同，除了涉及到附加通信功能。Alice和Bob每一方的计算机设备102a，120b上的客户端应用程序分别包括附加通信功能。也就是，(在任何当事方或第三当事方的怂恿下)使Alice 103a能够与Bob 103b建立单独的侧信道301。侧信道301能够独立于P2P网络进行数据交换。这种通信有时称为“链下”。例如，这无需将事务(尚未)发布到网络P2P 106上或进入到区块链150中就可用于在Alice和Bob之间交换事务152，直到当事方之一选择将事务广播到网络106。备选地或附加地，侧信道301可用于交换任何其他与事务相关的数据，例如密钥、协商的数额或条款、数据内容等。
侧信道301可以通过与P2P覆盖网络106相同的分组交换网络101来建立。备选的或附加的，侧信道301可以通过不同网络来建立，例如，移动蜂窝网络，或诸如本地无线网络的局域网，或者甚至是Alice和Bob的设备1021，102b之间的直接有线或无线链路等。通常，本文任何地方所涉及的侧信道301均可以包括通过用于“链下”(即，独立于P2P覆盖网络106)交换数据的一种或更多种网络技术或通信媒介的任意一个或更多个链路。在使用多于一个链路的情况下，则可以将链下链路的捆绑或集合的整体称为侧信道301。因此，注意，如果说Alice和Bob经由侧信道301交换某条信息或数据或诸如此类，那么这并不一定意指所有这些条数据都必须经由完全相同的链路或甚至相同类型的网络来发送。
节点软件
图4图示了在基于UTXO或基于输出的模型的示例中在P2P网络106的每个节点104上运行的节点软件400的示例。节点软件400包括协议引擎401，脚本引擎402，堆栈403，应用级决策引擎404以及一组一个或更多个区块链相关功能模块405。在任意给定节点104处，这些模块可以包括挖矿模块405M、转发模块405F和存储模块405S中的任意一中、两种或全部三种(取决于节点的作用)。协议引擎401配置为识别事务152的不同字段并根据节点协议对它们进行处理。当接收到具有指向另一先前事务152m-1(Txm-1)的输出(例如UTXO)的输入的事务152m(Txm)时，协议引擎401识别Txm中的解锁脚本并将其传递给脚本引擎402。协议引擎401还根据Txm的输入中的指针来识别和检索Txm-1。如果Txm-1尚未在区块链150上，则可以从相应节点自己的待处理事务的矿池154中检索Txm-1，或者如果Txm-1已经在区块链150上，则可以从存储在相应节点或另一节点104处的区块链150中的区块151的副本中检索Txm-1。无论哪种方式，脚本引擎401在Txm-1的被指针指向的输出中识别锁定脚本并将其传递给脚本引擎402。
脚本引擎402因此具有检索Txm-1的锁定脚本和来自Txm的对应输入的解锁脚本。例如，图4示出了Tx1和Tx2，但这同样适用于任何一对事务，例如Tx0和Tx1等。脚本引擎402如前所述地运行这两个脚本，这将包括根据所使用的基于堆栈脚本语言(例如Script)将数据放置到堆栈403上和从堆栈403中检索数据。
通过一起运行脚本，脚本引擎402确定解锁脚本是否满足锁定脚本中定义的一个或更多个标准——即是否“解锁”了包括有锁定脚本的输出？脚本引擎402将该确定的结果返回给协议引擎401。如果脚本引擎402确定解锁脚本确实满足相应锁定脚本中指定的一个或更多个标准，则返回结果“真”。否则，返回结果“假”。
在基于输出的模型中，来自脚本引擎402的结果“真”是事务有效性的条件之一。通常，还有一个或更多个由协议引擎401评估的其他协议级条件也必须满足；例如，Txm的各输出中指定的数字资产的总数额不得超过各输入所指向的总数额，并且Txm-1的被指针指向的输出尚未被另一有效事务花费。协议引擎401对来自脚本引擎402的结果以及一个或更多个协议级条件一起进行评估，并且只有当它们都为真时，协议引擎401才会验证事务Txm。协议引擎401向应用级决策引擎404输出事务是否有效的指示。只有在Txm确实有效的情况下，决策引擎404才可以选择要控制挖矿模块405M和转发模块405F中的一者或两者，从而针对Txm执行它们各自的区块链相关功能。这可以包括：挖矿模块405M将Txm添加到节点的相应矿池154中以便挖掘成区块151，和/或转发模块405F将Txm转发到P2P网络106中的另一节点104。然而，注意，在各实施例中，尽管决策引擎404不会选择转发或挖掘无效事务，但相反，这并不一定意味着仅仅因为事务有效就要被迫触发挖矿或转发有效事务。可选地，在各实施例中，决策引擎404可以在触发任一种或两种功能之前应用一个或更多个附加条件。例如，若节点是挖矿节点104M，则决策引擎可以仅在事务既有效且留下足够的挖矿费用的条件下才选择对该事务进行挖矿。
还要注意，这里的术语“真”和“假”尽管肯定是一种可能的实现方式，但不必限于返回以仅仅单个二进制数字(位)的形式表示的结果。更一般地，“真”可以指任何表示成功或肯定结果的状态，“假”可以指任何表示不成功或非肯定结果的状态。例如，在基于账户的模型(图4中未示出)中，可以通过由节点104进行的对签章的隐式、协议级验证和智能合约的附加性肯定输出的结合来指示结果“真”(当两个独立结果均为真时，认为整体结果为真)。
身份验证协议
通过SMS文本进行的2FA(双因子验证)是一种越来越多地被采用以增强系统和数据的安全性的协议。私人及公共系统的持续违规以及日益严格的数据法规意味着公司越来越鼓励或强迫其客户提供他们的电话号码，以便通过2FA协议保护客户的数据和服务。通过使用电话号码，在提供初始因素(例如密码登录)后，向客户的电话发送包含有字母数字值的SMS。然后，客户将这个附加值输入到系统登录中，如果正确，则客户通过“认证”并获得访问权限。系统的安全性基于这样的前提：即，恶意行为者不太可能知道客户的密码并拥有客户的电话。然而，已经证明这种系统存在一些漏洞和缺陷。一种漏洞被称为“SIM交换”，其中攻击者使用公共信息(例如姓名和地址)制作假身份证，然后在手机运营商的商店处使用该身份证冒充手机所有者。这可能导致攻击者获得一张带有所有者电话号码的新SIM卡，从而允许攻击者拦截包含有字母数字值的SMS文本。
以上概述的缺陷通过本文描述的提议性的身份验证议得以解决。区块链的使用消除了对手机操作中间人的需求，区块链的透明性意味着，如果出于任何原因，恶意行为者确实设法窃取到了用户的私钥，那么使用被盗私钥生成的事务在区块链上是不可篡改的，并且可以作为欺诈案件的证据。
2FA的另一已知示例是基于软件的认证器，其实施两步式验证服务，其中用户(或恶意行为者)需要访问运行认证器应用程序的物理设备。虽然与基于SMS的协议相比具有一些优势，但这种认证器也有其缺点，例如它依赖于集中化系统的可用性以及它对网络钓鱼的易感性。相比之下，身份验证协议使用去集中化系统(区块链网络)，由此使得任何一个节点的故障都不会妨碍系统可用。
如下文将描述的，本公开的实施例提供了身份验证协议，该协议使第一当事方能够使用已签章的区块链事务作为验证凭证，以及使第二和/或第三当事方能够使用那些已签章的区块链事务来验证第一当事方的身份。这些实施例可以用作多因素认证协议的一部分。
图5示出了用于实现身份验证协议的示例系统500。该系统包括第一当事方501和第二当事方502(图5中称为“用户”和“访问权限方”)。第一当事方501操作包括有客户端应用程序的相应计算机设备，该客户端应用程序配置为生成区块链事务152并将其传输到区块链网络106，以及(例如从区块链150)获得区块链事务152。例如，第一当事方可以扮演Alice 103a的角色，其如参考图1至图3所描述的那样来操作钱包应用程序105a。在图5的示例中，第二当事方502同样操作包括有客户端应用程序的相应计算机设备，该客户端应用程序配置为生成区块链事务152并将其传输到区块链网络106，以及(例如从区块链150)获得区块链事务152。在这种情况下，第二当事方502可以扮演Bob 103b的角色，，其如参考图1至图3所描述的那样来操作钱包应用105b。应当理解，第一当事方501和第二当事方502可以执行Alice 103a和Bob 103b两者的一些或全部动作。也就是，原则上第一当事方501和第二当事方502可以具有相同的区块链相关能力，并且命名规则仅出于说明性目的。
第二当事方502充当“访问权限方”，即他们控制对资源或服务的访问。例如，第二当事方502可以控制对例如实物产品的物理资源或例如数字票证、选票、代币等的数字资源的访问。服务的示例包括：在线账户，例如银行账户、电子邮件账户、在线零售账户等；数字流媒体服务，等等。第二当事方502可以是零售商、公司、高校、慈善机构等。第一当事方501可以是客户、雇员、学生、捐赠者等。
作为示例，第二当事方502可以是房地产的所有者，并且第一当事方501可以是已经支付过第二当事方502以便在周末访问该房地产的度假者。
第一当事方501向第二当事方注册公钥。如上所述，本领域技术人员将熟知公钥(和公钥-私钥对)。例如，第一当事方501可以在其与第二当事方502的第一次交互期间注册他们的公钥，例如作为KYC协议或账户设置的一部分。
如图5所示，第一当事方501向第二当事方502提供一个或更多个第一凭证(1-FA)。例如，第一凭证可以是用户名、密码、信用卡、姓名、地址、驾驶执照、护照、易记单词、钥匙卡等。可以通过有线或无线连接503(例如参考图3所描述的侧信道301)将第一凭证提供给第二当事方502。例如，第一当事方可以通过电子邮件、SMS文本、Wi-Fi、蓝牙、NFC等向第二当事方传输第一凭证。第一凭证可以响应于来自第二当事方502的质询(或请求)而被提供，例如作为在线购买或账户登录的一部分。备选的，第一当事方501可以在没有接收到直接请求的情况下将第一凭证提供给第二当事方502。例如，继续以第一当事方501是度假者为例，第一当事方501可以在房地产的入口处出示钥匙卡或代码(第一凭证)。
响应于接收到第一凭证，第二当事方502生成请求事务Txrt并促使请求事务Txrt被传输到区块链网络106，例如，第二当事方502将请求事务Txrt传输到网络106的一个或更多个节点或者传输给随后将该请求事务传输到网络106的不同实体。请求事务Txrt至少包括第一输入和第一输出。请求事务Txrt可以包括额外的输入和/或输出。第一输入包括第二当事方502的签章。也就是，第二当事方502通过使用第二当事方502的私钥而生成的签章对事务进行签署，该私钥可以与第一当事方501或一般性公众已知的公钥相对应。第一输出被锁定于第一当事方501注册的公钥，以致于需要使用与第一当事方501注册的公钥相对应的私钥生成的签章，才能将其解锁并由此兑现或花费。
该输出可以是包括有所注册的公钥的哈希(公钥哈希)的P2PKH输出。要花费P2PKH输出，该花费事务的输入必须包含公钥，以使得该公钥的哈希(例如OP_HASH160)与P2PKH输出中的公钥哈希相匹配。换言之，P2PKH输出要求花费者提供两个项目：公钥，从而使得该公钥的哈希与P2PKH输出中的地址相匹配；以及针对该公钥和事务消息均有效的签章(无需按此顺序)。
第一当事方501可以从第二当事方502获得请求事务Txrt。然而，优选地，第一当事方通过扫描区块链150或区块链网络106的内存矿池来找到请求事务Txrt。当事务已经通过网络被实施时，该事务被传输并保存在所谓的内存矿池(内存式矿池)中，直到挖矿节点将它包含在下一区块151中。网络106上的每个节点都操作它们各自的内存矿池。请求事务Txrt可以通过扫描区块链或内存矿池以获取可支付给公钥或公钥地址的UTXO。换言之，第一当事方的钱包应用程序会扫描区块链或内存矿池以查找可支付给其注册的公钥或该注册公钥的哈希的事务。
在获得请求事务Txrt时，第一当事方501生成确认事务Txct。确认事务Txct会花费请求事务Txrt的输出。也就是，它引用被第一当事方501的注册公钥所锁定的请求事务Txrt的输出。为了花费请求事务Txrt的输出，确认事务Txct的输入包括有使用与注册的公钥相对应的私钥生成的签章。根据请求事务Txrt的输出类型，输入还可以包括注册的公钥。如果输出是P2PKH输出，就会是这种情况。确认事务Txct包括可被锁定于第二当事方502、第一当事方501或不同当事方的输出。优选地，该输出被锁定于第二当事方502，以便第二当事方(即，第二当事方的钱包应用程序)能够扫描区块链或内存矿池以查找可支付给第二当事方502的公钥(或其哈希)的UTXO。
响应于获得确认事务Txct以及可选地附加的任何其他验证步骤，第二当事方502向第一当事方501授予对资源或服务的访问权。
因此，确认事务Txct在区块链150或内存矿池中的存在充当了用于验证第一当事方501身份的附加凭证或认证因素。
图6示出了用于实现身份认证协议的另一示例系统600。图6的系统涉及第三当事方(称为“受信任第三当事方”)601。在本示例中，第二当事方(访问权限方)502仍然控制对资源或服务的访问权，但负责第一当事方501注册公钥以及生成请求事务的任务被委托给第三当事方601。第三当事方601可以是证书颁发机构，例如受托证明公钥的当事方。例如，第三当事方可以对个人进行严格的初始身份核查以将该个人与其公钥绑定起来。作为示例，第三当事方601可以与第一当事方501进行面对面会议，以核查他们是否与例如护照或驾驶执照的官方文件相匹配。
在该示例中，第二当事方502可以操作或不操作被配置用于访问区块链网络的计算机设备，而第三当事方601则确实操作相应的计算机设备106，该计算机设备106包括被配置用于生成区块链事务152并将其传输到区块链网络106以及(例如从区块链150)获得区块链事务152的客户端应用程序。有效地，第三当事方601可以执行参考图1至图3所描述的、归属于Alice 103a或Bob 103b的一些或全部动作。
注意，在图5的示例中，下面讨论的归属于第三当事方601的动作可由第二当事方502来执行，即在该示例中，第二当事方502和第三当事方601是同一当事方。
第一当事方501例如响应于对第一凭证的请求，而向第二当事方502提供一个或更多个所述第一凭证。第二当事方向第三当事方601发送请求(2FA-请求)以验证自称为第一当事方501的用户的身份。2FA-请求可以经由侧信道504(例如互联网)来传输，或使用区块链事务152来传输。
第三当事方601生成请求事务Txrt。如上所述，请求事务包括被锁定于第一当事方501注册的公钥的输出。图5的示例与该示例之间的区别在于请求事务Txrt的输入包括由第三当事方601生成的签章。然而，不排除请求事务可以包括来自第二当事方502和第三当事方601双方各自的签章的情况。第三当事方601将请求事务Txrt传输到区块链网络106。
第一当事方501例如通过扫描区块链150或内存矿池而获得请求事务Txrt，生成确认事务Txct，并将该确认事务Txct传输到区块链网络106。
第三当事方601例如通过扫描区块链150或通过扫描网络106的一个或更多个节点的内存矿池，而确定该确认事务Txct是否曾经被传输到区块链网络106。如果该确认事务Txct已记录在区块链中或存在于一个或更多个相应内存矿池中，则第三当事方向第二当事方502发送用于通知第二当事方第一当事方的身份已被验证的指示。例如，第三当事方601可以通过侧信道504传输指示，或者向第二当事方502传输包括有该指示的区块链事务152。在一些示例中，仅当确认事务Txct(以及相应的请求事务Txrt)已经记录在区块链150中时，第三当事方601才会传输该指示。
响应于接收到该指示，第二当事方502授予第一当事方501对资源或服务的访问权。
图7示出了用于验证第一当事方501身份的示例性序列图。图7示出了第一当事方如何可以包括两个不同的用户，“用户A”701a操作相应的钱包应用程序702a(虽然不是必需的)和“用户B”701b操作相应的钱包应用程序702b。在第一当事方501包括单个用户的情况下，用户A 701a与用户B 701b是同一用户。
用户A 701a向访问权限方502提供一个或更多个凭证。访问权限方向受信任第三当事方601传输请求以验证用户A的身份。受信任第三当事方601向锁定于用户B的公钥的区块链150传输请求事务Txrt。用户B的钱包应用程序702b从区块链150获得请求事务Txrt并向用户B 701a通知该请求以便提供第二凭证。用户B使用钱包应用程序702b生成确认事务Txct，并且钱包应用程序702b将该确认事务Txct传输到区块链150。受信任第三当事方601从区块链150获得确认事务Txct并向访问权限方502发送关于已验证第一当事方身份的指示。访问权限方502向用户A 701a授予对资源或服务的访问权。在此示例中，用户B 701b证实了用户A 701a的身份。例如，用户A可能是希望从商家购买商品或访问流媒体服务内容的孩子，而用户B可以是父母，他们能够首先决定访问购买或访问是否合适，然后证实孩子的身份。然而，优选地，用户A就是用户B，并且用户A正在提供确认事务以验证他们自己的身份。
作为可选特征，锁定于第一当事方的公钥的请求事务的输出可以附加地锁定于用于生成请求事务的当事方的公钥，即第二当事方502或第三当事方601。在这种情况下，该输出是多重签章输出。多重签章(也称为多签章)输出质询花费事务的输入以便包含有能与该多重签章输出中的m选n式公钥对应的签章。因此，在这些示例中，输出可由第一当事方501解锁(即，花费)。输出可备选地由第二当事方502或第三当事方601(取决于哪一当事方来生成请求事务)来解锁。例如，如果第二当事方502生成了请求事务，则输出可能是2选1式多重签章输出，其可以由第一当事方501或第二当事方502独立解锁。注意，一旦该输出被当事方之一所解锁(即花费)，则另一当事方无法再解锁(即，双重花费)。在第一当事方501解锁多重签章输出的情况下，花费事务即是确认事务。在第二当事方502或第三当事方601解锁多重签章输出的情况下，花费事务为取消事务。例如在请求事务被提交到网络106以来已经过去了一段时间后，取消事务允许第二当事方502或第三当事方601从UTXO集中移除请求事务。
作为另一可选特征，并且为了增强第一当事方502的隐私性，第一当事方502可以向第二当事方502或第三当事方601注册第一公钥，并且第二或第三当事方可以将请求事务的输出锁定于基于第一公钥生成的第二公钥。第二公钥是以被第一当事方501和第二或第三当事方502，601双方所周知的预定方式来生成。这允许第一当事方501能够扫描区块链150或内存矿池以查找第二公钥或对其哈希，以获得请求事务。例如，第一当事方501可以生成伪随机数并共享给第二当事方502或第三当事方601，反之亦然。伪随机数可以与第一公钥结合以生成第二公钥。根据所使用的公钥方案，伪随机数可能首先必须乘以生成点，例如如果使用ECDSA方案的话。可以使用Diffie-Hellman交换或其变体在各当事方之间共享伪随机数。如果第一当事方501随后与第二当事方502交互，例如为了获得对另一资源或服务的访问权，那么第二当事方或第三当事方可以将相同的伪随机数应用于第二公钥以生成第三公钥，并将在后请求事务的输出锁定于该第三公钥。
另一可选特征是在请求事务Txrt的输出中使用质询。该质询会质询确认事务Txct的输入以便包括预定响应。注意，该质询是针对确认事务Txct的输入包括了第一当事方501的签章的要求的补充。
首先，第一当事方501可以向第二当事方502传输消息，或者第二当事方502可以向第一当事方501传输消息。在一些示例中，第一当事方501和第二当事方502可以通过交换信息的方式来共同生成消息。该消息可以包括身份验证请求的详情，例如关于第一当事方501试图访问的资源或服务的信息、时间和/或日期信息等。通常，该消息可以包含任何形式的信息。在一些示例中，该消息包括用于生成第二公钥的伪随机数。该消息可以以加密形式发送，在这种情况下，第一当事方501和第二当事方502必须知道或共享解密密钥。本领域技术人员熟知用于共享解密密钥的方法。一种此类方法是Diffie-Hellman交换。
第一当事方501在获得请求事务Txrt后，可以确定请求事务Txrt是包括原始形式(即，作为明文)的消息还是加密形式(例如，作为密文)的消息。备选的，第一当事方501可以确定请求事务Txrt是否包括原始或加密形式的消息的哈希(或更多重哈希)。多重哈希是将哈希函数两次或更多次应用于消息的结果。注意，特定的哈希函数本身可能对消息进行多次哈希。通常，应用例如双哈希函数的多重哈希函数可以包括：一次或更多次应用第一哈希函数，然后再一次或更多次应用第二哈希函数，其中第一哈希函数和第二哈希函数可以是相同的哈希函数或不同的哈希函数。此外，可以对第一和/或第二哈希函数本身一次或更多次应用哈希函数。下面使用符号H2(X)来指代对消息X应用双哈希函数，其中H2(X)＝HA(HB(X))，并且其中HA和HB可以是相同或不同的哈希(或更多重哈希)函数。例如，哈希函数H160本身就是利用了两个不同的哈希函数RIPEMD160和SHA256的哈希函数，即hash160(X)＝RIPEMD160(SHA256(X))。
如果请求事务Txrt包括了预期的消息或消息的预期哈希(可能是多重哈希)，那么第一当事方501可以仅生成确认事务Txct。优选地，如果请求事务Txrt包括了消息的双哈希，则第一当事方501可以仅生成确认事务Txct。在第三当事方601生成请求事务Txrt的情况下，第二当事方502与第三当事方601共享消息或消息的(多重)哈希。
请求事务Txrt的输出可以包括预期的消息或消息的预期哈希(可能是多重哈希)。优选地，该输出包括要求知道该消息以便确认事务Txct的输入对该输出进行解锁的质询。例如，该输出可以包括哈希难题。哈希难题获取输入值，将哈希函数应用于该输入值并将其与预定哈希进行比较。如果输入值的哈希与预定哈希相匹配，则输出值1或“真”等。在事务的输出中包含进哈希难题则要求花费事务的输入包括有能经过哈希处理得到预定哈希的确切输入值(或原像)。
例如，如果请求事务Txrt的输出包括消息的哈希，则要求确认事务Txct的输入包含该消息本身。如果请求事务Txrt的输出包括消息的双哈希，则要求确认事务Txct的输入包含该消息的哈希。通常，要求确认事务Txct的输入包含请求事务Txrt的输出中所包含的(多重)哈希的原像。
以下示例描述了身份验证协议在双因素认证系统中的使用。在此示例中，用户正在购买商品(以下称为“销售事务”)，并且预计会签署用于表明他们允许进行信用卡事务的区块链事务。在产生这样的签章事务之后，信用卡公司和/或企业预计将继续完成该销售。该销售要求使用FIAT货币支付卡，并且第一个凭证(或因素)是支付卡(信用卡或借记卡)本身(或至少是相关号码)。
优选地，在实施MFA系统时必须考虑几个关键方面。必须努力防止恶意行为者破坏系统并使系统产生不希望的结果。若非大多数情况，许多个人宁愿不将他们的金融事务详情公开。期望最好在短时间内完成2FA过程。如果最终各当事方之间存在分歧，则出于审计目的可以要求一定程度的透明度。
2FAB方案的单一设计可能无法同时充分满足上述每个标准。因此，在提出了基本设计之后，再提出针对上述考虑的附加设计。
以下示例中使用了如下的首字母缩略词。PF1 701a(例如，第一当事方501)是寻求为商品或服务付款的个人。这包括商店里有人将一篮子商品带到收银台，或者可以是有人从支持互联网的设备进行在线购买。WF1 702a是PF1的区块链钱包。该钱包负责代表PF1来访问区块链150并向区块链150提交事务。WF1还能够计算字符串/文本的哈希值，以及存储并记录这些哈希值和相关文本。企业703(例如，第二当事方502)是PF1将支付商品和服务费用的公司。银行704(例如，第三当事方601)代表发行、监管和管理信用卡/借记卡使用的机构。PF2 701b是负责签署确认事务的个人，代表第二因素。PF2可以与PF1是同一个人。事实上，理想的选择是——同一个体来证明第一因素和第二因素。然而，PF1和PF2并不总是同一个体。出于这个原因，PF1和PF2在整个WP中都表示其具有各自的身份，这允许他们不是同一个人的情况。WF2 702b是PF2的区块链钱包。该钱包负责代表PF2来访问区块链并向区块链提交事务。WF2还能够观察区块链中任何来自银行的2FA请求，然后将此请求传达给PF2。
为了便于2FA系统的设计，做出以下假设。第一，在被信用卡公司或银行704授予信用卡时，个人注册公钥(例如ECDSA公钥)。此公钥与个人的银行账户相关联。如果用户或银行出于安全原因或其他原因的需要，用户可以向银行注册新的公钥(取代先前的公钥)。第二种假设是，当银行704授予信用卡时，个人和银行关于秘密值S达成共识，如果需要/请求对区块链上的销售事务数据进行加密，则银行704可能使用该秘密值S。该秘密值S可以使用Diffie Helman协议在信用卡持有人和银行704之间安全地生成和交换，并与持卡人的账户相关联。如果用户或银行704出于安全原因或其他原因认为先前的S被泄露，则用户可以重新与银行704接触并生成新的秘密值S(取代先前的秘密值)。
图8示出了2FA系统的示例性序列图。前三个步骤(从上到下)表示当个人决定购买一篮子商品和服务时在PF1与企业703之间的交互。这里，PF1已确定了所需的项目，以正式采购订单或其他形式向企业703出示此清单。企业703构建与PF1通信的费用清单invoice或账单bill(费用清单预计包括企业的身份信息)。如果PF1对费用清单的详情感到满意，则PF1向企业703提供其必要的信用卡详情。注意，采购订单、费用清单、信用卡不一定非要亲自交给对方；这可以通过使用诸如读卡器、收银机、移动电话等电子设备来通信。在企业703获得信用卡信息之后，收银员构建消息，例如正式的“销售事务数字表示”(STDR)。这可以是费用清单和PF1的信用卡信息的结合。企业703生成事务H(STDR)的概要(即哈希)并将其传达给PF1。要求PF1拥有能够核查H(STDR)值是否正确的计算设备，例如智能手机。此功能可由智能手机上可用的WF1来执行。假设H(STDR)已得到正确计算，则钱包将保留此哈希和STDR本身的记录，以期待下一阶段的2FA请求。
假设PF1确认H(STDR)值，则企业703可以继续处理用户的信用卡。企业703将STDR信息传递给PF1的银行704。
银行704验证该信息(例如企业标识符、信用卡信息、STDR格式等)，并检索当前针对该信用卡注册的公钥(PCC＝vCCG)，其中vCC是私钥，G是生成点。在所述验证之后，银行704使用诸如H(·)＝SHA256的哈希函数产生STDR的双哈希H2(SDTR)，并创建要提交到区块链的“2FA请求事务”(Txrt)，其中所述事务的输出(出于说明目的，标记为output-2FA)使用双哈希来“锁定”。“2FA请求事务”Txrt是银行704针对销售事务而正式请求第二认证因素的事务。“所请求”的第二因素是由PCC生成的用于签署区块链事务的数字签章(ECDSA)。为了花费前面提到的输出output-2FA，该数字签章必须出现在使用所述输出的花费事务的输入脚本中。下表提供了Txrt的示例：
Figure BDA0003644098610000251
对于Txrt，此事务的输入由银行704使用公钥PBank＝vbankG进行签署，预计该公钥被所提出系统的全部利益相关者所知晓和信任。事务有两个输出——第一个是output-2FA，第二个是不可花费(例如，OP_RETURN)输出。不可花费输出用于存储与事务相关的元数据。除了OP_RETURN输出之外，还有其他方法可以在事务中存储元数据。OP_RETURN输出显示了可包含在事务中的元数据的示例。这些在下表中进行描述。
Figure BDA0003644098610000252
对于output-2FA，其受到下面复制的锁定脚本的保护
Figure BDA0003644098610000261
该锁定脚本(Script)的前半部分索要H2(SDTR)的原像，其即将成为H(STDR)，其后半部分索要与注册到信用卡的公钥相关联的ECDSA签章Sig(PCC)。假设存在PF2不知道2FA-请求或不愿意确认事务的场景(例如，因为他们没有召回和批准销售事务)，请求事务Txrt可以进行如下更改。一种方式是允许银行704具有花费掉事务Txrt的output-2FA的选项。一段时间后，例如根据银行的判断，如果PF2没有花费output-2FA(即，提供了第二认证因素)，那么银行704可以将output-2FA“退还”给它自己。由此将调整output-2FA的锁定脚本以允许银行704或PF2解锁输出。
Figure BDA0003644098610000262
如上面脚本所示，这可以通过包含m选n式多重签章条件来达成，该条件索要针对两个公钥PBank或PCC中的任一者的签章。这里，锁定脚本开始于所需的有效签章数目(m)，然后列出m个签章必须对应的n个公钥的集合，然后是值n，以及用于核查是否所有m个签章都有效的操作码OP_CHECKMULTISIG。这样，银行704可以在必要时花费output-2FA。在事务Txrt创建之后，它随后由银行704提交到区块链。
当Txrt被成功挖掘(即，将区块151包含到区块链150上)时，PF2的持续扫描区块链(UTXO)以查找2FA请求的钱包(WF2)最终将注意到区块链150上的该事务的存在，并且提醒PF2该请求的存在。钱包WF2将始终专门寻找包含了以PCC为目标(任选的以<2FAB-ID><Txrt-ID>为目标)的输出output-2FA的事务。
假设PF2就是PF1(在双人钱包情况下WF2将是WF1)，该钱包能够核查从PF1与企业703之间的初始联系点接收的所保存的H(STDR)是否与OP_RETURN输出中的STDR的解密版本以及output-2FA中的H2(STDR)相对应。如果这些值对应(或不对应)并且PF2想要进行销售事务，则PF2选择钱包WF2中的该选项。
根据PF2的指令，WF2创建事务Txct。该事务即是2FA确认事务。该事务是PF2批准银行704完成销售事务的正式确认。
Figure BDA0003644098610000271
Txct事务的输入是Txrt的输出output-2FA。由此，output-2FA的解锁脚本将是：
&lt;Sig(P<sub>CC</sub>)&gt;&lt;P<sub>CC</sub>&gt;&lt;H(STDR)&gt;
或者，如果允许银行704取消Txrt：
0&lt;sigP<sub>CC</sub>&gt;&lt;H(STDR)&gt;
PF2必须包含使用了私钥vCC的事务的签章。此外，PF2必须提供H(STDR)。PF2包含此哈希值是PF2确定他们正在响应其应该响应的确切销售事务的一种方式。注意，如果STDR中有任何字符发生更改，那么这将产生完全不同的哈希值。
事务中可以包括向银行704返回y值的至少一个输出。可以采用第二OP_RETURN输出来存储所需的元数据。元数据可以包括<2FAB-ID>以表示该事务是2FAB事务，以及包括<Txct-ID>以表示该事务具体为2FAB确认事务。该事务将被提交到区块链。
当Txrt被成功挖掘后，银行704(其钱包软件持续扫描区块链150以查找Txct)最终将注意到区块链150上Txct的存在。银行704将专门寻找包含了以银行的公钥PBank为目标(可选以<2FAB-ID><2FA-ct-ID>标签为目标)的输出的事务。
银行704承担它需要做的任何其他非2FA验证过程，相应地调整用户的信用卡余额，然后向企业703发送已签署的授权，表明销售事务已被银行704批准。授权可以是区块链事务的形式。然后，企业703向用户提供商品或服务。
在图8的示例中，存在与在区块链150上确认事务所消耗的时间相关的延迟。对于工作量证明区块链，对事务进行挖掘(即将其包括在区块链150中)的平均时间是十分钟。请求事务Txrt与正在挖掘的确认事务Txct的组合意味着：从PF1制定销售详情的初始交互开始，大约需要20分钟客户才能获得商品或服务的权利。这在某些情况下可能不切实际。
区块链网络106的各节点将它们接收到的未确认事务存储在称为未确认事务内存矿池的数据库(通常简称为内存矿池)中。并非所有接收到的事务都会被添加到内存矿池中。如果某事务双重花费已存在于内存矿池中的另一事务的输入，它就会被丢弃。如果某事务不是标准事务，它也会被丢弃。一旦节点接收到新区块，或者自己挖掘出区块，则未确认事务内存矿池就会更新，移除该区块中包含的所有事务。当事务被创建时，它被通过少量节点中继到区块链网络106。接收该新事务的节点核查它是否有效并且是否是内存矿池中已有事务的双重花费。如果该事务通过核查，则将其中继到网络中的其他节点，否则，将其丢弃。内存矿池本质上充当了区块链中等待确认的事务的临时存储器。它由区块链网络106中用于核查事务有效性(包括格式化和双重花费)的节点来维护。每个节点保留一份内存矿池的副本，将新的有效事务传递给其他节点，并接受来自其他节点的有效事务进入其内存矿池版本。
鉴于此验证过程由每个节点在其各自内存矿池中的事务上执行，一个事务存在于多个内存矿池中被视为是不完美但足够合法化的事务。内存矿池中事务的合法性特别适用于工作量证明区块链，在工作量证明区块链中第一个(有效)事务广播是将该事务包含在下一区块中。鉴于跨节点上传、验证并广播事务发生得非常快——几乎是即时的——如果支付的预计收受方以足够的信用等级愿意接受内存矿池中的有效事务(尽管没有被挖矿)，那么这大大减少了从支付方发送事务以及事务被收受方“可见并接受”之间的时间。内存矿池不仅存储那些花费挖矿事务的UTXO的有效事务，而且内存矿池还存储那些花费内存矿池中已存在但尚未挖掘的事务的输出的事务，并接受这些事务为有效。这能够在内存矿池中创建一种事务链，其中每个事务都花费先前事务的输出，而只有第一个事务是花费挖矿事务的输出的事务。目前，这种链可长达25个事务。
图9示出了利用内存矿池的经修改的2FA协议的序列图。在此示例中，WF2扫描内存矿池901(和区块链150)并在出现针对PF2的确认请求时提醒PF2。如果PF2愿意提供第二验证因素，那么PF2签署确认事务Txct，该确认事务Txct花费内存矿池中的事务Txrt的输出output-2FA。PF2将事务提交到内存矿池。银行的钱包软件扫描内存矿池以查找此类2FA确认事务，如果针对销售事务，确认事务Txct确实存在于的内存矿池中，则银行704通知企业703继续进行销售事务。
图10示出了内存矿池901中的未确认事务的链。图11示出了内存矿池901中请求事务的双花(双重花费)尝试。主要担忧的是，在内存矿池中将事务“接受”为有效(对于MFA协议或一般来说)存在双花威胁。双花是例如“TransDS”的事务与例如Txct的另一事务花费同一输出，导致Txct被视为“无效”并被从节点的内存矿池901中移除，永远不被挖掘或包含在区块中。然而，实践中已经证实，实现双花是困难或不切实际的。话虽如此，即使双花成功了，这也不会对MFA协议造成困扰。销售事务需要的第二因素是使用vCC签章的Txct。如果银行704在内存矿池中看到使用vCC签章的事务Txct，即使(由于双花或其他原因)该事务从未被确认到区块中，但PF2已经签署了该事务Txct仍然是真实的。这可以作为对第二因素的充分确认。在这种理解中，内存矿池901将充当请求事务和确认事务的通信媒介，如图12所示。为方便起见，万一发生双花并且该事务永不被挖掘，矿银行704可以在其记录中保存Txct的副本。这可用于审计或纠纷。然而，在大多数情况下，在它们各自提交后的大约十分钟内，Txrt和Txct将被挖掘到区块链中。
某些当事方(例如客户和企业)在进行销售事务时可能要求或希望有一定程度的隐私性。在前面描述的实现方式中，采取了某些措施来保护客户隐私，例如销售事务(STDR)的详情不必包含在事务中，而是可以使用销售事务(STDR)的哈希和/或加密版本。鉴于区块链150是公共的且不可变的，这些措施是可取的。输出output-2FA的锁定脚本可以通过要求哈希H(STDR)出现在花费事务(Txct)的输入脚本中的方式来包含双重哈希(H2(STDR))。如果恶意行为者能够确定原始STDR，那么如果STDR相同，则恶意行为者将能够识别区块链150上表示的所有其他销售事务。为了防止这种情况，谨慎的做法是让每个STDR都是唯一性的。在一些示例中，STDR由以下一条或更多条信息构成：费用清单(关于所购买商品的详情)、信用卡详情和企业ID(用于标识企业703的信息，例如名称、地址、注册号等)。
如果客户使用同一张信用卡反复从同一家商店购买相同的商品，则存在每次STDR相同的危险。为了区分每个销售事务，STDR中可以包含一些唯一性数据。在某些情况下，销售事务的费用清单将包括唯一性标识符，通常称为“费用清单编号”。这将解决，但仅在一定程度上解决对唯一性STDR的需求。如果每次创建新的销售事务时该编号只是简单地递增固定值，那么感兴趣的当事方在计算上很容易识别“使用同一张卡从同一个企业703购买相同商品”的每个新销售事务。如果该编号是从足够大的集合中选择的随机数，重复的概率很低，那么这将是理想的。事务时间的日期时间值也可以用作一种生成唯一性STDR哈希的方式。然而，这面临着同样的挑战，即日期时间是以可预测的方式递增的值。出于这个原因，如果有人知道了至少一个STDR，那么此人就可以迭代日期时间并计算和识别“使用同一张卡从同一家企业购买相同商品”的销售事务的哈希。作为销售事务的ID的随机数(2FAB_Rand)是首选选项。如前所述，它可以是由企业703来创建，或者可以是由个人PF1产生的随机数。作为另一种选择，它可以是通过来自企业703和PF1双方初始交互中的输入而共同生成的随机数。2FAB_Rand的生成和验证过程可以合并到PF1和企业703之间的交互中，如图9所示。
考虑PF1和企业的随机值用作为kPF1和kBus，其中
0<kPF1,kBus<q
其中，q是大素数。
那么，值2FAB_Rand可以是：
2FAB_Rand＝(kPF1+kBus)modq
经修订的STDR(STDRR)值现在将修改为：
STDRR＝STDR||2FAB_Sand
其中，||表示级联。
预计2FAB_Rand值存储在PF1的钱包中。在某些情况下，2FAB_Rand值可以作为元数据包含在例如使用值S加密的2FAB-rt事务中。
除了担忧STDR的唯一性以外，还担忧PCC公钥的唯一性。回想信用卡的所有者在被授予信用卡时向银行704注册了公钥PCC。如果每个2FA事务都发送给同一值PCC，那么感兴趣的(可能是恶意的)当事方虽然不知道具体购买了什么，但如果他们能够对PCC卡所有者进行去匿名化，则能够轻松跟踪PF1进行的每一个购买。鉴于在PF1进行每个销售事务之前都与银行704通信并注册新的PCC值是不切实际的，可以探索利用唯一性PCC值的其他选项。例如，前面描述的2FAB_Rand值可用于生成新的公钥。假设所有当事方就椭圆曲线和一组参数(例如secp256k1椭圆曲线)达成一致，该组参数包括：
·G-q阶椭圆曲线上的基点：q×G＝0；以及
·q-大素数，那么，PCC公钥可以修订为：
Figure BDA0003644098610000301
对请求事务Txrt的输出output-2FA进行修订以便寻址到公钥PCC。客户PF1/PF2负责保留2FAB_Rand的知识，以便将此值与vCC配对以创建要成功提交确认事务Txct所需的签章。企业703负责将值2FAB_RandG传送给银行704。
本公开描述了将区块链事务用作第二认证因素的身份验证协议(例如MFA协议)。针对第二认证因素的请求表示在区块链事务中，并且对第二认证因素的知识的确认预计通过意向收受方提交花费了请求事务的输出的确认事务来完成。
区块链的使用引入了其自身的复杂性，首先是事务被确认进入区块的漫长(约10分钟)等待时间。该协议为了协议目的而通过允许将内存矿池中的未确认事务视为合法来解决这个问题。这适用于请求事务以及花费了未确认请求事务的输出的确认事务。这种接受未确认事务的做法使得认证过程几乎是即时的。在这种场景下，重要的是，在几乎可以肯定这两种事务最终将在区块链上得到确认的情况下，区块链充当了用于请求和确认转换的通信媒介。
使用区块链的另一担忧是隐私问题。客户可能不愿意让第三当事方能够识别他们的购买。MFA协议通过包括使用为每个唯一性事件(销售事务)生成的随机数来缓解这些担忧。这种唯一性随机值用于伪装正在被发送2FA请求的公钥，以及用于伪装该事件详情的表征。
除了缓解区块链150固有的限制之外，MFA协议还提供了优于现有方案的优势。区块链150是分散式系统的事实意味着不依赖单个故障点的可用性。同时，区块链150的透明性和不可变性意味着将存在有关2FA请求和已发送的确认的证据。在任何与MFA确认或缺乏确认有关的调查中，与监管机构、政府或法人实体相关的审计很容易得到助力，即银行不能否认他们发送了请求事务，而PF2/PF1不能否认曾经签署过确认事务。恶意行为者无法在PF2/PF1不知情的情况下秘密提供2FA确认。如果银行或企业在没有PF1/PF2签署的确认事务的情况下处理销售事务，那么这将是显而易见的。
尽管已根据使用法定货币的销售事务对协议进行了描述，但协议可适用于管理其他要求MFA认证的“事务”，例如安全访问文件夹或实体建筑物。
在这种考虑中：
-销售事务由通用事件取代；
-企业现在被描述为看门人或访问权限方；和
-银行现在被描述为证书颁发机构的受信任第三当事方，并被视为任何负责注册PF1的公钥等的实体或系统。
结论
应当理解，以上各实施例仅以示例的方式进行描述。更一般地，可以提供根据如下声明中的任何一项或更多项的方法、装置或程序。
声明1.一种提供凭证以使第二当事方能够验证第一当事方的身份的方法，其中所述第一当事方与第一公钥相关联，其中向第三当事方注册所述第一公钥，并且其中所述方法包括：
向所述第二当事方提供一个或更多个第一凭证；
获得请求事务，所述请求事务是区块链事务，其包括a)一输入，该输入包含基于所述第三当事方的相应私钥生成的签章，和b)一输出，该输出锁定于所述第一当事方的第二公钥，其中所述第二公钥基于所述第一公钥；
生成确认事务，所述确认事务是区块链事务，其包括引用了所述请求事务的输出的输入、以及基于与所述第一当事方的第二公钥相对应的私钥生成的签章；并且
促使所述确认事务被传输到区块链网络的一个或更多个节点以便被包含在区块链中。
一个或更多个第一凭证的示例包括：用户名、密码、生物标识符、电话号码、地址、以SMS文本(从第三当事方)接收的代码、支付卡(或其信息)、银行详情、易记字词等。
声明2.如声明1所述的方法，其中，所述获得包括从所述区块链获得所述请求事务。
声明3.如声明1所述的方法，其中，所述获得包括从所述区块链网络的一个或更多个节点的相应内存矿池获得所述请求事务，其中每个相应内存矿池包括一组相应的未确认区块链事务。
声明4.如任何前述声明所述的方法，其中，所述提供一个或更多个第一凭证是响应于接收到来自所述第二当事方的身份质询。
声明5.如任何前述声明所述的方法，其中，所述促使包括将所述事务传输到所述区块链网络的一个或更多个节点。
声明6.如任何前述声明所述的方法，包括：
从所述第二当事方接收、或向所述第二当事方发送：消息和/或所述消息的哈希中的至少一种；并且
确定所述请求事务是否包括所述消息、所述消息的哈希和/所述或消息的多重哈希中的至少一种，并且其中所述生成确认事务的条件是：所述请求事务包括所述消息、所述消息的哈希和/或所述消息的多重哈希的原像中的至少一种。
声明7.如声明6所述的方法，其中，所述请求事务的输出包括要求知道所述消息和/或所述消息的哈希的质询，以便被解锁，并且其中所述确认事务的输入包括所述消息、所述消息的哈希和/或所述消息的多重哈希的原像。
声明8.如声明6或声明7所述的方法，其中，该消息包括第一伪随机数。
声明9.如声明1至声明8中任一项所述的方法，其中，通过将所述第一公钥与第二伪随机数结合来生成所述第二公钥。
声明10.如声明1至声明8中任一项所述的方法，其中，所述第二公钥是所述第一公钥。
声明11.如声明8或声明9所述的方法，其中，所述第一随机数和/或所述第二伪随机数基于由所述第一当事方生成的第三伪随机数和由所述第二当事方生成的第四伪随机数。
声明12.如声明9或声明11所述的方法，其中，所述第二伪随机数是所述第一伪随机数。
声明13.如任何前述声明所述的方法，其中，所述第三当事方是所述第二当事方。
声明14.一种验证第一当事方身份的方法，其中，所述第一当事方与第一公钥相关联，其中向第三当事方注册该第一公钥，并且其中所述方法包括：
接收用于验证所述第一当事方身份的请求；
生成请求事务，所述请求事务是区块链事务，所述区块链事务包括a)包括了基于所述第三当事方的相应私钥生成的签章的输入以及b)锁定于所述第一当事方的第二公钥的输出，其中所述第二公钥基于所述第一公钥；
促使所述请求事务被传输到区块链网络的一个或更多个节点以便被包含在区块链中；并且
确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中，所述确认事务是区块链事务，所述区块链事务包括引用了所述请求事务的输出的输入以及基于与所述第一当事方的第二公钥相对应的私钥而生成的签章。
所述请求可以是区块链事务。
声明15.如声明14所述的方法，其中，所述确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中包括：
确定所述确认事务是否被包含在所述区块链中。
声明16.如声明15所述的方法，其中，所述确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中包括：
确定所述确认事务是否被包含在所述区块链网络的一个或更多个节点的相应内存矿池中，其中每个相应内存矿池包括一组相应的未确认区块链事务。
声明17.如声明14至声明16中任一项所述的方法，包括：
根据所述确认事务是否已被传输到所述区块链网络的一个或更多个节点来验证所述第一当事方的身份。
声明18.如声明17所述的方法，其中，从第二当事方接收所述请求，并且其中所述方法包括：
向所述第二当事方传输关于所述第一当事方的身份已被验证的指示。
所述指示可以是区块链事务。
声明19.如声明18所述的方法，其中，接收所述请求包括：接收关于所述第一当事方已向所述第二当事方提供一个或更多个第一凭证的指示。
声明20.如声明18或声明19所述的方法，其中，所述请求包括消息或所述消息的哈希中的至少一种，并且其中所述请求事务的输出包括要求了解所述消息和/或所述消息的哈希的质询，以便被解锁。
声明21.如声明20所述的方法，其中，所述消息包括第一伪随机数。
声明22.如声明14至声明21中任一项所述的方法，其中，所述第二公钥是通过将所述第一公钥与第二伪随机数结合来生成的。
声明23.如声明21或声明22所述的方法，其中，所述第一随机数和/或所述第二伪随机数基于由所述第一当事方生成的第三伪随机数和由所述第二当事方生成的第四伪随机数。
声明24.如声明14至声明21中任一项所述的方法，其中，所述第二公钥是所述第一公钥。
声明25.如声明14至声明24中任一项所述的方法，其中，所述请求事务的输出被锁定于所述第一当事方的第二公钥或所述第三当事方的公钥。
声明26.如声明25所述的方法，包括：
生成取消事务，所述取消事务是区块链事务，其包括引用了所述请求事务的输出的输入以及基于与所述第一当事方的公钥相对应的私钥生成的签章；以及
促使所述取消事务被传输到所述区块链网络的一个或更多个节点以便被包含在所述区块链中。
声明27.如声明17以及其所引用的任何声明所述的方法，其中，所述第二当事方控制资源或服务的访问权或所有权，并且其中基于对所述第一当事方的身份验证，将所述资源或服务的访问权或所有权授予所述第一当事方。
资源或服务的示例包括实物商品或数字商品、电子邮件账户、社交媒体或其他在线账户、流媒体服务、数字令牌(例如票证或投票)等。
声明28.如声明14至声明27中任一项所述的方法，其中，所述第二当事方是所述第三当事方。
声明29.一种计算机设备，包括：
包括有一个或更多个存储单元的存储器；和
包括有一个或更多个处理单元的处理装置，其中所述存储器存储有被布置用于在所述处理装置上运行的代码，所述代码配置为当在所述处理装置上运行时执行声明1至声明28中任一项所述的方法。
声明30.一种计算机程序，其嵌入在计算机可读存储器上并配置为当运行在声明29所述的计算机设备上时，执行声明1至声明28中任一项所述的方法。
一旦给出本文的公开内容，本领域技术人员将会显而易见其他的变型。本公开的范围不受所公开实施例的限制，而仅由所附权利要求进行限制。

Claims (30)

1.一种提供凭证以使第二当事方能够验证第一当事方的身份的方法，其中所述第一当事方与第一公钥相关联，其中所述第一公钥是向第三当事方注册的，并且其中所述方法由所述第一当事方执行并且包括：
向所述第二当事方提供一个或更多个第一凭证；
获得请求事务，所述请求事务是已经传输到区块链网络的一个或更多个节点的区块链事务并且包括a)包含基于所述第三当事方的相应私钥生成的签章的输入、和b)锁定于所述第一当事方的第二公钥的输出，其中所述第二公钥基于所述第一公钥；
生成确认事务，所述确认事务是区块链事务，所述确认事务包括引用所述请求事务的输出的输入、和基于与所述第一当事方的第二公钥相对应的私钥生成的签章；以及
促使所述确认事务被传输到区块链网络的一个或更多个节点以便被包含在区块链中。
2.如权利要求1所述的方法，其中，所述获得包括从所述区块链获得所述请求事务。
3.如权利要求1所述的方法，其中，所述获得包括从所述区块链网络的一个或更多个节点的相应内存矿池获得所述请求事务，其中每个相应内存矿池包括一组相应的未确认区块链事务。
4.如前述权利要求中任一项所述的方法，其中，所述提供一个或更多个第一凭证是响应于接收到来自所述第二当事方的身份质询。
5.如前述权利要求中任一项所述的方法，其中，所述促使包括将所述事务传输到所述区块链网络的一个或更多个节点。
6.如前述权利要求中任一项所述的方法，包括：
从所述第二当事方接收或向所述第二当事方发送消息和/或所述消息的哈希中的至少一种；以及
确定所述请求事务是否包括所述消息、所述消息的哈希和/所述或消息的多重哈希中的至少一种，并且其中所述生成确认事务的条件是：所述请求事务包括所述消息、所述消息的哈希和/或所述消息的多重哈希的原像中的至少一种。
7.如权利要求6所述的方法，其中，所述请求事务的输出包括要求知道所述消息和/或所述消息的哈希的质询，以便被解锁，并且其中所述确认事务的输入包括所述消息、所述消息的哈希和/或所述消息的多重哈希的原像。
8.如权利要求6或7所述的方法，其中，所述消息包括第一伪随机数。
9.如权利要求1至8中任一项所述的方法，其中，通过将所述第一公钥与第二伪随机数结合来生成所述第二公钥。
10.如权利要求1至8中任一项所述的方法，其中，所述第二公钥是所述第一公钥。
11.如权利要求8或9所述的方法，其中，所述第一随机数和/或所述第二伪随机数基于由所述第一当事方生成的第三伪随机数和由所述第二当事方生成的第四伪随机数。
12.如权利要求9或11所述的方法，其中，所述第二伪随机数是所述第一伪随机数。
13.如前述权利要求中任一项所述的方法，其中，所述第三当事方是所述第二当事方。
14.一种验证第一当事方身份的方法，其中，所述第一当事方与第一公钥相关联，其中所述第一公钥是向第三当事方注册的，并且其中所述方法由所述第三当事方执行并且包括：
接收用于验证所述第一当事方身份的请求；
生成请求事务，所述请求事务是区块链事务，所述请求事务包括a)包含基于所述第三当事方的相应私钥生成的签章的输入、和b)锁定于所述第一当事方的第二公钥的输出，其中所述第二公钥基于所述第一公钥；
促使所述请求事务被传输到区块链网络的一个或更多个节点以便被包含在区块链中；以及
确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中，所述确认事务是区块链事务，所述确认事务包括引用所述请求事务的输出的输入、和基于与所述第一当事方的第二公钥相对应的私钥而生成的签章。
15.如权利要求14所述的方法，其中，所述确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中包括：
确定所述确认事务是否被包含在所述区块链中。
16.如权利要求15所述的方法，其中，所述确定确认事务是否已被传输到所述区块链网络的一个或更多个节点以便被包含在区块链中包括：
确定所述确认事务是否被包含在所述区块链网络的一个或更多个节点的相应内存矿池中，其中每个相应内存矿池包括一组相应的未确认区块链事务。
17.如权利要求14至16中任一项所述的方法，包括：
根据所述确认事务是否已被传输到所述区块链网络的一个或更多个节点来验证所述第一当事方的身份。
18.如权利要求17所述的方法，其中，从第二当事方接收所述请求，并且其中所述方法包括：
向所述第二当事方传输关于所述第一当事方的身份已被验证的指示。
19.如权利要求18所述的方法，其中，接收所述请求包括：接收关于所述第一当事方已向所述第二当事方提供一个或更多个第一凭证的指示。
20.如权利要求18或19所述的方法，其中，，所述请求包括消息或所述消息的哈希中的至少一种，并且其中所述请求事务的输出包括要求了解所述消息和/或所述消息的哈希的质询，以便被解锁。
21.如权利要求20所述的方法，其中，所述消息包括第一伪随机数。
22.如权利要求14至21中任一项所述的方法，其中，所述第二公钥是通过将所述第一公钥与第二伪随机数结合来生成的。
23.如权利要求21或22所述的方法，其中，所述第一随机数和/或所述第二伪随机数基于由所述第一当事方生成的第三伪随机数和由所述第二当事方生成的第四伪随机数。
24.如权利要求14至21中任一项所述的方法，其中，所述第二公钥是所述第一公钥。
25.如权利要求14至24中任一项所述的方法，其中，所述请求事务的输出被锁定于所述第一当事方的第二公钥或所述第三当事方的公钥。
26.如权利要求25所述的方法，包括：
生成取消事务，所述取消事务是区块链事务，其包括引用了所述请求事务的输出的输入以及基于与所述第一当事方的公钥相对应的私钥生成的签章；以及
促使所述取消事务被传输到所述区块链网络的一个或更多个节点以便被包含在所述区块链中。
27.如权利要求17及其从属于权利要求中任一项所述的方法，其中，所述第二当事方控制资源或服务的访问权或所有权，并且其中基于对所述第一当事方的身份验证，将所述资源或服务的访问权或所有权授予所述第一当事方。
28.如权利要求14至27中任一项所述的方法，其中，所述第二当事方是所述第三当事方。
29.一种计算机设备，包括：
存储器，包括有一个或更多个存储单元；和
处理装置，包括有一个或更多个处理单元，其中所述存储器存储有被布置用于在所述处理装置上运行的代码，所述代码配置为当在所述处理装置上运行时执行如权利要求1至28中任一项所述的方法。
30.一种计算机程序，其嵌入在计算机可读存储器上并配置为当运行在如权利要求29所述的计算机设备上时，执行如权利要求1至28中任一项所述的方法。
CN202080079328.0A 2019-11-15 2020-10-15 使用区块链事务的多因素认证 Pending CN115119531A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1916644.6A GB2589090A (en) 2019-11-15 2019-11-15 Identity verification protocol using blockchain transactions
GB1916644.6 2019-11-15
PCT/IB2020/059676 WO2021094854A1 (en) 2019-11-15 2020-10-15 Multi factor authentication using blockchain transactions

Publications (1)

Publication Number Publication Date
CN115119531A true CN115119531A (zh) 2022-09-27

Family

ID=69063357

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080079328.0A Pending CN115119531A (zh) 2019-11-15 2020-10-15 使用区块链事务的多因素认证

Country Status (6)

Country Link
US (1) US20220393871A1 (zh)
EP (1) EP4046326A1 (zh)
JP (1) JP2023502057A (zh)
CN (1) CN115119531A (zh)
GB (1) GB2589090A (zh)
WO (1) WO2021094854A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112311538B (zh) * 2020-10-30 2024-04-23 北京华弘集成电路设计有限责任公司 一种身份验证的方法、装置、存储介质及设备
CN112749409B (zh) * 2021-01-06 2024-03-08 上海零数众合信息科技有限公司 一种区块链中基于随机数的加密方法
US20230308283A1 (en) * 2022-03-22 2023-09-28 Hewlett-Packard Development Company, L.P. Blockchain program verifications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106911641A (zh) * 2015-12-23 2017-06-30 索尼公司 用于授权访问的客户端装置、服务器装置和访问控制系统
US10333705B2 (en) * 2016-04-30 2019-06-25 Civic Technologies, Inc. Methods and apparatus for providing attestation of information using a centralized or distributed ledger
WO2019217937A1 (en) * 2018-05-11 2019-11-14 Civic Technologies, Inc. Rewards and penalties of the reward function for the attestation game

Also Published As

Publication number Publication date
JP2023502057A (ja) 2023-01-20
US20220393871A1 (en) 2022-12-08
GB2589090A (en) 2021-05-26
WO2021094854A1 (en) 2021-05-20
GB201916644D0 (en) 2020-01-01
EP4046326A1 (en) 2022-08-24

Similar Documents

Publication Publication Date Title
US20220321359A1 (en) Methods and systems for ownership verification using blockchain
US12081531B2 (en) Secure communications using loop-based authentication flow
US20240296429A1 (en) Information transaction infrastructure
KR102296831B1 (ko) 블록체인 네트워크에 기반한 디지털 티켓의 전송
JP2021168171A (ja) 複数のトランザクションをブロックチェーンに記録する方法及びシステム
US9818092B2 (en) System and method for executing financial transactions
CN112437938A (zh) 用于区块链地址和所有者验证的系统和方法
US20150356524A1 (en) System and method for executing financial transactions
EP3959628B1 (en) Trusted customer identity systems and methods
US20230291566A1 (en) Blockchain identities
US20220303258A1 (en) Computer-implemented system and method
CN111062717B (zh) 一种数据转移处理方法、装置和计算机可读存储介质
CN115119531A (zh) 使用区块链事务的多因素认证
JP2022532889A (ja) 複数インプットトランザクション
JP2022533777A (ja) プルーフ・オブ・ワーク
CN114747172A (zh) 加密链接身份
CN118451682A (zh) 基于零知识证明的子密钥真实性
Vahidalizadehdizaj et al. Mobile payment protocol 3D (MPP 3D) by using cloud messaging
CN115836314A (zh) 区块链事务输出的概率成员资格测试
Guler Secure Bitcoin Wallet
JP2024524794A (ja) ユーザイベントストリームをダストベースのランデブートランザクションに同期する方法およびシステム
CN118476186A (zh) 基于签名的原子交换
Rubasinghe Transaction Verification Model for Peer-to-Peer Service-Oriented Digital Currency Transactions Based on the Foundation of Blockchain Architecture

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination