From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9A0A6C002B for ; Tue, 7 Feb 2023 13:46:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 6165B60B8B for ; Tue, 7 Feb 2023 13:46:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6165B60B8B Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=mail.wpsoftware.net header.i=@mail.wpsoftware.net header.a=rsa-sha256 header.s=default header.b=kbJB+flj X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHpRNVq0e1wS for ; Tue, 7 Feb 2023 13:46:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A95CF60E22 Received: from mail.wpsoftware.net (unknown [66.183.0.205]) by smtp3.osuosl.org (Postfix) with ESMTP id A95CF60E22 for ; Tue, 7 Feb 2023 13:46:24 +0000 (UTC) Received: from camus (camus-andrew.lan [192.168.0.190]) by mail.wpsoftware.net (Postfix) with ESMTPSA id 027F2400D3; Tue, 7 Feb 2023 13:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.wpsoftware.net; s=default; t=1675777584; bh=4H4Ngx8kGxIKgN61ZkXtuAwthDCzfTcatGLUX3FCY/I=; h=Date:From:To:Subject:References:In-Reply-To; b=kbJB+fljAZiKPNnRd7HkcbOQ/tc1/oGTpwWjYUjP4w8CgOfuqpkVpamLMT6tshnBK UPSKITxZisWC8sPTSM+hADwLCyoL8ZmAiDx58cfP1mozfeh/U/qEYTZkdyaKQQ1im5 zAInSKRTEV3BFE7M27DittHksJdnqzTMythoN7Ga3XmIWtQIN6I73a28DVKzABRaLY tKLULHSRPfnwFBZ4M+vIm5Tq0HwuNs/PxH4prE55nqaGMvnw3Sa87TSYciLtfqYmDh 7GOsUxBDW7vH6xAwhhdmXF3WUtAvFJnseAmKWzus4cfCz45Vk+MXpPW+rV3Yk6WSh4 08u7bPZ9cVs6w== Date: Tue, 7 Feb 2023 13:46:22 +0000 From: Andrew Poelstra To: Yuval Kogman , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bAgrOVScsKO5Sq5R" Content-Disposition: inline In-Reply-To: Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs 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: Tue, 07 Feb 2023 13:46:26 -0000 --bAgrOVScsKO5Sq5R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrot= e: >=20 > Since Taproot (more generally any kind of MAST) spends have variable size= which > depends on the path being used, the last such input to be signed in a mul= tiparty > transaction can always use a larger than estimated signature to unfairly = extract > a fee contribution from the other parties to the transaction (keeping the > absolute fees the same and reducing the feerate for the transaction). > Using Miniscript [1] it is possible for all participants to determine the maximum witness size of the tree, which can bound the size of this attack. In fact, they can bound the size *given that their own signature is used*, or subject to other whatever other conditions they would like, and only sign under those conditions. Furthermore, under Taproot individual signatures have a maximum size of 65 bytes; an "attacker" can reduce this to 64 by not including a sighash flag, but he has one byte of play. (Pre-Taproot signatures could take up to 73 bytes with significant room to reduce this by using crypto tricks and/or grinding). Peter Todd also suggests in this thread that the use of uncompressed keys can cause "surprise" witness inflation, but (a) since segwit uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in Taproot), and (b) we expect users of Miniscript to always know all the keys used in a script that they're signing. Except perhaps in obscure cases where, say, the "victim" is a somewhat passive countersigner of a transaction, e.g. BitGo, ... in which case they're not the one putting up fees or with an interest in the transaction going through. With Miniscript, the problem is narrower: * There is some more-expensive branch that could be taken without Alice's signature. In which case Alice is only signing at all to optimistically reduce the witness size... but she cannot assume that she is going to be successful! Notably, in this case Alice does not really have any interest in the coins, in the sense that they can move entirely without her consent, so it's hard to imagine that she has an interest in the transaction's speedy confirmation. * There is some more-expensive branch that could be taken by moving Alice's signature. This is the case that you identify in the thread. While the attack remains in both cases, fortunately Miniscript gives Alice the tools to (a) determine which, if any, case applies to the script under question, and (b) determine what the maximum witness size might be, and just sign assuming that, treating any savings as "bonus". [1] https://bitcoin.sipa.be/miniscript/ [2] In Taproot, if you want to prevent signatures migrating to another branch or within a branch, you can use the CODESEPARATOR opcode which was redisegned in Taproot for exactly this purpose... we really did about witness malleation in its design! If you want to prevent signatures from moving around *within* a branch, --=20 Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster --bAgrOVScsKO5Sq5R Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmPiVi0ACgkQxYjWPOQb l8H24gf+Ml1E9iSksNjlM1kzIZmSh6eB8kq2JHLz/hrzlrqAPRAHnqLNNepkJGkE CRj8nf5qC1fkymozOulE3safWKE+8dgA6DmWtV4Jv4fB5h+UEmGyqZDmV8tDtSng aJMvxZ+5VizTZoBUk9+wW24p1Mfb3UtFCD5LQUrohFXMd2m4/Vx5WS0iT5zFgI6e bH99gDKvsaK3DlSj0uqSEP/rZ1gbiOFv6hZvDchk6b1yn6E0aaNHhAITVrkxSfA0 fsVxvqSeEhdGa7OW7+cH8Z23VGfpNKRtEdtPOTbwb/DRNMUdN+jFgosj12sijil7 8NDlf2XZi1s4xJyVGRxugvS78TJAgQ== =+Q0Y -----END PGP SIGNATURE----- --bAgrOVScsKO5Sq5R--