> In the context of fee bumping, I don't see how this is a criticism
> unique to transaction sponsors, since it also applies to CPFP: if you
> tried to bump fees for transaction A with child txn B, if some mempool
> hasn't seen parent A, it will reject B.
Agree, it's a comment raising the
Thanks for your thoughtful reply Antoine.
> In a distributed system such as the Bitcoin p2p network, you might
> have transaction A and transaction B broadcast at the same time and
> your peer topology might fluctuate between original send and
> broadcast of the diff, you don't know who's seen
> This entirely misses the network cost. Yes, sure, we can send
> "diffs", but if you send enough diffs eventually you send a lot of data.
The whole point of that section of the email was to consider the
network cost. There are many cases for which transmitting a
supplementary 1-in-1-out
> That's not an argument not to do it though if you take a longer term
> perspective on building the strongest possible foundation for Lightning or
> other Layer 2 projects. The security benefit would just be delayed until a
> significant majority of Bitcoin Core users upgraded to a version
> This is the assumption which I don't agree with and hence asked some
> questions in my email. A new RBF policy used by default in Core will not
> improve the security of projects that are vulnerable to multiple RBF policies
> or rely on these policies in a way that affects their security.
> I suspect as with defaults generally most users will run whatever the
> defaults are as they won't care to change them (or even be capable of
> changing them if they are very non-technical).
30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some
are even running
Hello,
I'm opposed to recursive covenants because they allow the government to
_gradually_ restrict all bitcoins.
Without covenants, other miners can fork to a free blockchain, if the
government tells miners each transaction to be added in the block. Thus the
government cannot impose desires
