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, Some queries about Transaction Aggregation, 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.
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.
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âŚ
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 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
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?
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).
Because Schnorr signatures cannot be non-interactively aggregated.
