2018-03-01比特币MAST方案分享

比特币MAST方案分享本次分享以下内容：

1、MAST方案实施背景

2、MAST具体实现方案

3、方案的好处

4、可行性分析

内容的四个方面

实现背景：

主要出于比特币安全原因，我们知道所有比特币交易都是公开的、可追溯的，并且永久存储在比特币网络中。美剧《网络犯罪调查》第二季中有一个比特币窃贼被捕的过程，充分展示了比特币交易可追溯的意义（视频）。其原理是锁定比特币交易的时间和金额。地址，只要比特币小偷移动比特币或者在交易平台上出售比特币，他的IP甚至实名信息都可能被追查到。

针对这个溯源问题，提出了几种解决方案，但都不能完全解决

1、使用新地址收款

每次要接收新付款，您都应该使用新的比特币地址。此外，您可以使用多个钱包来满足不同的需求。这样做会隔离您的每个事务，因此它们无法链接。向您付款的人不会看到您的其他比特币地址比特币合约地址，也不会知道您如何使用它们。

2、尽量不要透露比特币地址

如果您从该地址向您的其他地址发送任何资金，这些地址的隐私也将归您所有

3、Coinjoin混合交易

混合交易就是把很多人的交易签名在一起，这样就不容易确定谁和谁有交易，例如：

有两笔交易，用户Blob向Ted转账15BTC，找零5BTC；用户 Alice 转给 Carol 8BTC，换 2BTC，我们将两笔交易合二为一，输入输出不变，用户 Bob 只需对他的输入进行签名，然后交给用户 Alice，而用户 Alice 只需签署她的意见。签名完成后，就可以发布广播了。

本质上，CoinJoin 允许多个用户将来自多个交易的所有输入和输出组合成一个大交易。这样的交易将包括来自不同地址的比特币输入和来自不同地址的输出。它们之间没有联系，我们无法通过发送地址找到对应的接收地址。

（这可以比作一群人把现金放在一起购物，只要每个人都确保自己的钱花在自己的东西上，其他人就无法知道每个人花了多少钱）

目前我们在游戏中使用这种模式。使用场景为用户a向用户b转让一只猫，转让费由平台c支付。这实际上是两笔交易。我们将它们合并为一笔交易，既可以保证交易相互关联，又不需要平台向用户发币，交易过程复杂。

这些方案可以带来一定程度的隐私，但是一旦交易上链，还是有办法锁定交易双方的。 MAST方案可以做到，即使交易在链上，你也可能只知道交易双方的信息。

实施方案

MAST方案由三部分组成，即支付脚本哈希（P2SH）、抽象语法树（AST）和默克尔树

支付哈希脚本（P2SH）

比特币有两种常见的脚本格式

P2PKH（支付到公钥地址模式）：

