net: Remove -whitelistforcerelay #16057

1. 
   MarcoFalke commented at 5:47 PM on May 20, 2019: member

   This flag has been added in 86755bc to allow "(re-)broadcast" of transactions through a "gateway" node.

   However, if our gateway node does not accept the transaction, the peers connected to the gateway are likely to not accept it as well. For illustrative purposes, a list of example tx reject reasons that would result in tx (re-)broadcast:

   • Tx is already in the mempool
   • Tx has too low fee to get into the mempool
   • Tx violates standardness policy

   So a smaller than default mempool (or higher than default minrelaytxfee) is probably the only reason a tx could be rejected by our gateway and be accepted by other peers.

   Instead of using whitelistforcerelay for that use case, I suggest to run a recent version of Bitcoin Core with a default (or higher than default) maxmempool setting and default (or lower than default) minrelaytxfee settings.

   Note that the setting has then been turned off by default in 72bd4ab.

2. net: Remove -whitelistforcerelay fa481b19b6
3. MarcoFalke added this to the milestone 0.19.0 on May 20, 2019
4. 
   sipa commented at 5:50 PM on May 20, 2019: member

   This is a flag that you'd set on the gateway node, whitelisting the "internal" peers. That way, when the internal nodes rebroadcast, the rebroadcast traverses the gateway, who will forward it to its (new) peers, even when the gateway already had the transactions in its mempool.

   The rebroadcast mechanism works at all because peers (slowly) rotate, giving new opportunities for relay. When you're behind a singular gateway node, it stops working. The forced relay option fixes this.

5. 
   MarcoFalke commented at 5:59 PM on May 20, 2019: member

   Is there any data available that shows that this works? I'd assume that the fluff starves rather quickly. Even if the gateway can send it to another (new) peer, that peer can't send it forward because it's peers already have it.

   Regardless, if the rationale for this is to rebroadcast txs from a wallet that is connected over p2p, the mechanism should only work when the tx is already in the mempool.

6. 
   sipa commented at 6:01 PM on May 20, 2019: member

   I don't have data, but my point is that if forced relay is useless, then rebroadcasting itself is useless.

7. DrahtBot added the label P2P on May 20, 2019
8. DrahtBot added the label Validation on May 20, 2019
9. 
   MarcoFalke commented at 6:04 PM on May 20, 2019: member

   Yeah, I agree

10. MarcoFalke removed the label Validation on May 20, 2019
11. 
    sipa commented at 6:05 PM on May 20, 2019: member

    So concept NACK unless there's evidence rebroadcasting in general doesn't work, in which case that can be removed too.

12. MarcoFalke closed this on May 20, 2019

    ---

13. MarcoFalke deleted the branch on May 20, 2019
14. MarcoFalke locked this on Dec 16, 2021

Milestone
0.19.0