Minglejingle: Scalable blockchain with non-interactive transactions

tevador · January 22, 2021, 5:53pm

gist.github.com

https://gist.github.com/tevador/f3a66a2f15a8a3a04a1dde1ea65f9205

minglejingle.md

## Minglejingle: Scalable blockchain with non-interactive transactions

This article describes the Minglejingle (MJ) protocol: a redesign of Mimblewimble (MW) for non-interactive transactions. It preserves the security and privacy properties, supports payment proofs and off-chain payjoins.

### 1. Introduction

Blockchains are distributed ledgers that preserve the transaction history so that new network participants can, at any point in the future, verify these two security properties:

1. **Supply security**: No counterfeit coins have been created.
2. **Ownership security**: No coins have been moved without the authorization by the owner of the associated private keys.

This file has been truncated. show original

Feel free to review and comment.

Should be relevant since discussions about non-interactive transactions have taken place here in the past.

senator · January 22, 2021, 9:27pm

Could GRIN be redesigned in case it determines that (MJ) is a more efficient protocol?

tevador · January 22, 2021, 9:43pm

Actually, MW is still the more efficient protocol if you can live with interactive transactions.

And the differences between the protocols are so large that I don’t think it’s suitable as a fork for an existing MW blockchain.

oryhp · January 22, 2021, 10:39pm

I’m a big proponent of interactive transactions, but this document is a pleasure to read and is very well structured. I especially liked that you approached this by reasoning about the properties the other proposals were partly missing (namely payment proofs and ownership security) and describing a way to get them back. I’ll reread it again when I’m less tired, just wanted to thank you for sharing this work. I hope you stay around.

Edit:

However, this replay attack doesn’t achieve much (besides Mallory losing his money), so a solution may not be necessary.

I think here’s a typo and it should be Dave instead of Mallory. It is possible to steal money through an attack like this. Let’s say there exists a TX_N which sends coins to Mallory and TX_N is a continuation of the TX2 graph - a transaction graph that builds from an output created in TX2. If Mallory replays a sequence of transactions TX2 → TX3 → … TX_N, she could profit from this attack. As long as there exists a sequence of known state transitions where Mallory profits (or anyone else as any observer can pull off the attack), then it is profitable for this party (or many) to replay a sequence of transactions. These kind of replay attacks that replay a sequence of transactions may become harder to pull off in practice if we have a good (preferably trustless) way of aggregating transactions together - which is another open problem and we’re just starting exploring the ideas of how to achieve this.

There are some details that I’ve skipped. It’s not really enough to know all the state transitions, some other constraints need to hold as well.

tevador · January 23, 2021, 11:07am

@oryhp I’ve updated section 5.5 to explain why it’s the sender of the duplicate output who is losing money and not Dave.

Anynomous · January 23, 2021, 4:49pm

It looks interesting @tevador, I only partly red it and only partly get it.
Just a though in general about adding non-interactive transaction to Grin:

Can we not use something like extention blocks to provide non-interactive transaction while not being part of the core of Grin? Basically I think that interactive-transactions are in most cases not an issue except for

Receiving mining rewards and
Interaction with exchanges.

So although not great for transaction monotonicity and while not being the most elegant solution, side-chains or extention-blocks would provide a practical solution without need to bloat or even adjust the core of Grin.
Since coins can be burned and created when moved to and from the side-chain/extention-block, compatability becomes less important allowing for more diverse solutions like Minglejingle which provide a practical solution.

grin001 · January 24, 2021, 1:31am

It’s a very good plan！

liberty · February 9, 2021, 6:16am

This would be super awesome if implemented!! Keeping my fingers crossed!

Ghost · February 16, 2021, 11:11pm

It is an exciting read.
How do we test it?

Paouky · February 17, 2021, 9:45am

Davidb is implementing it on Litecoin MW Extension Blocks, I believe.

Anynomous · February 17, 2021, 1:12pm

Ok, maybe that is why I thought the idea sounded familiar when I red it. Can anyone of the Grin developers summarize again why Grin is not implementing Minglejingle (yet)? I thought it “the signature not being proven secure in the random oracle model”, or was it something else?

tromp · February 17, 2021, 3:24pm

Can anyone of the Grin developers summarize again why Grin is not implementing Minglejingle (yet)?

It has so many downsides.

it adds a huge amount of complexity, making Grin harder to understand and explain
it bloats the chain
it’s hard to mix with regular MW transactions
it makes it easier to lose funds by sending to a wrong address
it makes future 2nd layer transacting behave differently
it requires scanning the chain to see if someone paid you
it adds unneccesary friction to use cases that are naturally multisig, including atomic swaps and payment channels

Anynomous · February 17, 2021, 6:56pm

Thanks @tromp, clearly enough reasons to think long and hard for better solutions. Still it could have its use when be implemented in a side chain of Grin but only if nothing better can be found.

dog · February 17, 2021, 7:29pm

Well said, and that makes this a lot easier to compare with mw

tevador · February 17, 2021, 8:32pm

Minglejingle is not an upgrade path from Mimblewimble. It’s a separate protocol.

I’d say it adds a reasonable amount of complexity compared to vanilla MW. Still nothing compared to Monero, though.
Correct, although again nothing compared to other blockchains like zcash, beam or Monero.
MJ is not designed to mix non-interactive and interactive transactions.
It’s a double-edged sword because for example, Grin cannot be sent to a paper wallet.
I don’t see how it’s relevant.
Correct, that’s the only way how privacy can work without any sender-receiver interaction. But the sender could also provide the transaction ID to the recipient out of band, in which case no scanning is needed.

Anynomous · February 18, 2021, 9:51am

But could mimble wimble and minglejingle theoretically interact if they are on a separate chains, e.g. via some coin burning and creation process, or in another way?

If so, could be a sperate project, a "Smile’ mingeljingle blockchain that interact with the “Grin” mimble wimble blockchain

david · February 18, 2021, 2:57pm

I echo what @tevador says, but (6) is also generally true for vanilla mw, because you can’t assume the same wallet seed isn’t used on 2 different wallets (mobile and desktop, for example). Both Grin/MW and Grin++ scan every output.

And address checksums make (4) irrelevant.

tromp · February 18, 2021, 3:12pm

You can if the user declares a seed not to be shared.

There are other causes of lost funds besides mistyping, such as using a recipient address that the recipient can no longer access.

Topic		Replies	Views
Mimblewimble CoinSwap proposal Development and Technical Discussion	75	11945	October 8, 2023
Another Take on Non Interactive Transactions Development and Technical Discussion	21	1478	December 23, 2018
Mimblewimble Whitepaper V2 Research	5	1318	January 17, 2021
Happy MimbleWimble Day!	0	317	July 19, 2019
Mimblewimble Non-Interactive Transactions Development and Technical Discussion	10	1694	February 18, 2018

Minglejingle: Scalable blockchain with non-interactive transactions

Related Topics