# Is blockwise kernel aggregation possible? **URL:** \ **Category:** Development and Technical Discussion\ **Created:** [August 1, 2019, 7:55am UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739 "2019-08-01T07:55:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Flitwick](https://avatars.discourse-cdn.com/v4/letter/f/71e660/32.png) [@Flitwick](https://forum.grin.mw/u/Flitwick)\ **Post date:** [August 1, 2019, 7:55am UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/1 "2019-08-01T07:55:02Z")
From the forum, I have found multiple questions regarding the aggregation of transactions and their kernels. However, I have had a hard time convincing myself that it is not possible, as the answers from other Posts (_[Eliminating transaction kernels](https://forum.grin.mw/t/eliminating-transaction-kernels/1542)_, _[Some queries about Transaction Aggregation](https://forum.grin.mw/t/some-queries-about-transaction-aggregation/1753)_, etc.) seldom provides a deeper explanation to why this is the case. From my understanding, the kernels cannot be aggregated because we have to interact to aggregate the signatures. E.g., hence the signatures, are all signing different data (the transactions) we cannot merely sum over them to compute a multi-signature. **Thought experiment** : Say that we do not sign the transaction itself, but instead the date, e.g., 1 of august for today. We still prove that we know the hidden transaction values as we can construct the signature. However, we could aggregate the Schnorr signatures of every transaction into a single “block”-signature. This aggregation will give some issues as we can only construct blocks of transactions that have the same date signed, but as far as I see, it could heavily limit the storage requirements. Is this a correct way to understand the scheme? If not, please feel free to correct any misunderstandings. ---
**Author:** ![antioch](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/antioch/32/45_2.png) [@antioch](https://forum.grin.mw/u/antioch)\ **Post date:** [August 1, 2019, 9:41am UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/2 "2019-08-01T09:41:05Z")
The aggregation is not dependent on _what_ is being signed but the keys used during the signing. All parties involved in the multiple transactions would need to agree up front to aggregate their transaction signatures together. We don’t actually sign the transaction itself - the only thing signed is the transaction features (coinbase or not), the fee and the lock height. You are proposing a single multi-party signature across all transactions in the block. While technically possible it would not feasible in practice - everyone involved in every transaction would need to communicate interactively. ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [August 1, 2019, 10:39am UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/3 "2019-08-01T10:39:04Z")
> [@antioch](#): > > the only thing signed is the transaction features (coinbase or not), the fee and the lock height. More precisely, the message is different for the 3 types of kernel we have: > Even if you could get signers to interact, they could only jointly sign for a single message. Most blocks use multiple messages, e.g. coinbase and non-coinbase kernels, different fees, different lock heights… ---
**Author:** ![Flitwick](https://avatars.discourse-cdn.com/v4/letter/f/71e660/32.png) [@Flitwick](https://forum.grin.mw/u/Flitwick)\ **Post date:** [August 1, 2019, 12:34pm UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/4 "2019-08-01T12:34:44Z")
Ok, I misunderstood the definition of aggregation, I believed it was similar to a multiparty signature, my bad. I believed that we could generate the transactions, as usual, but other signature-message, and then let the miner sum the signatures, and verify using the summed public key. Then the block should be this multi-signature and summed excess instead of separate kernels, but elseway similar. I found that [TariLabs](https://tlu.tarilabs.com/cryptography/digital_signatures/introduction_schnorr_signatures.html#key-cancellation-attack) go a bit into detail and that a _key cancellation attack_ could hit this naive scheme. However, I do not fully understand what this attack would mean in this scenario. Would it give him the ability to create and sign a transaction (where he knows the amount) in such a manner that he does not need to know the ‘private-key’? # Edit Utilising this naive scheme introduces a straightforward attack that can steal funds by using the _key cancellation attack_ without the attacker needing to know any private keys. _Example_: Say that _Alice_ transfer 5 coins to _Bob_. She does **not** know the _private-key_ under which they are stored; however, she knows the amount. Say that _Alice_ mines a block before _Bob_ have spent the funds. She can then generate two **fake** transactions; One using the funds she sent to _Bob_ as an input, and an output with the same amount (5 coins) but a _private-key_ picked by _Alice_ herself. And another transaction by _Alice_, where she adds an additional output with 0 coins, but a _private-key_ that ‘offsets’ the excess. Looking at the transactions individually, they will **fail** but summed they can create a valid signature that they will satisfy. Thank you for your time and answers. It was a great help for me 👍 ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 8, 2023, 7:14am UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/5 "2023-07-08T07:14:43Z")
> [@Flitwick](#): > > Say that _Alice_ transfer 5 coins to _Bob_. She does **not** know the _private-key_ under which they are stored; The correct term is _blinding factor_. > [@Flitwick](#): > > One using the funds she sent to _Bob_ as an input, and an output with the same amount (5 coins) but a _private-key_ picked by _Alice_ herself. > And another transaction by _Alice_, where she adds an additional output with 0 coins, but a _private-key_ that ‘offsets’ the excess. Alice cannot produce a rangeproof for an output for which she doesn’t know the blinding factor. So there is no such key cancellation attack. ---
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 8, 2023, 12:34pm UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/6 "2023-07-08T12:34:14Z")
> [@tromp](#): > > Alice cannot produce a rangeproof for an output for which she doesn’t know the blinding factor. In the proposed attack, the output which Alice cannot produce a rangeproof for is just an intermediate output that gets removed by cut-through. So a 3rd party looking only at the set of outputs _after cut-through_ wont see the output that Alice didn’t have a key for and there will not be an invalid rangeproof in the set Alice provides to you. What about the inverse: if a key cancellation attack is not possible, then why can’t we do blockwise kernel aggregation? ---
**Author:** ![tromp](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/tromp/32/22_2.png) [@tromp](https://forum.grin.mw/u/tromp)\ **Post date:** [July 8, 2023, 12:49pm UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/7 "2023-07-08T12:49:06Z")
> [@AceKaplin](#): > > In the proposed attack, the output which Alice cannot produce a rangeproof for is just an intermediate output that gets removed by cut-through. That’s not what you described. Please describe in detail the final transaction after cut-through in which all blinding factors must be known by Alice (in order to provide rangeproofs). > [@AceKaplin](#): > > why can’t we do blockwise kernel aggregation? Because Schnorr signatures cannot be non-interactively aggregated. ---
**Author:** ![AceKaplin](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/acekaplin/32/4958_2.png) [@AceKaplin](https://forum.grin.mw/u/AceKaplin)\ **Post date:** [July 8, 2023, 1:02pm UTC](https://forum.grin.mw/t/is-blockwise-kernel-aggregation-possible/5739/8 "2023-07-08T13:02:20Z")
Ah, I see where I misstepped. You’re right. Thank you.