00美元的费用收入。像往常一样：侧链的coinbase txn将向某人（在本例中为“Simon”）支付这2000美元。在BIP301下，Simon不进行散列，而是让一个layer1 txn向layer1矿工（“Mary”）支付1999美元。 BIP301使这种专业化的劳动在第一层变得不可信。如果 Mary 拿走了 Simon 的钱，那么她必须让 Simon 控制一边：块。 规格说明 BIP300由两条消息组成：“BMM接受”和“BMM请求”。这些管理称为“h*”的东西。 所以我们将讨论： H* — 侧链的hashMerkleRoot，以及它的重要性。 “BMM Accep” — h*如何输入 main:coinbase。当Mary”接受”BMM请求时，Mary正在认可一个side:block。 “BMM请求” — — Simon 向 Mary 提供资金，如果（且仅当）她将认可一个特定的h*。当 Simon 广播BMM请求时，Simon 正在尝试一个 side:block。 h* h*（”h star”）是侧链的Merkle根哈希。 在BIP301中，侧链的coinbase txn充当标头（它包含前一个side： block和前一个main：block的哈希）。因此，MerkleRoot包含所有重要的内容。 注意：在BIP301侧链中，“header”和“block hash”没有显著的共识意义，在设计中主要是为了帮助IBD。（相比之下，在主链中，header和block hash决定了难度调整和累积PoW。） 上图：h*位于main： coinbase中。h*包含所有side：txns，包括side：coinbase。side：coinbase包含许多“类似头”的字段，例如上一个side：block的哈希。 Mary控制main： coinbase，因此她可以选择任何h*。她的选择将决定哪个side：block被“找到”。 BMM接受 要“接受”BMM的提议（并接受 Simon 的钱），Mary 必须支持 Simon 的区块。 对于每一 side:block Mary希望背书，Mary将以下内容放入 main:coinbase OP_RETURN： 1字节-OP_RETURN（0x6a） 4字节-消息头（0xD1617368） 32字节-h*（从Simon获得） 代码详情在这里。 如果这些OP_RETURN输出不存在，则不接受任何请求。（而且，Mary 不会从请求中得到钱。） Mary 和 Simon 有可能是同一个人。他们会完全信任对方，所以BMM过程就到此为止。只有接受；请求是不必要的。 当Simon和Mary是不同的人时，Simon将需要使用BMM请求。 BMM请求 Simon 将使用BMM请求从 Mary 那里购买查找侧链块的权利。 对于Simon想要尝试的每一 Side:Block ，他广播一个包含以下内容的txn： 3字节-消息头（0x00bf00） 32字节-h*（边：MerkleRoot） 1 byte-nSidechain（侧链ID） 4-bytes-prepreMainHeaderBytes（前一个main： block的最后四个字节） 我们使用扩展序列化格式。（SegWit使用ESF在txns中定位scriptWitness数据；我们在这里使用它来定位上面的五个字段。） Message头将此txn标识为BMM事务。h*由Simon选择以对应于他的side： block。nSidechain是创建侧链时分配给侧链的编号。preSideBlockRef允许Simon在任何先前存在的side：block上构建（允许他绕过一个或多个无效块，详情如下）。MainpreHeaderBytes是前一个main：block的最后四个字节（详情如下）。 如果此txn未通过以下任何检查，则此txn无效： 每个“BMM请求”都必须匹配一个相应的“BMM接受”（上一节）。 每个main： block中每个侧链只允许一个BMM请求。换句话说，如果700个用户为侧链#4广播BMM请求，那么main：miner会挑出一个BMM请求来包含。 4个字节的 prevMainHeaderBytes 必须匹配前一个 main:block header的最后四个字节。因此，Simon的txns仅对当前块有效，在他知道的块历史中（因此，他知道的当前侧链历史）。 大多数BMM请求txns永远不会成为一个块。 Simon 会提出许多BMM请求，但只有一个会被接受。由于只有一个BMM请求可以成为真正的交易， Simon 可能会觉得整天都可以提出多个报价。这意味着 Mary 有许多报价可供选择，并且可以选择支付她最多的一个。 此BIP允许BMM请求通过 Lightning进行。一种方法在这里。（BMM接受不能超过LN，因为它们驻留在main： coinbase txns中。） 向后兼容 作为软分叉，旧软件将继续运行而无需修改。为了无信任地强制执行BMM，节点必须观察“成对”的交易，并使其受到额外规则的约束。未升级的节点会注意到区块链中存在此活动，但他们不会理解其中的任何一个。 就像P2SH或新的OP Code一样，这些老用户永远不会直接受到分叉的影响，因为他们不会期望收到这种付款。（事实上，这里唯一收到BTC的人都碰巧是矿工。所以比以往任何时候都没有理由期待兼容性问题。） 与所有以前的软分叉一样，未升级的用户会受到间接影响，因为他们不再执行完全验证。 部署 此BIP将通过 UASF-style 的块高度激活进行部署。块高度TBD。 参考实施 见：https://github.com/drivechain-project/mainchain 另外，有关兴趣，请参阅此处的示例侧链：https://github.com/drivechain-project/sidechains/tree/testchain 参考文献 http://www.drivechain.info/literature/index.html http://www.truthcoin.info/blog/blind-merged-mining/ http://www.truthcoin.info/images/bmm-outline.txt 贡献者 感谢所有为讨论做出贡献的人，特别是：ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber。 版权 该BIP根据BSD2条款许可证获得许可。 来源：金色财经lg...
北美站
