# Minglejingle: Scalable blockchain with non-interactive transactions **URL:** \ **Category:** Research\ **Created:** [January 22, 2021, 5:53pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288 "2021-01-22T17:53:48Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [January 22, 2021, 5:53pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/1 "2021-01-22T17:53:48Z")
> Feel free to review and comment. Should be relevant since discussions about non-interactive transactions have taken place here in the past. ---
**Author:** ![senator](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/senator/32/3388_2.png) [@senator](https://forum.grin.mw/u/senator)\ **Post date:** [January 22, 2021, 9:27pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/2 "2021-01-22T21:27:06Z")
Could GRIN be redesigned in case it determines that (MJ) is a more efficient protocol? ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [January 22, 2021, 9:43pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/3 "2021-01-22T21:43:44Z")
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. ---
**Author:** ![oryhp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/oryhp/32/2923_2.png) [@oryhp](https://forum.grin.mw/u/oryhp)\ **Post date:** [January 22, 2021, 10:39pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/4 "2021-01-22T22:39:49Z")
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. ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [January 23, 2021, 11:07am UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/5 "2021-01-23T11:07:56Z")
@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. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [January 23, 2021, 4:49pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/7 "2021-01-23T16:49:58Z")
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. ---
**Author:** ![grin001](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/grin001/32/4403_2.png) [@grin001](https://forum.grin.mw/u/grin001)\ **Post date:** [January 24, 2021, 1:31am UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/8 "2021-01-24T01:31:04Z")
It’s a very good plan！ ---
**Author:** ![liberty](https://avatars.discourse-cdn.com/v4/letter/l/958977/32.png) [@liberty](https://forum.grin.mw/u/liberty)\ **Post date:** [February 9, 2021, 6:16am UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/9 "2021-02-09T06:16:44Z")
This would be super awesome if implemented!! Keeping my fingers crossed! ---
**Author:** ![Ghost](https://avatars.discourse-cdn.com/v4/letter/g/f04885/32.png) [@Ghost](https://forum.grin.mw/u/Ghost)\ **Post date:** [February 16, 2021, 11:11pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/10 "2021-02-16T23:11:44Z")
It is an exciting read. How do we test it? ---
**Author:** ![Paouky](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/paouky/32/513_2.png) [@Paouky](https://forum.grin.mw/u/Paouky)\ **Post date:** [February 17, 2021, 9:45am UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/11 "2021-02-17T09:45:22Z")
Davidb is implementing it on Litecoin MW Extension Blocks, I believe. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [February 17, 2021, 1:12pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/12 "2021-02-17T13:12:10Z")
> [@Paouky](#): > > Davidb is implementing it on Litecoin MW Extension Blocks 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? ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [February 17, 2021, 3:24pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/13 "2021-02-17T15:24:16Z")
> 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 ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [February 17, 2021, 6:56pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/14 "2021-02-17T18:56:34Z")
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. ---
**Author:** ![dog](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/dog/32/2230_2.png) [@dog](https://forum.grin.mw/u/dog)\ **Post date:** [February 17, 2021, 7:29pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/15 "2021-02-17T19:29:51Z")
Well said, and that makes this a lot easier to compare with mw ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [February 17, 2021, 8:32pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/16 "2021-02-17T20:32:46Z")
Minglejingle is not an upgrade path from Mimblewimble. It’s a separate protocol. > [@tromp](#): > > 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 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. ---
**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\ **Post date:** [February 18, 2021, 9:51am UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/17 "2021-02-18T09:51:44Z")
> [@tevador](#): > > MJ is not designed to mix non-interactive and interactive transactions 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 😉 ---
**Author:** ![david](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/david/32/660_2.png) [@david](https://forum.grin.mw/u/david)\ **Post date:** [February 18, 2021, 2:57pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/18 "2021-02-18T14:57:58Z")
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. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [February 18, 2021, 3:12pm UTC](https://forum.grin.mw/t/minglejingle-scalable-blockchain-with-non-interactive-transactions/8288/19 "2021-02-18T15:12:38Z")
> [@david](#): > > you can’t assume the same wallet seed isn’t used on 2 different wallets You can if the user declares a seed not to be shared. > [@david](#): > > And address checksums make (4) irrelevant. There are other causes of lost funds besides mistyping, such as using a recipient address that the recipient can no longer access.