> From what I understand we'll have about 35 message types on the network with
> the addition of BIP324. 256 possible IDs sounds like plenty room to grow, but
> perhaps we can be a bit more conservative:
>
> We could use the first bit to signal a 2-byte message ID. That allows us to
>
AJ/Antoine et al
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice is a well funded advisory, with enough resources to spam
the network so that enough nodes see her malicious transaction first,
how
Hi Pieter, hello list,
On 26.10.22 12:39, Pieter Wuille via bitcoin-dev wrote:
1. The most straightforward solution is using the BIP process as-is: let BIP324
introduce a fixed initial table, and future BIPs which introduce new
messages can introduce new mapping entries for it. In
We updated the MuSig2 BIP draft to fix the vulnerability published in an earlier
post [0].
We also wrote an article [1] that contains a description of
1. the vulnerable scheme (remember that the original MuSig2 scheme is not
vulnerable because it doesn't allow tweaking)
2. an attack against
actually, peter makes an important point here
technically, all we need is for *miners* to consistently mine "full rbf"
as long as they do, businesses that accept 0conf will have to adjust their
risk accordingly, and the problem of misaligned incentives is resolved
i don't think it matters what
Hi,
I wanted to chime in on the "teleport" feature explained by Ruben, as I
think exploring something similar for Taro could be super useful in an LN
setting.
In today's Taro, to transfer tokens you have to spend a UTXO, and present a
proof showing that there are tokens committed to in the
