Discussion zone for wiki doc: "Mimblewimble Non-Interactive Transaction"

[garyyu]

This is a discussion zone for wiki doc: https://github.com/gottstech/gotts/wiki/Mimblewimble-Non-Interactive-Transaction

(Revised at Oct. 10, 2020)

[tromp]

In your construction, is it the case that if Alice makes two payments to Bob, then she knows the difference in blinding factors of the resulting outputs of Bob?

[garyyu]

@tromp Thanks for comments. And Yes, she knows, but that is the normal form of Stealth Address, did you see any potential problem of that leaking for the difference in blinding factors?

Say, in first payment of Alice to Bob: P₁'=H(k₁)A)G+B

then in second payment of Alice to Bob: P₂'=H(k₂)A)G+B

So, for Alice, she knows the difference in the private keys of P₁' and P₂': p₁' - p₂' = H(k₁A) - H(k₂A)

Is this what you are thinking? I think the Monero has been using this Stealth Address scheme for years.

[tromp]

In regular MW, that would be a problem. When Bob spends one of them to an accomplice of Alice, she can steal the other output by reusing the kernel. I guess your additional spending signature prevents that?!

[garyyu]

The additional spending signature attached to Input need the p'₁ and p'₂ itself, so it indeed prevents that.

Now in this non-interactive transaction scheme, each signature has its dedicated purpose:

• Signature in transaction kernel is only used to prove that the excess has no H component, i.e. sth in form x*G+0*H.
• Signature in Input is used to prove the ownership of the spending output.

[garyyu]

@DavidBurkett posted a finding into https://t.me/gottstech/791 at Nov. 24, 2020

I'm reading through your proposal for non-interactive transactions, and I have some concerns about the security of it.

There appears to be a number of ways that the receiver can change or cut-through the output before it confirms in a block.

This malleability means we don't have non-repudiation. The receiver can claim to have never received the funds

I see you attempt to prevent cut-through by having the kernel sign the number of inputs, but it's trivial to attack that.

The attacker can just lie about the number of inputs in their transaction, and can set it to any number they want in order to make that equation balance. So I don't really understand how that is supposed to prevent anything

There are other issues with malleability also, but this one is by far the simpler attack, so I'd like to discuss it first when you have time.

And my checking:

If the dishonest receiver (i.e. "attacker" in your sensence) lies about the number of Inputs, the transaction he/she create must fail on validation. so, he can't send his lying transaction.

but, if this lying transaction of this dishonest receiver is not sent, and instead he send a merged transaction with the previously received transaction (and when which is still in mempool), and execute a cut-through, Oops! looks like indeed problem here :-(

For Gotts, that should not a problem at all, since it's not a privacy coin project, we use public value and a transparent transaction graph is ok here, we can use sth as a disaggregate-able "aggregation", to make the merged/aggregated/CoinJoined transaction is capable to dis-aggregate, then this lying transaction from dishonest receiver will be recovered and detected. It can not pass the validation.

But for privacy coins, the obscured transaction graph is an important feature there in Mimblewimble, the method in Gotts can not be directly used here.

[garyyu]

Today I got a time to describe a fix for above flaw and a solution to freeze cut-through for NIT, I will update the paper later.

A feasible solution is freezing all cut-through behaviour in the transaction pool, by adding a field n and a field h into the transaction kernel, and by a consensus with an unordered Outputs vector and unordered Kernel vector when merging. The field n is used to indicate how many Outputs a transaction has. The field h is a hash value which is used to lock the Outputs to forbid cut-through. In transaction validation, we use field n to draw the single-kernel-related Outputs from transaction Outputs vector (considering the case of multi-kernel transaction, especially the merged transaction case), and validate the field h by h=Hash( H(O1) || H(O2) || ... || H(On) ), where O_i is one Output in the kernel-related Outputs vector.

As drawing in figure.2, the merged transaction T12 will have ordered Inputs vector [I1, I2] for example, and multi-kernel [K1, K2] , and unordered Outputs vector [O1,C1,C2,O2] which can easily split into {[O1,C1], [C1,O2]}, sinc­­­e the vector size before merging is known as n for each kernel.

The cut-through between the blocks is still feasible, which is great to reduce weight for non-archive nodes. Normally the cut-through between blocks is launched for the old blocks beyond the Horizon, we will discuss more about that in §3.1.

(...)

Another cost in this solution is the new field n and the unordering in both kernel vector and output vector which increases the linkability risk. For example, still with above example T12, the {K1, [O1,C1]} is always link-able in public block, also for the {K2, [C2,O2]}. But it’s obvious that the Input/Output relationship is still unlink-able here, because Inputs vector is ordered (by hash) and there’s no Inputs vector size indicator.

The last one is about the payload size increment. Looking into that for Outputs vector size encoding, since we can use the variable size transaction kernel, we can define a missing field n means n=2, so as to cover over most of use cases with zero size increment. For other cases with n!=2, one octet should be enough to encode this .

[garyyu]

Above fix solution is not perfect yet. I did a major updating on this NIT scheme a few days ago and published in https://eprint.iacr.org/2020/1064.pdf , please use the latest version for the reviewing and comments. 🌻