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.
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’?
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