Amboss is not, but Thunderhub is client-side on your node, and it should know whether it was able to unlock the HTLC with the preimage it got from Amboss, right?

Interesting... feature? of ghost addresses right now is, you can send sats to someone using one, and unless they are actively tracking the balance in their node's wallet, they will have no idea that they received anything.

It's like Secret Santa with sats. Perfect for Christmas.

itchy-amber-koi@ghst.to

itchy-amber-koi@ghst.to

Had my nostrplebs address pointing to it for a bit to try it out.

H/T to nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424 and nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj for making it easy to switch the wallet your nip-05 is pointing to on the fly and not have to worry about folks zapping an old wallet.

We're natural procrastinators, so it works for us.

The tradition we have is wrapping them all on the night of Christmas Eve.

Nah. Just a holiday respite.

LOTS of UTXO consolidation in the mempools right now. It's a beautiful thing!

A bit more context on what is happening. The ghost address generates an invoice that tells the sender to route the payment to a fake node that doesn't exist, with your node as the last hop along the way. When your node gets the HTLC instructing it to forward the payment to a node that it has no channels with, it reaches out to Amboss to see if they have a preimage to unlock the HTLC so your node can keep the sats.

Since your node did not appear to be the destination in the HTLC, the payment is not recorded in your transaction history whatsoever, but your available balance increases.

As I understand it, Amboss is only contacted by my node to get the preimage when it sees that the next hop it is supposed to forward a payment to is not a real node at all. Since all other transactions routed through my node will presumably involve real nodes that I have channels open to, my node will not reach out to Amboss for any other transactions it routes.

Of course, since Thunderhub is open source, you can go audit the ~40 lines of code they added to implement the service on the node's side of things: https://github.com/apotdevin/thunderhub/compare/v0.13.27...v0.13.28

If my understanding is correct, then they will be able to see the payments your node that are routed using your ghost address, but nothing else. Which would mean that it's still a massive improvement over using custodial Lightning, where ALL of your transaction information is exposed to the custodian, and they hold your keys, so they can rug you at any time. By contrast, Amboss only sees those payments I receive through the ghost address, NONE of my outgoing transactions, and most importantly does not hold my keys.

No. It doesn't appear that your node knows what it is at all, so it doesn't show up in your transaction history whatsoever, as fees paid or otherwise.

From what I understand, when your node sees the payment, it acts as if it is just one hop along the way to route the payment to another destination until it is told by Amboss, "Yeah, about that.. You are actually the destination. Go ahead and keep those sats without forwarding them." That's in the least technical terms possible, mostly because I don't know the technical terms. 🤣

It does not scale to every individual being able to run their own lightning node. But I don't think that is how lightning will be used. I think it will be larger businesses and eCash mints, or something similar, using lightning as their interoperability layer.

Lightning channels. Time to get the node set up with some liquidity!

Uh... Been using my node with Zeus over Tailscale for a couple years now and never thought of setting up a local and tor profile for when those would be more appropriate... Thank you!

I must say, nostr:npub19tcpurtt6xulhw0r6sc404j9jraj0h8me2lzs7z2tqewz7l0hpas59nlea's ghost addresses are REALLY slick and easy to set up!

Now we just need to be able to see the deposits in our wallet, rather than just the balance changing without an indication of why. I think that requires LND to update something so they show up in the transaction history, though.

Oh, and NIP-57 support would be fantastic, since my main use-case would be receiving zaps straight to self-custody, and I am sure I am not alone in that.

Either way, GREAT WORK!

Time to go play! Thank you nostr:npub19tcpurtt6xulhw0r6sc404j9jraj0h8me2lzs7z2tqewz7l0hpas59nlea !

Oh, I get that. More Bitcoin that can't be spent just means it is more scarce. It ultimately doesn't hurt Bitcoin.

Yes, but what you are talking about is organic, as a result of people who don't know better failing to manage their UTXOs. The above constitutes the intentional acceleration of this process via bloating the UTXO set with thousands and thousands of dust UTXOs a day, because they have JPEGs or shitcoin tokens attached to them.

This update coming to Umbrel or Start9 soon?

nostr:npub1m0n0nautpnk0jntmg89kgjucfwygrsppcpf963um5eqkjehqwess7rd0un explained what was going on here over on the former bird app: https://twitter.com/mononautical/status/1737960825954898198

And yes, it's BRC20 BS.

Can someone explain to me what is going on here?

https://mempool.space/tx/e571d064b6960b71801e7f3beb04cef36677d4e816ea1397f6f39da43c90749a

Noticed this massive transaction with only one input and 500 outputs of 500 sats each. Yes, 500 new UTXOs and ONLY 500 sats in each of them, so they are all dust.

Moreover, the total of these outputs was only 250k sats, but the fee paid was 7.2m sats!!

Is this some BRC20 nonsense, or something?

#asknostr