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

[Manuel]

@chimp1984 Thanks, I very much appreciate the discussion before I put together a proposal.

> To avoid spam pow can be used

That would be an option, but could it be tried first by keeping only the trade fee on the seller's side?  If the buyer does not pay and does not request mediation (unresponsive), maybe the seller could republish the offer, so he doesn't lose the trade fee. The problem is that only sell offers would be allowed.  Alternatively, PoW could be required for both buyer and seller or only for the buyer.  But i am not sure if this would be an important UX impact for an onboarding buyer.

> BSQ bonds might be used for additional security

As I see it, this is the best possible way I can think so far to avoid scams from the sellers.

> In case of scam of the seller the buyer might be able to do a bank chargeback

This is a turn around of the chargeback problem (turning it into a solution instead of a problem) but it is obviously a last recourse action.  Not desirable at all.

> repeated small payments in LN.

This would be an awesome solution in general for Bisq if automated.  Problem is clunkiness of fiat payments systems, as you say.

> Tracking exposure from parallel trades 

Wouldn't it be possible to limit this kind of offerts per fiat account?  That is, only one or two sell offers of this type at a time and X offers per time period (week, month, etc).  Of course, this would only make sense from a point of view of facilitating onboarding, maybe not so for the off chain trade protocol in general. 

> How does Bisq get trade fees 

Only the trade fee of the seller if we keep it.  But might be worth getting less fees if it is a tool to get much more users onboard

> Should that be only be supported for sell offers 

If we want to also support buy offers, I understand PoW is needed to avoid spam, although that could impact UX for newbies.

Not that I have that many ideas, and maybe they are silly, but as a summary:

- Limit the number of offers published by sellers (if only sellers are allowed)

- Limit the number of offers taken by buyers or published by buyers (if buyer offers are allowed).

- To minimize the risk of buyer using stolen accounts, and considering the buyer would be signed by the seller (the seller must be a signer), we could limit buyers to take this kind of offers only once per payment account.  That is, taking this offers would only be allowed for unsigned buyer accounts (which is good in the sense this offers would be available only to those who need them). The problem would be to avoid the buyer taking several offers at the same time.  Another possibility is a "pre-signed" status that could be broadcasted when the buyer takes one of these offers.  

- Maybe, in order to avoid stolen accounts, it would be more secure to allow only buyer offers with PoW, so attempts to make more than one trade of this kind per payment account could be much more obvious and easily detected by the network.  And then only sellers with old accounts could take those buy offers.  But this would be a less liquid / immediate approach.  

- The above could be also achieved by internally limiting it within Bisq client (i.e. the client would not allow to take more than one offer of this type).  It is true that someone with coding knowledge could easily bypass it.  However, if this is limited within the client but despite this limitation someone tries to take more than one offer, then the network knows with a 99,9% probability that the buyer is a scammer?

Probably this has been discussed before, but as a general rule couldn't honest clients discriminate dishonest clients by detecting behaviors that are outside what is allowed as of the client specifications?  Not different from BTC nodes or miners rejecting invalid transactions.   If I am correct on this, it is a powerful decentralized tool we can heavily use to reject dishonest users / actions.

-- 
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-734782329
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201127/052658d3/attachment.htm>