Mimblewimble can realize non-interactive transactions, Litecoin, Grin, etc. will benefit

Write in front: If a technology is difficult to use or user-friendly, then it will be difficult to adopt it widely. In the previous Mimblewimble protocol, the transaction required the sender and receiver to interact online at the same time, which prevented the large-scale application of related projects. Today, Grin ++ wallet developer David Burkett has proposed a proposal to support Mimblewimble non-interactive transactions, which can be applied to blockchain projects such as Litecoin and Grin .

David Burkett mentioned in the Litecoin Forum developer section:

The biggest news for January is that I found a way to support Mimblewimble's non-interactive trading! The biggest difficulty in using the MW protocol is that the sender and receiver need to communicate, which requires both parties to be online. The new proposal can eliminate this need, thereby removing major obstacles to user experience, while supporting reception via cold storage, making hardware wallets easier to support.

• Blockchain's Transformation of the Computing Power Industry | Return to Common Sense
• Coin Metrics: USDT market usage is optimistic, tokens transfer on average every 8 days
• How many entities hold Bitcoin? These 7 exchanges are worth watching

On the development side, the build process has been determined for libmw and the local build is working for libmw-ltc (check out libmw-core and libmw-ltc to the same parent directory, and you should be able to build libmw-ltc). I will set up CI / CD next month or so.

In addition, I have built a robust database framework with transaction processing capabilities to support atomic updates across multiple tables, and have implemented a currency-independent block database query and update, and have used LTC-specific block headers and The block model was partially tested.

The security audit results are from Grin ++, so I have applied all the fixes to Grin ++ and libmw and will wait for the final review by the auditors. It turns out that the implementation of C ++ is very complicated, and the related audits have taught me lessons. As part of this process, I learned a lot, so the Grin ++ & libmw codebase has become significantly better. Thanks again to the contributors to the Grin, Beam, and LTC communities for making auditing possible.

On the Grin ++ side, we have completed a successful planned hard fork, solving the synchronization problem before the hard fork, and Grin ++ 0.7.5 is now available, which is by far the most stable version.

In February, the first task was to implement the Litecoin Extended Block (EB) consensus rules, including all verifications and a complete set of tests. This is the most important part of the code, so make sure that all the details are correct and that the code has complete test coverage, which will be very time consuming. Once completed, I will develop an API for the extension block (EB) so we can start integrating LBMW into the existing Litecoin code base.

I will also focus on a comprehensive review of the new unilateral transaction proposal, and if no major security issues are identified, I will create a LIP (Litecoin Improvement Proposal) for community feedback.

From this post, we can see that the Mimblewimble application solution that David Burkett is developing for Litecoin is currently in its early stages, and the biggest progress among them is the non-interactive transaction proposal.

So how does this magical solution work? Let's look at the translation of the proposal:

Mimblewimble offline transaction proposal

The Mimblewimble blockchain protocol can improve the privacy and scalability of cryptocurrencies such as Bitcoin by using pedersen promises, schnorr signatures, and a new technology called 'cut-through'. While bringing these benefits, it also needs to pay some expensive price. So far, building MW transactions requires interaction between the sender and receiver to create outputs and collectively sign the transaction. This paper proposes a method to achieve unilateral transactions under conditions that minimize the impact on the scalability and privacy of the mimblewimble protocol.

Current Mimblewimble agreement

Like Bitcoin, Grin also uses the UTXO model. Transactions are created by including inputs to be spent, creating new outputs of equal or lower value, and signing and constructing a range proof that verifies ownership of the inputs.

Unlike Bitcoin, Grin uses confidential transaction (CT) technology, so the inputs and outputs are pedersen promises (rG + vH). Unlike signatures added to the input, each transaction has only one signature, which is part of the transaction kernel.

In order for a transaction to be valid, the following conditions must be met (for simplicity, transaction fees and transaction compensation are ignored):

1. The sum of the output commitments minus the sum of the input commitments must be equal to the kernel commitment, that is (r_out1..n*G +v_out1..n*H) - (r_in1..n*G +v_in1..n*H) = r_kern*G ;
2. A signature of the kernel excess value (rk = sum(ro1..n) - sum(ri1..n)) of some known message base point G;
3. A rangeproof proof that all output values ​​are not negative;

The combination of these three proves that the sender is the owner of the input and guarantees that no new coins are created in the transaction.

This protocol requires the sender (Alice) to interact with the receiver (Bob) to construct transactions to avoid exposing each other's input and output blind factors. This is a three step process:

1. Alice uses her input to create an unsigned transaction, changes the output and rangeproof, an intermediate kernel containing the difference between the output and input blind factors, and submits it to a nonce signed by schnorr;
2. Bob creates his output and rangeproof, adds his share in the kernel commitment to generate the actual transaction kernel, submits it to nonce, and provides a partial signature of the transaction kernel;
3. Alice signs her kernel signature and aggregates the two signatures;

