Hi,
I think the topic of how to improve transaction relay policy and fee
bumping is an important one that needs to be worked on, so I'm glad
this is a topic of discussion. However I am pretty skeptical of this
consensus change proposal:
The Sponsor Vector TXIDs must also be in the block the
Hi ZmnSCPxj,
> The SE can run in a virtual environment that monitors deletion events and
records them.
> Such a virtual environment could be set up by a rootkit that has been
installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
on can allow
Hello AC,
Yes that's a real issue. In the context of multi-party protocols, you may
pre-signed transactions with the feerate of _today_ and then only going to
be broadcast later with a feerate of _tomorrow_.
In that case the pre-signed feerate may be so low that the transaction
won't even
Not sure if I'm missing something, but I'm curious if (how) this will work if
the sponsored transaction's feerate is so low that it has been largely evicted
from mempools due to fee pressure, and is too low to be widely accepted when
re-broadcast? It seems to me that the following requirement
