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.
-
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. -
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. -
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) * (1/a2) * G
Key moment:
a2 * A2i - a1 * A1i=G
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=s * G
s is a random scalar number.
The shared secret is the public key S.
3.3.2. The sender generates hints for the recipient
P1i=s * A1i
P2i=s * A2i
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).
Bi=x(S) * A1i
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
Сl=r * G - Bi + v * H
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 HASH1*G, which can be calculated.
C= HASH1 * G + Bi + Cl
The sender must attach a check of the range of transferred coins, for this we represent C in the following form:
С= (HASH1+r) * G+v * H
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 = HASH1 * G + 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
S=a2 * P2i - a1 * P1i
3.5.2. Calculates
n - HASH256(y(S))=v(0-64 bits) + id1 *2^64 (64-128 bits) + id2 * 2^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.
x(S) * bi * (1/a1)
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).
- 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.