声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表火星财经官方立场。
边肖：记得要集中注意力。
资料来源：巴比特
写在前面：如果一项技术很难使用，或者对用户不友好，那么它很难被广泛采用。但之前的Mimblewimble协议需要发送方和接收方同时在线交互，阻碍了相关项目的大规模应用。今天，Grin wallet的开发者David Burkett提出了一个支持Mimblewimble非交互交易的提案，可以应用于Litecoin和Grin等区块链项目。David Burkett在Litecoin论坛的开发者版块提到：
一月份最大的新闻就是我找到了支持Mimblewimble非交互交易的方法！使用MW协议最大的困难是发送方和接收方需要通信，这就要求双方都在线。但是，新的提案可以消除这种需求，这可以消除主要的用户体验障碍，并支持通过冷存储接收，从而使硬件钱包更容易支持。在开发方面，已经为libmw确定了构建过程，本地构建正在为libmw-ltc工作(将libmw-core和libmw-ltc签出到同一个父目录，您应该能够构建libmw-ltc)。我将在下个月左右建立CI/CD。
此外，我还构建了一个具有事务处理功能健壮的数据库框架，以支持跨多个表的原子更新，并实现了与货币无关的块数据库的查询和更新，该数据库已经用LTC专用的块头和块模型进行了部分测试。
安全审计结果是从Grin获得的，所以我已经对Grin和libmw应用了所有的修复，并将等待审计人员的最终审查。事实证明，C的实现非常复杂，相关审计给了我一个教训。作为这个过程的一部分，我学到了很多，所以Grin libmw代码库明显变得更好了。再次感谢Grin、Beam和LTC社区的贡献者，是他们让审计成为可能。
在Grin方面，我们已经完成了一次成功的计划硬分叉，解决了硬分叉前的同步问题，Grin 0.7.5现已面世，是目前为止最稳定的版本。
2月份的第一项任务是实现Litecoin扩展块(EB)的共识规则，包括所有验证和一整套测试。这是代码中最重要的部分，所以要确保所有的细节都是正确的，代码有完整的测试覆盖，这将非常耗时。一旦完成，我将为扩展块(EB)开发API，以便我们可以开始将LBMW集成到现有的Litecoin代码库。
我还将集中精力全面审查新的单边交易提案。如果没有发现重大安全问题，我将创建一个LIP (Litecoin改进建议)用于社区反馈。
从这篇帖子中，我们可以看到David Burkett目前正在为Litecoin开发的Mimblewimble应用方案正处于起步阶段，最大的进展就是非交互交易提案。
那么，这个神奇的方案是如何实现的呢？让我们来看看提案的译文：
Mimblewimble离线交易提议
Mimblewimble区块链协议可以通过使用pedersen promise、schnorr签名和一种称为“直通”的新技术来提高比特币等加密货币的隐私性和可扩展性。在带来这些好处的同时，它也需要付出一些昂贵的代价。到目前为止，构建MW事务需要发送方和接收方之间的交互来创建输出并共同签署事务。提出了一种在最小化对mimblewimble协议可扩展性和隐私性影响的条件下实现单边事务的方法。
当前的Mimblewimble协议
和比特币一样，Grin使用UTXO模型。通过包括要花费的投入、创建相等或更低价值的新产出以及签署和建立范围证明来验证投入的所有权，来创建交易。
与比特币不同，Grin使用的是机密交易(CT)技术，所以输入输出都是彼得森承诺(rG vH)。与添加到输入中的签名不同，每个事务只有一个签名，它是事务内核的一部分。
为了使交易有效，必须满足以下条件(为简单起见，忽略交易成本和补偿):
输出承诺的总和减去输入承诺的总和必须等于内核承诺，即(r _ out1.n * g v _ out1.n * h)-(r _ in1.n * g v _ in1.n * h)=r _ kern * g；内核ExcessValue的签名(RK=sum (RO1.n)-总和(RI1.n))的一些已知消息基点G；射程证明)；所有输出值都不是负的；三者的结合证明了发送者是投入物的所有者，并保证了交易中不会产生新的硬币。
但是这个协议需要发送方(Alice)和接收方(Bob)进行交互来构造一个事务，避免暴露对方输入输出的盲目因素。这是一个分为三步的过程：
Alice用她的输入创建一个无符号事务，改变输出和rangeproof，一个包含输出和输入之间的盲因子差的中间内核，并将其提交给nonce施诺尔签名；Bob创建他的输出和rangeproof，添加他在内核承诺中的份额以生成实际的事务内核，将其提交给nonce，并提供事务内核的部分签名；Alice签署她的内核签名，并聚合这两个签名；虽然该协议可以工作，并允许Alice无限制地向Bob转账，但其交互性在安全性、可用性和隐私性方面带来了一些挑战。构建交易要么需要用户在线保存密钥，要么需要某种形式的带外通信，这可能会导致隐私泄露和MITM攻击。
建立非交互式事务
长期以来，大多数人认为在mimblewimble协议中不可能实现非交互式事务，因为创建rangeproof和构造schnorr签名需要知情输出的盲因子。
要解决这个问题，首先要想办法让发送者和接收者都知道盲因子，而不让其他人知道。Diffie-Hellman密钥交换算法非常适合解决这个问题。发送方只需要生成一个密钥对，用接收方的公钥执行ECDH，生成一个共享密钥，可以作为盲因子。然后，发送方可以生成接收方的输出、盲因子和签名，以创建有效的交易。
但这种方案也带来了两个明显的问题。
第一个问题是，发送方仍然需要将其公钥和值传递给接收方，因此我们需要在不影响隐私的情况下将其作为输出的一部分。但是没有明显的提交数据的方法。我们不能将它作为内核的一部分，因为它会将内核链接到输出，从而消除隐私的好处。
第二个问题是，爱丽丝和鲍勃最后都拿到了基金的钥匙，也就是说鲍勃并没有成为基金的独家所有人，纠纷是不可能解决的。我们需要一种方法来验证只有Bob可以花费输出。
一项新提议
已经证明，在rangeproof中可以加密近32字节的数据。例如，如果我们使用一个已知的key blake2b(output_commitment)，我们可以公开提交一些额外的数据。如果我们在rangeproof中“加密”的数据是一个散列，那么我们实际上可以公开提交所需的数据。这允许我们包含一个新的数据块(output_data ),它包含：
发送方的临时公钥；收件人的公钥；输出值(用ecdhe(发送方密钥，接收方密钥)加密)；输出盲因子(用ECD He(发送方密钥，接收方密钥)加密)；然后，我们可以添加以下一致性规则来验证输出：
每个rangeproof都可以通过使用blake2b(output_commitment)进行重绕；每个输出必须包含output_data(包括sender_pubkey、receiver_pubkey和一些额外的加密数据)；RIMD160(布雷克2B(output _ data))必须匹配重绕范围认证数据的前20个字节；节点必须存储所有UTXO的output_data，因此我们还可以要求1个新的共识规则，以便在以后使用它时验证输入：
每个输入必须包含一个有效的签名：SIG (receiver _ pubkey，input _ commitment)输入和输出可以像往常一样继续被修剪。我们现在提供了一种向接收方发送资金的方式，并保证发送方不能重新花费这些资金。
安全
因为发送方和接收方都知道输出的盲因子，所以只根据内核来验证当前的UTXO集是不够的。这需要验证所有最近输入的签名。我们建议新节点验证最近的X块的所有输入签名，其中X=coinbase成熟值，因为风险是相似的。
而这仍然会留下一个在今天看来不太可能实现的攻击点。这种攻击的工作方式如下(假设已经验证了过去一天的输入签名):
Alice为Bob创建了一个带有输出的事务；把Bob Alice买的东西发给对方；几天(也许甚至几年)过去了，鲍勃仍然没有花光他的钱；在过去的一天里，爱丽丝强迫一个街区进行了大规模重组。然后，她可以将Bob的输出发送回自己，因为她知道盲因子，并且没有在超过1天的块中签署交易；虽然这种攻击理论上可以让你花掉任何币龄的硬币，但必须是攻击者之前发出的，而不是接收者花掉的硬币。但是，这种攻击所能带来的好处不太可能覆盖重组攻击的成本。不过谨慎一点，当你收到大量硬币的时候，你只需要自己花掉就可以防止这种攻击，但是额外需要的内核成本是很小的。
隐私问题
只要密钥对不被重用，上面提到的方案就不会泄露任何额外的隐私。为了确保这一点，我们建议对输出数据做一个相当小的修改，以支持某种形式的秘密地址(ISAP或DKSAP)。
付款证明
现在，付款很容易证明。证明付款的所有必要条件是原始输出、rangeproof、output_data和merkle proof(显示范围证明的MMR成员资格)。
多重签名钱包
目前，要安全地向多签名钱包发送资金，发送方和所有接收方需要进行交互。然而，新提案以多签名钱包的隐私损失为代价消除了这种需要。
其他改进
由于我们现在有了提交额外数据作为输出的一部分的方法，我们可以将费用或其他数据从内核移动到output_data结构，这允许修剪，从而减小区块链的大小。
表示感谢/感激
感谢John Tromp对重组攻击的详细描述，感谢Jasper van der Maarel对bulletproofs和多重签名钱包技术的建议，感谢Phyro将内核细节移入输出数据结构的建议。同时，我要感谢Daniel Lehnberg、Antioch Peverell、Phyro和Vladislav Gelfer对上述设计的宝贵反馈。
