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
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:
- It makes payjoins impossible.
- Not trully non-interactive in the Bitcoin sense as it requires an additional communication round.
Yes. P1, P2, n, unlike the blinding factor, can be sent unencrypted or simply posted on the site.
[Edit: deleted by author]
ignore me… I just saw my question was addressed several times above, already
There is another way to prevent a transaction from being changed before being written to the blockchain:
- 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.
- J signs B and Cl.
- 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.
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).
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.
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.
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.
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.
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.