[bisq-network/proposals] Using PoW for the P2P network messages as dos protection (#268)

[cd2357]

> There is still the open question how to do the first contact to find out the peers network load indicator.

It could be similar to how TCP/IP recalibrates the timeout window for retransmission ([link](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Timeout-based_retransmission)).

Basically:
- sender attempts to send a message (with an assumed default or mininmal PoW P1 in header or payload)
- recipient decides
  - is there too much load / more PoW required? then NACK with a nonce in the reply (next connect attempt would need to use this nonce, to prevent PoW reuse)
  - is provided PoW enough? then open connection, accept incoming msg
- if sender was rejected, he can retry with PoW P2 = 2 x P1
  - for a honest Bisq node that is already connected: no degradation, their connections were open based on a low initial PoW
  - for a honest Bisq node that is just now connecting (during attack) : this means having to wait 1s, 2s, 4s, etc until connection established (alternatively: after a threshold, Bisq could show a popup "network is currently under load, please try again later")
  - for an attacker: regardless of number of nodes, any potential "flood" of new connections is reduced to a "trickle"

---

@MwithM wrote

> I point this proposal to #265 as they're so related: Maker and taker fee tx works as spam protection.

Based on that idea: "proof of payment" could be used to get priority in the event of network load. In other words, "prove that you have paid trade fees" (by signing a nonce with the priv key) = "ok you are likely an honest Bisq node, will accept your connection / evtl require less PoW".

Recipients could keep a temporary list of "which incoming connections proved which fee payment", to prevent that an attacker re-uses the key for one fee payment on multiple clients (bots) to create a flood of connections. Once the load reduces, the recipient could "forget" this list, or even not bother maintaining it, until load spikes again.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/268#issuecomment-712701116
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201020/aeadc292/attachment.html>