From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2C8EB7A for ; Fri, 20 Sep 2019 12:47:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93AB681A for ; Fri, 20 Sep 2019 12:47:49 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id k25so1592282oiw.13 for ; Fri, 20 Sep 2019 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=pzOK2uR1qqVOcScjUrrZxDfHfZ7SotE4dhuj8jZeRKE=; b=H4lD7Y1sGGralmt0oTWmtujFUTQyic4SOymwW6ekjb97t1ml5eksXf4x1yoxQTspE5 9ZZqLg1nNhjET9R4qyVSfH0zP3KNjBe+BI8tw8P4oRTnz2ZYvhkaDShHWo4iCZ0T4Ip3 fGZ0DJfjPJlq4cngnH0h/IGJ/jwskzdJPCr8PfDOr6qRoLSffOOdfI/kHuMzU5wh7ams RRuthUAjsGftENQIYDPahEOzKqohk3Qtx00/kxPHsg8VT+Mqj6xpvMTVNAxZyMkQW17s O0XF9bx9YX0wvV6EPJacpXTvY8Pu2z5Z3FXV0edTH207J7SoEtsJlhsJePqtT/taBQpt qVQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=pzOK2uR1qqVOcScjUrrZxDfHfZ7SotE4dhuj8jZeRKE=; b=Sh+lsAfO9XjXNh5U17f0riVR8a4eqc41ZfPBafFCZCoMhAgfzJDle0iEixr1C+LKHd cxukrMt2jyhT8uPZ01MusgGg+JO8iB1bgkxU8MjkdREljZpu17zg+miQ1u/g1agluGzl 5sNh+HUJg9TK93HWMwY4vvTnrCDPCK93olY4F3n4auRtLx2sbF4D/Mj2HxGQ2UIAHpq9 duW1CKlr2SR7IHbSkoJjdKdhPl9MuccmHr1UpE8rLAwIB3Eio6Zs0oWDvMZkbExwBv8K FVsDmVVZ/meE4g9VTbB+yxyHYSJjhoBLlxc6W2bMeFNv1yyoWDJG4qwx9blI9t0B3ygD TalA== X-Gm-Message-State: APjAAAWHuUrEWxk/7YDJYqiNVilGUtbooMm8osJVFNmTUuNYZeHWhCNB qB+QGYWvqlQLcbdTq0DhVdxcnAQCCDm6GcvnA9tlZYiORQ== X-Google-Smtp-Source: APXvYqyG6llk9b7zUbBelTs68K4w/g1UplcuZ8ZM9dj1BRK3yYl+sy+MuK+TJ5RLx1eXzGFQJ/QvDsb6fESa9fuJxXc= X-Received: by 2002:aca:b583:: with SMTP id e125mr2827141oif.2.1568983668644; Fri, 20 Sep 2019 05:47:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Tromp Date: Fri, 20 Sep 2019 14:47:37 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 21 Sep 2019 15:21:46 +0000 Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 52, Issue 15 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2019 12:47:50 -0000 > 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