4 ms·
Hi John, thanks for pointing this out. I would edit my comment to reflect the fact that Grin does not allow non-interactive kernel merging but has edit locked t
by EthanHeilman 8y ago
Hi John, thanks for pointing this out. I would edit my comment to reflect the fact that Grin does not allow non-interactive kernel merging but has edit locked that comment.
>Non-interactively merging transactions doesn't combine the kernels into 1.
In theory Mimblewimble should support non-interactive kernel merging unless intentionally disabled. There are a bunch of reasons not to allow non-interactive kernel merging such as kernel locktimes, griefers adding spam transactions to your transaction, etc...
Even if non-interactive kernel merging is disabled you can still interactively merge kernels using say CoinShuffle++ and you should to save on the number of kernels.
- tromp 8y ago> Mimblewimble should support non-interactive kernel merging unless intentionally disabled. It's not intentionally disabled. We'd love for Dandelion nodes and miners to be able to merge kernels. But unfortunately that's not possible with the Schnorr signatures and secp256k1 curve we're using.
- DennisP 8y agoThe page mentions future optimization, what do you think is achievable?
- tromp 8y agoLots is possible with fancier crypto. BLS signatures allow non-interactive aggregation, making storage size truly independent of historical transactions, but require faith in less well researched pairing-based crypto. RSA accumulators are discussed in another comment. Right now, Grin's design is conservative, relying on the same security assumptions as Bitcoin. The one crucial difference is that money supply is fully verifiable in Bitcoin, while Grin allows undetected inflation if the ECDLP (Elliptic Curve Discrete Log Problem) gets broken.