• 7.7复杂的脚本示例

    7.7复杂的脚本示例

    在本节中，我们将本章中的许多概念合并成一个例子。 我们的例子使用了迪拜公司所有者Mohammed的故事，他们正在经营进出口业务。

    在这个例子中，Mohammed希望用灵活的规则建立公司资本账户。他创建的方案需要不同级别的授权，具体取决于时间锁定。

    多重签名的计划的参与者是Mohammed，他的两个合作伙伴Saeed和Zaira，以及他们的公司律师Abdul。三个合作伙伴根据多数规则作出决定，因此三者中的两个必须同意。然而，如果他们的钥匙有问题，他们希望他们的律师能够用三个合作伙伴签名之一收回资金。最后，如果所有的合作伙伴一段时间都不可用或无行为能力，他们希望律师能够直接管理该帐户。

    这是Mohammed设计的脚本： 具有时间锁定（Timelock）变量的多重签名

    1. IF
    2.   IF
    3.     2
    4.   ELSE
    5.     <30 days> CHECKSEQUENCEVERIFY DROP
    6.     <Abdul the Lawyer's Pubkey> CHECKSIGVERIFY
    7.     1
    8.   ENDIF
    9.   <Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 CHECKMULTISIG
    10. ELSE
    11.   <90 days> CHECKSEQUENCEVERIFY DROP
    12.   <Abdul the Lawyer's Pubkey> CHECKSIG
    13. ENDIF

    Mohammed的脚本使用嵌套的IF … ELSE流控制子句来实现三个执行路径。

    在第一个执行路径中，该脚本作为三个合作伙伴的简单的2-of-3 multisig操作。

    该执行路径由第3行和第9行组成。第3行将multisig的定额设置为2（2 - 3）。

    该执行路径可以通过在解锁脚本的末尾设置TRUE TRUE来选择： 解锁第一个执行路径的脚本（2-of-3 multisig）

    1. 0 <Mohammed's Sig> <Zaira's Sig> TRUE TRUE

    提示 此解锁脚本开头的0是因为CHECKMULTISIG中的错误从堆栈中弹出一个额外的值。 额外的值被CHECKMULTISIG忽略，否则脚本签名将失败。 推送0（通常）是解决bug的方法，如CHECKMULTISIG执行中的错误章节所述。

    第二个执行路径只能在UTXO创建30天后才能使用。 那时候，它需要签署Abdul（律师）和三个合作伙伴之一（三分之一）。

    这是通过第7行实现的，该行将多选的法定人数设置为1。要选择此执行路径，解锁脚本将以FALSE TRUE结束： 解锁第二个执行路径的脚本(Lawyer + 1-of-3）

    1. 0 <Saeed's Sig> <Abdul's Sig> FALSE TRUE

    提示 为什么先FALSE后TRUE？ 反了吗？这是因为这两个值被推到堆栈，所以先push FALSE，然后push TRUE。 因此，第一个IF操作码首先弹出的是TRUE。

    最后，第三个执行路径允许律师单独花费资金，但只能在90天之后。 要选择此执行路径，解锁脚本必须以FALSE结束： 解锁第三个执行路径的脚本（仅适用于律师）

    1. <Abdul's Sig> FALSE

    在纸上运行脚本来查看它在堆栈(stack)上的行为。

    阅读这个例子还需要考虑几件事情。 看看你能找到答案吗？

    • 为什么律师可以随时通过在解锁脚本中选择FALSE来兑换第三个执行路径？
    • 在UTXO开采后分别有多少个执行路径可以使用5,35与105天？
    • 如果律师失去钥匙，资金是否流失？ 如果91天过去了，你的答案是否会改变？
    • 合作伙伴如何每隔29天或89天“重置”一次，以防止律师获得资金？
    • 为什么这个脚本中的一些CHECKSIG操作码有VERIFY后缀，而其他的没有？