Settings for third party bot operators

[Reckless-Satoshi]

Hello guys,

This bot is simply amazing. I would love to help this project and eventually try to run by myself a bot for an English speaking community. There is a few features I would love to see before getting into it. I will leave them here as a wish list. As I have never written .js, I don't think I can implement them by myself, but if I find the courage, I might try!

1. Add .env setting DONATE_DEV to set (%) of FEE that is donated to the dev team.
2. Add .env setting DEV_NODE_ID (for keysend) or DEV_NODE_ADDRESS (for LNURL).
3. Add .env setting: LANGUAGE. Related to Issue #28.
4. Add .env setting DISPUTE_FEE. Option to set a fee (%) to open a dispute.

Why

1. It is important that if the bot is operated by someone else than the developer, the developer keeps receiving the support needed. Of course, it could be up to the bot operator to donate to dev. However, for a more systematic developer support, there could be an option so the bot automatically sends some % of FEE for every transaction to the dev LN node.

2. As long as BOLT13 is not out keysend /LNURL are the way to go.

3. I understand eventually the private messaging language could be selected by the user as thought in Issue #28 . However, the group offers language is unique for all users and must be set by the bot operator for his community. I'm happy to translate the text in bot/messages.js if this is a useful task.

4. At a first glance, it seems the most costly part for a bot operator will eventually be the labor needed to resolve disputes. Therefore, if the DISPUTE_FEE does not exist, the operator might have to increase the overall FEE to cover costs. In turn, making the bot less attractive for every user. Example of how this could work. When the user wants to open a dispute he gets notified that there is a fee to open a dispute. The fee is deducted from the BTC transaction amount (e.g. 0.3%). Next, the user has to confirm to proceed with the dispute by providing a new LN invoice with the new amount and a expiry not shorter than 12 hours. DISPUTE_FEE should help to rise the entry barrier to dispute spamming, lower the bot operator cost and the fee for every other user. (Note: this type of disputes can only be opened by buyers and there might be several unintended consequences. Needs some more thought!)

[grunch]

Hi, thanks for your kind words, as you see in the issues the will be translated to multiple languages and let people around the world use it, being said that, it's open source and you can fork it and use of course.

The decision of having it in spanish only now is intentional cause we are testing the bot and finding bugs before the bot can be used by the entire world, so far the plan is working, the bot is being used in spanish speakers countries and we are having an amazing feedback, now we need more help on development.

About your recommendations:

1. Do you mean this to be saved on database for people running the same software with another telegram bot api will send us manually later?

Or do you mean that after each payment on other people's bot it will ask for a payment request to our node to send those sats?

2. We can show the node_id, in fact there is a /info command that returns the node id, it's not documented yet.

3. Yes, will do that in the future.

4. I totally agree on this, I've been thinking a lot on this disputes and DISPUTE_FEE is one of the things we will have before add multi-language.

The real issue here is currently this bot will not scale to a worldwide use, I see the we have two options, both need DISPUTE_FEE:

1. Hire people to solve disputes like hodlhodl, but this is a corporative way of solving things which I don't like and pay them with DISPUTE_FEE.

2. Allow to users to create their own communities in their language and their currency, linked to their own channels for order listing, this will add more independency to users, with this we will remove a lot of centralization for this project, the users will not need to ask to admins for anything, and the dispute solvers will be people identified by the community, they would do our benevolent dictators, people have to trust on them but if people don't trust them they have the option of leaving that community and find another one or create a new one, the bot would pay to those dispute solvers with DISPUTE_FEE of course.

This is what I think we will do, is a lot more work but totally worth it.

[Reckless-Satoshi]

1. Do you mean this to be saved on database for people running the same software with another telegram bot api will send us manually later?