Although the protocol works and allows Alice to transfer funds to Bob without restriction, the interaction properties pose some security, usability, and privacy challenges. Building a transaction requires either the user to keep the key online or some form of out-of-band communication, which can lead to privacy breaches and MITM attacks.

Set up non-interactive transactions

For a long time, the vast majority of people believe that non-interactive transactions are not possible in the mimblewimble protocol, because the blindness factor of informed output is necessary to create rangeproof and construct schnorr signatures.

To solve this problem, we must first find a way to let the sender and receiver know the blindness factor, not others. The Diffie-Hellman key exchange algorithm is very suitable for solving this problem. The sender only needs to generate a key pair, perform ECDH using the receiver's pubkey (public key), and generate a shared key that can be used as a blind factor. The sender can then generate the receiver's output, blind factor, and signature to create a valid transaction.

But this scheme also brings two obvious problems.

The first problem is that the sender still needs to pass its public key and value to the receiver, so we need to include it as part of the output without affecting privacy. But there is no obvious way to submit data. We cannot use it as part of the kernel because it links the kernel to the output, eliminating the benefits of privacy.

The second problem is that Alice and Bob eventually got the keys to the funds, which means that Bob has not become the sole owner of the funds and it is impossible to resolve the dispute. We need a way to verify that only Bob can spend the output.

New proposal

It turns out that nearly 32 bytes of data can be encrypted in range proof. For example, if we use a known key blake2b(output_commitment) , we can publicly submit some additional data. If the data we "encrypt" in rangeproof is a hash, then we can actually submit the required data publicly. This allows us to include a new data block ( output_data ), which contains:

1. Sender's ephemeral public key;
2. Recipient public key;
3. Output value (encrypted with ECDHE(sender's key, receiver's key) );
4. Output blind factor (encrypted with ECDHE(sender's key, receiver's key) );

We can then add the following consensus rules for validating the output:

1. Each range proof is rewindable by using blake2b(output_commitment) ;
2. Each output must include output_data (which includes sender_pubkey , receiver_pubkey and some additional encrypted data);
3. ripemd160(blake2b(output_data)) must match the first 20 bytes of the ripemd160(blake2b(output_data)) range proof data;

The node must store the output_data all UTXOs, so when used later, we can also request a new consensus rule to validate the input:

1. Each input must contain a valid signature: sig(receiver_pubkey, input_commitment)

Inputs and outputs can continue to be pruned as usual, and we now provide a way to send funds to recipients and guarantee that senders cannot re-spend those funds .

safety

Because both the sender and receiver know the blindness of the output, it is not enough to just verify the current UTXO set against the kernel. This requires verification of all recent input signatures. We recommend that new nodes verify all input signatures of recent X blocks, where X = coinbase maturity value, because the risks are similar.

And this still leaves an attack point that seems unlikely today. This attack works as follows (assuming input signatures from the past day are verified):

1. Alice creates a transaction containing Bob's output;
2. Bob sends what Alice bought to the other party;
3. A few days (or even years) have passed, and Bob still hasn't spent his coins;
4. Alice forced a major reorganization of +1 blocks in the past day. She can then send Bob's output back to herself because she knows the blind factor and hasn't performed signature verification on transactions in the block for more than 1 day;

Although such attacks theoretically allow you to spend coins of any age, they must be coins previously sent by the attacker and not consumed by the recipient. However, the benefits that such an attack can bring are unlikely to cover the cost of a reorganization attack. However, to be cautious, when you receive a large amount of coins, you only need to spend these coins yourself to prevent this attack, and the additional core cost required is very small.

Private issues

As long as the key pair is not reused, the above-mentioned scheme will not reveal any additional privacy. To ensure this, we recommend making a fairly small modification to the output data to support some form of hidden address ( ISAP or DKSAP ).

Proof of payment

Payments can now be fairly easily proven. All the necessary conditions to prove a payment are the original output, rangeproof, output_data and merkle proof showing the rangeproof MMR membership.

Multi-signature wallet

Currently, securely sending funds to a multi-signature wallet requires the sender and all recipients to interact. The new proposal eliminates this need at the expense of privacy in multi-signature wallets.

Other improvements

Since we now have a way to submit additional data as part of the output, we can move fees or other data from the kernel into the output_data structure, which allows pruning to reduce the size of the blockchain.

Thanks

Thanks John Tromp for the detailed description of the reorganization attack, Jasper van der Maarel for the advice on bulletproofs and multi-signature wallet technology, and Phyro for the suggestion to move the kernel details to the output data structure. We also thank Daniel Lehnberg, Antioch Peverell, Phyro, and Vladislav Gelfer for their valuable feedback on the above designs.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!