Non-interactive transactions for the MW blockchain.

Non-interactive transactions for the MW blockchain.
Below is the concept of the proposed transactions. It is assumed that the reader is familiar with the principles of building transactions in the MW blockchain. This concept describes only the general principles of building a non-interactive transaction.

  1. The main advantages of the proposed transactions.
    1.1. Transactions do not degrade the privacy of the MW blockchain.
    1.2. After the input data is used up, most of the data can be removed from the blockchain.
    1.3. The recipient performs a quick search for transactions belonging to him. The number of transactions per wallet can be quite large, but is limited by the size of the array in memory. This implementation completely removes the association of the public address from any visible transaction data.
    1.4. The sender can enter a hidden identifier into the transaction so that the recipient knows exactly who made the payment.
    1.5. You can implement a payment cancellation feature provided that the recipient has not accepted the payment within a given number of blocks. This can be useful if the sender wants to insure that the payment is not sent to the wrong address.

  2. The main disadvantages of the proposed transactions compared to standard MW transactions.
    2.1. Non-interactive transactions are always explicitly linked to the kernel, so they cannot be masked by false inputs and outputs. Thus, to obfuscate the transaction graph, you need to use these transactions as an intermediate state, which in some scenarios will lead to a double commission (see point 4 for more details).
    2.2. The input size of unspent transactions has been increased compared to the standard MW input. Added coordinates of 3 elliptic curve points and 256-bit scalar. If you implement the payment cancellation function, then 1 more point of the elliptic curve is added.
    2.3. Increased the size of the core stored in the blockchain by at least a 256-bit scalar. If you implement the payment cancellation function, then the coordinates of 1 point and a scalar indicating the number of blocks before cancellation are added to the blockchain.

  3. Main idea.
    3.1. Basic designations:

  • C - Pedersen’s obligations;
  • G-point blinding factor generator;
  • H- point of the generator of the number of coins;
  • a1, a2, bi – scalar values, acquired in some way from the initial phrase of the purse;
    -A1i, A2i – recipient’s public keys - address;
    -Kc - output non-interactive transaction;
    -D - additional data;
    -S - shared secret;
    -P1i, P2i – recipient hints that use encrypted quick access to the shared secret;
  • n - hint, in which the payee, payment identifier (clause 1.4.) and part of the public key A1i are encrypted;
  • Bi - public key for withdrawal of funds by the recipient

3.2. Create an address.
The recipient generates the 2 public keys in a special way so that the shared secret can be determined independently of the public keys themselves.
A1i = bi*(1/a1)G
A2i = (bi+1)
Key moment:
a1, a2 are unique for each wallet.

3.3. Forming the output of a non-interactive transaction - Kc by the sender. The output of the transaction consists of 3 parts: Pedersen’s commitment -C, verification of the range of transferred funds BP(C) and additional data -D that the recipient needs to calculate the shared secret, as well as to determine the amount transferred and the hidden identifier (clause 1.4.)

3.3.1. To begin, the sender generates a shared secret
s is a random scalar number.
The shared secret is the public key S.
3.3.2. The sender generates hints for the recipient
3.3.3. The sender generates a hint - n, in which the transmitted amount, the payment identifier (clause 1.4.) and part of the public key A1i are encrypted.
n= HASH256(y(S))+v(0-64 bits)+id1
2^64(64-128 bits) + id2*2^128(128-192 bits)
y(S) – y coordinate of the shared secret S
v is the number of transferred coins;
id1 – payment identifier;
id2 - the first 64 bits of the x coordinate of the public key A1i.

3.3.4. The sender generates the public key of the recipient (also at this stage, a public key can be generated for the return of funds).
x(S) – x coordinate of the shared secret S
3.3.5. The sender computes a common hidden factor from the shared secret.
r= HASH256(x(S))
3.3.6. The sender forms a local Pedersen commitment

3.3.7. The sender commits all elements of the transaction (it is necessary so that when included in a block, it is impossible to change the constituent elements of the output). To do this, it calculates a hash from the sum of the hashes of each element of the transaction and adds to the total hidden factor.

HASH1= HASH256(HASH256(n)+ HASH256(P1i)+ HASH256(P2i)+ HASH256(Bi)+ HASH256(Cl))
3.3.8. The sender generates the final commitment of Pedersen and writes it into the transaction element by element, with the exception of HASH1G, which can be calculated.
The sender must attach a check of the range of transferred coins, for this we represent C in the following form:
С= (HASH1+r)G+vH
The check of the range of transferred coins performed using “Bulletproofs” will be denoted by BP(C).
3.3.9. The final output of the confidential transaction will look like this:
Kc=C;BP(C);D = HASH1G+Bi+Cl; BP(C); (n,P1i,P2i).
Remember that HASH1
G does not have to be written down, it can be calculated.

3.4. Fixing a non-interactive transaction in the blockchain.
Since the sender knows the common hidden factor, it is necessary to ensure the transfer of ownership to the recipient. To do this, the following data is recorded in the blockchain:
Bi- public key of the recipient (in the process of spending the output of a non-interactive transaction, it will be signed and will be taken into account as an offset on a par with other MW cores);
HASH1 – clause 3.3.7 (prevents the sender from changing the transaction in the future, otherwise the sender will be able to rebuild the transaction with the same core, but zero cost v);
When implementing the payment cancellation function, the sender’s public key and the number of blocks through which the payment can be returned must be included.

