> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
> However, I do think the adversary model should be broadened, as there
> is a potential positive
On Sat, Feb 11, 2023 at 09:40:38AM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Yes. If you would otherwise sign the tapleaf, then I would recommend also
> signing the entire tapbranch.
Opened https://github.com/bitcoin-inquisition/bitcoin/issues/19 for
this.
(I think it's better to call
Yes. If you would otherwise sign the tapleaf, then I would recommend also
signing the entire tapbranch.
On Sat, Feb 11, 2023 at 12:15 AM Anthony Towns wrote:
> On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >The fix
On 9 February 2023 12:04:16 am AEST, Russell O'Connor via bitcoin-dev
wrote:
>The fix for the bug is to sign the entire tapbranch instead of the tapleaf.
>
>On Wed., Feb. 8, 2023, 04:35 Michael Folkson,
>wrote:
>
>> Hi Andrew
>>
>> > There is a bug in Taproot that allows the same Tapleaf to be
On Wed, 8 Feb 2023 at 02:56, Antoine Riard wrote:
> From what I understand, there are many inputs for the coinjoin transaction,
> the latest signer provides an inflated witness downgrading the multi-party
> transaction feerate.
Yep!
> It doesn't sound to me a fee siphoning as occurring with
The fix for the bug is to sign the entire tapbranch instead of the tapleaf.
On Wed., Feb. 8, 2023, 04:35 Michael Folkson,
wrote:
> Hi Andrew
>
> > There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
>
On Wed, Feb 08, 2023 at 09:34:57AM +, Michael Folkson wrote:
> Hi Andrew
>
> > 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
Hi Andrew
> 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
Hi Yuval,
> Since the absolute fee amount is already committed to by the provided
> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
Mallory can
> broadcast any valid signatures up to the maximum standard weight and
minimum
> relay fees, or in collusion with a miner, up to
On Tue, Feb 07, 2023 at 01:35:12PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> 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
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,
On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev wrote:
> 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
>
Some people highlighted some minor problems with my last email:
On Tue, Feb 07, 2023 at 01:46:22PM +, 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
On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrote:
>
> 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
> multiparty
> transaction can always use a larger than
On Tue, Feb 07, 2023 at 11:36:58AM +0200, Nadav Ivgi via bitcoin-dev wrote:
> > Since Taproot (more generally any kind of MAST) spends have variable size
>
> Isn't this the case with any arbitrary script execution? Non-taproot
This is even been true for P2PKH inputs: you can double the space of
> Since Taproot (more generally any kind of MAST) spends have variable size
Isn't this the case with any arbitrary script execution? Non-taproot
P2(W)SH can also have multiple (OP_IF-gated) script branches. For example
with ` CHECKSIG IF SHA256 EQUALVERIFY ENDIF`, Mallory can
initially
Hi Yuval,
This is an interesting attack. Usually I think of spending with a big
weight witness in the context of slowing down a confirmation of a
transaction, especially a DLC creation tx. There you can delay its
confirmation past some time (i.e. see if your team won the game, and then
either
## Summary
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 multiparty
transaction can always use a larger than estimated signature to unfairly extract
a fee contribution from the other parties to
18 matches
Mail list logo
