Fund Proof in Mimblewimble

[suem]

In Bitcoin, it’s quite an intuition to prove how many coins an owner has, since the value is transparent there in an UTXO (Unspent Transaction Output). The validator only need verify it’s a true UTXO on the chain and buried with enough block confirmations. Also in ETH, and more easier because of the user account system.

In Mimblewimble privacy coin system, sometimes a fund proof is also needed. For example, a custodian system must have the proof of assets (a typical example as https://wbtc.network/dashboard/audit), a contract could require the parties prove the fund existence before going to formal stage, etc.

Instead of disclosing the coin/s amount directly, it will be much better (or mandatory) to keep the built-in privacy feature in a privacy coin system. Obviously opening the Pedersen Commitment x*G+a*H by disclosed a value and x*G with an attached signature by private blinding factore x is NOT an acceptable solution here.

A possible method could be a new designed range proof to prove a>v, where v is a disclosed value, instead of the existing cryptographic primitive of a range proof for a>0.

Another method is using current Mimblewimble implementation to provide a quick proof of a>v. The idea is to create a fake transaction, which can be validated on the chain but can NOT be packed in any block.

A typical native interactive transaction in Mimblewimble looks like:

(x_i*G +a_i*H) + (E’ + s*G) = (x_c*G +a_c*H) + (x_r*G +a_r*H) + f*H
where,

• (x_i*G +a_i*H) is the Input coin.
• (x_c*G +a_c*H) is the change Output coin.
• (x_r*G +a_r*H) is the payment Output coin.
• x_i, x_c, x_r are blinding factors.
• a_i, a_c, a_r are transaction values.
• E’ is the public excess, for kernel signature. ‘s’ is the transaction offset.
• f is the transaction fee.

To create a fund proof of a_i > v, where v is a disclosed value, we just need let a_r = v and f = 0, then sending this fake transaction to the receiver/validator with an attached signature of x_r*G.

This fake transaction can pass validation on the chain if without fee checking, and it can not be packed by any miner because of fee checking consensus. Or even quite safe to be mined (impossible of course) since the owner will not have any lose.

The attached signature of x_r*G is used to prove the “coin” (x_r*G +a_r*H) has the said disclosed amount v.

That’s all
Welcome your comments.

[Konstantin]

If fee value will be 0, I think this transaction can be published if it will be combined with another transaction that pays the fees.
Sure, there is no reason for anybody do that because attacker will need to pay extra fee and there will be no gain for attacker because this transaction is self transaction.
I think we should eliminate fee part of the formula at all, so this transaction can’t be the part of CoinJoin, right?

Also there is still privacy leak as for any proof. Because proof suppose to be sent to public, observer can make a conclusion that inputs from this transaction are likely the part of swap trade and swap amount in MWC is known.

[suem]

@Konstantin

If fee value will be 0, I think this transaction can be published if it will be combined with another transaction that pays the fees.

No, it can not. The CoinJoin can not cancel a transaction kernel, so the kernel with the fee value 0 will be still there and it’s not allowed to be mined in the consensus.