3.5. Identification of a non-interactive transaction by the receiver.
3.5.1. The recipient calculates the shared secret
3.5.2. Calculates
n- HASH256(y(S))=v(0-64 bits)+id12^64(64-128 bits)+ id22^128(128-192 bits)
if the received number is less than 192 bits, then the transaction belongs to the recipient.
Now the recipient knows the values v, id1, id2.
3.5.3. Knowing id2, the recipient can search the array and determine from which public keys the transaction was generated. The number of elements in the array is equal to the maximum number of possible transactions for one wallet.
3.5.4. The recipient calculates the private key for Bi.

3.6. Spending.
To spend the funds, the recipient signs Bi with Schnor’s signature and a fee is paid. At the same time, the unspent output, which has now become the input of a new transaction, changes the value of the blinding factor by the value of Bi.
The Pedersen Commitment for Transaction Entry will now have the following value:
C’= HASH1*G+Cl
There is no need to sign the modified commitment range, as the Schnor signing of the kernel ensures that there is no hidden amount of coins in Bi.

3.7. Removal from the blockchain.
After spending a transaction, the following data can be removed from the blockchain:
HASH1*G+Cl; BP(C); (n,P1i,P2i).

  1. The problem of obfuscating the transaction graph.
    To obfuscate the transaction graph in the MW blockchain, it is possible to add false inputs and outputs during the propagation of a transaction at the stage of the Dandelion stem. False inputs and outputs are indistinguishable from regular inputs and outputs of interactive MW transactions. The outputs of non-interactive transactions are different from the outputs of interactive MW transactions, so you won’t get lost in false outputs.
    In order to solve this problem, it is necessary to avoid constructing a transaction in which the input and output will be part of non-interactive transactions. The recipient must first send funds to the MW stdout among other false outputs, and then a non-interactive transaction can be created using the MW stdout mixed with the false inputs as input. Thus, a non-interactive transaction will be an intermediate state between standard inputs and outputs of MW.

Cool, but Pedersen Commitments can be broken, at this case we should switch to Switch Commitments.

This is a bold claim. Can you link a paper?

There is no paper. I proposed this concept in order not to compromise between the speed of identifying non-interactive transactions in the blockchain and the complete severing of links between the address of the transaction and the data that is recorded in the blockchain. This is posted for discussion.

I think your work can be published here to discuss it in scientific communities. Proof-Of-Concept will be useful too. Last step is PR into Pull requests · mimblewimble/grin · GitHub

1 Like

I think this is the place where such works can be published. If he is not needed here, then no one needs him.

I was responding to @ardocrat who said Pedersen Commitments can be broken. I would love to read more about that.

This is a fine place to discuss Grin Ideas. I didn’t mean to make you think otherwise.

I don’t have much to comment on your idea though. It reads very simklar to past NITX strategies, and at this point I’m confident it is not possible to non-interactively construct a single MW transaction without breaking any security guarantees.

It is possible to securely achieve 2-sided transfers, but it comes with some undesirable tradeoffs.

Hi @Andi, It’s great seeing someone new put a lot of thought into new schemes for MW. Seeing that you’re new to the forum, I’m not sure if you’re familiar with some noninteractive schemes that were presented in the past. I think the two most comprehensive noninteractive schemes were LIP-04 and MingleJingle. It might be good to compare your scheme to theirs, although to be fair, the community we have today seems to be slowly embracing the interactive nature of it - it’s not as bad as people first believe!

Here’s a link to one of the discussions on the topic An open discussion on Non-interactive transactions and a transaction type comparison table I made a few years ago. I think the forum post I linked above contains valuable conversation around the topic. A lot of noninteractive schemes introduce a lot more complexity to the protocol than we have today (as can be seen from LIP-04 images). I’m personally not convinced adding such complexity is a good thing because the simple construction of MW is one of it’s unique characteristics and so is its interactive nature once people learn to live with it.


By quantum computer. Vulnerability of blockchain technologies to quantum attacks - ScienceDirect
Grin is ready for this, soft fork is needed.

While its true that quantum computers could break such a thing, they currently cannot fit enough qbits on to one in order to break low bit RSA. Could be a really long time before we see tangible threat by quantum.

1 Like

Back in 2012, the quantum factorization record [1], using Shor’s algorithm for numbers not of a special form, was 21, factored as 3x7.

Now, over a decade of supposed quantum progress later, the record is … still 21. I don’t see them getting much further in the next decade.

[1] Integer factorization records - Wikipedia


What about the protocol used by Beam? I have never tried Beam, but I think it is non-interactive as well, isn’t it?

When pasting the text, some (*) were removed, which were the sign of multiplication. Unfortunately, I don’t have access to edit.

It’s better to look at this link Non-interactive transactions for the MW blockchain.pdf - Google Drive

This looks rather different from those, assuming I understood it correctly.

This proposal is more like the sender just giving the blinding factor and amount to the receiver, i.e. creating of 1-of-2 output. The difference is that it uses the chain itself as a communication medium from sender to receiver, making it way more complicated then just sharing the info on a private communication medium.

1 Like

Your estimates are correct

iirc you had a similar idea (1 of 2) but it made payment proofs impossible, is that right or was that something else?

Yes, the idea of payment through a temporary 1-of-2 has been proposed several times in different forms, including by myself. And none of them can support payment proofs, because you cannot prove which of the 2 parties spends a 1-of-2.


I do not fully understand why it is impossible to prove who spent? In the proposed version, the public key that must be signed to spend the input is explicitly specified. The sender can prove that this public key is derived from the address that the recipient gave it.