search

bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
43 stars 16 forks source link

Using PoW for the P2P network messages as dos protection #268

Closed chimp1984 closed 3 years ago

chimp1984 commented 3 years ago

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Our P2P network is vulnerable to dos attacks like all permissionless, open networks. We have some basic protection in place but I doubt they would help much in case the network gets attacked.

One potential solution might be a proof of work scheme. Another one to use some sort of anonymous credentials.

The idea is longer around but I just stumbled over a discussion at the Tor mailinglist [1] about using proof of work for dos protection [2], so I got motivated to re-think that approach.

High level idea

Every node signals the level of load it has and this is an indicator for the required proof of work other nodes need to fulfill if they send a message to that node. The difficulty is a function of the message type and the nodes network load. In normal operation the diffuclty would be that low that there is no performance degradation. Only in attack scenarios once a node gets under heavy load it will become more expensive to send messages to that node and so increases the costs for the attacker. The motivated user still can access the attacked node but it will require more time and resources as usual.

The hash function should be choosen so that it is GPU and ASIC resistant (at least hard to optimize for). It should not use any hash function used in popular blockchains and it should be memory-hard.

There is still the open question how to do the first contact to find out the peers network load indicator. We could allow a very lightweight message to be used for that with the exception to not need pow or have a default level of pow which is cheap enough for normal users to not cause performance degredation but which would sum up if an attacker wants to use that on a larger scale. Persisting node addresses of past connections and using that for the decision if a new connection without pow is accepted or not might be another option.

Another open issue is how to ensure pow is not re-used. A challenge-response pattern can be used as we have a request-response model or continuous hand-shakes. The first message can be used to deliver a nonce which need to be part of the pow solution.

Additional protection

The discussion at [2] concludes that the pow protection will only work against script kiddy and medium size bot net attacks (cost about 400 USD) but not against large botnet attacks (cost about 34k USD). It also causes problems for users on low-end hardware like mobile phones. We should keep in mind the mobile user even we do not have a mobile trading app yet. To mitigate both the large botnet attack scenario as well as to offer low-end hardware users an option, the paper [2] discusses models for anonymous credentials. I have not looked further into those models but I think we should consider that as well. Bisq might have already some sort of tokens (account age, BSQ) which maybe could be used in that context.

[1] https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html [2] https://github.com/tevador/torspec/blob/2424e7d16772a1b13d1f9288c5b7fd0656363836/proposals/ideas/xxx-pow-over-intro-v1

MwithM commented 3 years ago

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

cd2357 commented 3 years ago

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).

Basically:

@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.

mpolavieja commented 3 years ago

Sorry about the off-topic, but I've always thought that PoW could somehow be used instead of BTC deposit for small transactions, to onboard new users that do not have BTC.

chimp1984 commented 3 years ago

Sorry about the off-topic, but I've always thought that PoW could somehow be used instead of BTC deposit for small transactions, to onboard new users that do not have BTC.

Hm.. I see it more as a dos protection so replacing the maker fee, but the security deposit is more in place to avoid that traders are careless and lazy but with already done pow there is no incentive to follow the protocol. The refund of the deposit it the key but that is not possible with pow, its more like a fee/cost.

mpolavieja commented 3 years ago

traders are careless and lazy

What I had in mind was a model where the buyer trusts the seller for small quantities. No deposits and no locked BTC. Only sellers with signed accounts above x age could do this, so they would risk those accounts being banned from bisq if they don't release the BTC. In order to ensure both parties do not forget about the trade or go offline, some PoW should be required periodically during the trade. If no PoW for two times in a row (for example), then you leave the trade. But I know this would imply a different trading protocol, it would not ensure avoiding lazyness, so probably is not worth it.... So as I said, just an off-topic thought.

chimp1984 commented 3 years ago

Yes the idea for some sort of "trusted sellers" might be an idea. They can be bonded. But buyer who is lazy and takes an offer but never sends fiat has nothing to lose... if seller has not locked up btc beside the trade amount he would have a bit less risk, but still not sure if its worth it. But trying out some experience where users can get some extra previlege by locking up BSQ mitght be interesting and a path to something which can later be used more general. E.g. might lead to the off chain trade protocol or a new idea in that direction.

With the new idea in #279 the requirement to have locked up funds would vanish, so that would change quite a bit.

But we have to take care not to design a system which lead to having a few big market makers who act as kind of sub-exchange and would be a problem for privacy (if many traders trade with them, they become a honeypot) and they would risk regulatory issues if they operate as professional traders/company. Shutting them down then would hurt Bisq as well as a large part of liquidy would disappear then.

sqrrm commented 3 years ago

