CN116671064A - 多重签名事务 - Google Patents

多重签名事务 Download PDF

Info

Publication number
CN116671064A
CN116671064A CN202180087427.8A CN202180087427A CN116671064A CN 116671064 A CN116671064 A CN 116671064A CN 202180087427 A CN202180087427 A CN 202180087427A CN 116671064 A CN116671064 A CN 116671064A
Authority
CN
China
Prior art keywords
transaction
input
signature
output
signed
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
CN202180087427.8A
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 CN116671064A publication Critical patent/CN116671064A/zh
Pending legal-status Critical Current

Links

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/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
    • H04L9/3255—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 using group based signatures, e.g. ring or threshold 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种用于为区块链生成多重签名事务的计算机实现的方法，包括：接收第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；对所述第一输出以及所述第一输入的所述非签名部分进行电子签名，从而生成当被包含时满足所述多重签名要求的签名，其具有：(i)相关联的sighash single标志，以及(ii)至少一个其他签名；接收第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及，对所述第二输出以及所述第二输入的所述非签名部分进行电子签名，从而生成当包含在签名部分中时至少部分地满足所述签名要求的签名，其具有相关联的sighash single标志。

Description

多重签名事务
技术领域
本公开涉及输入具有多重签名解锁要求的区块链事务。
背景技术
区块链是指一种分布式数据结构，其中在分布式对等(P2P)网络(以下称为“区块链网络”)中的多个节点中的每个节点处维护区块链的副本，并且广泛公开该副本。区块链包括一系列数据区块，其中每个区块包括一个或多个事务(transaction)。除所谓的“coinbase事务”外，每个事务都指向序列中的先前事务，该序列可以跨越一个或多个区块，回到一个或多个coinbase事务。coinbase事务将在下文进一步讨论。提交给区块链网络的事务包括在新区块中。新区块的创建过程通常称为“挖掘”，该过程涉及多个节点中的每个节点争相执行“工作量证明”，即，基于等待被包括在区块链的新区块中的一组定义的有序且核实有效的未决事务的表示解决加密难题。应当注意的是，区块链可以在一些节点处被修剪(prune)，并且区块的发布可以通过仅发布区块头来实现。
区块链中的事务可用于以下目的中的一个或多个：传送数字资产(即，一定数量的数字通证)；对虚拟化分类账或注册表中的一组条目进行排序；接收和处理时间戳条目；和/或对索引指针按时间排序。也可利用区块链实现区块链上的层级附加功能。例如，区块链协议可允许在事务中存储附加的用户数据或数据索引。能够存储在单个事务中的最大数据容量没有预先指定的限制，因此可以并入越来越复杂的数据。例如，这可用于在区块链中存储电子文档、音频或视频数据。
区块链网络的节点(通常称为“矿工”)执行分布式事务注册和验证过程，这将后续更详细地描述。总之，在该过程中，节点核实事务并将这些事务插入到区块模板中，这些事务尝试为该区块模板标识有效的工作量证明解。一旦找到有效的解，新区块便会被传播到网络的其它节点，从而使得每个节点能够在区块链上记录新区块。为了将事务记录在区块链中，用户(例如，区块链客户端应用程序)将该事务发送到网络中的节点中的一个节点进行传播。接收该事务的节点可以争相寻找将核实有效的事务并入新区块的工作量证明解。每个节点被配置为执行相同的节点协议，该协议将包括用于确认事务有效的一个或多个条件。无效事务将不会传播或并入到区块中。假定事务已经核实有效，从而在区块链上被接受，则该事务(包括任何用户数据)将因此在区块链网络中的每个节点上作为不可改变的公共记录进行注册和索引。
成功解决工作量证明难题可创建最新区块的节点通常被奖励一个称为“coinbase事务”的新事务，该事务分发数字资产数额，即通证数量。无效事务的检测和拒绝是通过竞争节点的行动来执行的，这些竞争节点充当网络的代理并且通过激励报告和阻止不正当行为。信息的广泛发布使得用户可以连续地审计节点的性能。仅发布区块头使得参与者可以确保区块链具有持续完整性。
在“基于输出的”模型(有时称为基于UTXO的模型)中，给定事务的数据结构包括一个或多个输入和一个或多个输出。任何可花费输出包括指定数字资产数额的元素，该元素可从进行中的事务序列导出。可花费输出有时称为UTXO(“未花费事务输出”)。输出还可以包括锁定脚本，该锁定脚本指定输出的未来赎回条件。锁定脚本是限定核实和传送数字通证或资产所必需的条件的谓词。事务(除coinbase事务之外)的每个输入包括指向先前事务中的此类输出的指针(即引用)，并且还可以包括解锁脚本，用于解锁指向输出的锁定脚本。因此，考虑一对事务，将其称为第一事务和第二事务(或“目标”事务)。第一事务包括指定数字资产数额的至少一个输出，并且包括定义解锁该输出的一个或多个条件的锁定脚本。第二目标事务包括至少一个输入和解锁脚本，该至少一个输入包括指向第一事务的输出的指针；该解锁脚本用于解锁第一事务的输出。
在此类模型中，当第二目标事务被发送到区块链网络以在区块链中传播和记录时，在每个节点处应用的有效性条件之一将是解锁脚本满足在第一事务的锁定脚本中定义的一个或多个条件中的所有条件。另一条件将是第一事务的输出尚未被另一早期有效事务赎回。根据这些条件中的任何一个条件发现目标事务无效的任何节点都不会传播该事务(作为有效事务，但可能注册无效事务)，也不将该事务包括在要记录在区块链中的新区块中。
另一种事务模型是基于账户的模型。在这种情况下，每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由节点单独存储到区块链中，并不断更新。
发明内容
在区块链事务中，签名有三个目的：提供对正在花费的资金的所有权或合法控制的证据；授权所述花费；以及确保事务信息的完整性。第三个功能确保在不使所述签名无效的情况下无法更改所述事务的具体详细信息。例如，对输出进行签名可以确保，一旦所述事务被广播到网络，任何人都无法拦截所述事务并修改分配资金的地址。
对于某些基于输出的事务模型，通常在对事务进行签名时，签名方创建签名，所述签名应用于所述事务中定义的所有输入和输出。然而，通过在创建签名时使用不同的标签(称为sighash标志)，可以使签名具有特定性，从而使其仅应用于或“背书”所述事务的某些元素。
在多方就单个事务进行协作的情况下，传统的sighash ALL签名方法需要各方之间进行一些初始通信以确定事务详细信息，然后才能继续进行签名。这可能效率低下，并且在许多情况下会产生不能准确反映各方之间关系的相互依赖关系。相比之下，组合不同的sighash标志可以为各方提供对所述事务的不同部分进行独立签名的灵活性。
当事务具有至少一个多重签名(multisignature)花费要求时，可能需要这种灵活性。UTXO的多个所有者需要授权花费所述UTXO，花费的UTXO被分配给这些所有者或其他各方中的个人。在一些实例中，需要为多重签名要求提供签名的人不需要同时授权向各方转账的确切数额。使用标准sighash ALL签名模型并不适合这种分层花费结构，因为在这种模型中，在提供签名之前必须知道所有输入和输出。因此，未被要求或未被授权根据与具有多重签名花费要求的UTXO相关的政策授权转账的各方仍然需要通过区块链授权转账。这可能会导致以下情况，例如，根据政策无法拒绝支付的一方不提供签名，从而阻止支付。
根据本文公开的一个方面，提供了一种用于为区块链生成多重签名事务的计算机实现的方法，所述方法包括：接收所述多重签名事务的第一输入-输出对的第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当被包含在所述第一输入的签名部分中时满足所述多重签名要求的签名，其具有：(i)相关联的sighash single标志，和(ii)相对于所述多重签名要求有效的至少一个其他签名；接收所述多重签名事务的第二输入-输出对的第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及，使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当被包含在所述第二输入的签名部分中时至少部分地满足所述签名要求的签名，其具有相关联的sighash single标志。
附图说明
为了帮助理解本公开的实施例并示出如何实施此类实施例，现将仅通过举例的方式参考附图进行说明，其中：
图1是一种用于实现区块链的系统的示意性框图；
图2示意性地示出了可记录在区块链中的事务的一些示例；
图3A示出了客户端应用程序的示意性框图；
图3B示出了可由图3A的客户端应用程序表示的示例性用户界面的示意性模型；
图4示出了用于处理事务的一些节点软件的示意性框图；
图5是具有两个签名方的示例性多重签名事务；
图6是具有三个签名方的示例性多重签名事务；
图7是生成多重签名事务的示例性方法；以及
图8是生成多重签名事务的多个用户设备的示意图。
具体实施方式
示例性系统概述
图1示出了一种用于实现区块链150的示例性系统100。系统100可以包括分组交换网络101，通常是诸如互联网的广域互联网。分组交换网络101包括多个区块链节点104，该多个区块链节点可以被设置成在分组交换网络101内形成对等(P2P)网络106。虽然未示出，但是区块链节点104可以被设置为近完全图。因此，每个区块链节点104高度连接到其它区块链节点104。
每个区块链节点104包括对等体的计算机设备，不同的节点104属于不同的对等体。每个区块链节点104包括处理装置，该处理装置包括一个或多个处理器，例如一个或多个中央处理单元(CPU)、加速器处理器、专用处理器和/或现场可编程门阵列(FPGA)，以及其它设备，例如专用集成电路(ASIC)。每个节点还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。存储器可包括一个或多个存储器单元，其采用一个或多个存储器介质，例如诸如硬盘等磁介质、诸如固态硬盘(SSD)、闪存或电可擦可编程只读存储器(EEPROM)等电子媒介和/或诸如光盘驱动器等光学介质。
区块链150包括一系列数据区块151，其中在分布式或区块链网络106中的多个区块链节点104中的每个节点处维护区块链150的相应副本。如上所述，维护区块链150的副本不一定意味着完全存储区块链150。相反，只要每个区块链节点150存储每个区块151的区块头(下面讨论)，区块链150就可以进行数据修剪。区块链中的每个区块151均包括一个或多个事务152，其中该上下文中的事务是指一种数据结构。数据结构的性质将取决于用作事务模型或计划的一部分的事务协议类型。给定的区块链全程使用一个特定的事务协议。在一种常见的事务协议中，每个事务152的数据结构至少包括一个输入和至少一个输出。每个输出指定将数字资产的数量表示为财产的数额，其一个示例是输出被密码锁定到的用户103(需要该用户的签名或其它解进行解锁，从而进行赎回或花费)。每个输入指向先前事务152的输出，从而链接这些事务。
每个区块151还包括区块指针155，其指向区块链中先前创建的区块151，以定义区块151的顺序。每个事务152(除coinbase事务之外)包括指向先前事务的指针，以定义事务序列的顺序(注：事务152的序列可进行分支)。区块151的区块链一直追溯到创始区块(Gb)153，该创始区块是区块链中的第一区块。区块链150中早期的一个或多个原始事务152指向创始区块153，而非先前事务。
每个区块链节点104被配置为将事务152转发到其它区块链节点104，从而使得事务152在整个网络106中传播。每个区块链节点104被配置为创建区块151，并将相同区块链150的相应副本存储在其相应的存储器中。每个区块链节点104还维护等待并入到区块151中的事务152的有序集(或“池”)154。有序池154通常称为“内存池”。在本文中，该术语并不意在限制于任何特定的区块链、协议或模型。该术语是指节点104已接受为有效的有序事务集，并且对于该有序事务集，强制节点104不接受试图花费相同输出的任何其它事务。
在给定的当前事务152j中，输入(或每个输入)包括指针，该指针引用事务序列中先前事务152i的输出，指定该输出将在当前事务152j中被赎回或“花费”。通常，先前事务可以是有序集154或任何区块151中的任何事务。尽管为了确保当前事务有效，将需要存在先前事务152i并核实其有效，但是在创建当前事务152j甚至向网络106发送当前事务152j时，不必存在先前事务152i。因此，在本文中，“先前”是指由指针链接的逻辑序列中的前任，而不一定是时间序列中的创建时间或发送时间，因此，不一定排除无序创建或发送事务152i、152j的情况(参见下面关于孤立事务的讨论)。先前事务152i同样可以称为先行事务或前任事务。
当前事务152j的输入还包括输入授权，例如先前事务152i的输出被锁定到的用户103a的签名。反过来，当前事务152j的输出可以加密锁定到新用户或实体103b。因此，当前事务152j可将先前事务152i的输入中定义的数额转移到当前事务152j的输出中定义的新用户或实体103b。在某些情况下，事务152可具有多个输出，以在多个用户或实体间分割输入数额(其中一个可以是原始用户或实体103a，以便进行变更)。在某些情况下，事务还可以具有多个输入，将一个或多个先前事务的多个输出中的数额汇总在一起，并重新分配到当前事务的一个或多个输出。
根据基于输出的事务协议，例如比特币，当诸如个体用户或组织这类的一方103希望颁布新的事务152j时(由该方采用的自动程序或人为地)，该颁布方将该新事务从其计算机终端102发送到接收者。颁布方或接收者将最终向网络106的一个或多个区块链节点104(现在通常是服务器或数据中心，但原则上也可以是其它用户终端)发送该事务。另外还不排除颁布新事务152j的一方103可以将事务直接发送到一个或多个区块链节点104，并且在一些示例中，可以不将事务发送到接收者。接收事务的区块链节点104根据在每个区块链节点104处应用的区块链节点协议来检查事务是否有效。区块链节点协议通常要求区块链节点104检查新事务152j中的加密签名是否与预期签名相匹配，这取决于事务152的有序序列中的先前事务152i。在这种基于输出的事务协议中，这可以包括检查新事务152j的输入中包括的一方103的密码签名或其它授权是否与新事务分配的先前事务152i的输出中定义的条件匹配，其中该条件通常包括至少检查新事务152j的输入中的密码签名或其它授权是否解锁新事务的输入所链接到的先前事务152i的输出。条件可以至少部分地由包括在先前事务152i的输出中的脚本来定义。或者，这可仅由区块链节点协议单独确定，或可通过其组合确定。无论采用哪种方式，如果新事务152j有效，区块链节点104会将其转发到区块链网络106中的一个或多个其它区块链节点104。这些其它区块链节点104根据相同的区块链节点协议应用相同的测试，并因此将新事务152j转发到一个或多个其它节点104等等。通过这种方式，新事务在区块链节点104的整个网络中进行传播。
在基于输出的模型中，给定输出(例如，UTXO)是否分配(例如，花费)的定义是，根据区块链节点协议，其是否通过另一个随后事务152j的输入有效赎回。事务有效的另一个条件是其试图赎回的先前事务152i的输出尚未被另一个事务赎回。同样，如果无效，则事务152j将不会在区块链150中传播(除非被标记为无效并且被传播用于提醒)或记录。这可防止重复花费，即事务处理者对同一个事务的输出分配超过一次。另一方面，基于账户的模型通过保持账户余额防止重复花费。因为同样存在定义的事务顺序，账户余额在任何时候均具有单一定义的状态。
除了核实事务有效之外，区块链节点104还争相成为在通常称为挖矿的过程中创建事务区块的第一个节点，而该过程由“工作量证明”支持。在区块链节点104处，新事务被添加到尚未出现在记录在区块链150上的区块151中的有效事务的有序池154。然后，区块链节点争相通过尝试解决加密难题以组装有序事务集154中事务152的新有效事务区块151。通常情况下，这包括搜索“随机数”值，从而当随机数与未决事务有序池154的表示并置且进行哈希处理时，哈希值的输出满足预定条件。例如，预定条件可以是哈希值的输出具有某个预定义的前导零数。注意，这仅仅是一种特定类型的工作量证明难题，并且不排除其它类型。哈希函数的特性是，相对于其输入，其具有不可预测的输出。因此，该搜索只能通过强力执行，从而在试图解决难题的每个区块链节点104处消耗大量的处理资源。
解决难题的第一区块链节点104在网络106上宣布难题解决，提供解决方案作为证明，然后网络中的其它区块链节点104则可以轻松检查该解决方案(一旦给出哈希值的解决方案，就可以直接检查该解决方案是否使哈希值的输出满足条件)。第一区块链节点104将一个区块传播到接受该区块的其它节点达成阈值共识，从而执行协议规则。然后，有序事务集154被每个区块链节点104记录为区块链150中的新区块151。区块指针155还分配给指向该区块链中先前创建的区块151n-1的新区块151n。创建工作量证明解所需的大量工作(例如采用哈希的形式)发出信号通知第一节点104的意图以遵循区块链协议。这些规则包括如果它分配与先前核实有效的事务相同的输出，则不接受事务为有效，否则称之为重复花费。一旦创建，区块151就不能修改，因为它在区块链网络106中的每个区块链节点104处进行标识和维护。区块指针155还向区块151施加顺序。由于事务152记录在网络106中每个区块链节点104处的有序区块中，因此提供了事务的不可改变公共分类账。
应当注意的是，在任何给定时间争相解决难题的不同区块链节点104可以基于在任何给定时间尚未发布的事务的池154的不同快照来这样做，具体取决于它们何时开始搜索解或接收事务的顺序。解决相应难题的人员首先定义新区块151n中包括的事务152及其顺序，并且更新当前的未发布事务池154。然后，区块链节点104继续争相从新定义的未发布事务有序池154中创建区块，等等。此外，还存在解决可能出现的任何“分叉”的协议，其中两个区块链节点104彼此在很短的时间内解决难题，从而在节点104之间传播区块链的冲突视图。简言之，分叉方向最长的成为最终区块链150。应当注意的是，这不会影响网络的用户或代理，因为同一事务将出现在两个分叉中。
根据比特币区块链(和大多数其它区块链)，成功构造新区块104的节点被授予在分配附加限定数量数字资产的新特殊类型事务中新分配附加的、接受的数额的数字资产的能力(与代理间或用户间事务相反，该事务将一定数量的数字资产从一个代理或用户转移到另一个代理或用户)。这种特殊类型的事务通常称为“coinbase事务”，但是也可以称为“启动事务”或“产生事务”。它通常形成新区块151n的第一事务。工作量证明发出信号通知构造新区块的节点的意图以遵循协议规则，从而允许稍后赎回该特定事务。在可以赎回该特殊事务之前，区块链协议规则可能需要成熟期，例如100个区块。通常，常规(非生成)事务152还将在其输出中的一个输出中指定附加事务费用，以进一步奖励创建其中发布该事务的区块151n的区块链节点104。该费用通常称为“事务费用”，并在下文中讨论。
由于事务核实和发布中涉及的资源，通常至少每个区块链节点104采用包括一个或多个物理服务器单元的服务器的形式，或者甚至整个数据中心。但是，原则上来说，任何给定区块链节点104均可采用一个用户终端或联网在一起的一组用户终端的形式。
每个区块链节点104的存储器均存储被配置为在区块链节点104的处理装置上运行的软件，以根据区块链节点协议执行其相应的角色并处理事务152。应当理解的是，在本文中归因于区块链节点104的任何动作均可通过在相应计算机设备的处理装置上运行的软件执行。节点软件可以在应用层或诸如操作系统层或协议层的较低层或这些层任意组合的一个或多个应用中实现。
扮演消费用户角色的多方103中的每一方的计算机设备102也连接到网络101。这些用户可以与区块链网络106交互，但不参与核实事务或构造区块。其中一些用户或代理103可以充当事务中的发送者和接收者。其它用户可以与区块链150交互，而不必充当发送者或接收者。例如，一些当事方可以充当存储区块链150的副本(例如，已经从区块链节点104获得区块链的副本)的存储实体。
各方103中的一些或所有当事方可以作为不同网络的一部分连接，例如覆盖在区块链网络106之上的网络。区块链网络的用户(经常称为“客户端”)可以被称为是包含区块链网络106的系统的一部分；然而，这些用户不是区块链节点104，因为它们不执行区块链节点所需的角色。相反，每一方103可以与区块链网络106交互，从而通过连接到区块链节点106(即，与区块链节点106通信)来利用区块链150。出于说明目的，示出了双方103及其相应的设备102：第一方103a及其相应的计算机设备102a，以及第二方103b及其相应的计算机设备102b。应当理解的是，更多此类当事方103及其相应的计算机设备102可能存在并参与系统100，但为了方便起见，未进行说明。每一方103均可以是个人或组织。仅出于说明目的，在本文中，第一方103a称为爱丽丝，第二方103b称为鲍勃，但应当理解的是，这并不仅限于爱丽丝或鲍勃，且本文对爱丽丝或鲍勃的任何引用均可分别用“第一方”和“第二方”替换。
每一方103的计算机设备102包括相应的处理装置，其包括一个或更多个处理器，例如一个或更多个CPU、图形处理单元(GPU)、其他加速器处理器、特定应用程序处理器和/或FPGA。每一方103的计算机设备102还包括存储器，即采用非暂时性计算机可读介质形式的计算机可读存储器。该存储器可包括一个或更多个存储器单元，其采用一个或更多个存储器介质，例如诸如硬盘等磁介质、诸如SSD、闪存或EEPROM等电子媒介和/或诸如光盘驱动器等的光学介质。每一方103的计算机设备102上的存储器存储软件，其包括被设置为在处理装置上运行的至少一个客户端应用程序105的相应实例。应当理解的是，在本文中归因于给定方103的任何行动均可通过在相应计算机设备102的处理装置上运行的软件执行。每一方103的计算机设备102包括至少一个用户终端，例如台式或笔记本电脑、平板电脑、智能手机或诸如智能手表等的可穿戴设备。给定方103的计算机设备102还可包括一个或更多个其他网络资源，诸如通过用户终端访问的云计算资源。
客户端应用程序105最初可通过例如从服务器下载的适当计算机可读存储介质，或通过诸如可移动SSD、闪存密钥、可移动EEPROM、可移动磁盘驱动器、软盘或磁带等的可移动存储设备、诸如CD或DVD ROM等的光盘或可移动光驱等提供至任何给定方103的计算机设备102。
客户端应用程序105至少包括“钱包”功能。这有两个主要功能。其中一个功能是使相应方103能够创建、授权(例如签名)事务152并将其发送到一个或多个位比特币节点104，然后在区块链节点104的网络中传播，从而包括在区块链150中。另一个功能是向相应方汇报其目前拥有的数字资产数额。在基于输出的系统中，该第二功能包括整理分散在区块链150中属于相关方的各种事务152的输出中定义的数额。
注意：虽然各种客户端功能可以描述为集成到给定客户端应用程序105中，但这不一定是限制性的，相反，在本文中所描述的任何客户端功能可以在由两个或更多个不同应用程序组成的套件中实现，例如经由API进行接口连接或一个应用程序作为另一个应用程序的插件。更通俗地说，客户端功能可以在应用层或诸如操作系统的较低层或这些层的任意组合实现。下面将根据客户端应用程序105进行描述，但应当理解的是，这不是限制性的。
每个计算机设备102上的客户端应用程序或软件105的实例可操作地耦合到网络106的区块链节点104中的至少一个。这可以启用客户端105的钱包功能，以将事务152发送至网络106。客户端105还可联络区块链节点104，以在区块链150中查询相应方103作为接收者的任何事务(或实际上在区块链150中检查其它方的事务，因为在实施例中，区块链150是在某种程度上通过其公开可见性提供事务信任的公共设施)。每个计算机设备102上的钱包功能被配置为根据事务协议制定和发送事务152。如上所述，每个区块链节点104运行软件，该软件被配置为根据区块链节点协议核实事务152并转发事务152以便在区块链网络106中传播。事务协议和节点协议相互对应，给定事务协议和给定节点协议一起实现给定的事务模型。相同的事务协议用于区块链150中的所有事务152。网络106中的所有节点104使用相同的节点协议。
当给定方103(比方说爱丽丝)希望发送拟包含在区块链150中的新事务152j时，她将根据相关事务协议(使用其客户端应用程序105中的钱包功能)制定新事务。然后，她将事务152从客户端应用程序105发送到她所连接的一个或多个区块链节点104。例如，这可能是与爱丽丝的计算机102最佳连接的区块链节点104。当任何给定区块链节点104接收新事务152j时，其将根据区块链节点协议及其相应的角色进行处理。这包括首先检查新接收的事务152j是否满足变为“有效”的特定条件，具体示例稍后将详细讨论。在一些事务协议中，有效条件可通过事务152中包含的脚本在每个事务的基础上进行配置。或者，条件可仅仅是节点协议的内置功能，或通过组合脚本和节点协议进行定义。
如果新接收的事务152j通过有效性测试(即：“有效”的条件下)，接收事务152j的任何区块链节点104将向在区块链节点104处维护的有序事务集154中添加新的核实有效事务152。进一步地，接收事务152j的任何区块链节点104随后将核实有效事务152传播至网络106中的一个或多个其它区块链节点104。由于每个区块链节点104应用相同的协议，因此假定事务152j有效，这意味着事务很快将在整个网络106中传播。
一旦进入在给定区块链节点104处维护的未决事务有序池154，该区块链节点104将开始争相解决其各自的包含新事务152的池154的最新版本上的工作量证明难题(请记住，其它区块链节点104可以尝试基于不同的事务池154来解决难题。但是，首先解决难题的人将定义包括在最新区块151中的事务集合。最终，区块链节点104将解决有序池154的一部分的难题，该有序集154包括爱丽丝的事务152j)。一旦包括新事务152j的池154完成工作量证明，其将不可变地成为区块链150中区块151中的一个区块的一部分。每个事务152包括指向早前事务的指针，因此事务的顺序也被不可变地记录下来。
不同的区块链节点104可以首先接收给定事务的不同实例，并且因此在一个实例被发布到新区块151中之前具有关于哪个实例“有效”的冲突视图，此时所有区块链节点104同意所发布的实例是唯一的有效实例。如果区块链节点104将一个实例接受为有效实例，然后发现第二实例已记录在区块链150中，则区块链节点104必须接受这一点，并将丢弃(即，视为无效)其最初接受的实例(即，在区块151中尚未公布的实例)。
作为基于账户的事务模型的一部分，由一些区块链网络操作的另一种类型的事务协议可称为“基于账户的”协议。在基于账户的情况下，每个事务均不通过参考过去事务序列中先前事务的UTXO来定义转移的数额，而是通过参考绝对账户余额进行定义。所有账户的当前状态由网络的节点单独存储到区块链中，并不断更新。在此类系统中，事务使用账户的运行事务记录(也称为“头寸”)进行排序。该值由发送者签名作为其加密签名的一部分，并作为事务引用计算的一部分进行哈希处理。此外，可选的数据字段也可以在事务中签名。例如，如果数据字段中包含先前事务的ID，该数据字段可指向先前事务。
基于UTXO的模型
图2示出了示例性事务协议。这是基于UTXO的协议的示例。事务152(简称“Tx”)是区块链150的基本数据结构(每个区块151包括一个或多个事务152)。下面将通过参考基于输出或基于“UTXO”的协议进行描述。但这并不限于所有可能的实施例。应当注意的是，虽然参考比特币描述了示例性基于UTXO的协议，但是它同样可以在其它示例区块链网络上实现。
在基于UTXO的模型中，每个事务(“Tx”)152包括数据结构，其包括一个或多个输入202和一个或多个输出203。每个输出203可包括未花费事务输出(UTXO)，其可用作另一新事务的输入202的来源(如果UTXO尚未赎回)。UTXO包括指定数字资产数额的值。这表示分布式分类账上的一组通证。UTXO还可包含其来源事务的事务ID以及其它信息。事务数据结构还可包括标头201，其可包括输入字段202和输出字段203的大小指示符。标头201还可包括事务的ID。在实施例中，事务ID是事务数据(不含事务ID本身)的哈希值，且存储在提交至节点104的原始事务152的标头201中。
比方说爱丽丝103a希望创建转移相关数字资产数额至鲍勃103b的事务152j。在图2中，爱丽丝的新事务152j标记为“Tx1”。该新事务获取在序列中先前事务152i的输出203中锁定至爱丽丝的数字资产数额，并至少将此类数额中的一部分转移至鲍勃。在图2中，先前事务152i标记为“Tx0”。Tx0和Tx1只是任意的标记，其不一定意味着Tx0指区块链151中的第一事务且Tx1指池154中的后续事务。Tx1可指向仍具有锁定至爱丽丝的未花费输出203的任何先前(即先行)事务。
当爱丽丝创建其新事务Tx1时，或至少在她将该新事务发送至网络106时，先前事务Tx0可能已经有效并包括在区块链150的区块151中。该事务此时可能已包括在区块151中的一个区块中，或者可能仍在有序集154中等待，在这种情况下，该事务将很快包括在新区块151中。或者，Tx0和Tx1可以创建并一起发送至网络106；或者，如果节点协议允许缓冲“孤立”事务，Tx0甚至可以在Tx1之后发送。本文事务序列上下文中使用的“先前”和“后续”一词是指由事务中指定的事务指针定义的序列中的事务顺序(哪个事务指向哪个其他事务等等)。它们同样可以替换为“前任”和“继任”、“先行”和“后代”或“父项”和“子项”等。这不一定指其创建、发送至网络106或到达任何给定区块链节点104的顺序。然而，指向先前事务(先行事务或“父事务”)的后续事务(后代事务或“子事务”)不会有效除非父事务有效。在父事务之前到达区块链节点104的子事务被视为孤立事务。根据节点协议和/或节点行为，其可被丢弃或缓冲一段时间，以等待父事务。
先前事务Tx0的一个或更多个输出203中的一个包括特定的UTXO，标记为UTXO0。每个UTXO包括指定UTXO表示的数字资产数额的值以及锁定脚本，该锁定脚本定义后续事务的输入202中的解锁脚本必须满足的条件，以使后续事务有效，从而成功赎回UTXO。通常情况下，锁定脚本将数额锁定至特定方(该数额的事务的受益人)。即，锁定脚本定义解锁条件，该解锁条件通常包括以下条件：后续事务的输入中的解锁脚本包括先前事务被锁定到的一方的加密签名。
锁定脚本(亦称scriptPubKey)是节点协议识别的域特定语言中写入的一段代码。此类语言的特定示例称为“脚本(Script)”(S大写)，其可由区块链网络所使用。锁定脚本指定花费事务输出203所需的信息，例如爱丽丝签名的要求。解锁脚本出现在事务的输出中。解锁脚本(亦称scriptSig)是提供满足锁定脚本标准所需信息的域特定语言中写入的一段代码。例如，其可包含鲍勃的签名。解锁脚本出现在事务的输入202中。
因此在示出的示例中，Tx0的输出203中的UTXO0包括锁定脚本[Checksig PA]，该锁定脚本需要爱丽丝的签名Sig PA，以赎回UTXO0(严格来说，是为了使试图赎回UTXO0的后续事务有效)。[Checksig PA]包含爱丽丝的公私密钥对中的公钥PA的表示(即哈希)。Tx1的输入202包括指向Tx1的指针(例如，通过其事务ID(TxID0)，其在实施例中是整个事务Tx0的哈希值)。Tx1的输入202包括在Tx0中标识UTXO0的索引，以在Tx0的任何其他可能输出中对其进行标识。Tx1的输入202进一步包括解锁脚本<Sig PA>，该解锁脚本包括爱丽丝的加密签名，该签名由爱丽丝通过将其密钥对中的私钥应用于预定的部分数据(有时在密码学中称为“消息”)创建。爱丽丝需要签名以提供有效签名的数据(或“消息”)可通过锁定脚本、节点协议或其组合进行定义。
当新事务Tx1到达区块链节点104时，该节点应用节点协议。这包括一起运行锁定脚本和解锁脚本，以检查解锁脚本是否满足锁定脚本中定义的条件(其中该条件可包括一个或更多个标准)。在实施例中，这涉及并置两个脚本：
<Sig PA><PA>||[Checksig PA]
其中“||”表示并置，“<…>”表示将数据放在堆栈上，“[…]”表示由锁定脚本组成的函数(在该示例中指基于堆栈的语言)。同样，脚本可以使用公共堆栈一个接一个地运行，而不是并置脚本。无论采用哪种方式，当一起运行时，脚本使用爱丽丝的公钥PA(包括在Tx0的输出的锁定脚本中)，以认证Tx1的输入中的解锁脚本是否包含爱丽丝签名预期部分的数据时的签名。也需要包括预期的部分数据本身(“消息”)，以便执行此认证。在实施例中，签名的数据包括整个Tx1(因此不需要包括一个单独的元素来明文指定签名的部分数据，因为其本身便已存在)。
消息m是从要签名的事务的具体详细信息中导出的。由于该消息从签名到验证都必须相同，因此该过程确保在不使签名核实无效的情况下无法修改消息中包括的事务数据。
/>
如上所示，消息是通过以设定顺序级联事务信息的某些元素来生成的。在验证签名期间，消息不是显式发送的，而是由验证者基于广播事务中的数据重新创建的；事务信息通过在签名中使用的相同过程级联并进行双重哈希处理以产生消息摘要，e。如果用于重新创建消息的事务的任何部分在签名生成之后已更改，则消息将不相同，并且验证将失败。
这种在签名消息中使用事务详细信息的过程在事务广播到发布到区块链之间的延迟期间可提供重要的安全元素。然而，由于在不使签名核实无效的情况下无法更新事务的任何“已签名”(即，包括在签名消息中)元素，因此一些事务字段永远不能包括在签名消息中。这些字段是每个输入的解锁脚本(必须更新以在生成签名之后包括签名)和事务ID(TxID)，其是完整事务的双重哈希(包括解锁脚本中的签名)。由于这两个字段都必须包含签名(或从中导出)，因此只有在签名生成之后才能确定。
本领域技术人员将熟悉通过公私密码进行验证的细节。基本上而言，如果爱丽丝已使用其私钥加密签署消息，则给定爱丽丝的公钥和明文中的消息，诸如节点104等其它实体可验证消息必须已经由爱丽丝签名。签署通常包括对消息进行哈希，签署哈希值和将此标记到消息作为签名，从而使公钥的任何持有者能够验证签名。因此，应当注意的是，在实施例中，在本文中对签名特定数据片段或事务部分等的任何引用可以意味着对该数据片段或事务部分的哈希值进行签名。
如果Tx1中的解锁脚本满足Tx0的锁定脚本中指定的一个或多个条件(因此，在所示示例中，如果在Tx1中提供了爱丽丝的签名并进行验证)，则区块链节点104认为Tx1有效。这意味着区块链节点104会将Tx1添加到待定事务有序池154。区块链节点104还会将事务Tx1转发到网络106中的一个或多个其它区块链节点104，以便其会在整个网络106中传播。一旦Tx1有效并包括在区块链150中，这会将UTXO0从Tx0定义为已花费。应当注意的是，Tx1仅在花费未花费事务输出203时才有效。如果其试图花费另一事务152已经花费的输出，则即使满足所有其它条件，Tx1也将无效。因此，区块链节点104还需要检查先前事务Tx0中引用的UTXO是否已经花费(即，其是否已经形成另一有效事务的有效输入)。这是为何区块链150对事务152施加定义的顺序很重要的原因之一。在实践中，给定区块链节点104可维护单独的数据库，标记已花费事务152的UTXO 203，但最终定义UTXO是否已花费取决于是否在区块链150中形成了另一有效事务的有效输入。
如果给定事务152的所有输出203中指定的总数额大于其所有输入202所指向的总数额，则这是大多数事务模型中的另一失效依据。因此，此类事务不会传播或包括在区块151中。
请注意，在基于UTXO的事务模型中，给定UTXO需要作为一个整体使用。不能“留下”UTXO中定义为已花费的一部分数额，而同时又花费另一部分。但UTXO的数额可以在后续事务的多个输出之间分割。例如，Tx0的UTXO0中定义的数额可以在Tx1中的多个UTXO之间分割。因此，如果爱丽丝不想将UTXO0中定义的所有数额都给鲍勃，她可以使用剩余部分在Tx1的第二输出中自己找零，或者支付给另一方。
在实践中，爱丽丝通常还需要包括用于比特币节点104的费用，该比特币节点104在区块151中成功包含爱丽丝的事务104。如果爱丽丝未包括此类费用，则Tx0可能会被区块链节点104拒绝，并且因此尽管在技术上有效，但可能不会传播并且包括在区块链150中(如果区块链节点104不希望接受事务152，节点协议不强迫区块链节点104接受)。在一些协议中，事务费用不需要其自身的单独输出203(即不需要单独的UTXO)。相反，输入202指向的总数额与给定事务152的输出203指定的总数额之间的任何差额都将自动提供给发布事务的区块链节点104。例如，假设指向UTXO0的指针是Tx1的唯一输入，并且Tx1仅具有一个输出UTXO1。如果在UTXO0中指定的数字资产数额大于在UTXO1中指定的数额，则可以由赢得工作量证明竞赛以创建包含UTXO1的区块的节点104分配该差值。替代地或附加地，这不一定排除可以在其自身事务152的其中一个UTXO 203中明确指定事务费用。
爱丽丝和鲍勃的数字资产由区块链150中任何位置的任何事务152中的锁定至他们的UTXO组成。因此，通常情况下，给定方103的资产分散在整个区块链150的各种事务152的UTXO中。区块链150中的任何位置均未存储定义给定方103的总余额的一个数字。客户端应用程序105的钱包功能的作用是将锁定至相应方且在其它随后事务中尚未花费的各种UTXO值整理在一起。为实现这一点，其可以查询存储在任何一个位比特币节点104处的区块链150的副本。
应当注意的是，脚本代码通常用示意图表示(即使用非精确语言)。例如，可以使用操作码(opcode)来表示特定功能。“OP_...”是指脚本语言的特定操作码。举例来说，OP_RETURN是脚本语言操作码，当在锁定脚本的开始处在操作码前加上OP_FALSE时，操作码创建事务的不可花费输出，该输出可以在事务内存储数据，从而将数据不可改变地记录在区块链150中。例如，数据可包括需存储在区块链中的文件。
通常，事务的输入包含对应于公钥PA的数字签名。在实施例中，这基于使用椭圆曲线secp256k1的ECDSA。数字签名对特定的数据段进行签名。在实施例中，对于给定事务，签名将对部分事务输入以及部分或全部事务输出进行签名。对输出的特定部分进行签名取决于SIGHASH标志。SIGHASH标志通常是包含在签名末尾的4字节代码，用于选择签名的输出(并因此在签名时固定)。
六种不同的标志类型允许签名选择性地背书并因此确定所有输入和输出或各种子集的详细信息。下面基于解锁索引2中的输入的签名示出了不同的集合。已背书的输入和输出以粗体示出。
每个表格顶部显示的标志名称指示消息中包括哪些输出：ALL、NONE或SINGLE。每个标志有两种变体，这两种变体指示签名消息中包括哪些输入：“标准”变体(ALL、NONE、SINGLE；图2中表格的顶行)包括所有输入，而“任何人能够支付(ACP)”变体(ALL|ACP、NONE|ACP、SINGLE|ACP；底行)仅包括签名解锁的输入。对于单个标志变体(SINGLE或SINGLE|ACP)，应当注意的是，已签名的单个输出始终是位于输入要解锁到的匹配索引位置处的输出。顶行所示的变体，即对所有输入进行签名的变体，在本文中也可以分别称为ALL|ALL、NONE|ALL和SINGLE|ALL。与ACP变体一样，第一项表示有签名的输出，第二项表示有签名的输入。
消息中受sighash标志选择影响的字段是Hash(Outpoints)、Hash(nSeqs)、Hash(Outputs)和sigHashFlag字段本身。在计算哈希字段时，清空不包括的输入和输出(基于sighash标志)，并且按顺序级联其余数据并对其进行哈希处理。例如，对于sighash ALL|ACP签名，删除索引0(Outpointi)和索引1(Outpointj)中的输入的信息，但保留所有输出的详细信息，从而产生以下哈希字段：
Hash(Outpoints)＝Hash([TxIDk][indexk])
Hash(nSeqs)＝Hash([nSeqk])
Hash(Outputs)＝Hash([valuew][lockScriptLengthw][lockScriptw][valuex]...
[lockScriptLengthx][lockScriptx][valuey][lockScriptLengthy]...
[lockScripty][valuez][lockScriptLengthz][lockScriptz])
对于sighash SINGLE签名，保留所有输入，而仅保留一个输出–在索引2中与签名的位置匹配的输出，从而得出：
Hash(Outpoints)＝Hash([TxIDi][indexi][TxIDj][indexj][TxIDk][indexk])
Hash(nSeqs)＝Hash([nSeqi][nSeqj][nSeqk])
Hash(Outputs)＝Hash([valuey][lockScriptLengthy][lockScripty])
消息字符串中的其他字段不受sighash标志的影响。无论签名授权哪个输入，版本和锁定时间字段(始终包括在签名消息中)对于基于同一事务的所有签名都是相同的。其余字段(outpointk、lockScriptLengthk、lockScriptk、valuek和nSeqk)与要签名的输入直接相关，因此将根据创建签名以解锁的输入而更改，但是不受sighash标志选择的影响，因为要解锁的输入必须始终进行签名。
将签名消息与匹配的私钥一起传递到ECDSA签名算法以生成签名(r,s)。为了将该签名包括在区块链事务中，必须将其转换为单个字符串，该字符串放置在其授权的输入的解锁脚本字段中。通过级联签名的两个元素r和s，并使用DER标准将其编码为字节格式来创建该字符串。
在消息中，将sighash标志作为最后一个字节附加，其中每个sighash标志由特定值表示，如下表所示，以提供序列化签名：
sig(a,m)＝[r][s][sigHashFlag]。应当注意的是，对于具有支付到公钥哈希(P2PKH)锁定脚本的输出点，在将签名放置在解锁脚本字段之前，为签名进一步附加其相关联的公钥。在验证期间，对于事务中的每个签名，基于事务信息和sighash标志来重新创建消息，并且使用该消息检查签名的有效性。
标志名称 字节值 具有分叉ID的字节值
ALL 0x01 0x41
NONE 0x02 0x42
SINGLE 0x03 0x43
ALL|ACP 0x81 0xC1
NONE|ACP 0x82 0xC2
SINGLE|ACP 0x83 0xC3
这六个sighash标志可提供对从仅一个输入(NONE|ACP)到所有输入和输出(ALL)的任何内容进行签名的灵活性(通过将其包括在签名消息中)。对于sighash ALL之外的标志，这意味着可以在不使签名核实无效的情况下更改从签名消息中排除的事务信息。与使用sighash ALL的标准方法相比，这可提供更大的灵活性。例如，“任何人能够支付”标志变体不会对要签名的输入之外的输入的详细信息施加任何限制，这允许其他各方在不使彼此的签名核实无效的情况下向事务中添加输入(即，“支付”)。
锁定脚本有时称为“scriptPubKey”，指其通常包括相应事务被锁定到的当事方的公钥。解锁脚本有时称为“scriptSig”，指其通常提供相应的签名。但是更通俗地说，在区块链150的所有应用中，UTXO赎回的条件并不一定包括对签名进行验证。更通俗地说，脚本语言可用于定义任何一个或多个条件。因此，可以优选更为通用的术语“锁定脚本”和“解锁脚本”。
侧信道
如图1所示，爱丽丝和鲍勃的计算机设备102a、120b中的每个计算机设备上的客户端应用程序都可以包括附加通信功能。此附加功能可使爱丽丝103a建立与鲍勃103b的单独侧信道107(在任何一方或第三方的鼓动下)。侧信道107使得能够脱离区块链网络交换数据。此类通信有时称为“链下off-chain”通信。例如，这可用于在爱丽丝与鲍勃之间交换事务152，而不将该事务(尚未)注册到区块链网络106上或将其发布到链150上，直到其中一方选择将其广播到网络106上。以这种方式共享事务有时称为共享“事务模板”。事务模板可能缺少形成完整事务所需的一个或多个输入和/或输出。替代地或附加地，侧信道107可用于交换任何其它事务相关数据，例如密钥、议付数额或条款、数据内容等。
通过与区块链网络106相同的分组交换网络101可建立侧信道107。替代地或附加地，侧信道301可以经由诸如移动蜂窝网络的不同网络或者诸如无线局域网络的局域网建立，甚至经由爱丽丝和鲍勃的设备102a、102b之间的直接有线或无线链路建立。通常，在本文中任何地方所指的侧信道107可以包括经由一项或多项联网技术或通信介质的任何一条或多条链路，这些链路用于“链下”交换数据，即脱离区块链网络106交换数据。在使用多条链路的情况下，链下链路束或集合整体上可以称为侧信道107。因此，应当注意的是，如果说爱丽丝和鲍勃通过侧信道107交换某些信息或数据等，则这不一定意味着所有这些数据都必须通过完全相同的链路或甚至相同类型的网络发送。
客户端软件
图3A示出了用于实现本公开方案的实施例的客户端应用程序105的示例性实施方式。客户端应用程序105包括事务引擎401和用户界面(UI)层402。根据上文讨论的方案以及稍后将进一步详细讨论的内容，事务引擎401被配置为实现客户端105的基础事务相关功能，诸如制定事务152，通过侧信道301接收和/或发送事务和/或其他数据，和/或发送事务至一个或更多个节点104以通过区块链网络106传播。根据本文公开的实施例，每个客户端105的事务引擎401包括生成和修改多重签名事务的函数403。
函数403通过在事务的第一索引中提供输出和需要多个解锁签名的输入来生成多重签名事务。在输入中提供第一签名，该签名只授权第一索引的输出，即第一签名具有SINGLE|ALL或SINGLE|ACP sighash标志。在此阶段，需要更多签名来解锁第一索引的输入，此阶段的事务称为部分多重签名事务。
客户端应用程序105将所述部分多重签名事务传输到与被授权解锁第一索引中的输入和/或向事务添加附加输入和输出的用户相关联的客户端应用程序105。
在已经接收所述部分多重签名事务的用户设备上，可以使用函数403在第一索引中提供另一签名。如果需要更多签名来解锁输入，则该签名具有SINGLE|ALL或SINGLE|ACPsighash标志，或者如果该签名是所需的最终签名，则该签名具有ALL sighash标志，以便签名授权事务的所有输出。函数403还在第二索引或下一索引中定义输出或输入和输出，具体取决于第一索引中使用的sighash标志。在提供输入和输出的情况下，输入包括具有单个sighash标志的签名。在第一索引中提供最终签名的情况下，必须在提供签名之前提供附加输出。
该UI层402被配置为通过相应用户的计算机设备102的用户输入/输出(I/O)方式呈现用户界面，包括通过设备102的用户输出方式向相应用户103输出信息，和通过设备102的用户输入方式接收来自相应用户103的输入。例如，用户输出方式可包括提供视觉输出的一个或显示多个屏(触摸或非触摸屏)、提供音频输出的一个或更多个扬声器、和/或提供触觉输出的一个或更多个触觉输出设备等。用户输入方式可包括例如一个或更多个触摸屏的输入阵列(可与用于输出方式的那个/那些相同或不同)；一个或更多个基于光标的设备，诸如鼠标、轨迹板或轨迹球；一个或更多个麦克风和语音或声音识别算法，用于接收语音或声音输入；一个或更多个基于手势的输入设备，用于接收手动或身体手势形式的输入；或者一个或更多个机械按钮、开关或控制杆等。
注：虽然本文中的各种功能可以被描述为集成到同一客户端应用程序105中，但这并不一定构成限制，相反，它们可以在两个或更多个不同应用程序组成的一套程序中实现，例如一个应用程序作为另一个应用程序的插件或经由API(应用程序编程接口)进行接口。比如，事务引擎401的功能可以在单独的应用程序中实现，而不是在UI层402中实现，或者诸如事务引擎401的给定模块的功能可以在多个应用程序之间分割。同时，也不排除部分或全部描述的功能可以在比如操作系统层实现。在本文任何位置引用单个或给定应用程序105或诸如此类的情况下，应当理解的是这只是作为示例，并且更通俗地说，所描述的功能可以在任何形式的软件中实现。
图3B给出了用户界面(UI)300的示例的模型，该UI可由客户端应用程序105a的UI层402在爱丽丝的设备102a上呈现。应当理解的是，类似的UI可以由客户端105b在鲍勃的设备102b或任何其他方的设备上呈现。
通过图示的方式，图3B从爱丽丝的角度示出了UI 300。该UI 300可包括一个或更多个UI元素301、302、303，该一个或更多个UI元素通过用户输出方式呈现为不同的UI元素。
例如，UI元素可包括一个或更多个用户可选择的元素301，这些元素可以是屏幕上的不同按钮、菜单中的不同选项或者诸如此类。用户输入方式被设置成使用户103(在这种情况下为爱丽丝103a)能够选择或以其它方式操作其中一个选项，诸如通过点击或触摸屏幕上的UI元素，或者说出所需选项的名称(注：本文使用的“手动”一词仅用于与自动进行对比，而不一定限于用手执行操作)。例如，这些选项使用户(爱丽丝)能够选择要修改的事务、选择要包含在多重签名事务中的输出点或输出、生成事务或提供签名。
替代地或附加地，UI元素可以包括一个或多个数据输入字段302，例如，通过该数据输入字段，用户可以输入文本以包括在OP_RETURN中、或提供私钥(private key)或口令(password)。这些数据输入字段通过用户输出方式呈现，例如屏幕上，并且数据可通过用户输入方式输入到字段中，例如键盘或触摸屏。或者，数据可以例如基于语音识别口头地接收。
替代地或附加地，UI元素可包括向用户输出信息的一个或更多个信息元素303。例如，这/这些可以在屏幕上呈现或可听见。
应当理解的是，呈现各种UI元素、选择选项和输入数据的特定方式并不重要。这些UI元素的功能稍后将进行更详细地讨论。还应当理解的是，图3中示出的UI 300只是一个图示模型，在实践中，它可包括一个或更多个进一步的UI元素，为了简洁起见，未对其进行说明。
节点软件
图4示出了在基于UTXO或基于输出的模型的示例中，在网络106的每个区块链节点104上运行的节点软件450的示例。应当注意的是，另一实体可以运行节点软件450，而不被分类为网络106上的节点104，即，不执行节点104所需的动作。节点软件450可以包含但不限于协议引擎451、脚本引擎452、堆栈453、应用级决策引擎454以及一个或多个区块链相关功能模块455的集合。每个节点104可以运行节点软件，该节点软件包含但不限于以下所有三个：共识模块455C(例如，工作量证明)、传播模块455P和存储模块455S(例如，数据库)。协议引擎401通常被配置为识别事务152的不同字段，并根据节点协议处理此类字段。当接收到具有指向另一先前事务152i(Txm-1)的输出(例如，UTXO)的输入的事务152j(Txj)时，协议引擎451标识Txj中的解锁脚本并将其传递给脚本引擎452。协议引擎451还基于Txj的输入中的指针来标识和检索Txi。Txi可以在区块链150上发布，在这种情况下，协议引擎可以从存储在节点104处的区块链150的区块151的副本中检索Txi。或者，Txi还可以在区块链150上发布。在这种情况下，协议引擎451可以从节点104维护的未发布有序事务集154中检索Txi。无论采用哪种方式，脚本引擎451都会标识Txi的引用输出中的锁定脚本，并将其传递给脚本引擎452。
因此，脚本引擎452具有Txi的锁定脚本和来自Txj的相应输入的解锁脚本。例如，在图2中示出了事务标记的Tx0和Tx1，但是同样的事务也可以应用于任何事务对。如前所述，脚本引擎452一起运行两个脚本，这将包括根据所使用的基于堆栈的脚本语言(例如脚本)将数据放置到堆栈453上和从堆栈453检索数据。
通过同时运行脚本，脚本引擎452确定解锁脚本是否满足锁定脚本中定义的一个或多个标准，即解锁脚本是否对包括锁定脚本的输出进行解锁？脚本引擎452将该确定的结果返回给协议引擎451。如果脚本引擎452确定解锁脚本确实满足在相应的锁定脚本中指定的一个或多个标准，则返回结果“TRUE”。否则，返回结果“FALSE”。
在基于输出的模型中，来自脚本引擎452的结果“TRUE”是事务有效性的条件之一。通常，还必须满足由协议引擎451评估的一个或多个进一步协议级条件；例如，Txj的输入中所指定的数字资产的总数额不超过其输出中指向的总数额，并且Txi的指向输出尚未被另一有效事务花费。协议引擎451评估来自脚本引擎452的结果以及一个或多个协议级条件，并且只有当它们都为TRUE时，协议引擎才核实事务Txj有效。协议引擎451将事务是否有效的指示输出到应用级决策引擎454。只有在Txj确实有效的条件下，决策引擎454才可以选择同时控制共识模块455C和传播模块455P，以执行其就Txj.的相应区块链相关功能。这包括共识模块455C，向节点的相应有序事务集154添加Txj，用于并入区块151中；以及传播模块455P，将Txj转发到网络106中的另一个区块链节点104。可选地，在实施例中，应用级决策引擎454可以在触发这些函数中的一个或两个函数之前应用一个或多个附加条件。例如，决策引擎可以只选择在事务有效且预留足够事务费用的条件下发布事务。
此外，还应当注意的是，在本文中，术语“TRUE”和“FALSE”不一定限于返回仅以单个二进制数(位)形式表示的结果，尽管这确实是一种可能的实现方式。更通俗地说，“TRUE”可以指指示成功或肯定结果的任何状态，而“FALSE”可以指指示不成功或不肯定结果的任何状态。例如，在基于账户的模型中，可以对签名的隐式协议级核实和智能合约的附加肯定输出的组合来指示结果为“TRUE”(如果两个单独的结果均为TRUE，则认为总体结果为TRUE)。
多重签名事务
在单个事务中使用多个签名的简单示例是，当输入或输出具有多重签名(multisig)解锁要求时。通常，这些签名用于允许多方共享对账户或资产的控制，并且需要m/n个(m-of-n个)签名来授权花费，其中m≤n。
具有multisig解锁要求的UTXO代表由多方控制的资产，各方均持有签名私钥。通常，使用这些multisig UTXO作为输入的事务将在授权签名方之间私下起草并预先商定，然后各方将根据完整事务创建签名。然而，在一些情况下，输出可能与组中的一个成员特别相关，而该成员希望能独立控制对输出的分配。
一个示例是，在离婚期间，将双方共有的联合账户解散为两个独立的、单独控制的账户。代表爱丽丝和鲍勃的联合储蓄账户的UTXO可能具有2/2multisig解锁要求，其中爱丽丝和鲍勃各持一个签名私钥。如果他们希望将这些资金转移到两个单独控制的输出中，可以创建事务并按如下方式进行签名：
1.爱丽丝在索引0中设置multisig输入，在索引0中定义其输出，并对SINGLE进行签名。由于multisig输入和爱丽丝的输出位于相同的索引位置，因此该签名支持输入并修复爱丽丝的输出。即使不能确保他们之间的信任，爱丽丝也可以安全地将此发送给鲍勃，因为鲍勃无法在未核实爱丽丝的签名无效的情况下修改爱丽丝的输出，从而核实multisig输入的解锁脚本无效。同样地，由于核实输入有效所需的第二签名不存在，因此不存在事务被拦截以及未分配资金被重新路由到另一地址的危险。
2.鲍勃现在可以将其输出添加到索引1中，并使用sighash ALL对multisig输入进行签名。这提供了核实输入有效所需的第二签名，并修复了鲍勃的输出。
这种使用不同sighash标志的签名序列允许爱丽丝和鲍勃避免所有使用sighashALL进行签名的事务中固有的相互依赖。爱丽丝和鲍勃都没有机会在未核实事务无效的情况下编辑对方的输出。同样，任何一方都不能为自己分配超过应有的值：如果爱丽丝将其输出值设置得太高，鲍勃就不会签名批准事务；如果鲍勃将其输出值设置为高于商定值，输出值将超过输入值，事务就会无效。
在multisig涉及两方以上的情况下，例如一群股东控制一个公司账户，可以实施类似的过程。例如，给定具有n/n解锁要求的账户，股东可以通过以下方式兑现其在公司的股份。即将离职的股东应将公司multisig设置为输入，并将其期望退回的资金分配到输出0中的个人地址。他们应使用上述示例中描述的SINGLE标志进行签名。n-1个其余股东需要提供额外的签名来授权multisig输入。他们还必须分配代表其剩余股份值的第二输出，其中multisig花费要求不包括离职方(即，n-1/n-1)。同意这些条款的每个股东应使用sighashALL标志在输入0中对multisig进行签名。这有助于修复新的multisig输出，并提供核实原始multisig输入有效所需的n个签名。下文将考虑多个股东可能希望同时套现的情况，例如公司完全解散的情况。
以本文描述的方式使用不同的sighash标志允许在签名过程中出现某种形式的对话，从而排除了各方在签名之前对事务细节进行阐述和商定的初步讨论的必要性。尽管这些提法仍然需要持有multisig UTXO密钥的所有各方的合作，但与完全预先确定使用sighash ALL标志时所需的所有事务信息相比，提供的签名过程更精简。
然而，在单个输入的情况下，不可能独立对两个以上的输出进行签名。为此，可以将附加输入放置在任何索引位置，为签名提供占位符，从而允许使用单个标志变体对任何索引位置的输出进行签名。这些输入可以引用希望控制匹配输出的一方所控制的任何UTXO；输入值可以由该方通过增加其分配的输出值相对于multisig账户输入的预期份额来收回。或者，输入可以是明确向各方发行的“通证”(标称值)，作为这些事务中的输入。在明确出于此目的发行通证的情况下，可以创建通证，使得其锁定脚本包含附加标准，该标准确保在生成签名时使用特定的sighash标志，例如，确保使用SINGLE或SINLGE|ACP sighash标志对通证输入进行签名。通证以及使用通证的事务在本申请人于提交本申请的同一天提交的名称为“事务签名标志”的英国专利申请中有更详细的描述，该申请通过引用并入本文。
本文描述的用作占位符的输入(应具有标称值或通过增加配对输出的值来收回的值)将称为标称输入(nominal input)。
在同一事务中出现多个输入时，必须考虑的另一个因素是输入是否可以预定义，或者是否必须保持灵活性。前一种情况要求在开始签名之前在各方之间安排一些细节，但提供了防止延展性的保护，因为没有必要使用ACP标志变体。相比之下，后一种选择允许各方灵活地对事务进行签名和更新，但意味着可能需要额外的措施来防止延展性。
固定输入集
上面介绍了拥有n/nmultisig账户的一群公司股东的用例。提供了一种系统，该系统允许一个股东兑现其股份，而将剩余资金留在由其余股东控制的(n-1)/(n-1)multisig账户中。然而，如果股东们决定完全解散multisig账户，各方可能希望独立地对自己的输出进行设置和签名。为了支持这一点，除了multisig输入之外，还可以包括标称输入，以便可以单独对后面索引位置的输出进行签名。如下面的示例所示，最先和最后签名的各方不需要提供额外的标称输入，但必须为其他每个签名者提供标称输入。
例如，假设爱丽丝Alice、鲍勃Bob和查理Charlie是持有他们希望解散的3/3multisig账户的密钥的股东。作为将在链中间进行签名的一方，鲍勃必须向第一签名方(爱丽丝)提供其标称输入的详细信息。签名过程将按如下方式进行：
1.爱丽丝设置预先商定的输入，在索引0中定义她的输出，并使用SINGLE标志对Sig A进行签名。她的签名支持multisig输入并修复她的输出，但允许鲍勃和查理添加其他输出。
2.鲍勃在索引1中设置其输出地址。他必须生成两个签名：Sig B_1和Sig B_2，SigB_1支持索引0中的multisig输入，Sig B_2放置在索引1中并修复鲍勃的输出。这两个签名均应使用sighash SINGLE标志，以允许查理在稍后阶段添加他的输出。
3.查理在索引2中设置其输出地址。由于现在已经定义了所有的输入和输出，因此查理可以使用sighash ALL进行签名。这意味着他只需要为multisig输入生成一个签名SigC，因为ALL标志意味着它将在不需要匹配输入的情况下修复他的输出。在此阶段，所有输入都接收到所需签名，因此事务有效。
该方案可以轻松扩展为包括更多参与者，第一方和最后一方分别遵循爱丽丝和查理的步骤，其他各方遵循鲍勃的步骤。尽管各方都设置了自己的输出值，但任何人都不可能获得超过其商定份额的份额。在该方案的最后阶段之前签名的参与者(即，该示例中的爱丽丝和鲍勃)需要添加后续签名，以核实multisig输入的花费有效——如果他们为自己分配额外的份额，后来各方将不会同意对事务进行签名。最后一方不需要任何进一步的签名，但在此阶段，只有适当份额的值未分配——设置更高的输出值会导致事务无效，因为没有足够的输入。
该方案能够为各方提供独立的控制权来对其输出进行设置和签名，并简化签名过程，其中事务仅通过每个参与者传递一次以进行签名。尽管如此，即使没有看到事务最终版本的各方也可以确信该过程对他们来说是公平的，因为他们全权负责设置自己的输出。
动态输入
在一些情况下，在签名开始之前预定义所有输入是不可取的(或不可能的)。例如，与上一节中描述的n/nmultisig相比，对于m/nmultisig(其中m<n)，有许多不同的签名子集可以满足multisig解锁要求。由于根据设计，所包含的标称输入集应代表将其签名应用于multisig输入的各方，因此在签名过程之前定义这些标称输入意味着只有一组特定的m个签名有效。这限制了m/nmultisig设计所包含的灵活性。因此，最好使用ACP sighash标志，以便在签名期间可以根据哪些方有空或选择提供签名来动态设置输入。
然而，允许这种灵活性意味着签名顺序变得更加重要。在上述解散公司股份账户的情况下，multisig账户中包含的全部值设置为由事务分配，因此在链中早期进行签名的各方只需确保他们被分配有适当的值。相比之下，对于可以动态添加输入和输出的事务，如果multisig账户预计将保留剩余资金，各方可能不希望在该过程早期签名，因为他们丧失了拒绝后来各方添加的输出的权利。
还值得注意的是，在链中间签名的各方，如前一示例中的鲍勃，需要提供两个单独的签名。其中一个签名(在标称输入中)用于修复他的个人输出，而另一个签名则授权multisig输入。根据鲍勃在链中的位置，如果这些签名是在所有事务输入最终确定之前提供的，鲍勃必须使用SINGLE|ACP sighash标志。如果是这种情况，后来一方(查理)可能会删除鲍勃单独签名的输入-输出对(表示向鲍勃的账户转账)，同时保持鲍勃对multisig地址的签名不变。删除鲍勃的输出后，除查理的常规份额之外，查理还可以将本应分配给鲍勃的值添加到查理自己的输出中。由于查理是最后一个提供签名的人，因此他能够提供核实multisig输入的花费有效所需的最终签名，从而使事务有效。
因此，在链中早期签名的各方无法批准在他们签名之后增加的花费，并且也容易受到链中后来各方删除其输出的影响。避免此漏洞的一种选择是确保像鲍勃这样的中间链参与者在第一轮签名期间仅提供一个签名(用于其输入-输出对)，一旦链中的最后一方签名(即，定义了所有输入和输出，并且应用了sighash ALL)，事务应重新分发给中间链各方，以便他们检查其输出详细信息是否尚未编辑或删除，如果是，则提供核实multisig输入的花费有效所需的最终签名。
第二种选择是创建独立系统(例如，软件)，该系统在每个阶段都预先编程了multisig事务的预期格式，包括输入和输出的数量和值、使用的签名标志等。这可用于在每个签名阶段之后检查若干标准，例如：
1.未删除或编辑事务上一次迭代的任何信息。这将防止攻击，例如删除SINGLE|ACP对等。
2.签名应用正确。这可能包括完整的签名验证，例如ECDSA和/或检查是否使用了特定的sighash标志，以便签名过程的后续阶段可以按计划进行。
3.如果使用预先发行的通证作为输入，则该通证可在当前事务中使用(例如，基于其输出点、其值、嵌入OP_RETURN中的一次性代码等)。
4.输出值适当。这应考虑到上一步骤中添加的新输入所带来的任何附加值。
在一些实施例中，这些检查是在提供最终签名之后并且在传输到区块链之前执行的。
如果不满足在生成多重签名事务的任何阶段检查的任何一项标准，则多重签名事务不会传输到区块链。
图5和图6示出了可以生成的示例性多重签名事务500、600。每个事务500、600具有唯一的事务ID。本文使用的术语“多重签名事务”是指包括至少一个输入的区块链事务，该至少一个输入标识具有多重签名解锁要求的UTXO。
图5所示的多重签名事务500适用于这样一种场景：只需要两方授权多重签名输入的花费，但该事务包括与第三方相关联的输入，例如团队中初级成员的费用。
图5所示的多重签名事务500包括三个输入和四个输出。
在索引0处，有第一输入，该第一输入包括非签名部分和签名部分。非签名部分包括标识具有2/n多重签名解锁要求的UTXO的输出点。签名部分提供了两个签名：爱丽丝提供的具有SINGLE|ACP sighash标志的签名(A0)，以及鲍勃提供的具有ALL sighash标志的签名(B)。由于鲍勃的签名对事务500的所有输入和输出进行签名，因此只有在定义了所有输入和输出之后才能提供其签名。
在索引0处提供第一输出，其中包括与尚未分发给爱丽丝、鲍勃或初级团队成员并减去所需事务费用的输入值的剩余部分对应的UTXO。该UTXO锁定到授权方的n个私钥，并要求其中两方授权花费，即UTXO具有2/nmultisig解锁要求。应当理解的是，仅当multisig输入的值未用完时，才需要该输出。在该场景中，重要的是将multisig输出(如果有更改)放置在索引0中，以便签名授权花费multisig输入(索引0)的各方也对multisig输出进行签名，即使他们只使用SINGLE标志变体。如果要将multisig账户放置在后面的索引位置，则在该过程早期签名的各方不会对multisig输出进行签名，因此他们无法确保是否分配了正确的更改量；稍后签名的各方可以为自己分配额外的资金。
在事务500的索引1处有一个输入，其中包括标识已分配给爱丽丝的UTXO的输出点，以及包含爱丽丝的签名(A1)和SINGLE|ACP sighash标志的解锁脚本。在索引1处还有一个输出，其中包括爱丽丝定义并锁定到其公钥的UTXO。该输出的值应足以涵盖爱丽丝的费用以及该输入的输出点中指示的UTXO。
在事务500的索引2处有一个输入，其中包括标识已分配给鲍勃团队初级成员的UTXO的输出点，以及包含初级团队成员的签名(JB)和SINGLE sighash标志的解锁脚本，尽管也可以使用SINGLE|ACP sighash标志。在索引2处还有一个输出，其中包括要分配给初级成员的UTXO，以及将UTXO锁定到初级成员的公钥的锁定脚本。UTXO足以涵盖初级成员的费用以及该输入的输出点中指示的UTXO。
在爱丽丝对事务进行电子签名后，鲍勃或鲍勃团队初级成员提供输入-输出对。因此，爱丽丝必须使用单个sighash标志的ACP变体。或者，如果只有爱丽丝能够包含输入-输出对，例如，如果爱丽丝有权管理初级成员的所有费用，则爱丽丝可以在索引0中提供具有SINGLE sighash标志的签名，因为在爱丽丝需要提供其签名之前已经知道所有输入。
在索引3处没有输入，但有第三输出，其中包括与鲍勃的费用对应的UTXO，以及将UTXO锁定到鲍勃的公钥的锁定脚本。只有在提供了事务500中的所有输入和输出之后，鲍勃才能提供具有ALL sighash标志的签名。
图6所示的多重签名事务600适用于需要三方或更多方授权花费多重签名输入的场景。在所示的示例中，没有其他方对事务600做出贡献，即提供输入，尽管应当理解的是，可能会有如上述费用示例中提供的附加输入。
图6所示的多重签名事务600包括三个输入和四个输出。
在索引0处有第一输入，其中包括签名部分和非签名部分。非签名部分包括标识具有3/n多重签名解锁要求的UTXO的输出点I0。签名部分提供了三个签名：爱丽丝提供的具有SINGLE|ACP sighash标志的签名(A0)，鲍勃提供的具有SINGLE sighash标志的第一签名(B0)，以及查理提供的具有ALL sighash标志的签名(C)。由于查理的签名对事务600的所有输入和输出进行签名，因此只有在定义了所有输入和输出之后才能提供其签名。
在索引0处提供了第一输出，其中包括与尚未分发给爱丽丝、鲍勃和查理或用于涵盖事务费用的输入值的剩余部分对应的UTXO。该UTXO锁定到授权方的n个私钥，并要求其中三方授权花费，即UTXO具有3/n multisig解锁要求。应当理解的是，仅当multisig输入的值未用完时，才需要该输出。
在事务600的索引1处有第二输入，其中包括标识已分配给爱丽丝的UTXO的输出点I1以及解锁脚本。锁定脚本包括爱丽丝的具有SINGLE|ACP sighash标志的第二签名(A1)，该签名解锁第二输入中指示的UTXO。在索引1处还有第二输出，其中包括要分配给爱丽丝的UTXO，以及将UTXO锁定到爱丽丝的公钥的锁定脚本。UTXO足以涵盖爱丽丝的费用以及第二输入的输出点中指示的UTXO。
在事务600的索引2处有第三输入，其中包括标识已分配给鲍勃的UTXO的输出点I2以及解锁脚本。锁定脚本包括鲍勃的具有SINGLE sighash标志的第二签名(B1)，该签名解锁第二输入中指示的UTXO。在索引1处还有第二输出，其中包括要分配给鲍勃的UTXO，以及将UTXO锁定到鲍勃的公钥的锁定脚本。UTXO足以涵盖鲍勃的费用以及第二输入的输出点中指示的UTXO。
爱丽丝在索引0处提供其签名后，鲍勃提供该输入-输出对。因此，爱丽丝必须使用单个sighash标志的ACP变体。或者，如果在事务生成之前已经知道索引1中的输出点，则爱丽丝可以在索引0中提供具有SINGLE sighash标志的签名，因为在爱丽丝需要提供其签名之前已经知道所有输入。
在索引3处没有输入，但有第四输出，其中包括与查理的费用对应的UTXO，以及将UTXO锁定到查理的公钥的锁定脚本。
只有在提供了事务600中的所有输入和输出后，查理才能在索引0中提供具有ALLsighash标志的签名。
这里需要注意的是，理论上查理可以在索引3中添加其输出之前，删除索引1和索引2中与爱丽丝和鲍勃的费用对应的输入-输出对。查理可以增加他分配给自己地址的输出值，这样他就可以收到所有三组费用的支付。爱丽丝和鲍勃在索引0中提供的授权花费multisig账户的签名(A0和B0)将保留在事务中，因此查理可以通过添加自己的签名来满足multisig输入签名要求。
分层Multisig
在一些情况下，使用各方一次性添加签名时创建的自然层级结构可能是有益的，在这种情况下，早期签名者没有机会否决后来各方的花费。这种不对称结构可能适用于各方在multisig账户中没有同等权限的情况。
其中一个示例是，可能持有的用于涵盖常规业务费用的公司往来账户。该账户可能有m/nmultisig花费要求，每个签字人在层级结构和签名程序中占有特定位置。例如，假设爱丽丝Alice、鲍勃Bob和查理Charlie是拥有自己的初级员工团队的高级管理人员。黛利拉Delilah是公司CFO。爱丽丝、鲍勃、查理和黛利拉都持有公司multisig往来账户的有效密钥。虽然所述各方是主要签名者，并且通常每个月担任一个角色，但高级财务团队可以持有四个额外的有效密钥，如果主要签字人不在，他们可以代替主要签字人。由此提供了具有4/8解锁要求的multisig账户。提交费用有一个正式的程序，从最初级的成员开始。
1.爱丽丝、鲍勃和查理团队的初级成员必须根据下面所示的“初级”事务格式，在每个月的设定日期之前提交任何个人费用报销。
○费用应采取具有标称输入的SINGLE|ACP签名输入-输出对的形式。
○输出值应等于(相对于输入值)员工的费用报销，并且应分配给他们自己的地址。
○可以在输出的OP_RETURN中引用费用的确切详细信息，例如通过包括费用数据的哈希。
2.爱丽丝、鲍勃和查理整理各自团队提交的费用，并执行以下步骤，以根据下面的“管理人员”格式生成事务，该事务应在当月第二个截止日期之前提交给黛利拉。
○未经管理人员批准的任何费用都将从费用集中删除。
○如果管理人员想要提交自己的费用或代表团队产生的费用，他们可以额外生成具有标称输入的SINGLE|ACP签名输入-输出对。
○每一个批准的费用都应设置在事务中从索引1开始的匹配输入-输出位置。
○管理人员应将公司multisig账户包含在输入0中。为了避免不同multisig签字人独立生成的签名之间产生冲突，应预先确定索引0中的输出。
■例如，如果一家公司拥有HD钱包，他们可以将每个连续月份的私钥定义为特定范围内的下一个索引，并生成密钥结构。
■分配给输出0的值应只是一个(预先商定的)小数值；管理人员不知道所有费用相加后账户的最终余额是多少。一旦知道所有费用，黛利拉就会向新地址分配第二(更大的)输出。
■管理人员应为multisig输入(以及预定义输出)提供SINGLE|ACP签名，即使其团队当月未提交任何费用。
3.黛利拉将整理从爱丽丝、鲍勃和查理处接收的管理人员事务，并形成与下面的公司模板相匹配的组合事务。
○黛利拉应将爱丽丝、鲍勃和查理的签名组合在一起作为multisig输入。
○管理人员和团队成员的所有费用均放置在从索引1开始的匹配输入-输出位置。
○黛利拉可以添加额外的输出而不需要额外的标称输入，因为她是最后一个签名的。这些输出可能包括她的个人费用以及租金和水电费等其他公司支出。
○黛利拉应将multisig输入的剩余值分配给最终输出中定义的预先商定的multisig公司账户。
○最后，黛利拉可以生成授权multisig输入以及核实事务有效所需的最终签名。为了安全起见，必须使用sighash ALL进行签名。
第30/40页
该设置还允许在单个事务中支付整个公司的费用，并允许每月在区块链上显示整个公司的账户，从而提供简洁且不可变的审计跟踪。该示例使用了将SINGLE|ACP标志与multisig输入组合时固有的分层结构。该结构允许管理人员检查和批准初级团队成员的费用，而无需初级成员批准管理人员的费用报销。同样地，CFO可以检查初级人员、管理人员和团队的费用，而无需进行任何相互检查。
尽管要求管理人员在事务最终确定之前进行签名，这取消了他们否决其他管理人员或CFO的支出的能力，但在multisig要求中包含他们的签名确实有好处：每个月提供签名意味着他们必须提交团队的费用或确认没有费用，这提供了一定程度的问责制，并且有助于确保不会遗漏费用。值得注意的是，通过要求所有管理人员每月提交multisig账户的签名，该系统实际上是完全由CFO控制的1对1账户。然而，提高multisig账户的要求很简单，例如，所有三位管理人员都要签名，CFO要最终确定事务并签名，另外还需要五名董事会成员的两个签名。这意味着将对CFO进行检查，这在某些情况下可能是适当的。一种替代方案是，最终签名密钥是门限系统，其中多方持有私钥的份额，并且一定数量的团队成员的子集需要协作，以生成有效签名。
本文描述的签名过程还提供了简化系统：在任何阶段都不需要团队协作，因为各方都可以生成自己独立的功能事务模板；对签名顺序几乎没有限制，只是各级各方每个月都有一个需要采取行动的截止日期；所有签名都在一轮签名中收集，无需回溯；所有信息都直接从一方传递给另一方，通信可以是单向的。这些特性意味着个人在提交费用时具有很大的自由(例如，对等方之间没有固定的签名顺序)，而不会限制整个系统的势头。此外，最低限度的沟通要求对大型团队特别有利，因为在大型团队中安排讨论可能会很困难。
该签名程序提供了如何组合多个sighash标志以实现复杂签名系统的综合示例。具体地，本文描述的系统使个人有机会在不放弃独立性的情况下就联合事务进行协作。这些系统还概述了交换部分形成、部分签名的事务如何作为沟通工具，而不是在使用sighashALL进行签名时所需的初步对话，从而进一步显著简化签名程序。
链下和链上动作
图7示出了生成图6所示形式的多重签名事务的示例性方法，其中输入事先未知，即具有动态输入的事务。左边所示的方法步骤由参与方的用户设备在链下实现，右边的步骤由区块链节点在链上实现。
在步骤S702中，定义了第一输入的输出点，其指示的UTXO具有multisig解锁要求。还定义了第一输出，该输出是新的多重签名地址，其具有与第一输入中的UTXO相同的签名要求。该输出的值应等于第一输入的值减去其他输出的预期值和适当的事务费用。
在步骤S704中，在第一输入处提供用于解锁第一输入的输出点中指示的UTXO的全部所需签名，但那些与第一输入的一些UTXO将传送到的各方相关联的签名除外。在图7的示例中，有两个附加输出，因此在步骤S704中提供m-2个签名。这些签名具有SINGLE|ACPsighash标志，因为后续输入尚未定义。然而，如果在任何一方签名之前已经定义了所有输入，则这些签名可以具有SINGLE标志，由于已经提供了所有输入，因此可以将其包含在消息中。在第一索引处提供的这些签名仅对索引0处的输出进行签名，并且仅对索引0处的输入进行签名(在SINGLE|ACP sighash标志的情况下)，或对事务的所有输入进行签名(在SINGLE sighash标志的情况下)。
在步骤S706中定义第二输入的输出点。该输出点表示UTXO，具有单个签名解锁要求，并且由希望分配他们独立控制的输出的一方控制。例如，图6中的输出点I1与之前分配给爱丽丝的UTXO相关联，是输入-输出对的输出点，其中一定数额的数字资产作为输出分配给爱丽丝。
在步骤S708中，用于解锁由第二输入中的输出点指示的UTXO的签名具有单个sighash标志。由于所有输入都是已知的，因此sighash标志可以是SINGLE，使得通过签名对事务的所有输入进行签名，也可以是SINGLE|ACP，使得仅对索引1处的输入进行签名。在任何一种情况下，仅对索引1处的输出进行签名。即使输入-输出对是由对第一输入进行签名的倒数第二方提供的，在具有动态输入的事务中使用SINGLE|ACP更加通用，以允许最后一方对在多个地址之间分割其份额的选项进行签名，例如，如果最后一方需要支付团队成员的费用，情况可能如此。使用SINGLE|ACP还允许以任何时间顺序提供输入-输出对，这在中心方收集输入-输出对并编译多重签名事务时是有利的。
在步骤S708中，在第一输入处提供用于解锁第一输入的输出点中指示的UTXO的第m-1个签名。该签名与在步骤S706中提供输入-输出对的一方相关联。
在步骤S710中，在索引2中定义最终输出。该输出没有对应的输入。负责提供最终输出的一方(之前没有提供用于对多重签名UTXO进行签名的签名)在索引0中的第一输入处提供具有ALL sighash标志的最终签名，以对事务的所有输入和所有输出进行签名，即步骤S712。在提供最终签名之后，不能对事务进行进一步更改。
然后将事务传输到区块链节点，该节点在步骤S714中通过运行上述锁定脚本和解锁脚本核实事务有效。一旦核实有效，便将事务发布到区块链，即步骤S716。
应当理解的是，如图7所示的方法的步骤可以改变。例如，定义第二输入的步骤(步骤S706)可以在第一输入中提供m-2个签名中的至少一个签名之前执行，也就是说，在未提供输出的至少一方对第一输入进行签名之前执行。在第一输入中提供签名的步骤(步骤S704)可以在多个步骤中执行，每个签名在单独的步骤中提供。这些签名中的一些签名可以在第二输入的签名之前提供，而另一些签名则可以在第二输入的签名之后提供，具体取决于哪一方授权第二输入。为第一输入提供签名的步骤(步骤S708)可以包括两个单独的步骤，并且可以通过类似于步骤S706和步骤S708的用于提供附加输入-输出对的额外步骤分开。
图8示出了用于生成多重签名事务600的示例性系统。
该系统包括三个用户设备802a、802b、802c以及区块链节点(未示出)，每个用户设备由授权对事务600做出贡献的一方操作。每个用户设备802a、802b、802c包括用于存储计算机程序的存储器以及在其上运行计算机程序的至少一个处理器。计算机程序在运行时配置处理器以呈现客户端应用程序300，供该方或用户使用。各方可以称为授权方，因为他们通过提供签名来授权事务600的输入和输出。
第一方(爱丽丝)通过客户端应用程序300在第一用户设备802a处定义事务的第一输出、第一输出点以及第一输入的第一签名，这些内容均包括在索引0处。在第一输入处提供的签名具有SINGLE|ACP标志，因为在签名之前不知道事务的输入。第一输出是数字资产的剩余部分，该部分不分配给任何一方，也不用于支付事务费用，并且锁定到多个公钥。
爱丽丝还在第一用户设备802a处定义包含在索引1处的输入-输出对。该输入-输出对包括第二输入以及定义锁定到爱丽丝的公钥的UTXO的第二输出。同样，由于并非所有输入都是已知的，因此爱丽丝使用SINGLE|ACP标志进行签名。如果在爱丽丝提供任何签名之前所有输入都是已知的，她可以在索引0和索引1处使用SINGLE sighash标志。
然后，第一用户设备802a将部分完成事务传输到第二用户设备802b。
第二用户设备802b由第二方(鲍勃)操作。第二方通过在第二用户设备802b上运行的客户端应用程序300定义第三输入和第三输出，用户设备802b将第三输入和第三输出包括在事务600的索引2中。第二用户设备802b还在索引0处的第一输入中提供第二方的签名。鲍勃提供的每个签名具有SINGLE|ACP标志，由于他不是最终签名方，因此可以提供进一步输入。然而，如果已知对事务进行签名的最后一方不会提供任何进一步输入，或者该方未被授权提供任何进一步输入，则鲍勃可以使用SINGLE标志进行签名。然后，将部分完成事务发送到第三用户设备802c。
第三用户设备802c由第三方(查理)操作。第三方通过在第三用户设备802c上运行的客户端应用程序300定义第四输出，用户设备802c将第四输出包含在事务600的索引3中。第三用户设备802c还在索引0处的第一输入中提供第三方的最终签名，以授权事务600的所有输入和输出。
一旦最终签名包含在输入中，事务就有效。第三用户设备802c将现在已完成事务600传输到区块链节点进行核实。
系统可以包括对事务600做出贡献的附加方操作的附加用户设备。所述各方可以被授权对多重签名输入(第一输入)进行签名，或者仅被授权为事务提供输入-输出对，被授权对多重签名输入进行签名的一方可以删除这些输入-输出对。
有权对第一输入的输出点进行签名的任何一方可以提供第一输出以及第一输入的非签名部分。该方不需要提供输入-输出对来将一定数额的数字资产转移给自己。在上述示例中，爱丽丝可以定义第一输出，并在索引0处提供其签名，但如果她自己不需要任何数字资产，例如，她没有要支付的费用，她就不会在索引1处提供输入-输出对。此时，将部分完成事务发送到第二用户设备208b，其中在索引1处提供鲍勃的输入-输出对。
在一些实施例中，第一输入中引用的整个UTXO将转移到各方，就像上文所述的解散multisig账户的情况一样。在此类实施例中，爱丽丝在索引0处提供的输出包括要锁定到爱丽丝的公钥的数字资产数额。爱丽丝定义第一输入和第一输出之后，部分完成事务将发送到第二用户设备，鲍勃在第二用户设备处定义其输入-输出对并将输入-输出对包含在索引1处。
向被授权对事务做出贡献的各方提供通证，以证明该方被授权做出贡献的做法可能是有利的。通证是锁定到通证发行事务中发行的被授权方的公钥的UTXO。协调事务的一方(在上述示例中可以是CFO黛利拉)生成通证发行事务。
通证事务的每个输出可以包括定义sighash标志的签名条件，该标志必须由一方在多重签名事务中对通证进行签名时提供，或在提供其输入-输出对时提供。如果授权花费通证时使用的sighash标志与签名要求中定义的sighash标志不匹配，则事务不会作为有效事务返回。
通证的值很小，因此如果以后不使用通证，通证发行者损失的数字资产数额可以忽略不计。
如果一方定义的输入不包括多重签名输入以外的通证，则CFO可以删除对应的输入-输出对，或者管理人员可以拒绝将费用包含在事务中。同样地，可以删除在不可用于当前事务的任何通证。在事务中包含最终签名的CFO的计算机设备可以在提供最终签名之前检查输入是否为有效通证。
在上述示例中，多重签名输入具有m/n解锁要求，也就是说，需要提供UTXO锁定到的n个签名中的m个签名来解锁用于花费的UTXO。然而，应当理解的是，上述事务可以包含具有n/n解锁要求的输入，为此，需要UTXO锁定到的所有n个签名用于花费。
第二索引或后续索引中提供的UTXO可以具有多重签名解锁要求，而不是如上所述示例中的单个签名解锁要求。在这种情况下，输入的非签名部分包括标识UTXO的输出点，签名部分包括满足多重签名要求的具有单个sighash标志的两个或多个签名。
虽然上述事务是在提交费用的上下文中进行解释的，但应当理解的是，多重签名事务可以用于其他场景，其中至少一个输入具有多重签名解锁要求，并且各方可以定义自己的输出。
事务费用
如上所述，事务费用必须与事务配对。该费用可以通过多种方式提供。
多重签名输入可以完全涵盖事务费用。也就是说，第一索引的输出中的数字资产数额等于多重签名输入数额减去事务费用以及分配给其他各方的事务的所有其他输出。
任何给定事务的事务费用数额是根据事务规模(即输入和输出的数量)计算的。因此，对于输入和输出的数量可以变化的事务，在提供第一输出时事务费用是未知的，使得为事务费用提供的数额可能会也可能不会完全涵盖该费用。在这种情况下，在提供第一输出时，只知道费用估值。
可以为事务费用提供大于估值的数额，以确保涵盖事务费用。然而，这可能会导致支付不必要的大量事务费用。
相反，可以使用一个或多个其他输入来至少部分地涵盖事务费用。使用多个输入来涵盖事务费用的一些示例性方式包括：
●使用估值来提供事务费用的部分多重签名输入，在提供所有输入-输出对和最终输出之后，提供所需数额的事务费用输入。可以使用NONE或ALL sighash标志对该输入进行签名。
●使用估值来提供事务费用的部分多重签名输入，在提供所有输入-输出对和最终输出之后，提供事务费输入-输出对，其中输入大于所需数额，并且一旦支付事务费用，输出就等于输入的剩余部分。输出返回给对事务输入进行签名的一方。可以使用SINGLE、SINGLE|ACP和ALL sighash标志中的任何一个标志对该输入进行签名。
●不使用事务费用的任何多重签名输入，而是使用事务费用输入或事务费用输入-输出对来涵盖全部事务费用。如上所述，必须在提供所有其他输入和输出之后提供这些内容。
●多重签名输入仅用于涵盖包含多重签名输入和最终输出的第一索引的部分事务费用。也就是说，多重签名输入涵盖与一个输入和两个输出相关联的事务费用。后续输入中的每个输入用于涵盖与其输入-输出对相关联的事务费用，使得每个输入-输出对的输出中的数字资产数额等于输入以及分配给对所述输入进行签名的一方的多重签名输入的数额减去输入-输出对的事务费用。
应当理解的是，可以使用多重签名事务的输入的其他组合来支付事务费用。
结论
一旦给出本文的公开内容，所公开技术的其它变体或用例对于本领域技术人员可能变得显而易见。本公开的范围不受所描述的实施例限制，而仅受随附权利要求限制。
例如，上面的一些实施例已经根据比特币网络106、比特币区块链150和比特币节点104进行了描述。然而，应当理解的是，比特币区块链是区块链150的一个特定示例，并且上述描述通常可以应用于任何区块链。也就是说，本发明决不限于比特币区块链。更一般地，以上对比特币网络106、比特币区块链150和比特币节点104的任何引用可以分别参考区块链网络106、区块链150和区块链节点104来替换。区块链、区块链网络和/或区块链节点可以共享如上所述的比特币区块链150、比特币网络106和比特币节点104的部分或全部所述特性。
在本发明的优选实施例中，区块链网络106是比特币网络，并且比特币节点104至少执行对区块链150的区块151进行创建、发布、传播和存储中的所有所述功能。不排除可能存在仅执行这些功能中的一个或部分功能但不是全部功能的其它网络实体(或网络元件)。也就是说，网络实体可以执行传播和/或存储区块的功能，而不创建和发布区块(请记住，这些实体不被认为是优选的比特币网络106的节点)。
在本发明的其他实施例中，区块链网络106可以不是比特币网络。在这些实施例中，不排除节点可以执行对区块链150的区块151进行创建、发布、传播和存储中的至少一个或部分功能但不是所有功能。例如，在这些其它区块链网络上，“节点”可用于指被配置为创建和发布区块151但不存储和/或传播这些区块151到其它节点的网络实体。
甚至更通俗地说，上面对术语“比特币节点”104的任何引用可以用术语“网络实体”或“网络元件”代替，其中这样的实体/元件被配置为执行对区块进行创建、发布、传播和存储中的一些或全部角色。这种网络实体/元件的功能可以在硬件中实现，方法与上面参照区块链节点104所述的方式相同。
应当理解的是，上述实施例仅通过示例的方式进行描述。更通俗地说，可根据下述任何一个或多个语句提供一种方法、装置或程序。
语句1.一种用于为区块链生成多重签名事务的计算机实现的方法，所述方法包括：接收所述多重签名事务的第一输入-输出对的第一输入的非签名部分和第一输出，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成一签名，当所述签名被包含在所述第一输入的签名部分中时，满足所述多重签名要求，所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，和(ii)相对于所述多重签名要求有效的至少一个其他签名；接收所述多重签名事务的第二输入-输出对的第二输入的非签名部分和第二输出，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及，使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成一签名，当该签名被包含在所述第二输入的签名部分中时，至少部分地满足所述签名要求，所述第二输入的所述签名部分具有相关联的sighash single标志。
语句2.根据语句1所述的计算机实现的方法，其中所述方法还包括：在接收到所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分之后：接收所述多重签名事务的最终输出，所述最终输出没有相关联输入；以及，使用与所述多重签名要求的最终公钥对应的最终私钥，对所述多重签名事务的所有输入的非签名部分和所有输出进行电子签名，从而生成最终签名，当该最终签名被包含在所述第一输入的所述签名部分中时，满足多重签名条件，所述第一输入的所述签名部分具有：(i)相关联的sighash all标志，以及(ii)满足所述多重签名要求的至少所述签名。
语句3.根据语句2所述的计算机实现的方法，其中所述方法还包括：在生成所述最终签名之后，将所述多重签名事务传输到区块链节点。
语句4.根据前述任一项语句所述的计算机实现的方法，其中如果所述签名要求需要多个签名，所述方法还包括：使用与所述签名要求的另一公钥对应的另一私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成另一签名，当该另一签名包含在所述第二输入的签名部分中时，部分地满足所述签名条件，所述第二输入的所述签名部分具有：相关联的sighash single标志、以及至少部分地满足所述签名条件的所述签名。
语句5.根据前述任一项语句所述的计算机实现的方法，其中在具有sighash“单个-任何人能够支付”(single-anyone can pay)标志的所述第一输入的所述签名部分接收满足所述多重签名要求的所述至少一个其他签名中的至少一个之后，接收所述第二输入的所述非签名部分，从而仅对所述多重签名事务的所述第一输出以及所述第一输入的所述非签名部分进行签名。
语句6.根据前述任一项语句所述的方法，其中在所述至少部分地满足所述签名要求的所述签名之后提供附加输入，其中所述至少部分地满足所述签名要求的所述签名与单个-任何人能够支付标志相关联，从而仅对所述多重签名事务的所述第二输出以及所述第二输入的所述非签名要求进行签名。
语句7.根据前述任一项语句所述的方法，其中所述第一可花费输出的一部分分配给对所述第二输入的所述非签名部分进行签名的一方。
语句8.根据前述任一项语句所述的方法，其中所述多重签名事务的所述第二输入将所述第二可花费事务输出的任何剩余数字资产返回给对所述第二输入的所述非签名部分进行签名的一方。
语句9.根据前述任一项语句所述的方法，其中所述第二可花费事务输出中定义的数字资产数额是基于维护所述区块链的区块链网络的当前事务费用设置的。
语句10.根据前述任一项语句所述的方法，其中所述方法还包括：在提供所有输出以及输入的所有非签名部分之后，提供事务费用输入的非签名部分，用于至少部分地支付维护所述区块链的区块链网络的当前事务费用，其中所述事务费用输入包括第三可花费事务输出的输出点，所述第三可花费事务输出中定义的数字资产数额是基于所述当前事务费用设置的。
语句11.根据语句10所述的方法，其中所述第三可花费事务输出中定义的所述数字资产数额大于所述事务费用输入支付的所述事务费用的一部分，所述方法还包括：提供事务费用输出，用于将所述第三可花费事务输出的剩余部分重新分配给对所述事务费用输入的所述非签名部分进行签名的一方。
语句12.根据语句10所述的方法，其中所述第三可花费事务输出中定义的所述数字资产数额等于所述事务费用输入支付的所述事务费用的一部分，其中所述事务费用输入不与输出相关联。
语句13.根据前述任一项语句所述的方法，其中所述第二可花费事务输出是分配给对所述第二输入的所述非签名部分进行签名的一方的通证，以授权该方参与所述多重签名事务。
语句14.根据语句13所述的方法，其中所述通证的锁定脚本定义了必须使用其才能有效地花费所述通证的sighash标志。
语句15.根据语句3或其任何从属语句所述的方法，所述方法还包括：检查是否满足事务标准，其中只有在满足所述标准的情况下才将所述多重签名事务传输到所述区块链，其中所述标准包括以下各项中的至少一项：未删除和/或更改所述多重签名事务上一次迭代的信息；所提供的所述签名是经过验证的；正确的sighash标志与所述签名相关联，其中所述正确的签名允许按要求执行所述方法的后续阶段；使用有效通证；所述多重签名事务的输出的值是适当的。
语句16.一种用于为区块链生成多重签名事务的计算机系统，所述计算机系统包括一个或多个处理器，其中所述处理器被配置为：接收所述多重签名事务的第一输入-输出对的第一输入的非签名部分和第一输出，所述第一输入包括对多重签名要求进行编码的区块链事务的可花费输出的输出点；使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一非签名输入进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成一签名，当该签名被包含在所述第一输入的签名部分中时，满足所述多重签名要求，所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，和(ii)满足所述多重签名要求的至少一个其他签名；接收所述多重签名事务的第二输入-输出对的第二输入的非签名部分和第二输出，所述第二输入包括对需要至少一个签名的签名要求进行编码的区块链事务的可花费输出的输出点；以及，使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成一签名，当该签名包含在所述第二输入的签名部分中时，至少部分地满足签名条件，所述第二输入的所述签名部分具有相关联的sighashsingle标志。
语句17.根据语句16所述的计算机系统，其中所述一个或多个处理器还被配置为：在接收到所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分之后：接收没有相关联输入的所述多重签名事务的最终输出；以及，使用与所述多重签名要求的最终公钥对应的最终私钥，对所述多重签名事务的所有输出以及所有输入的非签名部分进行电子签名，从而生成最终签名，当该最终签名包含在所述第一输入的签名部分中时，满足多重签名条件，所述第一输入的所述签名部分具有：(i)相关联的sighash all标志，和(ii)满足所述多重签名要求的至少所述签名。
语句18.根据语句17所述的计算机系统，其中所述计算机系统还包括用于核实区块链事务有效的区块链节点，其中所述一个或多个处理器被配置为：在生成所述最终签名之后，将所述多重签名事务传输到所述区块链节点。
语句19.根据语句16至18中任一项所述的计算机系统，其中如果所述签名要求需要多个签名，所述系统还被配置为：使用与所述签名要求的另一公钥对应的另一私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成另一签名，当该另一签名包含在所述第二输入的签名部分中时，部分地满足所述签名条件，其中所述第二输入的所述签名部分具有：相关联的sighash single标志、以及至少部分地满足所述签名条件的所述签名。
语句20.根据语句16至19中任一项所述的计算机系统，其中所述一个或多个处理器包含在单个计算机设备中。
语句21.根据语句16所述的计算机系统，其中所述计算机系统是第一用户设备。
语句22.根据语句21所述的计算机系统，其中所述计算机系统包括第二用户设备，所述第二用户设备被配置为：执行根据语句2或3所述的方法。
语句23.根据语句21或22所述的计算机系统，其中所述计算机系统包括第三用户设备，所述第三用户设备被配置为：在接收到所述第二输入的所述非签名部分之前，生成满足所述多重签名要求的所述至少一个其他签名中的至少一个，以便包含在具有sighash单个-任何人能够支付标志的所述第一输入的所述签名部分中，从而仅对所述多重签名事务的所述第一输出以及所述第一输入的所述非签名部分进行签名。
语句24.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据语句1至15中任一项所述的方法。
语句25.一种用于区块链的多重签名事务，所述多重签名事务嵌入在计算机可读介质上并且包括：所述多重签名事务的第一输入-输出对的第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；当被包含在所述第一输入的签名部分中时满足所述多重签名要求的签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，和(ii)相对于所述多重签名要求有效的至少一个其他签名，满足所述多重签名要求的所述签名是通过以下方式生成的：使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名；所述多重签名事务的第二输入-输出对的第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及，当被包含在所述第二输入的签名部分中时至少部分地满足所述签名要求的签名，其中所述第二输入的所述签名部分具有相关联的sighash single标志，至少部分地满足所述签名要求的所述签名是通过以下方式生成的：使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名。

