MIME-Version: 1.0
References: <mailman.36.1568980810.20526.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.36.1568980810.20526.bitcoin-dev@lists.linuxfoundation.org>
From: John Tromp <john.tromp@gmail.com>
Date: Fri, 20 Sep 2019 14:47:37 +0200
Message-ID: <CAOU__fzUET=R0jB6f1fhxL5a_xQ0N24oPDUJGBHr-sYiorMiHA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15
Precedence: list

> However, my understanding is that, at least with the original mimblewimbl=
e.txt from Jedusor, the signatures and the Pedersen-commitment-to-0 could a=
ll be aggregated into a single signature and Pedersen-commitment-to-0, if w=
e 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 an=
d might not have considered the possibility of signature aggregation when u=
sing 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 Sign=
atures" section, which to my understanding, combines absolute-locktime kern=
els 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