How about letting signed accounts be trusted sellers that don't require funds to be locked up for a small amount to allow nocoiners a way in. The POW is a way to limit spamming with these unfunded offers. Buyers are taking the risk here, but perhaps there could be some revocation of the signed status for signed sellers acting in bad faith.

Another option is to stick with the fee transaction as we do now but not lock that up in a deposit tx. Then there would be proof of funds and something more to tie the seller to, but money would still not be locked in a 2of2 for the seller.

mpolavieja commented 3 years ago

@sqrrm, that's exactly what I had in mind. I am thinking about changes in the trade protocol and that while it is true that it would be different, in reality I think it shouldn't be that hard because there is none but just the seller sending the BTC once he receives the payment.

Maybe the best PoW that could be requested on the side of the buyer is to send a receipt of the payment. If banning an old signed account is not deterring enough fot the seller to comply, locking some BSQ on the side of the seller could do the trick.

In any case, the good thing is that if the buyer does not pay, the seller loses nothing but his time and no arbitration is needed at all. I am not sure if his sell offer could be republished so he does not even lose the maker fee.

If only the signed old account is at risk, and the seller does not care about losing it, the buyer could request a legitimate chargeback to the bank if the seller does not send the BTC.

mpolavieja commented 3 years ago

@sqrrm, @chimp1984, I am thinking that this kind of trades could be easily done off-chain (Lightning Network) because there is no deposit nor multisig needed. If I am correct, this would be ideal for onboarding as buyers would dodge mining fees, buyer would publish an LN invoice in his offer and seller would pay it once he receives buyer's payment.

I have several ideas on how to incentivize sellers to comply and also to deterr professional (i.e. centralized) sellers. Maybe I should put it all together in a proposal.

sqrrm commented 3 years ago

Not sure a user with no bitcoin would have a lightning channel open to receive LN funds. It would also not be helpful for further trading on bisq. Another issue is the ease for scammers with stolen bank accounts, would have to be very small amounts to make sure it's not worth it for them. Still think it could be worth considering further.

mpolavieja commented 3 years ago

It would also not be helpful for further trading on bisq.

True, he would have to redeem for L1 BTC to be able to use it further on Bisq. I was thinking of it as a further step towards the off chain protocol. I am not sure if it would be worth for a scammer to burn a stolen account for low quantities. I'll think more about the whole idea.

chimp1984 commented 3 years ago

@mpolavieja Curious about more details about your ideas!

The direction goes really into the off-chain trade protocol.

So to summarize:

Open questions:

mpolavieja commented 3 years ago

@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 is totally unresponsive until the trade expires (no chat message, no started payment, no mediation request), 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:

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.

chimp1984 commented 3 years ago

couldn't honest clients discriminate dishonest clients by detecting behaviors that are outside what is allowed as of the client specifications?

Usually we deal with that in the trade process. Like the account age cannot be verified until the payment account data are know, which is not part of the offer. So makers could fake their account age, but at the trade process the taker verifies as soon he gets the accout data and would fail the trade if faked. Depends on the circumstances but that model that the peer is the verifyer works in many use cases.

On a more broad general use case it is difficult as "false flagging" to kick competitors our would be a problem. Reputation systems with positive flags cause sybil attack problems, with negative flags its creates the problem of "false accusation". For the negative score proposal we considered that it can be only propagated by mediators who act as trusted/bonded/neutral entities but of course lead to a bit higher level of centralisation.

chimp1984 commented 3 years ago

I would love to see some real data for the no-coiner onboarding problem. It is a problem which gets mentioned since ages but as far I am aware it is always brought up from Bitcoiners never from real "first timers" - which can be explained that they are not involved in Bisq yet. But I have also the suspicion that we interpret more of a problem into it as it is really and as there is no easy solution I think we should first find out how many users would be affected by that. Getting first BTC via friends, meetupds, ATM, vouchers should already cover 90% of those, and then for 5 users/year it will not be justified to invest a lot of work (and risk) to get a solution for those.

The reason I got more excited in the discussion is that those ideas might help us to get to a new trade protocol version (off chain would be still my favorite if we find a safe way how to do it).

Regarding fees: One way to think about alternatives to direct trade fee payment could be to require BSQ purchase (BSQ bonds). This increase demand of BSQ and by that increase price which makes Bisq financially more sustainable (require less issuance if BSQ had higher value). So we could look for alternatives for fee payment for those who are willing to set up a BSQ bond and use that additionally as security tool. So it solves 4 problems at once:

As BSQ bonds cannot be enforced (would cause too high burden to enter) there will be always the normal burned fee which helps to stabilize the issuance/burn rate.

mpolavieja commented 3 years ago

