> However, my understanding is that, at least with the original > mimblewimble.txt from Jedusor, the signatures and the > Pedersen-commitment-to-0 could all be aggregated into a single signature and > Pedersen-commitment-to-0, if we were to use Schnorr-like signatures.
Non-interactive aggregatability depends on the signature scheme. Schnorr doesn't support it, whereas something like BLS signatures does. The original paper excludes the use of the latter with the remark "And also imagine that we must not pairing-based cryptography or new hypotheses, just regular discrete logarithms signatures like Bitcoin." > Indeed, the original mimblewimble.txt mentions having to store every `k*G` > and every signature attesting to it, although does not mention Schnorr and > might not have considered the possibility of signature aggregation when using > Schnorr-like signatures. Schnorr signatures can only be aggregated interactively though, and is thus limited to individual transactions which are built interactively. > In addition, the mimblewimble.pdf from andytoshi includes a "Sinking > Signatures" section, which to my understanding, combines absolute-locktime > kernels with partial O(log n) aggregation of the signatures that attest it. I must admit to never having quite understood Sinking Signatures, but they were deemed to have too many drawbacks for practical use. > It seems to me that neither technique is possible with relative locktime > kernels. Kernels already sign for optional additional attributes such as fee and lock height. A relative kernel would just add a reference to another kernel as an additional attribute. Which doesn't seem to affect its aggregatability. -John _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
