# Non-interactive transactions for the MW blockchain **URL:** \ **Category:** Research\ **Created:** [April 29, 2023, 4:16pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472 "2023-04-29T16:16:04Z")\ **Posts on this page:** 11\ **Page:** 3
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 7, 2023, 5:31pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/41 "2023-07-07T17:31:52Z")
> [@tevador](#): > > That does not actually solve the issue. > > Any payment proof must be bound to the output key `B` by showing that it was indeed constructed from the recipient’s public key. Even if you remove `P1, P2, n` from the blockchain data, Mallory can still replace `B` with `B'` since it’s not actually anchored in the verification equation (it is added and then subtracted again as a part of `Cl`). > > The only solution is to have the sender sign `B` using another key that can’t be swapped out without invalidating the transaction. I don’t think it’s possible to change the composition of a transaction without knowing P1 and P2. If you change any element of which the сommitment consists, then the HASH1 parameter will change. In this case, the proof of range will need to be confirmed. The recipient will not be able to do this, because he does not know P1, P2, n ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [July 7, 2023, 7:00pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/42 "2023-07-07T19:00:14Z")
If I understand correctly, you want to sign `B` with the range proof and the removal of `P1, P2, n` is meant to keep the blinding factor secret until the transaction has been confirmed in the blockchain. I think that would achieve the goal of fixing this vulnerability. You could actually get rid of `P1, P2` completely and just send the blinding factor to the recipient directly. However, the drawbacks are: 1. It makes payjoins impossible. 2. Not trully non-interactive in the Bitcoin sense as it requires an additional communication round. ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 7, 2023, 8:05pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/43 "2023-07-07T20:05:39Z")
Yes. P1, P2, n, unlike the blinding factor, can be sent unencrypted or simply posted on the site. ---
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 7, 2023, 8:44pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/44 "2023-07-07T20:44:54Z")
[Edit: deleted by author] ignore me… I just saw my question was addressed several times above, already ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 26, 2023, 6:18am UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/45 "2023-07-26T06:18:31Z")
There is another way to prevent a transaction from being changed before being written to the blockchain: 1. We add a new type of kernel excess J to the composition of the commitment C. Not earlier than after a random number of blocks, the sender can reveal its value and thus remove it from the blockchain. 2. J signs B and Cl. 3. The condition must be met: J cannot exist in the blockchain without B Thus spent non-interactive transactions will slightly increase the blockchain. The increase will be due to the fact that kernel excess is created in one block and signed in another. ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [July 26, 2023, 8:18am UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/46 "2023-07-26T08:18:18Z")
> [@Andi](#): > > We add a new type of kernel excess J > [@Andi](#): > > J signs B and Cl. In practice, Alice would need to add 2 extra kernels: `J` that signs the output for Bob, and `J'` that signs her change output. If there was just one kernel, you’d have the same problem that was mentioned earlier (linking the two outputs together via the signature or revealing which output is Alice’s change). > [@Andi](#): > > after a random number of blocks, the sender can reveal its value and thus remove it from the blockchain. In Mimblewimble, old kernels can also be destroyed by the original transacting parties, but this doesn’t happen in practice because there is no incentive to do so. ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 26, 2023, 11:35am UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/47 "2023-07-26T11:35:26Z")
In fact, there are two cernel excesses. B and J. B is signed by Bob to protect ownership, and J is signed by Alice to protect the contents of the transaction from possible alteration by Bob. After a certain number of blocks, Bob will no longer be able to create a fork, so Alice reports the value of J and the cernel excess can be removed from the blockchain. Cernel excess B, like other standard cernel excesses, cannot be removed, as this will allow Alice to return her coins. Alice will be able to create such a version of the blockchain from which everything that happened after will be excluded. And this version will satisfy all conditions. ---
**Author:** ![tevador](https://avatars.discourse-cdn.com/v4/letter/t/e19adc/32.png) [@tevador](https://forum.grin.mw/u/tevador)\ **Post date:** [July 27, 2023, 9:29pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/48 "2023-07-27T21:29:02Z")
This protocol also seems to be vulnerable to the generalized birthday attack. Let’s assume that Mallory is able to construct two different payments TX1 and TX2 to Bob with keys `B1` and `B2` such that `B1 = -B2`. This will happen if `x(S1) + x(S2) = 0` where `S1` and `S2` are the corresponding shared secrets. Such shared secrets can be found using the Wagner’s algorithm if the number of outputs is sufficiently high. In this example, we are using just 2 outputs. Some time later, Bob will use these two outputs to pay Carol in transaction TX3. Mallory can collude with Carol and steal Bob’s change output from TX3. ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 28, 2023, 3:12pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/49 "2023-07-28T15:12:19Z")
Yes, it is theoretically possible. But there will be not two payments, but several thousand or tens of thousands, and this can be done if they are all sent to one address. And all of them must be sent to Bob, and Bob must send them all without exception to Carol. Also, Bob must not spend change from any of these trades. The probability of such a scenario is close to 0. You can also make protection in the wallet, as it can be determined that a large number of transactions are coming to one address. ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [July 28, 2023, 6:42pm UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/50 "2023-07-28T18:42:33Z")
Maybe I’m wrong and the payments will be much less. If you have information about this, I would be grateful. Also thank you for your analysis. ---
**Author:** ![Andi](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Andi](https://forum.grin.mw/u/Andi)\ **Post date:** [January 5, 2025, 9:21am UTC](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472/52 "2025-01-05T09:21:00Z")
Good day. I tried to change the approach to creating non-interactive transactions. I invite those who are interested to familiarize themselves with the preliminary scheme and express their comments. [Non-interactive transactions\_new - Google Docs](https://docs.google.com/document/d/12Bke1C950XSUKJ_7xfUss9nn6oso_USXfi9NlCtGCSo/edit?usp=sharing) [Previous page](https://forum.grin.mw/t/non-interactive-transactions-for-the-mw-blockchain/10472.md?page=2)