Minglejingle: Scalable blockchain with non-interactive transactions

Feel free to review and comment.

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

11 Likes

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

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.

1 Like

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 TXN which sends coins to Mallory and TXN 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 -> … TXN, 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.

1 Like

@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.

1 Like

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

  1. Receiving mining rewards and
  2. 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.

2 Likes

It’s a very good plan!

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

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

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

1 Like

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?

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

It has so many downsides.

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

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.

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

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

  1. I’d say it adds a reasonable amount of complexity compared to vanilla MW. Still nothing compared to Monero, though.
  2. Correct, although again nothing compared to other blockchains like zcash, beam or Monero.
  3. MJ is not designed to mix non-interactive and interactive transactions.
  4. It’s a double-edged sword because for example, Grin cannot be sent to a paper wallet.
  5. I don’t see how it’s relevant.
  6. 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.
1 Like

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 :wink:

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.

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.