Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 852AFC002B for ; Tue, 7 Feb 2023 18:35:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5303161030 for ; Tue, 7 Feb 2023 18:35:25 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5303161030 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=Kg7cGeyF X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 9XK1mUDPTAjK for ; Tue, 7 Feb 2023 18:35:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 06D0C60BB1 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by smtp3.osuosl.org (Postfix) with ESMTPS id 06D0C60BB1 for ; Tue, 7 Feb 2023 18:35:23 +0000 (UTC) Received: by mail-pf1-x431.google.com with SMTP id g9so11402423pfo.5 for ; Tue, 07 Feb 2023 10:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=BZQlj6cLdjkxc844P7Ackb/Wmtyk9IrJvfZUrNIQAd8=; b=Kg7cGeyFdLQEHWm6fAyhnVlRQMCGbBOia2P4HfT5CEAWwcWutArSPYLwWqHKp88sCG l/r9wy589ZSuYxU+Glsf1Vrgb3KTMrZqRMvo/eEi9B0/ZuY2qemhbhFqgSqMCJv+F8+V 8BJ3fpn+J2J1noCq469cZb4YAU8WMzRhbaYeWU3F28Dc70Z7m+eWvnHv6NY8yvC4TlOW GM9UQ9LgbStfLDyQglC9XqwbsY2psp+ZVgUcjiXaHmuENKx5IH4fQ+FkN9jXl56/GxYo kHhQ7WY4fwRkJHXUHCIVBL1eLSLRyGUlUfDKjTJWJO5VPH+dFuf1D4UvtS5/0rHWVW4a ujiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BZQlj6cLdjkxc844P7Ackb/Wmtyk9IrJvfZUrNIQAd8=; b=Fku/DZdDc2dnfvcgJSEEC7X3vnqD+G50ZnCPkpVtlzuo1pHL4tg8dTxuUWLzfpwCqE OCaOfbgf06+5vOM5K1aynmWdTmQKT7ojAsrU5awVc72UMsS+qjP4DIXAqrN2qfrESA1C NXBGmjfWTWjh63k314jVtMXgX83iPPhkyhDFpCm05ui9M1QC095u3HzbLyDLBi8c1pMt vbKFq7FqSBoWmLMprNdEZSShUHsG5bh2VrIy1b+5/uKaPTX5wfg9h+BNAnq3Zx0PipW+ DKh7vZHbxr/aqWuiVknTkmXi0IULuWTe1bn9hMmnmrFaVlvxMTHOIK/7WHuyZ1iNIyyP DLkw== X-Gm-Message-State: AO0yUKU8Rl3QxkwuHE4JaiGRzV7K2QzrkwKSXx5/t79tfvcSPihvBaiM Eg3svPs3Q6vB/NAwsiEdBnYpLoAoir8Y3lo5fTrAJjvc3L9REw== X-Google-Smtp-Source: AK7set8/1jjmBSdcrh3ov4oT5UfaLxDodHhy75vqg+5RrK93Fz0LB/m3TX2ThszRrD00TeVvjW8KuurrlJ4rSL49ny0= X-Received: by 2002:a63:a101:0:b0:4fb:1c1c:5f38 with SMTP id b1-20020a63a101000000b004fb1c1c5f38mr524514pgf.47.1675794923349; Tue, 07 Feb 2023 10:35:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Tue, 7 Feb 2023 13:35:12 -0500 Message-ID: To: Andrew Poelstra , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001f8a8405f4206984" 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 18:35:25 -0000 --0000000000001f8a8405f4206984 Content-Type: text/plain; charset="UTF-8" There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates. The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend. On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Some people highlighted some minor problems with my last email: > > On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev > wrote: > > > > > > > > [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! > > In Taproot the tapleaf hash is always covered by the signature (though > not in some ANYONECANPAY proposals) so you can never migrate signatures > between tapbranches. > > I had thought this was the case, but then I re-confused myself by > reading BIP 341 .... which has much of the sighash specified, but not > all of it! The tapleaf hash is added in BIP 342. > > > > > If you want to prevent signatures from moving around *within* a > > branch, > > > > And this sentence I just meant to delete :) > > > -- > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000001f8a8405f4206984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a bug in Taproot that allows the same Taplea= f to be repeated multiple times in the same Taproot, potentially at differe= nt Taplevels incurring different Tapfee rates.

The= countermeasure is that you should always know the entire Taptree when inte= racting with someone's Tapspend.

On Tue, = Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> wrote:

Some people highlighted some minor problems with my last email:

On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev w= rote:
>
> <snip>
>
> [1] https://bitcoin.sipa.be/miniscript/
> [2] In Taproot, if you want to prevent signatures migrating to another=
>=C2=A0 =C2=A0 =C2=A0branch or within a branch, you can use the CODESEPA= RATOR opcode
>=C2=A0 =C2=A0 =C2=A0which was redisegned in Taproot for exactly this pu= rpose... we
>=C2=A0 =C2=A0 =C2=A0really did about witness malleation in its design!<= br>
In Taproot the tapleaf hash is always covered by the signature (though
not in some ANYONECANPAY proposals) so you can never migrate signatures
between tapbranches.

I had thought this was the case, but then I re-confused myself by
reading BIP 341 .... which has much of the sighash specified, but not
all of it! The tapleaf hash is added in BIP 342.

>
>=C2=A0 =C2=A0 =C2=A0If you want to prevent signatures from moving aroun= d *within* a
>=C2=A0 =C2=A0 =C2=A0branch,
>

And this sentence I just meant to delete :)


--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:=C2=A0 =C2=A0https://www.wpsoftware.net/andrew

The sun is always shining in space
=C2=A0 =C2=A0 -Justin Lewis-Webster

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000001f8a8405f4206984--