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.

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

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.

Yes, thank you.


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.

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 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

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

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.

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.