Then, if we want to use this kind of trades as a testbed for the off-chain protocol, probably requiring a BSQ bond would be the way to go. An independent BSQ bond / burning proof would be required for each different (hash) payment account, so if someone generates many payment accounts that are internally the same (i.e. same account number), we don't care because he will have to pledge a bond for each one of them.

To avoid too many paralell trades, maybe we could have an extended order book (visually hidden) where all the offers within the ongoing trades are still accesible with a hash of the payment account. If for example we don't allow more than 1 concurrent offer, no matter if maker or taker, with the same hash, a second offer would be rejected (or not shown) in the public order book, and would only be allowed (or shown) in the public order book once the previous offer is completed within a trade or canceled.

This is the only "intelligent" thing (if intelligent at all or not discussed before) that I can contribute for the off chain protocol. Regarding the onboarding, it could be tried on a second stage. I´ll write it on a separate comment.

mpolavieja commented 3 years ago

For onboarding users (buyers without BSQ bonding).

On a second stage, if we want to try buyers without BSQ bonding for small quantities, maybe we could try something rather manual to get a feeling of how much demand there is for it. Only very experienced Bisq users would do this kind of sell offers (maybe initially a controlled group) and would coordinate with the buyer and require him some proof of ownership trhough the chat before disclosing their payment data to the buyer. We could pick up some old ideas such as a digital signature https://github.com/bisq-network/proposals/issues/79, to publish the trade id (or some other string) in social media where the name of the owner of the account is clearly shown (twitter, a verified keybase account, etc) as explained in https://github.com/bisq-network/proposals/issues/83. If the buyer is unresponsive, the seller could cancel the trade straight away.

On a third stage, if we see there is enough demand, some implementation could be carried out for those payment methods where the seller is always able to verify the buyer basic payment data. For example SEPA would not work as sellers don't usually get to see the IBAN from the buyer, but just the BIC, name of the bank and name of the buyer. So a scammer could make / take many small offers with unsigned accounts using fake IBANS within the same bank, and then pay all of them from the same stolen payment account.

So for those payment methods where the seller is always able to verify the basic payment data (i.e. account number), we could use a hash of the payment basic data so no more than one concurrent offer is possible (any new offer would be rejected if there is one still alive offer in the open or hidden order book). So if the scammer has to wait a full trade to start another one, maybe that would be deterring enough. We could even leave the hash in the hidden order book a bit longer if it is not too much overhead for the p2p network, so the scammer would have to wait even longer, therefore chances that his stolen account has been already discovered on the first payment are high.

For payment methods where the seller is not able to verify basic payment data from the buyer, we would have to leave it manual or standirize some verification only if possible and popular (from the information harvested on the manual second stage), like for example if we see that keybase works very well.

chimp1984 commented 3 years ago

I don't see a way how to verify that a trade has been completed. Only the 2 traders know that but not the whole network to be able to limit offers. The off chain trade protocol tried to design a system where that becomes possible but it feels too complex and too fragile.

Maybe another old idea would be more adequate: A lending market where the one who gives credit does his risk assessment with the credit requester however they confirm to do that. If the credit is not paid back its the risk of of the credit offerer and his fault that his risk check was not good enough. So that app would only bring those together and provides a communication platform but does not provide any security.

mpolavieja commented 3 years ago

Only the 2 traders know that but not the whole network to be able to limit offers

Ok, I am sure that I am missing something, but if the network keeps that "hidden" order book with offers within ongoing trades with the following data:

The buy side record would only dissapear if the buyer confirms the trade as completed, same for the sell side record. They would not disappear if they are offline (maybe this could cause too much traffic).

Why couldn't we trust this?

EDIT: It could be a problem that even if the trade does settle, one of the traders never comes back online or refuses to confirm the trade. But in that case the offer could be deleted from the hidden order book after a period of time and if no mediation has been requested for that trade.

mpolavieja commented 3 years ago

If there is a risk that the "hidden" order book info is lost (because all clients go offline and new clients do not know about that info), maybe we could use two new types of tx (open offer / closed offer) that DAO nodes keep track of, so the clients could build that hidden order book from there. Kind of avoiding double spends on btc, but in this case avoiding double offers (or avoiding offers above the bonding limit).

I don't have the knowledge if it is possible to "deposit" some BSQ when opening the offer and get some back and burn the remaining when closing the offer to incentivize traders informing about their trades.

chimp1984 commented 3 years ago

So you mean when a offer is taken both traders publish a message with the hash of payment account data of both traders and when they complete the trade they publish another message with the same hash which signals the trade is completed. But then everyone knows when a certain pair has traded. Also without some blinding elemente one who knows the payment account data of boths traders (because one has traded with both in the past) could create those hashes and see who is trading. The idea goes into the direction of the off-chain protocol but it requires more complex constructions to avoid those privacy issues. Here was the latest version in detail: https://docs.google.com/document/d/1sTbm7SuIGQ5HWCwbxYfnklyMHB_-jIr7kAM9-ZSzzH8/edit

