Thanks for pointing out that small pools benefit from less strict mempool policy nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqy0hwumn8ghj7mn0wd68yttjv4kxz7fwvf5hgcm0d9hzumnfde4xzqpq85h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qtyz2zr . I hadn't considered that.
Do you think Bitcoin core could benefit from moving the social interactions around the repository to nostr? gitworkshop.dev features nostr based pull request and issue management for instance.
@npub1wnlu28xrq9gv77dkevck6ws4euej4v568rlvn66gf2c428tdrptqq3n3wr after realizing that miners who are too small to receive transactions out of band benefit from a permissive relay policy, I'm starting to wonder if DATUM and StratumV2 are the right tools for node operators to express their opinions rather than mempool policy.
Perhaps its time to stop calling our nodes "full nodes" if they aren't producing cost effective hash-rate.
Whats your take on this?
Datum and sv2 are just using whatever your mempool policy is
Selectively propagating does seem to have negative side effects.. Would it make sense for nodes to propagate all valid transactions to the peers in order to level the playing field for small miners while still applying the policy to their own hash-rate?
I'm starting to wonder if a node that doesn't produce its own hash-rate is sufficient to keep Bitcoin secure. Perhaps all node operators need to participate in consensus actively by producing hash-rate.
Absolutely! Gitworkshop.dev has improved a lot since Fabian Jahr last checked it out. I think this is a great opportunity to give it another shot..
