Just wondering what the Grin thoughts were on eliminating transaction kernels (e.g. https://github.com/BeamMW/beam/wiki/Thoughts:-eliminating-transaction-kernels)
It occurred to me that despite the ability to do cut-through, there is still the situation that Grin transactions will each cause a permanent addition of 104 bytes to the blockchain. That’s better than e.g. Monero where a pruned transaction will typically add 304 bytes permanently to the blockchain. But it’s not an order of magnitude improvement, and Grin loses all sorts of useful functionality in order to achieve that efficiency (like not being able to do non-interactive transactions, and so not being able to send funds to an offline/cold storage wallet)
We may consider methods of kernel compaction at a later date. They will require extensive research on the security implications and other possible downsides. Committing to such a scheme at launch seems premature to me. At least we’ll be able to benefit from the experience gathered by BEAM.
not being able to send funds to an offline/cold storage wallet
Doesn’t the standard nonintactive idea of 1 of 2 mulisig plus deleting data work?
From the https://lists.launchpad.net/mimblewimble/msg00087.html and https://github.com/mimblewimble/grin/blob/master/doc/wallet/transaction/basic-transaction-wf.png,we know every transaction has a kernel(include the excess of all the inputs and outputs, a signature, message).So we can only eliminate inputs and outputs but not transaction’s kernel.
Assume we maintain the blind factor rSG, random nonce kSG, e=H(kSG+rSG | M) and Schnorr signature sS=kS+e*rS as the kernel of each input, as well as these values of each output. When an output is used as an input of the other transaction , we can aggregate that input/output and their kernels. Is that right?
The kernels themselves cannot be aggregated non-interactively. i.e. It would require the participation of all the parties involved in the associated transactions (not just the specific inputs/outputs) as all parties are involved in generating the kernel signatures.
It does not really solve the problem since the computer generating the 1/2 is online and even after deleting the keys somebody might have been able to copy them.
I think we can use slates that are verified on the offline machine. Then the response could get out from the offline machine via qr-code.
Unless you already have an airgaped machine, from there you could create a 1/2 multi to a paper wallet and delete the keys. But that will be as secure as the airgaped machine.