ripcurlx commented 3 years ago

I would love to see some real data for the no-coiner onboarding problem. It is a problem which gets mentioned since ages but as far I am aware it is always brought up from Bitcoiners never from real "first timers" - which can be explained that they are not involved in Bisq yet.

The easiest way would be to add a link with something like "I don't have any bitcoins" into the fund your trade popup and track the hits received in the wiki where we describe different options how to acquire your first bitcoin. That would be a first indication how critical this problem is right now for our target group.

mpolavieja commented 3 years ago

But then everyone knows when a certain pair has traded

True. Problem with privacy is two-fold, (1) for fiat payments, an undercover agent could harvest tons of information no matter how private the system is (once he has the bank details, he can request to the bank with all the transactions from his trading peers), and (2) the anonimity set of bonded traders would be rather limited (at least at the begining).

But no matter the above, we have to try our best for privacy. So, isn't the private use of bonds very similar, if not identical, to what privacy coins like Monero already solve?

That is, seting up a bond would be like mining Monero coins, and using them in a Bisq offer would be like a Monero multisig tx, so only when buyer and seller confirm settlement, the "coin" (bond) can be used again for another offer. I lack the technical knowledge if all these can be implemented in the BSQ chain. If it is possible maybe it is a lot of development effort, but in the other hand it is an already well proven system so implementation risks are much lower.

The "only" thing additionally needed is to incentivize traders to confirm the settlement to avoid mediation requests of traders asking to free up their bonds because the other trader did not confirm. One way could be to atomically tie the bonds from both traders, if technically possible, so both bonds won't be unlocked until both traders confirm, and/or to give BSQ back from the trading fee upon confirmation (more BSQs back if the trade is confirmed sooner)

chimp1984 commented 3 years ago

@mpolavieja If the bond would be part of the multisig we could not use 1 bond for multiple trades but it would be rather like an extra security deposit/bond in BSQ. Also BSQ does not support MultiSig and a bond need to be sitting on 1 utxo with a timelock to give the option for confiscation, which would not work well with a more complex tx structure (could be prob. done, but complexity will add risks). Also its important that there is not more than 1 tx where the funds get locked up (deposit tx) as otherwise we lose the atomicity.

But that idea might be interesting by using BTC with a timelock for an additional bond. So the payout would be split in the payout of the trade amount+sec. deposit and a time-locked payout tx of the bond. Basically what we have with the delayed payout tx but having a separte tx for the bond. So if the time-lock is for instance 1 months, that is usually enough time to cover chargeback risk the traders get their bond back from the timelocked tx. If there is a chargeback the victim can burn the bond of both with an alternative tx without timelock and ask for reimbursement from the refundagent/DAO.

Here the tx structure for that scheme:

Deposit tx:

Payout tx:

Time-locked bond refund tx:

Burn bond refund tx (no time lock):

But I think people would not like to lock up for each trade a bond covering the trade amount (about 100%) which stays locked for 1 months, specially for market makers that would become very expensive from a liquidity point of view. It would also add new txs where we want to reduce number of txs.... so all in all I don't think thats a good idea, but for brainstorming and maybe find other solutions its an interesting approach.

mpolavieja commented 3 years ago

If the bond would be part of the multisig we could not use 1 bond for multiple trades

If you look at the bond set up as mining new coins (following the Monero analogy), a 5000 BSQ Bond could generate for example 10 "bond-coins" or "bond-tokens" ("worth" 500 BSQ each), so you could use the bond for 10 concurrent trades worth 500 BSQ each. If this is not possible, you would need to set up several smaller bonds (one "bond-coin" per each bond) to support several concurrent trades. This is more expensive (mining fees) but in turn improves a bit on the anonimity set.

BSQ does not support MultiSig and a bond need to be sitting on 1 utxo with a timelock to give the option for confiscation

The BSQ Bond would still be the same than now. Imagine for one second that you have an additional sidechain, which is a Monero fork managed by trusted nodes (no PoW). You would create "bond-coins" in that sidechain by setting up a bond, you would destroy them when recovering the BSQ Bond in the BSQ chain. You would use the coins to back each offer taking advantage of the built-in untreacebility of Monero.

Of course, I know my suggestion is crazy, but I write it just in case it sparks some ideas that could be applied to the off-chain protocol. What I think is not that crazy is that the problem we are facing with the traceability of trades is the same, if not identical, to what privacy coins have apparently solved. So maybe it could be possible or reasonable to copycat their privacy techniques into the new trade protocol?