Avatar
Bee Aye
524314bfcee6e82f86973ca054d2452a0cfd8a437e9feb9bb39403a5d1e30e55
Trying out nostr with no follows. just DVMs and client feeds.

sure, as long as you had multiple account creation codes with alby. another option: you can make multiple Stacker.News accounts, and attach the one getalby lnaddress as a receiving address to those various Stacker.News account and thus giving you several ln addresses that all send sats to your node.

its a good question, and i think the answer lies in when you add dollars to coinbase, there is like10 days seasoning before you can withdraw it back out. so if you swap into usdc instead of withdrawing, you dont have to wait for it to season in your bank, then deposit it back into coinbase. its a tool for people that trade shitcoins within an exchange like Coinbase's ecosystem that dont want to deal with delays relating to pegging in and out of fiat.

Replying to Avatar Ivan

if ur albyhub service has restarted on say start9, you gotta reinput the password before send / receive will work again.

this i agree with. its insulting imo to even do it if you can already make this happen with existing editable fields. look, i replicated this new 'feature' by updating my pronouns in my display name instead. i think if its believed to be important, Vitor should show some conviction or not even bother. this all seems lame, thoughtless, and will just piss off people that dont like it, and not add functionality that actually satisfies people that would use it! In an attempt to like head off such controversy, he might have just made even more...

few

sats that is, a few sats

Replying to Avatar Rusty Russell

It is important to empathize with frustrated users. It's sometimes an unattainable ideal, but who hasn't hit software that Just Doesn't Work? We don't really care if it's just something about our setup, or fundamentally broken, or a completely unhelpful error message: it's an incredibly frustrating feeling of impotence.

Sure, you shouldn't take it out on the devs you aren't paying, but we're all human.

I can't speak for all developers, but I became a FOSS coder in the Linux Kernel. That gave me a pretty thick skin: Linus could be an ass, and even when he was wrong there was no appeal. So I generally find it easier to sift through the users' frustrations and try to get to the problem they are having.

https://github.com/ElementsProject/lightning/issues/7180

And often it turns out, I agree! This shit should just Work Better!

CLN payments are the example here, and it was never my priority. That might seem weird, but the first production CLN node was the Blockstream store. So we're good at *receiving* payments! But the method of routing and actually making payments is neither spec-defined nor a way to lose money. It's also hard to measure success properly, since it depends on the vagaries of the network at the time

But it's important, turns out :). And now we see it first-hand since we host nodes at Greenlight. So this release, unlike most, was "get a new pay system in place" (hence we will miss our release date, for the first time since we switched to date-based releases). Here's a list of what we did:

1. I was Release Captain. I was next in the rotation anyway, but since this was going to be a weird release I wanted to take responsibility.

2. I wrote a compressor for the current topology snapshot. This lets us check a "known" realistic data set into the repo for CI.

3. I wrote a fake channel daemon, which uses the decompressed topology to simulate the entire network.

4. I pulled the min-cost-flow solver out of renepay into its own general plugin, "askrene". This lets anyone access it, lets @lagrange further enhance it, and makes it easier for custom pay plugins to exist: Michael of Boltz showed how important this is with mpay.

5. A new interface for sending HTLCs, which mirrors the path of payments coming from other nodes. In particular, this handles self-pay (including payments where part is self-pay and part remote!) and blinded path entry natively, just like any other payment.

6. Enhancements and cleanups to our "libplugin" library for built-in plugins, to avoid nasty hacks pay has to do.

7. Finally, a new "xpay" command and plug-in. After all the other work, this was fairly simple. In particular, I chose not to be bound to the current pay API, which is a bit painful in the short term.

8. nostr:nprofile1qqsx533y9axh8s2wz9xetcfnvsultwg339t3mkwz6nayrrdsrr9caagppemhxue69uhkummn9ekx7mp0fqcrlc changed our gossip code to be more aggressive: you can't route if you can't see the network well!

Importantly, I haven't closed this issue: we need to see how this works in the Real World! Engineers always love rewriting, but it can actually make things worse as lessons are lost, and workarounds people were using before stop being effective.

But after this fairly Herculean effort, I'm going to need to switch to other things for a while. There are always other things to work on!

love to see it as a CLN node runner 🤙