From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E2B4FC0171 for ; Mon, 10 Feb 2020 00:17:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id D7FCD20110 for ; Mon, 10 Feb 2020 00:17:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sr2ozi7DoKy for ; Mon, 10 Feb 2020 00:17:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87]) by silver.osuosl.org (Postfix) with ESMTPS id 5205D20104 for ; Mon, 10 Feb 2020 00:17:33 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1j0wlX-0002yl-SJ for bitcoin-dev@lists.linuxfoundation.org; Sun, 09 Feb 2020 19:17:31 -0500 Date: Sun, 9 Feb 2020 18:15:54 -0600 From: "David A. Harding" To: Bitcoin Protocol Discussion Message-ID: <20200210001554.dafhn5ppakcmsj4f@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4ah4jcfub2ot2nmx" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 00:17:35 -0000 --4ah4jcfub2ot2nmx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 09, 2020 at 02:47:29PM -0600, Anon via Bryan Bishop via bitcoin= -dev wrote: > 1) Is Taproot actually more private than bare MAST and Schnorr separately? Yes. > What are the actual anonymity set benefits compared to doing the separate= ly? When schnorr and taproot are done together, all of the following transaction types can be part of the same set: - single-sig spends (similar to current use of P2PKH and P2WPKH) - n-of-n spends with musig or equivalent (similar to current use of P2SH and P2WSH 2-of-2 multisig without special features as used by Blockstream Green and LN mutual closes) - k-of-n (for low values of n) using the most common k signers (similar to BitGo-style 2-of-3 where the keys involved are alice_hot, alice_cold, and bob_hot and almost all transactions are expected to be signed by {alice_hot, bob_hot}; that common case can be the key-path spend and the alternatives {alice_hot, alice_cold} and {alice_cold, bob_hot} can be script-path spends) - contract protocols that can sometimes result in all parties agreeing on an outcome (similar to LN mutual closes, cross-chain atomic swaps, and same-chain coinswaps) The four cases above represent an overwhelming percentage of the spends seen on the block chain today and throughout Bitcoin's entire history to date, so optimizing to include them in the anonymity set presents a huge benefit. > 2) Is Taproot actually cheaper than bare MAST and Schnorr separately?=20 Earlier in y'alls email, you claim that the difference between the two approaches for a particular example is 67 bytes. I haven't checked that calculation, but it seems you're talking entirely about bytes that could appear in the witness data and so would only represent 16.75 vbytes. Compare that to the size of the other elements which would need to be part of a typical input: - (36 vbytes) outpoint - (1) scriptSig compactSize uint - (4) nSequence=20 - (16.25) schnorr signature (includes size byte) That's 57.25 vbytes exclusive of your example data or 74.00 vbytes inclusive. That means the overhead you're concerned about adds only about 23% to the size of the input (or 30% on an exclusive basis). That's definitely worth considering optimizations for, but I'm personally ok with requiring users of advanced scripts (who can't manage to produce mutual closes) pay an extra 23% for their inputs in order to allow the creation of the large anonymity set described above for all the other cases. If, subsequent to deployment, large numbers of users do end up using taproot script-path spends and we want to make things more fair, we can even out the weighting, perhaps by simply increasing the weight of key-path spends by 16.75 vbytes (though that would, of course, proportionally lower the capacity of the block chain). As mentioned in a separate email by Matt Corallo, it seems worthwhile to optimize for the case where script-path spenders are encouraged to look for mutually-agreed contract resolutions in order to both minimize block chain use and increase the size of the anonymity set. > What evidence do we have that the assumption it will be more common to > use Taproot with a key will outweigh Script cases? The evidence that current users of single-sig, n-of-n, and k-of-n (for small n) with a default k-set, and mutual-agreed contract protocol outcomes vastly outweigh all other transaction inputs today and for all of Bitcoin's history to date. -Dave --4ah4jcfub2ot2nmx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl5AoLoACgkQ2dtBqWwi adMFzBAAj9l5U1T0pnRrA8/2LWQLmuETF4kaNEcM294nkIfk18MivBIxFjiAjPwn mRciyGTPYktSkU2/gbvaGTnGejkI2MH+LpIDlxw79xvKrrOw+ozYMFUzvTSRQRY8 O4jmXFSzUTKJbMLfQgfPSZk/ut+wQ2gUI9ZUiiFpPzqUCKlZ4+/HOYNnXimcBjXz I4uDGMcQp27GL9/5rOBc7zBMekg3TczQbrlZaVYbLCr0Gwa+RJaj05EasAFpej2c YPhfMORfslw7fBww+Xsllre3wOF1TpBllBJ9uenI2ZDB8xmEU+oITtwSVrMbVo9C yEIS4wTpvUAAHqhHckTpScU3eXCGSmM5Y4ktI6pNDBM6hBAI6xVsrutp0Tdxwacd vN5u+rsWVJJ891gOFR0l33z32XvEza4p7LF34b0CXSo4U7KBzzDOK0pxJYidyMob 7u5xTiV3ue8su3EQXV4S9YrfLBMiH/Xxt3t2wDPASloO5HhGOBscmB2tCX0h6i59 cfrGOsNjDBbg1pl9RkTex7VviVkG9n8J9renPPPUGkeK0LAfpJ1csvtSkx/1Sq1e YeLo1fNsEhwdWY4wexoOkAZ5czBodgY9UZjCqVLCogt5rlXNJqUz7xP/O09izAjm tufZvMEwmhRiYIglzI4yF4D5LzeIryyJxTQ2KJeqftsUtvckZNM= =FApq -----END PGP SIGNATURE----- --4ah4jcfub2ot2nmx--