Claims (25)

1.一种用于为区块链生成多重签名事务的计算机实现的方法，所述方法包括：
接收所述多重签名事务的第一输入-输出对的第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；
使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当被包含在所述第一输入的签名部分中时满足所述多重签名要求的签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，以及(ii)相对于所述多重签名要求有效的至少一个其他签名；
接收所述多重签名事务的第二输入-输出对的第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及
使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当被包含在所述第二输入的签名部分中时至少部分地满足所述签名要求的签名，其中所述第二输入的所述签名部分具有相关联的sighash single标志。
2.根据权利要求1所述的计算机实现的方法，其中所述方法还包括：在接收到所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分之后：
接收没有相关联输入的所述多重签名事务的最终输出；以及
使用与所述多重签名要求的最终公钥对应的最终私钥，对所述多重签名事务的所有输出以及所有输入的非签名部分进行电子签名，从而生成当被包含在所述第一输入的所述签名部分中时满足多重签名条件的最终签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash all标志，以及(ii)满足所述多重签名要求的至少所述签名。
3.根据权利要求2所述的计算机实现的方法，其中所述方法还包括：在生成所述最终签名之后，将所述多重签名事务传输到区块链节点。
4.根据前述任一项权利要求所述的计算机实现的方法，其中如果所述签名要求需要多个签名，所述方法还包括：
使用与所述签名要求的另一公钥对应的另一私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当包含在所述第二输入的签名部分中时部分地满足所述签名条件的另一签名，其中所述第二输入的所述签名部分具有：相关联的sighash single标志、以及至少部分地满足所述签名条件的所述签名。
5.根据前述任一项权利要求所述的计算机实现的方法，其中在具有sighash单个-任何人能够支付标志的所述第一输入的所述签名部分接收满足所述多重签名要求的所述至少一个其他签名中的至少一个之后，接收所述第二输入的所述非签名部分，从而仅对所述多重签名事务的所述第一输出以及所述第一输入的所述非签名部分进行签名。
6.根据前述任一项权利要求所述的方法，其中在所述至少部分地满足所述签名要求的所述签名之后提供附加输入，其中所述至少部分地满足所述签名要求的所述签名与单个-任何人能够支付标志相关联，从而仅对所述多重签名事务的所述第二输出以及所述第二输入的所述非签名要求进行签名。
7.根据前述任一项权利要求所述的方法，其中所述第一可花费输出的一部分分配给对所述第二输入的所述非签名部分进行签名的一方。
8.根据前述任一项权利要求所述的方法，其中所述多重签名事务的所述第二输入将所述第二可花费事务输出的任何剩余数字资产返回给对所述第二输入的所述非签名部分进行签名的一方。
9.根据前述任一项权利要求所述的方法，其中所述第二可花费事务输出中定义的数字资产数额是基于维护所述区块链的区块链网络的当前事务费用设置的。
10.根据前述任一项权利要求所述的方法，其中所述方法还包括：在提供所有输出以及输入的所有非签名部分之后，提供事务费用输入的非签名部分，用于至少部分地支付维护所述区块链的区块链网络的当前事务费用，其中所述事务费用输入包括第三可花费事务输出的输出点，所述第三可花费事务输出中定义的数字资产数额是基于所述当前事务费用设置的。
11.根据权利要求10所述的方法，其中所述第三可花费事务输出中定义的所述数字资产数额大于所述事务费用输入支付的所述事务费用的一部分，所述方法还包括：提供事务费用输出，用于将所述第三可花费事务输出的剩余部分重新分配给对所述事务费用输入的所述非签名部分进行签名的一方。
12.根据权利要求10所述的方法，其中所述第三可花费事务输出中定义的所述数字资产数额等于所述事务费用输入支付的所述事务费用的一部分，其中所述事务费用输入不与输出相关联。
13.根据前述任一项权利要求所述的方法，其中所述第二可花费事务输出是通证，所述通证被分配给对所述第二输入的所述非签名部分进行签名的一方，以授权该方参与所述多重签名事务。
14.根据权利要求13所述的方法，其中所述通证的锁定脚本定义sighash标志，其中必须使用所述sighash标志才能有效花费所述通证。
15.根据权利要求3或其任何从属权利要求所述的方法，所述方法还包括：检查是否满足事务标准，其中只有在满足所述标准的情况下才将所述多重签名事务传输到所述区块链，其中所述标准包括以下各项中的至少一项：
未删除和/或更改所述多重签名事务上一次迭代的信息；
所提供的所述签名是经过验证的；
正确的sighash标志与所述签名相关联，其中所述正确的签名允许按要求执行所述方法的后续阶段；
使用有效通证；
所述多重签名事务的输出的值是适当的。
16.一种用于为区块链生成多重签名事务的计算机系统，所述计算机系统包括一个或多个处理器，其中所述处理器被配置为：
接收所述多重签名事务的第一输入-输出对的第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的区块链事务的可花费输出的输出点；
使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一非签名输入进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当被包含在所述第一输入的签名部分中时满足所述多重签名要求的签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，和(ii)满足所述多重签名要求的至少一个其他签名；
接收所述多重签名事务的第二输入-输出对的第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的区块链事务的可花费输出的输出点；以及
使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当包含在所述第二输入的签名部分中时至少部分地满足签名条件的签名，其中所述第二输入的所述签名部分具有相关联的sighashsingle标志。
17.根据权利要求16所述的计算机系统，其中所述一个或多个处理器还被配置为：在接收到所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分之后：
接收没有相关联输入的所述多重签名事务的最终输出；以及
使用与所述多重签名要求的最终公钥对应的最终私钥，对所述多重签名事务的所有输出以及所有输入的非签名部分进行电子签名，从而生成当包含在所述第一输入的签名部分中时满足多重签名条件的最终签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash all标志，以及(ii)满足所述多重签名要求的至少所述签名。
18.根据权利要求17所述的计算机系统，其中所述计算机系统还包括用于核实区块链事务有效的区块链节点，其中所述一个或多个处理器被配置为：在生成所述最终签名之后，将所述多重签名事务传输到所述区块链节点。
19.根据权利要求16至18中任一项所述的计算机系统，其中如果所述签名要求需要多个签名，所述系统还被配置为：
使用与所述签名要求的另一公钥对应的另一私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名，从而生成当包含在所述第二输入的签名部分中时部分地满足所述签名条件的另一签名，其中所述第二输入的所述签名部分具有：相关联的sighash single标志、以及至少部分地满足所述签名条件的所述签名。
20.根据权利要求16至19中任一项所述的计算机系统，其中所述一个或多个处理器包含在单个计算机设备中。
21.根据权利要求16所述的计算机系统，其中所述计算机系统是第一用户设备。
22.根据权利要求21所述的计算机系统，其中所述计算机系统包括第二用户设备，所述第二用户设备被配置为：执行根据权利要求2或3所述的方法。
23.根据权利要求21或22所述的计算机系统，其中所述计算机系统包括第三用户设备，所述第三用户设备被配置为：在接收到所述第二输入的所述非签名部分之前，生成满足所述多重签名要求的所述至少一个其他签名中的至少一个，以便包含在具有sighash单个-任何人能够支付标志的所述第一输入的所述签名部分中，从而仅对所述多重签名事务的所述第一输出以及所述第一输入的所述非签名部分进行签名。
24.一种计算机程序，所述计算机程序包含在计算机可读存储器上并且被配置为当在一个或多个处理器上运行时，执行根据权利要求1至15中任一项所述的方法。
25.一种用于区块链的多重签名事务，所述多重签名事务嵌入在计算机可读介质上并且包括：
所述多重签名事务的第一输入-输出对的第一输出以及第一输入的非签名部分，所述第一输入包括对多重签名要求进行编码的第一可花费事务输出的输出点；
当被包含在所述第一输入的签名部分中时满足所述多重签名要求的签名，其中所述第一输入的所述签名部分具有：(i)相关联的sighash single标志，以及(ii)相对于所述多重签名要求有效的至少一个其他签名，满足所述多重签名要求的所述签名是通过以下方式生成的：使用与所述多重签名要求的公钥对应的私钥，对所述第一输入-输出对的所述第一输出以及所述第一输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名；
所述多重签名事务的第二输入-输出对的第二输出以及第二输入的非签名部分，所述第二输入包括对需要至少一个签名的签名要求进行编码的第二可花费事务输出的输出点；以及
当被包含在所述第二输入的签名部分中时至少部分地满足所述签名要求的签名，其中所述第二输入的所述签名部分具有相关联的sighash single标志，至少部分地满足所述签名要求的所述签名是通过以下方式生成的：使用与所述签名要求的公钥对应的私钥，对所述多重签名事务的所述第二输入-输出对的所述第二输出以及所述第二输入的所述非签名部分进行电子签名，但不对所述多重签名事务的任何其他输出进行电子签名。
CN202180087427.8A 2020-12-23 2021-11-23 多重签名事务 Pending CN116671064A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2020453.3 2020-12-23
GBGB2020453.3A GB202020453D0 (en) 2020-12-23 2020-12-23 Multisignature tranactions
PCT/EP2021/082664 WO2022135812A1 (en) 2020-12-23 2021-11-23 Multisignature transactions