Exactly, I am assuming eventually there might be more instances of p2plnbot showing up on Telegram. It would be great if these bots, operated by the community, have a default way to donate a given amount to the dev team for every successful trade. Not necessarily manually, the stream of sats to dev could be automatically. Inspiration for this feature comes from open source mining software (e.g. https://github.com/xmrig/xmrig, the software donates 1% to dev, but can be disabled in source code).

As for the DISPUTE_FEE, I also believe the decentralized way with many communities and 'benevolent dictators' is the more robust approach. It also matches perfectly since the bot is open source (and this is the bitcoin way! :D). A list of the public communities, with language/currency/etc could be centrally hosted on a git readme. E.g,:

Community	Language	Currency	Num Users	Bot Handle	Admin	Base Fee	Dispute Fee
SevEX	Spanish	All	+300	@lnp2pbot	grunch	(...)	(...)
(...)
(...)

---

I gave a bit more thought to the issue of only the buyer being able to open a dispute with fee. The only way around this is to ask the seller to post a small collateral.

E.g., the initial hodl invoice is created for 100.5% of the trade amount. If no dispute is initiated, the seller is returned 0.5% when he releases the payment to the buyer.

Additional pros: it would eliminate the perverse incentive for the seller to not release the sats. No more need to incentivize with punishment (banning the account). The cons: the whole trade pipeline becomes a bit more complex and convoluted (more HTLCs that can potentially fail)

Locking collateral can be seen in other p2p platforms such as Bisq. What are your thoughts on best ways to implement a DISPUTE_FEE ?

[grunch]

The idea from xmrig sounds interesting, I am not sure yet if this can work in our case cause being a pool is not the main goal of the bot.

About the dispute, we don't need to ask for additional collateral amount cause the bot can take the % from the seller after settle the hold invoice, but the bot will need to ask a new invoice to the buyer to send a new amount without the %, but I am not sure if both have to pay the dispute or only the one who started it.

[Reckless-Satoshi]

The idea from xmrig sounds interesting, I am not sure yet if this can work in our case cause being a pool is not the main goal of the bot.

I see. As an open source project, it's unavoidable that someone could try to capitalize the idea in a different way of what you have in mind (e.g., run a new bot instance, with a big marketing budget, etc). If this was to happen, it might be good if the bot has a default and sustainable way to support the development. This feature might not have any effect anyway in that regard. I guess it is ultimately up to you :)

---

but I am not sure if both have to pay the dispute or only the one who started it.

Well, I see the DISPUTE_FEE can serve potentially 2 functions:

1. Cover the labor costs of dispute solving.
2. Decrease dispute spamming and create incentives against cheating, i.e., the dispute loser pays the fee.

If the fee is taken from the trading amount, the dispute winner will always cover the dispute fee. It solves (1), although it might seem unfair. However, it doesn't solve (2), as an intentional cheater knows he will never be punished if caught:

• The buyer will be deducted the sats of the dispute fee when the resolution is favorable to him.

• The fee can only be charged to the seller when he wins the dispute and the sats are returned to him.

Therefore:

• A cheater seller can open disputes for free, as long as he knows the trade will get finalized. For example, the seller can lie to the judge and say the fiat was never received, at no cost if caught.

• A cheater buyer can open a dispute for free, as long as he knows the trade will be cancelled. For example, the buyer can lie to the judge and say he did send the fiat, at no cost if caught.

I believe the only way of solving (2) is asking the seller for extra collateral. Yet, to cover all possible cases above, the buyer would also need to post collateral too. Cons: Many more interactions and HTLC and messier user experience.

---

Another approach involving fewer HTLCs to achieve (2) so the dispute loser always pays the DISPUTE_FEE:

• The user is asked to deposit X amount of sats after /start to be able to trade.
• The user can /withdraw the deposit at any time if they do not wish to trade anymore.
• The deposit is slashed in case of losing a dispute.
• In case of slashing or insufficient collateral, the user needs to post more sats to keep trading.

Cons: high friction and user unfriendly. Not great when trying to grow the user base, but maybe good when the bot is well established. It also adds a lot of complexity and the bot becomes de facto custodian of funds (not great).

[grunch]

Hi @Reckless-Satoshi I am sorry for the delay in the response.

Thank you for your suggestions, I agree on you that those are our options, I don't like any of them but we need to do something about it.

One of the things we did have coded on the bot is a /ban command, to ban users from the bot by admins and a MAX_DISPUTES env var, which ban users after that value.

I think I lean more towards the fee is taken from the trading amount, the dispute winner will always cover the dispute fee and admins can ban users if it look to obvious that it was an intent of cheating or the bot will do it after MAX_DISPUTES.

I know it can be unfair, but this way we are not destroying our non custodial UX which is working pretty well right now, this is what the bot is, a fast non kyc non custodial way of trade btc, if we change this we have just a regular bot.

I have a theory that I want to put in practice, which is what I told you before, the one which users choose their own dictator in small (or not so small) communities, I think it might work.

What do you think about it? do you think users will be against this?