Super cool man!! But is your server having some issues? I keep getting this response with status 500 and {"detail":""} as body when entering the LNURL in lnbits. Also failed to pay my LN address with breez.
whenever someone requests an invoice I have to find out what the current base-layer fees are so that I can set the minimum payment amount
when I launched zaplocker I almost immediately encountered a bug where the server hanged with no response from the third-party api I use to query for fees
I thought that third-party api was rate limiting me, which is an easy thing to fix, and I changed my code so that it caches responses from the api and reuses them rather than constantly querying the api. After that code change the server worked all day, but today it broke again
and now it seems that the api's rate limit isn't the limiting factor -- apparently my server's operating system gets upset when I make more than about a thousand total queries to that api without a dns cache refresh. Even though I'm now spacing out those queries over time, I'm not refreshing my dns lookup table cache, so the cache fills up and has no more room for more queries <-- note that some of the stuff in that paragraph involves things I do not understand, so some parts of my description of the problem are probably erroneous
so my own server is rate limiting me, causing me to have to restart it every so often because that's the only way I know how to refresh the dns lookup table
I'm really out of my depth with this whole "manage your own server" thing
I talked with a smarter person I no longer think it's the OS. I think it's either our internet router or our internet service provider
the smarter person reminded me that dns lookups stop working on all of our work devices periodically and we usually fix it by restarting our router
the problem is usually discovered when someone tries to do npm install <package> on their laptop and npm just hangs, eventually telling us it can't resolve the dns name for registry.npmjs.com
the smarter person suspects it has something to do with the router trying to route over ipv6 but being busted somehow (or maybe our internet service provider is the one who's busted)
restarting the router fixes it and we've just been doing that so now I'm thinking it was maybe a poor decision to self host on a server that's connected to a router that frequently stops knowing how to map domain names to ip addresses
You can try manually adding an entry to the /etc/hosts file. I know, this will break in the long term because it's akin to just using the IP directly, but it will at least allow us to test it for now :)
Also I managed to fetch the lnurl data and now I get a different error: invalid amount. The range is apparently 4187 to 9007199254740 sats. And I'm trying with 5K, 10K and 15K sats, all with the same results.
how long it can be pending for depends on the sender's wallet
On my server I set a minimum pending time of 16 hours (actually 100 blocks but it works out to about 16 hours) but the sender's wallet is allowed to go over that minimum to give me the option of keeping it pending for longer
I've never seen a payment that could be held in a pending state for longer than 2 weeks
Hi, I tried settling over lightning and it came up with "Oh no, we couldn't find a route to you! Consider using the base layer to settle or try again later." ...
the invoice also needs a custom preimage matching the one in the second tan box thingy...currently only LND lets you create an invoice with a custom preimage but blixt is looking to add support
ping your favorite wallet and ask them to support it too!
The server was hanging because before giving out an invoice it queries mempool.space for the latest feerates and uses those to calculate minimum "receive" amounts
But I got rate-limited by mempool.space (I think) for querying for feerates too often
I changed the logic so it only queries them a maximum of once every 10 seconds
Try again and let me know if you encounter any other bugs
ok I found your payment and canceled the hodl invoice so you should have your money back (technically it never actually left your wallet)
not sure what went wrong though so I am investigating
I can tell this immediately: the payment was not in your "pending record", and notifications only go out when the database sees that you have something in your pending record
I don't know why the software detected your payment but did not enter it into your pending record (or maybe it did but somehow the record got deleted)
Check out the github for more info: https://github.com/supertestnet/zaplocker
Do you ever have time to eat or sleep in between building all these awesome things?
I sleep in a tent in the wilderness every night and due to a recent dietary change I only consume three things:
no way, me too!
deleted by author
Damn man, who are you? How do you do all of this?
I am Super Testnet and I do all of this because I think bitcoin is cool
It IS cool!
Super cool man!! But is your server having some issues? I keep getting this response with status 500 and
{"detail":""}as body when entering the LNURL in lnbits. Also failed to pay my LN address with breez.This is the LNURL if you want to debug:
LNURL1DP68GURN8GHJ77NPWPKX7CMTV4EZUCM0D5HJUAM9D3KZ66MWDAMKUTMVDE6HYMRS9A3XJMR5DPHKUUREUMA
yes, my server is having issues
whenever someone requests an invoice I have to find out what the current base-layer fees are so that I can set the minimum payment amount
when I launched zaplocker I almost immediately encountered a bug where the server hanged with no response from the third-party api I use to query for fees
I thought that third-party api was rate limiting me, which is an easy thing to fix, and I changed my code so that it caches responses from the api and reuses them rather than constantly querying the api. After that code change the server worked all day, but today it broke again
and now it seems that the api's rate limit isn't the limiting factor -- apparently my server's operating system gets upset when I make more than about a thousand total queries to that api without a dns cache refresh. Even though I'm now spacing out those queries over time, I'm not refreshing my dns lookup table cache, so the cache fills up and has no more room for more queries <-- note that some of the stuff in that paragraph involves things I do not understand, so some parts of my description of the problem are probably erroneous
so my own server is rate limiting me, causing me to have to restart it every so often because that's the only way I know how to refresh the dns lookup table
I'm really out of my depth with this whole "manage your own server" thing
thank you for your patience
No problem man, I know how it is.
10K requests indeed seems like a lot, but still I've never ran into an OS issue like that. What OS are you using?
I talked with a smarter person I no longer think it's the OS. I think it's either our internet router or our internet service provider
the smarter person reminded me that dns lookups stop working on all of our work devices periodically and we usually fix it by restarting our router
the problem is usually discovered when someone tries to do
npm install <package>on their laptop and npm just hangs, eventually telling us it can't resolve the dns name for registry.npmjs.comthe smarter person suspects it has something to do with the router trying to route over ipv6 but being busted somehow (or maybe our internet service provider is the one who's busted)
restarting the router fixes it and we've just been doing that so now I'm thinking it was maybe a poor decision to self host on a server that's connected to a router that frequently stops knowing how to map domain names to ip addresses
You can try manually adding an entry to the
/etc/hostsfile. I know, this will break in the long term because it's akin to just using the IP directly, but it will at least allow us to test it for now :)Also I managed to fetch the lnurl data and now I get a different error:
invalid amount. The range is apparently 4187 to 9007199254740 sats. And I'm trying with 5K, 10K and 15K sats, all with the same results.Good idea, I just did that
What wallet are you using? Your lnurl works fine in lnbits and phoenix for me
I tried to pay with breez
hmm breez isn't available for my phone so I can't test it, I'm sorry that it isn't working for you!
What about batching requests into a queue? Or does it need to be synchronous.
If IPv6 is causing problems, can you disable it? Though a past ISP for me only allowed IPv6, so I can understand that being limiting.
Maybe a the cheapest possible VPS with fixed IP could act as a proxy (or maybe would have the same problem).
At from my side sounds like a fun problem to solve :)
This is awesome!
Looks awesome dude.
🔗 Privacy-friendly: https://yewtu.be/watch?v=5LYt4H6xA-g
Non-custodial but the server still needs to be trusted. Right?
Yes because the server can cancel your inbound payments
Pretty cool!
Still, the tx wouldn't be pending for more than a day or a week right?
how long it can be pending for depends on the sender's wallet
On my server I set a minimum pending time of 16 hours (actually 100 blocks but it works out to about 16 hours) but the sender's wallet is allowed to go over that minimum to give me the option of keeping it pending for longer
I've never seen a payment that could be held in a pending state for longer than 2 weeks
I appreciate how great the tech innovation is and yet how bad the UX is 😄
Peak ux:Peak ux:
https://imgprxy.stacker.news/pS_R9O_eTjB6vZbJOEHAy_pO2ktbzHyHHV5DjVpFaTY/rs:fit:600:500:0/g:no/aHR0cHM6Ly93d3cuZW5lcmd5c3Rhci5nb3Yvc2l0ZXMvZGVmYXVsdC9maWxlcy9hc3NldHMvaW1hZ2VzL3dpbjIwMDBfcG93ZXJfb3B0aW9ucy5qcGc
Hi, I tried settling over lightning and it came up with "Oh no, we couldn't find a route to you! Consider using the base layer to settle or try again later." ...
Sounds like you know what to do next 👍
I generated an invoice with the amount (after fee), is that correct?
the invoice also needs a custom preimage matching the one in the second tan box thingy...currently only LND lets you create an invoice with a custom preimage but blixt is looking to add support
ping your favorite wallet and ask them to support it too!
Great job Super!
Love it!
I got the LN address... but both wallets I tried using to send me some sats give me a LNURL error. south_korea_ln@zaplocker.com is the address.
Ok I think I fixed the lnurl error
The server was hanging because before giving out an invoice it queries mempool.space for the latest feerates and uses those to calculate minimum "receive" amounts
But I got rate-limited by mempool.space (I think) for querying for feerates too often
I changed the logic so it only queries them a maximum of once every 10 seconds
Try again and let me know if you encounter any other bugs
Thanks for response.
It still hanging though... tried sending from SN and Alby this time.
working on it
#235914
awesome, zaplocker hold the payments and notify users to get them within 16 hours.
Based!
Awesome.
would u like a logo?
Sure, thanks!
https://imgprxy.stacker.news/ayhsjy9_iV8lrUUs7QihQP-wLHHl8Iecz04yyPbebDA/rs:fit:600:500:0/g:no/aHR0cHM6Ly9tLnByaW1hbC5uZXQvSEp1YS5wbmc
first idea
This is really great, thank you! I added it to my github: https://github.com/supertestnet/zaplocker
here it is in SVG https://we.tl/t-M8sz8QFTlF
Yo, this is nice. Tried zapping myself, though no notification as yet: sime@zaplocker.com
Hmm...did you at least receive the zap?
No, and Phoenix shows it as pending still.
ok I found your payment and canceled the hodl invoice so you should have your money back (technically it never actually left your wallet)
not sure what went wrong though so I am investigating
I can tell this immediately: the payment was not in your "pending record", and notifications only go out when the database sees that you have something in your pending record
I don't know why the software detected your payment but did not enter it into your pending record (or maybe it did but somehow the record got deleted)
Same again, second time round.
working on it
#235914
And yet another banger from supertestnet
amazing - will dig into the code.
Join me on Athena network to create a group for mining.
https://athene.network/
https://m.stacker.news/19536
deleted by author