Publications (1)

Publication Number Publication Date
CN116671064A true CN116671064A (zh) 2023-08-29

Family

ID=74221091

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180087427.8A Pending CN116671064A (zh) 2020-12-23 2021-11-23 多重签名事务

Country Status (5)

Country Link
EP (1) EP4268420A1 (zh)
JP (1) JP2024501939A (zh)
CN (1) CN116671064A (zh)
GB (1) GB202020453D0 (zh)
WO (1) WO2022135812A1 (zh)

Also Published As

Publication number Publication date
EP4268420A1 (en) 2023-11-01
JP2024501939A (ja) 2024-01-17
WO2022135812A1 (en) 2022-06-30
GB202020453D0 (en) 2021-02-03

Similar Documents

Publication Publication Date Title
CN116210016A (zh) 共生通证系统
CN114008969A (zh) 包含在区块链中的交易的延展性
CN116508291A (zh) 默克尔证明实体
CN115136543A (zh) 在区块链网络中使用的认证服务
CN115997229A (zh) 区块链上的协议
CN117480758A (zh) 用于验证区块链上的通证的计算机实现的方法和系统
CN113994628A (zh) 通过侧信道流式传输部分数据
CN116157796A (zh) 警报账户
CN116097264A (zh) 电子文件签名
CN117044161A (zh) 阻止敏感数据
CN114531941A (zh) 多标准区块链协议
CN117546167A (zh) 多级区块链
CN117751550A (zh) 分层共识
CN117280653A (zh) 多方区块链地址方案
CN116671061A (zh) 节点版本控制
US20230036852A1 (en) Single-use tokens
CN116745794A (zh) 区块链相关验证方法和系统
CN116057920A (zh) 连接到区块链网络
CN116671064A (zh) 多重签名事务
CN115699676A (zh) 自定义事务脚本
CN116636180A (zh) 事务签名标志
CN117678191A (zh) 消息交换系统
CN117280349A (zh) 多方区块链地址方案
CN117730512A (zh) 对区块链事务强制执行条件
CN117693923A (zh) 对区块链事务强制执行条件

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