Mimblewimble new proposal: non-interactive transactions, Litecoin and Grin will benefit

Original title: "Mimblewimble can realize non-interactive transactions, Litecoin, Grin, etc. will benefit"
Written by: David Burkett, Grin++ Developer Translated by: Satuoxi

If a technology is difficult to use or user-unfriendly, it will be difficult to be widely adopted. The previous Mimblewimble protocol required the sender and receiver to interact online at the same time, which hindered the large-scale application of related projects. Today, Grin++ wallet developer David Burkett 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 in January was that I found a way to support non-interactive transactions with Mimblewimble! The biggest difficulty with the MW protocol is that the sender and receiver need to communicate, which requires both parties to be online. The new proposal removes this need, thereby removing a major user experience barrier, while supporting receiving via cold storage, making it easier for hardware wallets to support.

On the development side, the build process has been finalized for libmw, and local builds are 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 be setting up CI/CD in the 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 implemented coin-independent block database queries and updates, which have been partially tested with LTC-specific block headers and block models.

The security audit results were derived from Grin++, so I have applied all fixes to Grin++ and libmw and will await the final review by the auditors. It turns out that the C++ implementation is very complex and the relevant audit taught me lessons. I learned a lot as part of this process, and the Grin++ & libmw codebases are significantly better as a result. Thanks again to the contributors in the Grin, Beam and LTC communities who made the audit possible.

On the Grin++ front, we have completed a successful planned hard fork, resolved pre-hard fork synchronization issues, and Grin++ 0.7.5 is now available, which is the most stable version to date.

The first task in February is to implement the consensus rules for the Litecoin extension block (EB), including all validation and a full set of tests. This is the most important part of the code, so it will be very time-consuming to ensure that all the details are correct and the code has complete test coverage. Once completed, I will develop an API for the extension block (EB) so that we can start integrating LBMW into the existing Litecoin code base.

I will also focus on fully reviewing new one-sided transaction proposals, and if no major security issues are found, 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 currently developing for Litecoin is in its early stages, and the biggest progress is the non-interactive transaction proposal.

So, how exactly is this magical solution implemented? Let’s take a look at the translation of the proposal:

Mimblewimble Offline Transaction Proposal

The Mimblewimble blockchain protocol improves the privacy and scalability of cryptocurrencies like Bitcoin by using Pedersen commitments, Schnorr signatures, and a new technique called 'cut-through'. These benefits come at a high price. Until now, constructing MW transactions required interaction between the sender and receiver to create outputs and collectively sign the transaction. This paper proposes a method to implement one-sided transactions with minimal impact on the scalability and privacy of the Mimblewimble protocol.

The current Mimblewimble protocol

Like Bitcoin, Grin uses the UTXO model. Transactions are created by including inputs to spend, creating new outputs of equal or lower value, and signing and constructing range proofs that verify ownership of the inputs.
Unlike Bitcoin, Grin uses confidential transactions (CT), so inputs and outputs are pedersen commitments (rG + vH). Unlike signatures added to inputs, each transaction has only one signature, which is part of the transaction kernel.

For a transaction to be valid, the following conditions must be met (ignoring transaction fees and transaction compensation for simplicity):

1. The sum of the output commitments minus the sum of the input commitments must equal the kernel commitment, i.e. (r_out1..nG +v_out1..nH) - (r_in1..nG +v_in1..nH) = 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 that proves that all output values ​​are non-negative;

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

This protocol requires the sender (Alice) and the receiver (Bob) to interact to construct a transaction in order to avoid exposing each other’s input and output blinding factors. This is a three-step process:

Alice creates an unsigned transaction with her inputs, changes the outputs and the rangeproof, an intermediate kernel containing the difference between the output and input blinding factors, and submits the Schnorr-signed nonce.
2. Bob creates his output and rangeproof, adds his share of the kernel commitment to produce the actual transaction kernel, commits to the nonce, and provides a partial signature of the transaction kernel;
Alice signs her kernel signature and aggregates the two signatures.

