From: John Tromp <john.tromp@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15
Date: Fri, 20 Sep 2019 14:47:37 +0200 [thread overview]
Message-ID: <CAOU__fzUET=R0jB6f1fhxL5a_xQ0N24oPDUJGBHr-sYiorMiHA@mail.gmail.com> (raw)
In-Reply-To: <mailman.36.1568980810.20526.bitcoin-dev@lists.linuxfoundation.org>
> 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
parent reply other threads:[~2019-09-20 12:47 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <mailman.36.1568980810.20526.bitcoin-dev@lists.linuxfoundation.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOU__fzUET=R0jB6f1fhxL5a_xQ0N24oPDUJGBHr-sYiorMiHA@mail.gmail.com' \
--to=john.tromp@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox