liquidswap-cli finalize accepted.txt --send

　　这 3 个步骤是使swap交易与标准交易无法区分的必要步骤。但是，它也存在着一些缺点。

　　该协议分析起来会更复杂。由于不同的原因，它可能会在不同的步骤失败，也许是提议格式不正确，交易不再有利可图，那么一方可能会中止协议。

　　Alice 还需要在线才能完成协议。 如果 Alice 花费太多时间来完成，Bob 可能会进行另一次swap交易并使他接受的提议无效。

　　这使得用户体验变得繁琐，并且很难将这些swap交易集成到其他服务中。

　　而一个两步协议将解决大多数的问题，事实上，两步协议的用户体验非常类似于“发送交易”：Alice询问她想要交换什么，然后最终交换发生。

　　在过去的几个月里，我们构建出了LiquiDEX这个想法。

　　LiquiDEX 是一个在 Liquid 网络上执行原子交换的两步协议。

　　该协议涉及到了两方：Maker 和 Taker，其中Maker 想要发送一些资产并接收一些其他资产作为交换，它创建 LiquiDEX 提议并发送给 Taker。Taker 接受该提议，并在 Liquid网络上结算swap交易。

• 　　版本：数字，可选的非负整数，默认为 0，

• 　　tx：字符串，十六进制编码的签名 Liquid 交易，

• 　　输入：对象数组，交易输入的非盲信息；item具有以下属性：Asset：字符串，十六进制编码的资产，聪：以聪为单位的整数数量，assetblinder:字符串，十六进制编码的资产盲注，amountblinder: 字符串，十六进制编码的数量盲注，

• 　　输出：对象数组，交易输出的非盲信息；item具有相同的输入对象格式。

　　Asset、assetblinder 和 amountblinder 与 Elements Core 一致地进行十六进制序列化，这与它们的字节序列化相反。

　　LiquiDEX 提案格式定义了 Maker 和 Taker 必须达成一致的内容。其他一切都可以由双方任意选择以实现所需的行为。

　　让我们分析一个他们可能选择做什么的例子。

第 1 步：Maker 制作提议（proposal）

　　Maker 有一个UTXO U_xA持有x数量的A资产，而他想要将其资产交换成y数量的B资产。

　　Maker创建了一笔交易，花费单个UTXO U_xA并接收y数量的B资产。

　　Maker屏蔽（blinds）这个输出。在实践中，这有一些重要的挑战，权衡和实现细节将在下一节中讨论。

　　Maker 使用SIGHASH_SINGLE | SIGHASH_ANYONECANPAY 对（唯一）输入进行签名，这允许 Taker 添加更多的输入和输出，而不会使 Maker 签名无效。

　　其他Maker按照上述规定创建 LiquiDEX 提议，并将提议发送给 Taker。

第 2 步：Taker 接受提议（proposal）

　　Taker 收到提议，并进行一些验证，其中可能包括： (责任编辑：admin)