Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Taker's offerbook #392

Open
mojoX911 opened this issue Jan 31, 2025 · 3 comments · May be fixed by #438
Open

Improve Taker's offerbook #392

mojoX911 opened this issue Jan 31, 2025 · 3 comments · May be fixed by #438
Assignees
Labels
enhancement This enhances the code and improves stuffs
Milestone

Comments

@mojoX911
Copy link

Make the taker's offerbook smarter so we don't have to redownload offers everytime for a swap.

@mojoX911 mojoX911 added the enhancement This enhances the code and improves stuffs label Jan 31, 2025
@mojoX911 mojoX911 added this to the v0.1.1 milestone Jan 31, 2025
@mojoX911 mojoX911 self-assigned this Jan 31, 2025
@mojoX911 mojoX911 moved this to WIP in core lib Feb 6, 2025
@ab-oggm
Copy link

ab-oggm commented Feb 27, 2025

What do you mean by making it smarter?
Inside the send_coinswap we sync_offerbook to get the latest offers. How do you think of making it smarter.

  • Do you suggest running some background process in a fixed interval to fetch the offer book and maintain a timestamp of the latest fetch, which we can directly call inside coinswap(latest time fetch) instead of calling sync_offerbook?

@mojoX911
Copy link
Author

mojoX911 commented Feb 27, 2025

Do you suggest running some background process in a fixed interval to fetch the offer book and maintain a timestamp of the latest fetch, which we can directly call inside coinswap(latest time fetch) instead of calling sync_offerbook?

Yes exactly. First step of smartness is to note a timestamp so we don't redownload recently downloaded offers again. The cutoff could be 30 mins, if last timestamp is more than 30 mins, redownload again.

2nd smartness is, having unique index for makers for which taker could manually select multiple makers to swap with. An interactive flow for the taker app, as suggested for manual utxo selection here will be even more perfect.

Further smartness could be, ban scoring, deciding on a strategy on give various ban score to makers, and set a ban score cutoof, beyond which makers will not be selected for swaps. Send feedback on maker's ban score to DNS, so other taker's also gets to know about bad makers. This requires more thoughts and can be done later.

For this issue only the timestamping and manual maker selection from offerbook would be enough.

@mojoX911 mojoX911 assigned ab-oggm and unassigned mojoX911 Feb 27, 2025
@mojoX911 mojoX911 removed the status in core lib Mar 6, 2025
@ab-oggm
Copy link

ab-oggm commented Mar 6, 2025

@mojoX911 do we have some doc to setup the DNS locally instead of using the hosted DNS. Will be easier to solve this issue.

@ab-oggm ab-oggm linked a pull request Mar 6, 2025 that will close this issue
@mojoX911 mojoX911 linked a pull request Mar 14, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This enhances the code and improves stuffs
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants