Lightning Address would you use it with a domain you don't control?

[DaveF]

Since it was brought up in another post.

For those of you that don't know lightning address is a protocol that sits on top of the lightning network /  LNURL and allows people to send lightning funds to you using just and email address:

From here: https://github.com/andrerfneves/lightning-address/blob/master/README.md



The issue is that if you do not control the DNS and web server that the domain is connected to the person who does can put whatever they want in the lnurl and take your money.
There are a lot of hosted wallets that allow you to have their address as a way to accept funds. mrdave@bitrefill.me will put money into my bitrefill balance luridbank39@walletofsatoshi.com would put funds in my phone wallet, and so on.

BUT, if you don't tell me you sent the funds and they take the money unless you tell me I'll never know you sent them.

Don't get me wrong I use it, I have 1 address that I run myself in addition to those 2. BUT, if say someone sent me a tip and didn't tell me and walletofsatoshi.com was taking it [NOTE I DON'T THINK THEY WOULD JUST USING THEM AS AN EXAMPLE] they could skim a lot and get away with it. And if someone does say something, 'oops it's in beta our bad, here is your money'

I was going to offer one of my lightning domains for people to use but then I thought of this and am now thinking about the pitfalls of it.

-Dave

[1713485642]

1713485642

[1713485642]

1713485642

[1713485642]

1713485642

[1713485642]

1713485642

[1713485642]

1713485642

[1713485642]

1713485642

[odolvlobo]

Requiring the server to provide a signature by the owner of the address might be a solution, though that might defeat the purpose of having a Lightning address.

[BlackHatCoiner]

Note that you have to trust both the DNS server and the web hosting server for not compromising the address, unless you port forward it from home. What's the problem with keysend? Isn't it a "Lightning Address" in the end?

Requiring the server to provide a signature by the owner of the address might be a solution, though that might defeat the purpose of having a Lightning address.

It does. The idea is to get the necessary payment information by just a GET request. Signature verification requires possession of the node's public key, which if provided in that request, can be altered by the attacker altogether.

[DaveF]

Note that you have to trust both the DNS server and the web hosting server for not compromising the address, unless you port forward it from home. What's the problem with keysend? Isn't it a "Lightning Address" in the end?

No problem with keysend, but with more and more wallets and services allowing you to send / receive lightning payments with email I was just thinking if anyone else saw the security risk.
For small amounts it probably does not matter one way or another, but as a service or once larger amounts of money are involved I can see it being an issue.

"just send it to my email" works with PayPal, Zelle, and tons of other services. Having it for lightning is good, but having someplace go evil and steal funds is bad.....

-Dave

[n0nce]

I agree, your concern makes sense. I wouldn't use Lightning addresses with domains I don't control, and in general never had the need for it anyway.
So far, regular invoices, offers and keysend, served me well.

[NotATether]

There is a kind of attack designed to redirect DNS requests to a different domain by attacking a layer of the protocol called BFG, that is responsible for the actual routing. So no. If LN becomes popular, we will see a sharp increase in this kind of attack, on services which host LNurls.

[n0nce]

There is a kind of attack designed to redirect DNS requests to a different domain by attacking a layer of the protocol called BFG, that is responsible for the actual routing. So no. If LN becomes popular, we will see a sharp increase in this kind of attack, on services which host LNurls.

Do you mean BGP hijacking? https://en.wikipedia.org/wiki/Border_Gateway_Protocol
I'd be much more concerned with privacy / security breaches by the actual company hosting the (legitimate) servers instead of someone trying to build a costly BGP attack, just to steal a few relatively small Lightning transactions.

Small in terms of: the amounts of money that could make the attack worthwhile, aren't / shouldn't be moved through Lightning and especially not through third-party-hosted Lightning addresses.

[NotATether]

There is a kind of attack designed to redirect DNS requests to a different domain by attacking a layer of the protocol called BFG, that is responsible for the actual routing. So no. If LN becomes popular, we will see a sharp increase in this kind of attack, on services which host LNurls.

Do you mean BGP hijacking? https://en.wikipedia.org/wiki/Border_Gateway_Protocol

Yes, thank you.

I'd be much more concerned with privacy / security breaches by the actual company hosting the (legitimate) servers instead of someone trying to build a costly BGP attack, just to steal a few relatively small Lightning transactions.

Small in terms of: the amounts of money that could make the attack worthwhile, aren't / shouldn't be moved through Lightning and especially not through third-party-hosted Lightning addresses.

The thing those is that you're not just robbing one address, you are robbing many different payments at the same time. So financially speaking, it will be very costly to the platform as people will dump their service once they realize someone is defrauding them. So the financial damage is almost as significant, in terms of percentages., as exchange hacks.

[n0nce]

So the financial damage is almost as significant, in terms of percentages., as exchange hacks.

That's a good point, I hadn't thought of it this way. Targeting a whole service instead of a single user, does make it similar to an exchange hack and potentially highly profitable.

It's interesting that you can even steal TLS certificates, so those won't help either:
https://www.princeton.edu/~pmittal/publications/bgp-tls-hotpets17

[DaveF]

The other issue I could see cropping up is as it becomes more popular is targeted attacks. Someone posting davef@bitc0intalk.org and things like that.

I am still thinking there has to be a way for me to offer up a service that does this that does not allow me to run with your funds. I'm not going to mind you, just more worried about the potential of other people doing it.

There is a kind of attack designed to redirect DNS requests to a different domain by attacking a layer of the protocol called BFG, that is responsible for the actual routing. So no. If LN becomes popular, we will see a sharp increase in this kind of attack, on services which host LNurls.

There are 2 things, 1 is the BGP as discussed before and also there are ways to attack DNS ( dns-poisoning )also:
https://www.okta.com/identity-101/dns-poisoning/

So it's all anarchy out there :-)

-Dave

[mailsats]

OK, I am a bit new to this stuff, so I am not sure if I fully understand the problem...

it seems to me that is someone's Lightning address ( public key ) is being sent to a server ( host of domain and node being used for the Lightning address ) then the owner of the domain / node can change a received ln-address, then change the ln-url that is contained within the address to his own.

so would it help then, when the transaction is en-route to the node ( ln address domain ) it is intercepted by something like " Lightning Box "

My understanding is that Lightning Box is an inbox that would capture a transaction, store it in an inbox, and alert the user of incoming transaction....
I assume this would happen befor the owner of the ln address domain could alter the lnurl....
https://github.com/hsjoberg/lightning-box

Lightning Box is in a very early stage, not much is finished yet.

Work In Progress, not suited for production just yet. Contributions, suggestions and ideas are appreciated. Database schema and configuration are bound to change.

Lightning Box is a payment inbox for Lightning Addresses. It's mainly suited for non-custodial Lightning wallets that might not always be online to receive payments.

Lightning Box will take the payment on behalf of the wallet and then notify the user about the payment via a communication medium (Email, Telegram, Push notification...). The user is then supposed to start their wallet to withdraw.

By utilizing the widely adopted protocols LNURL-auth and LNURL-withdraw, any supporting Lightning Wallet can use Lightning Box. Wallets that also support LNURL-withdraw's balanceCheck can keep the Lightning Box as known service inside the wallet and easily withdraw from the box without leaving the wallet.

[DaveF]

OK, I am a bit new to this stuff, so I am not sure if I fully understand the problem...

it seems to me that is someone's Lightning address ( public key ) is being sent to a server ( host of domain and node being used for the Lightning address ) then the owner of the domain / node can change a received ln-address, then change the ln-url that is contained within the address to his own.

so would it help then, when the transaction is en-route to the node ( ln address domain ) it is intercepted by something like " Lightning Box "

My understanding is that Lightning Box is an inbox that would capture a transaction, store it in an inbox, and alert the user of incoming transaction....
I assume this would happen befor the owner of the ln address domain could alter the lnurl....
https://github.com/hsjoberg/lightning-box

Lightning Box is in a very early stage, not much is finished yet.

Work In Progress, not suited for production just yet. Contributions, suggestions and ideas are appreciated. Database schema and configuration are bound to change.

Lightning Box is a payment inbox for Lightning Addresses. It's mainly suited for non-custodial Lightning wallets that might not always be online to receive payments.

Lightning Box will take the payment on behalf of the wallet and then notify the user about the payment via a communication medium (Email, Telegram, Push notification...). The user is then supposed to start their wallet to withdraw.

By utilizing the widely adopted protocols LNURL-auth and LNURL-withdraw, any supporting Lightning Wallet can use Lightning Box. Wallets that also support LNURL-withdraw's balanceCheck can keep the Lightning Box as known service inside the wallet and easily withdraw from the box without leaving the wallet.

2 separate things here.

What I posted about was the fact that with a Lightning Address i.e. something like davef@bitcointalk.org.

All that points to is LNURL string at https://bitcointalk.org/.well-known/lnurlp/davef

So at that point whoever controls bitcointalk.org can put in whatever information they want. So even if you are using your own self custody setup if you are doing this with a domain you do not control there is always the possibility of theft.

What you posted about is an intermediary service that allows you to not have to have your node on and accessible all the time.
To me, it looks like yet another answer in search of a question. If you are running something like a LN node it should be online all the time.

-Dave

[mailsats]

so when a new transaction ( using a lightning address ) is sent, this new transaction and its details would have to be written to a blockchain ( the blockchain? ) so it could not be altered

[garlonicon]

would you use it with a domain you don't control?

This is the classical problem of public keys: if you cannot share your public key in a safe way, then you cannot trust public key cryptography at all. Because no matter if this is your PGP key, your Bitcoin public key wrapped in any address type, or another kind of public key, the same thing is strictly required: sharing public keys in a safe way.

The same is true for classical PGP keys with e-mail addresses: if you have your mailbox on some server, and if you have your public key posted in some keybase, what if those entries will be manipulated? You cannot stop mailbox provider from sending fake e-mails that will be poorly verified by inexperienced users. And you cannot stop keybase maintainer from sending fake PGP key, fully controlled by them, if the end user will not double-check that a keybase is no longer trusted.

I am still thinking there has to be a way for me to offer up a service that does this that does not allow me to run with your funds.

There is a way, but you probably won't like it.

1. You can wrap your public key in your e-mail. For example, in Tor, there are those long names with 56 characters. You can also use shorter names, and introduce any kind of hashing, like it was with SHA-1 truncated to 80-bit for old names with 16 characters, then the size of the name is determined by the hashrate of the attacker.
2. Using any NameCoin-like solution will work. Blockchain-based names will be bulletproof, but then, your users will have to download and verify the full list of all names (or use a third party to do that, and then it will bring us back to the starting point).
3. Your server could be a proxy for Silent payments. Then, sharing a single public key is needed, and your service could be used for scanning addresses, and providing any kind of SPV proofs for users. Then, you can only leak connections between addresses, but you cannot change them, if you cannot control them, and if you only know about "the current thing to find on the blockchain".
4. User-based puzzles will also work. For example, if your user knows that "SHA-256(pubkey||secret)" starts with N number of zero bits, and you don't know the "secret", then you cannot generate a fake address (because it would be as suspicious as brute-forcing someone's PIN). And then, users can safely share that "secret" and "algorithm" combination, that can be shorter than "pubkey". It is the same as salted passwords: if sharing the full public key by sharing 56 characters like in onion addresses is too much, then sharing a shorter "secret" is possible.

