4 ms·
Talking about per-transaction data in mimblewimble is tricky because as different points in a transactions lifecycle it can change in size. 1. Each transaction
by EthanHeilman 8y ago
Talking about per-transaction data in mimblewimble is tricky because as different points in a transactions lifecycle it can change in size.
1. Each transaction comes with a value called a kernel, this kernel is constant size in the size of the transaction. It does not change with the number of inputs and outputs of a transaction.
2. Mimblewimble lets parties non-interactively merge transactions. So if you have 100 transactions you can merge them together and have only 1 really big transaction and 1 kernel.
3. In mimblewimble you only need to keep kernels and unspent outputs to prove to someone just joining the network that all the rules have been followed (fixed coin supply, all transactions where correctly authorized). Over time you can throw away most of that big merged transaction, as it's outputs get spend and just keep the kernel.
In theory each block should be one big transaction. Thus the size of blockchain grows with the number of unspent outputs and the number of blocks, but not the size of those blocks. This also makes validating the blockchain much faster and under certain circumstances may have privacy benefits.
Mimblewimble it is an important step on the path to scalable blockchains.
- DennisP 8y agoAha, so even though there are 100 bytes per transaction, you can merge all the transactions in the block so it's actually just 100 bytes per block (plus unspent outputs). Nice.
- deleted 8y ago[deleted]
- tromp 8y ago> 2. Mimblewimble lets parties non-interactively merge transactions. So if you have 100 transactions you can merge them together and have only 1 really big transaction and 1 kernel. Non-interactively merging transactions doesn't combine the kernels into 1. So a block ends up with all the kernels of all the original transactions.
- EthanHeilman 8y agoHi 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.