This is just a concept; an idea I got while taking a shower. Unfortunately, I don't have the technical/coding skills to implement this. What led to my idea was whatsat - an app which enables users to chat using the LN itself.
Motivation
It`s easy to send btc on-chain to someone. You just need their address and nothing more. You can send to it as many times as you want. This hurts privacy, but makes everything really easy for the sender. A charity can simply put their Bitcoin address on their website for example and anyone could donate to them. It`s not the same for Lightning. Since a different invoice is required for every single payment, a youtuber would not be able to accept donations over the LN easily, just on-chain. The goal of this proposal is to make it possible to do both.
The Concept
Since any message can be routed and sent through the LN we could also make a request and ask our recipient`s node to generate an invoice for an amount chosen by us and then send it to us, just like those text messages. Then we can decode this invoice and if everyone is OK (the amount is correct) we can attempt to pay it. All of this can happen under the hood. The UI/UX doesn't even need to change much. Instead of pasting an invoice in the "send" field of a wallet, we just paste a node's public key.
DoS Protection
Allowing anyone to make our node generate invoices is a bad idea. They could send a million requests and crash it. To prevent denial-of-service attacks, we should implement the following measures:
- Auto-Generated invoices should be with short expiration times. 10 minutes for example.
- A maximum of X invoices can be generated for a given node at a time. Let`s say X = 10. Once a node has requested 10 invoices it can request another one only when a) at least one of the previous 10 invoices has been paid or b) at least one of the previous invoices has expired.
- Nodes which have requested Y invoices, but haven't paid any of them could be banned from requesting new invoices for a day. If this behaviour continues the node could be permanently banned and any channels opened with it could be closed. Maybe an option to manually override this ban would be nice to have. A good value for Y might be 30.
- Nodes which have no channels open should not be allowed to request invoices. This prevents an attacker from spinning up 1000 nodes and requesting 10000 invoices from us.
Summary and Final Thoughts
The idea is to be able to send bitcoins over the Lightning Network to a static node`s public key, instead of having to ask for an invoice each time. The LN itself could be used to route requests for new invoices and the answers to those requests between the sender's and the recipient's nodes. The recipient`s node still needs to be online though. Maybe if we combine this with something like Lightning Rod we could achieve the same experience as with on-chain Bitcoin payments.
It`s also worth mentioning that one would not be able to do this for every node. Older nodes which have not upgraded to newer software which supports this new protocol addition simply won't know what to do when they get such a request and they won't reply with an invoice. If we want consistency we need everyone to upgrade. Or the vast majority at least.
I imagine it would not be that hard to implement something like this. The most difficult part would probably be the DoS-Protection logic. The creator of "Whatsat" already has the base for my idea implemented and it works.
This whole idea makes me think if it`s also possible to do the same on the base Bitcoin protocol and ask nodes for new addresses for each transaction. That would eliminate address reuse almost entirely and greatly increase the overall privacy. Onion routing should be used there too though and that`s another topic to discuss.
So what do you think? What are your concerns, recommendations, improvements, etc? Share your opinion. Let's make Bitcoin better!
submitted by
/u/Kalin101
[link] [comments]