[DaveF]

would you use it with a domain you don't control?

This is the classical problem of public keys: if you cannot share your public key in a safe way, then you cannot trust public key cryptography at all. Because no matter if this is your PGP key, your Bitcoin public key wrapped in any address type, or another kind of public key, the same thing is strictly required: sharing public keys in a safe way.

The same is true for classical PGP keys with e-mail addresses: if you have your mailbox on some server, and if you have your public key posted in some keybase, what if those entries will be manipulated? You cannot stop mailbox provider from sending fake e-mails that will be poorly verified by inexperienced users. And you cannot stop keybase maintainer from sending fake PGP key, fully controlled by them, if the end user will not double-check that a keybase is no longer trusted.

I am still thinking there has to be a way for me to offer up a service that does this that does not allow me to run with your funds.

There is a way, but you probably won't like it.

1. You can wrap your public key in your e-mail. For example, in Tor, there are those long names with 56 characters. You can also use shorter names, and introduce any kind of hashing, like it was with SHA-1 truncated to 80-bit for old names with 16 characters, then the size of the name is determined by the hashrate of the attacker.
2. Using any NameCoin-like solution will work. Blockchain-based names will be bulletproof, but then, your users will have to download and verify the full list of all names (or use a third party to do that, and then it will bring us back to the starting point).
3. Your server could be a proxy for Silent payments. Then, sharing a single public key is needed, and your service could be used for scanning addresses, and providing any kind of SPV proofs for users. Then, you can only leak connections between addresses, but you cannot change them, if you cannot control them, and if you only know about "the current thing to find on the blockchain".
4. User-based puzzles will also work. For example, if your user knows that "SHA-256(pubkey||secret)" starts with N number of zero bits, and you don't know the "secret", then you cannot generate a fake address (because it would be as suspicious as brute-forcing someone's PIN). And then, users can safely share that "secret" and "algorithm" combination, that can be shorter than "pubkey". It is the same as salted passwords: if sharing the full public key by sharing 56 characters like in onion addresses is too much, then sharing a shorter "secret" is possible.

But all of those add a shit ton of complexity. It would have to be something that is transparent for the user and simple (for people who might not understand how everything works) to verify.

As I said it was just an idea I was kicking around. Since in the end you would have to trust the person running the domain and the web-server I do not see a simple way of making sure the LNRUL is actually the one that should be there without adding a way for people to check it, which in theory means trusting someone else not to be in cahoots with the person running the service. Gets back to not your keys -not your coins. But it's not your domain - not your email.

-Dave