输出脚本：OP_DUP OP_HASH160 (0x14）[a 20-byte hash] OP_EQUALVERIFY OP_CHECKSIG

输入脚本：[签名字节][签名]0x01[公钥节号][公钥]

P2SH（支付脚本模式，需要使用多重签名）：

输出脚本：OP_HASH160 (0×14)[a 20-byte hash] OP_EQUAL "签名脚本":（输入脚本）

输入脚本：0x00 [bytes] [signature 1] 0x01...[ Bytes] [Signature m] 0x01 [Payment Contract Script Bytes] [m] [Bytes][Public Key1]...[Bytes][Public Key n ][n] OP_CHECKSIGVERIFY

这两者最大的区别是把公钥哈希或者脚本哈希放在输出脚本中。如果放公钥哈希，其实就是地址，那么交易地址就暴露了。如果您放置脚本哈希，您将无法知道它。转账到哪个地址？在这一步，地址已经被隐藏了，但是脚本需要隐藏。

抽象语法树 (AST)

我们来看一个例子：

Alice 希望能够随时使用她的比特币，但如果她的比特币在三个月内没有用完（可能是因为她死了或无能为力），她希望她的兄弟姐妹 Bob 和 Charlie 能够使用她的比特币。

这个脚本不仅包括 Alice 的公钥（需要验证她的私钥的签名），还包括超时逻辑以及 Bob 和 Charlie 的公钥。

在当前的比特币协议中，当爱丽丝的比特币被花费时，上述所有数据都必须加入到区块链中。但是没有使用支出条件，例如 Bob 和 Charlie 的公钥，这会增加交易规模，也会通过公开披露更多信息来暴露更多隐私，MAST 试图通过消除直接包含脚本未使用部分的需要来改善这种情况在区块链中。

抽象语法树 (AST) 是一种通过将程序分解为多个部分来描述程序的方法，这使得分析和优化更加容易。要生成 AST，您需要将每个函数连接到其依赖项，直到所有依赖项都映射完毕。

通过抽象语法树，我们将复杂规则分解为独立的简单条件。如果 Alice 花钱了，就把 Alice 这部分的条件锁住了；如果她的兄弟花钱，他的兄弟的条件被锁住，这不仅降低了交易费用，而且隐藏了未使用的信息。但是当脚本发生变化时，脚本哈希是不同的。为了保证脚本哈希能够验证脚本可以拆分，需要用到默克尔树的概念。

抽象语法树有现成的工具来帮助我们分解脚本。有关详细信息，请参阅

抽象语法树可以将脚本分解成部分，但是如何保证校验通过呢？毕竟消费条件已经上链，无法更改。这需要使用merkle

默克尔树

我们都知道默克尔树是一种特殊的二叉树，其特点是页面节点都是数据，其他非页面子节点都是哈希值。 Merkle Tree 的一个明显优势是它可以取出一个单独的分支（即验证路径）来验证一些数据。

所以我们通过抽象语法树把一个程序分解成不同的部分，然后通过默克尔树可以让我们在不存在整个程序的情况下验证这些部分属于一个完整的程序。

我们继续看上面的例子，这就是我们转换成默克尔树的样子

下面是merkle的两个分支树，如果Alice花钱，就用左边的树，如果她哥哥花钱，就用右边的树，验证只需要证明merkle根哈希相等。

好处1、更多隐私

在这个例子中，只有 alice 知道谁可以使用这个 Funds，以及对资金使用的任何限制，即使这里的资金被花掉了，你也只能知道其中的一个支出条件，而不能知道全貌。当然，Alice 也可以假装自己有很多消费条件，但只能消费。

在上述比特币窃贼的视频中，如果黑客将钱转移到默克尔根哈希中，那么只要他没有花掉钱，警方就不可能查出钱是从谁那里偷来的走了。

缺点是如果是两个商户之间的交易，可能会出现信任危机，因为只有转账的商户才完全知道消费情况，而收款的商户可能只知道一部分条件。

2、小额交易

使用mast后，代码分为几个脚本。当脚本超过 2 部分时，代码量明显减少，因此交易费用也会降低。

3、更大的智能合约

比特币脚本的字节大小是有限制的，一般脚本是1w字节，而P2SH限制是520字节。但是，我们使用 mast 将脚本分解为小脚本。虽然每个脚本限制在 1w 个字节，但整体可能非常复杂。

可行性分析1、什么时候上线

这个没法回答，因为比特币不上线，虽然mast只需要软分叉就可以上线，但是隔离见证已经做了两年了，最近才上线，比特币的发展忙着抄币围棋，核心技术发展比较慢。

2、应用场景待探索

当然你可以把现在的P2PKH改成mast模式，但是对于复杂的场景，用比特币脚本开发合约还是比较难的，比如如何发布一只以太猫？大家都习惯了可视化开发，现在真的很难用汇编语言来开发。

3、保存完整脚本的位置

我们转账时最后使用的merkle root hash比特币合约地址，这个是完整的脚本生成的，只有cost当时只用到了脚本的一部分，中间有时间差。这是一个将完整脚本放在哪里安全的问题。万一丢了，谁也用不着。