While the protocol works and allows Alice to transfer funds to Bob without restriction, the interactive nature of the transaction introduces several security, usability, and privacy challenges. Constructing transactions either requires users to keep their keys online or requires some form of out-of-band communication, which can lead to privacy breaches and MITM attacks.

Setting up non-interactive transactions

For a long time, it was widely believed that non-interactive transactions were impossible in the mimblewimble protocol because informed output blinding factors are necessary to create rangeproofs and construct schnorr signatures.

To solve this problem, we must first find a way to let the sender and receiver know the blinding factor, but no one else. The Diffie-Hellman key exchange algorithm is well suited to solve this problem. The sender only needs to generate a key pair, perform ECDH with the receiver's pubkey (public key), and generate a shared key that can be used as a blinding factor. The sender can then generate the receiver's output, blinding factor, and signature to create a valid transaction.

But this solution also brings two obvious problems.

The first problem is that the sender still needs to pass their public key and value to the receiver, so we need to include it as part of the output without compromising privacy. But there is no obvious way to submit the data. We can't include it as part of the kernel because it would link the kernel to the output, eliminating the privacy benefits.

The second problem is that both Alice and Bob end up with the keys to the funds, which means Bob does not become the sole owner of the funds and it is impossible to resolve disputes. We need a way to verify that only Bob can spend the output.

New proposals

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

1. The sender's ephemeral public key;

2. The recipient's public key;

3. Output value (encrypted using ECDHE(sender's key, receiver's key));

4. Output blinding factor (encrypted using ECDHE(sender's key, receiver's key));

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

1. Each rangeproof is rewindable using blake2b(output_commitment);

2. Each output must contain 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 rewound range proof data;

Nodes must store the output_data of all UTXOs, so when used later, we can also require 1 new consensus rule to verify the input:
Each input must contain a valid signature: sig(receiver_pubkey, input_commitment)

Inputs and outputs can continue to be pruned as usual, we now provide a way to send funds to a recipient with the guarantee that the sender cannot respend those funds.

Security

Because both the sender and receiver know the blinding factor of the output, it is not enough to just verify the current UTXO set against the kernel. This requires verifying the signatures of all recent inputs, and we recommend that new nodes verify all input signatures of the most recent X blocks, where X = coinbase maturity, because the stakes are similar.

This still leaves one attack point that seems unlikely to be possible today. This attack works as follows (assuming that the input signatures from the past day are verified):

1. Alice creates a transaction containing an output for Bob.

2. Bob sends the things Alice bought to the other party;

3. Days (or maybe even years) go by, and Bob still hasn’t spent his coins;

4. Alice forces a major reorganization of the past day + 1 blocks. She can then send Bob’s output back to herself because she knows the blinding factor and has not verified the signatures of transactions in blocks older than 1 day;

Although this attack theoretically allows you to spend coins of any age, they must be coins that were previously sent by the attacker and have not been spent by the recipient. However, the benefits of this attack are unlikely to cover the cost of performing a reorganization attack. However, to be prudent, when you receive a large amount of coins, you can prevent this attack by just spending them yourself, with very little additional kernel cost.

Privacy issues

The schemes described above do not leak any additional privacy as long as key pairs are not reused. To ensure this, we propose a fairly minor modification to the output data to support some form of stealth addresses (ISAP or DKSAP).

Proof of Payment

Payments can now be proven fairly easily. All that is necessary to prove a payment is the original output, the rangeproof, the output_data, and a merkle proof showing the rangeproof’s 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 the privacy of the multi-signature wallet.

Other improvements

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

Acknowledgements

Thanks to John Tromp for a detailed description of the reorg attack, Jasper van der Maarel for advice on bulletproofs and multi-signature wallets, and Phyro for the suggestion to move kernel details into the output data structure. Many thanks to Daniel Lehnberg, Antioch Peverell, Phyro, and Vladislav Gelfer for their valuable feedback on the above design.

Source link: litecointalk.io