Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15

[John Tromp]

> 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