Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5283D10EB for ; Wed, 21 Mar 2018 12:45:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.wpsoftware.net (wpsoftware.net [96.53.77.134]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C862C5FE for ; Wed, 21 Mar 2018 12:45:22 +0000 (UTC) Received: from boulet.lan (boulot.lan [192.168.0.193]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 70321400F0; Wed, 21 Mar 2018 12:45:21 +0000 (UTC) Date: Wed, 21 Mar 2018 12:45:21 +0000 From: Andrew Poelstra To: Anthony Towns , Bitcoin Protocol Discussion Message-ID: <20180321124521.GI9082@boulet.lan> References: <20180321040618.GA4494@erisian.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b3DtnEVdyItk0m9y" Content-Disposition: inline In-Reply-To: <20180321040618.GA4494@erisian.com.au> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation 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: Wed, 21 Mar 2018 12:45:23 -0000 --b3DtnEVdyItk0m9y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2018 at 02:06:18PM +1000, Anthony Towns via bitcoin-dev wro= te: >=20 > That leads me to think that interactive signature aggregation is going to > take a lot of time and work, and it would make sense to do a v1-upgrade > that's "just" Schnorr (and taproot and MAST and re-enabling opcodes and > ...) in the meantime. YMMV. > Unfortunately I agree. Another complication with aggregate signatures is that they complicate blind signature protocols such as [1]. In particular they break the assumption "one signature can spend at most one UTXO" meaning that a blind signer cannot tell how many coins they're authorizing with a given signature, even if they've ensured that the key they're using only controls UTXOs of a fixed value. This seems solvable with creative use of ZKPs, but the fact that it's even a problem caught me off guard, and makes me think that signature aggregation is much harder to think about than e.g. Taproot which does not change signature semantics at all. Andrew [1] https://github.com/jonasnick/scriptless-scripts/blob/blind-swaps/md/par= tially-blind-swap.md --=20 Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom --b3DtnEVdyItk0m9y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaslPgAAoJEMWI1jzkG5fB+UsH/A9RhQPcmKNuqvlc6r/B0fZz Rx7HEL9ze04OvlchH1nQ1dGqsQXFvGQUWMEoDvQEb/JLa6IcLm0Q//fsQtyff21G XLA6GFbsG/KB5E5sBCjczoPhspL8oEGP9d5qQb+DJiGhH/PaxURiRsw7Em5/lt5M OMT5Lly01NfwTP57qxPQ4ZBlsoikxPH1nFPYLVjx/33V1YEkf7I6UsUN4Q2JVgxB rMyIe+0D+8GVg7a+RI5DbjxEAcnoU8/hPvUmy5QofqKUfj1SuhWg/f1MtajesY6f e/BA321M1rwBGTW8bOPhdyxarYiuqbsHGWfL94AigIHwlOfmcE4d2Qzr4y8lW0g= =IHiH -----END PGP SIGNATURE----- --b3DtnEVdyItk0m9y--