but why do we need to onboard these normies ?

let them discover nostr organicaly, don't force them.

do we really need all people on nostr?

I never used twatter, instashit and fbibook, but I joined to nostr because of bitcoiners.

I do not see nostr as a bitcoin onboarding tool. And I do not see nostr as a social media. Is more like a protocol to add more features for bitcoin. See NWC, nostr market, private DMs etc. Here is the power of nostr.

Posting memes and videos is only as "imported" feature to have fun.

A new user if it doesn't know about bitcoin, nostr will be just another twatter. Do we really want nostr to be just another twatter?

I consider nostr more for bitcoiners that know what are they doing.

All the rest... fuck'em, I don't give a shit about NPCs.

That would require clients to send view events for every viewed note, and for clients to count the view events for every note it displays to the user. I think that's how reactions work, just would be more of them.

New market for bot views would open. Zaps for views.

I got a bit confused. Also, answering your question, I mixed up a bit by indicating the wrong type of error. But generally, when a payment cannot be sent further because, for example, we don't have enough balance on our side to send it further, an onion is also sent, which indicates a temporary error code, and the onion is also sent back to the sender. From it, they can see which node along the way sent it, so they don't send the same-sized payment through the same channel again.

Actually, I was talking in the context that instead of specifically regulating fees in channels that are drained, you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity. And if there is still enough liquidity to make the payment, even if it's small, let such a payment go through at a fixed rate that was there at any balance of our channel. I hope I expressed myself more clearly.

I got a bit confused. Also, answering your question, I mixed up a bit by indicating the wrong type of error. But generally, when a payment cannot be sent further because, for example, we don't have enough balance on our side to send it further, an onion is also sent, which indicates a temporary error code, and the onion is also sent back to the sender. From it, they can see which node along the way sent it, so they don't send the same-sized payment through the same channel again.

Actually, I was talking in the context that instead of specifically regulating fees in channels that are drained, you can just rely on such packets to be sent to the sender if the payment cannot go through due to insufficient liquidity. And if there is still enough liquidity to make the payment, even if it's small, let such a payment go through at a fixed rate that was there at any balance of our channel. I hope I expressed myself more clearly.

I might be wrong, but it seems to me that channel balancing through fees has some significant downsides. Let me try to explain them.

I personally witnessed a situation where I tried to make a payment from a mobile wallet and couldn't do it. The route went through my nodes. I started checking the logs and found that when the wallet sent the payment, it used fee parameters that were in the network graph several hours earlier. They were later changed to higher ones as liquidity decreased. At that time, I had an algorithm where if my channel's liquidity got depleted, the price would increase. For this reason, the payment couldn't go further. The sender's wallet used a lower fee because it saw that in the network graph, which didn't relay fresh data well due to the protocol's significant delay. Theoretically, when a payment doesn't go through due to fees, the intermediate node where it fails forms a response and sends new fees in that response. Upon receiving such a packet, the sender's wallet should, in theory, adjust the fees and resend it. Then, the payment would go through. But this doesn't always happen. It may be a bug in the system implementation or other reasons I can't fully understand. But at that time, I concluded that if I had fixed fees, that payment case would've succeeded, as the liquidity still allowed it.

Then it occurred to me that balancing channels based on such a scheme—setting low fees when you have a lot of liquidity and high fees when it depletes—creates a sort of logical contradiction. When you could earn from fees with your bitcoins locked on your side, with this algorithm, you earn very little while your bitcoins are locked and available. When the channel depletes and you have fewer locked bitcoins, you need to increase the fee. This makes it unlikely that you'll earn more than when you had funds in the channel. It all seemed somewhat illogical. Therefore, I thought it would be better to just set a fixed fee. After all, when the channel depletes, adjusting fees only signals to future senders that we can't process a large payment through this channel. We financially discourage them from sending through us. But there are other ways to avoid losing profit (since higher fees often encourage senders not to use your channel at all). For example, if we lack funds in a channel and someone tries to send through it, our Lightning Network server would simply send a packet to the sender indicating that funds can't be sent through this channel temporarily.

nostr:nprofile1qqsyv47lazt9h6ycp2fsw270khje5egjgsrdkrupjg27u796g7f5k0spzdmhxue69uhhwmm59e6hg7r09ehkuef0z22eq8 nostr:nprofile1qqszm52qe2qdkc4u7dma0klx3532jka2g8geck6fwxncyp90wktq2xspzdmhxue69uhhwmm59e6hg7r09ehkuef0j3fwkf

Hello buddies, I got albyhub connected to bitvora with nwc, everything works except listing transactions, can anyone help me troubleshoot please? I need some debug logs why albyhub doesn't like the txns list I return

Most of the things that make bitcoin interesting in the early days were unsavory.

Buzzbot is a great example of hacker mentality

Apparently AI works because you can add and subtract words. day - light + dark = night​

If briefly, a year ago I was adjusting fees step-by-step from zero to about a thousand ppm and recorded in a spreadsheet how much the Lightning network was generating per day. After reaching a thousand ppm, I reduced the fees again step-by-step and continued recording. I ended up with a fairly large spreadsheet. The fees fluctuated daily, of course, but when I looked at which fees were generating the most satoshis per day, 700 ppm seemed to yield more on average than others. Not long ago, I tried feeding this spreadsheet to ChatGPT, and based on its analysis, it suggested using about 1185 ppm to maximize profit. I tried that, but it turned out not to be the best option. A few days ago, I decided to set it back to 700 ppm, as I did about a year ago, and again, this number proved very close to generating the most daily commission revenue. So I settled on that figure.

I used to use a fee-balancing method, but then decided to abandon it. I'll look for where I might have written about it. Once I find it, I'll send you the link.

I was unaware zap time could be measured. This is insightful, thanks. Is that a hardware issue, or internet speed issue?

Is running a cloud based node custodial?

What is everyone using for iOS development?

So because of the state i live in this is what they offer me. 6k minimum is ok. I still haven't used it though. I wish the minimum was lower

There is more, you can deposit and earn

I made an account with them. Because I'm looking for Bitcoin backloans as well. And they gave me the option to deposit and get interest on it. I was accepted for for the loans. But, the limit is too high for me.