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 c
Hi list,
I'm proposing Tuesday 21st February at 18:00, i.e 2 weeks from now for the
4th Bitcoin contracting primitives WG meeting (the third Tuesday of
February month, as done previously).
As mentioned during the previous session, there is an issue if anyone would
like to propose an agenda topic
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 you
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, Fe
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
> Tapr
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 br
Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit :
> my favorite one is the javascript exploit for people that like to
> render untrusted blockchain data in their browser
Taking this example to show that from my standpoint it's not a good idea
to store "big things" in the blockchain
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 esti
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 y
> 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 demonstrat
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 tryi
11 matches
Mail list logo
