Offer Bitcoin payments over lightning network

[anon443 6]

Hi there,

I really love your service and will renew with the next big sale event. 
Being able to pay with crypto currencies is a must in the industry nowadays I find. 
I am glad you accept a variety of different currencies, especially Monero. 
Bitcoin payments are oftentimes prohibitively expensive due to high mining fees to get into the next block. Also they can take a long time if the mempool is overflowing with unprocessed transactions. 
It would be great if you could also accept payments over the lightning network which makes transactions instant and final for you, basically free for me to send and my service can be instantly activated instead of having to wait a certain amount for blocks to be mined. 
Integrating lightning payments is easy, free and secure. And even comes with some privacy improvements over regular Bitcoin transactions, so that nobody knows who paid you. 
please consider adding lightning support to make paying with Bitcoin cheaper, faster and more private while also reducing the load on the main blockchain. 
Resources like BTCpay Server make it easy to accept lightning payments along regular on-chain transactions all without a third party. 

Thank you so much, I am looking forward to opening a channel to you ! ☺️

[NigelMansell 3]

...so, 3 years later and we don't have any info.

1. More people are using/holding Bitcoin than other cryptocurrencies
2. Possible big exchange rate increases in the coming months will mean that paying onchain fees for $15 - $90 subscriptions to AirVPN will not make alot of sense
3. If onchain fees increase alot too, and the BTC rate stays high relative to EUR/USD, the effect of point 2 will be even greater

only low onchain fees make it possible to use BTC at AirVPN, even now really (current USD/BTC rate is $90,000).

I would understand if AirVPN have different priorities, VPN is perhaps not the easiest business to be in sometimes (from what it sound like to me). But I'd feel a little sad for the situation to become so difficult that I would cancel after many years of being with Air.

Yes, I know, "but Litecoin", to which I reply "but I have to send at least one BTC transaction or Lightning transaction to buy LTC, and cover the exchange's onchain fees on the Litecoin network, AND pay them a small percentage". The "but Litecoin" argument belongs back in the year 2013, Litecoin is not and never was as successful as Lightning network.

 

forgot to mention:

If you know that low value Lightning transactions in times of high onchain fees are a problem, then yes, it's an issue.

In April, Bitcoin Core version 29 will make a new type of script output standard to relay on the network. This will allow zero fee channel updates, but only if they include one of these new output types in the transaction.

The lightning network channel operators should begin to upgrade to the new style of channel after April (it's necessary first for the Bitcoin onchain network to upgrade to 29.0 in large numbers to ensure the new transaction type used by these new channels will be reliably relayed across the network)

Simply, the high onchain fees (and the 1% channel minimum) problem will go away sometime during next year (the work to do all this has been ongoing for several years)

 

  On 9/29/2021 at 9:53 AM, anon443 said:

basically free for me to send and my service can be instantly activated

this is also an important point: I make sure I have an hour to spare when I pay AirVPN onchain. Why? because the transaction might not get into a block before the timer counts down past an hour, and I would then need to 'cancel' that transaction, by paying extra fees to send the money back to my self instead. This never happened to me, half by luck, and the other half choosing a time when the miners seem to be mining the blocks quickly. So I do some quite careful planning to pay onchain!

None of that is necessary over lightning, the tx pays in seconds, or not at all.

I disagree that it would be easy to setup as a business. As a user, the mobile wallet apps are now much improved. But to receive money over lightning as a business needs more management + tech knowledge than receiving onchain transactions. But I think a time will come in the future (and maybe as soon as 2025) when receiving these ~ $50 transactions as onchain BTC will be unviable.

[Staff 10116]

  On 11/17/2024 at 7:44 AM, NigelMansell said:

I make sure I have an hour to spare when I pay AirVPN onchain. Why? because the transaction might not get into a block before the timer counts down past an hour, and I would then need to 'cancel' that transaction, by paying extra fees to send the money back to my self instead.

Hello!

This is totally unnecessary. If your transaction doesn't have any confirmation within one hour, it will be accepted whenever it is confirmed and the system will activate automatically your account plan. If something goes wrong contact the support team, no need to "cancel" the transaction, whatever you mean.
 

  Quote

..so, 3 years later and we don't have any info.

The concerns about LN have not been resolved in the last 3 years and therefore we are very cautious about it. The significant enlargement of the attack surface, the centralization problem (hub and spoke model), the closed-channel fraud issues, the betrayal of the custodial system, and a few other problems must all be considered carefully.

Kind regards
 

[NigelMansell 3]

  On 11/17/2024 at 3:37 PM, Staff said:

If your transaction doesn't have any confirmation within one hour, it will be accepted whenever it is confirmed and the system will activate automatically your account plan. If something goes wrong contact the support team, no need to "cancel" the transaction, whatever you mean.

ok, it's not clear to me why the timer exists. I assumed it is to protect AirVPN from any big changes in the market price before confirmation.

By 'cancel', I'm simplifying the trick of using fee-replacement to return one's money entirely to the change address. Doing this means writing the transaction using the cli interface, with Bitcoin Core. maybe other wallets allow it to be done with the gui, don't know the answer to that.
 

  On 11/17/2024 at 3:37 PM, Staff said:

The concerns about LN have not been resolved in the last 3 years and therefore we are very cautious about it. The significant enlargement of the attack surface, the centralization problem (hub and spoke model), the closed-channel fraud issues, the betrayal of the custodial system, and a few other problems must all be considered carefully.

I understand what you mean with the attack surface enlargement, it definitely changes (increases) the risks

Centralization argument makes no sense. There is no magic to improve the carrying capacity of blockchain tech, small percentage gains can be made, but once it begins to attract users, order of magnitude improvements aren't possible without somehow using the scripting system to create different network layers using a different protocol. Any of the other cryptocurrency networks will exhibit the same problems, if they were as widely used as Bitcoin.

The channel cheating issue will always exist somehow, even though there are proposals to improve it (and those might never happen, needs consensus changes). As for 'betrayal of the custodial system', well it's as I say, any blockchain network will have the same problems at the same scale. It's true that many of the mobile lightning wallets are custodial, but at least 2 popular ones are not.

so, you're right that LN is not perfect (I tried to explain how one problem, HTLCs that cannot be paid in high onchain fee environments is set to be solved during 2025). My point is you might end up not being able to accept BTC at all, or at least for all but the longest subscriptions. I just today renewed my subscription to AirVPN with only ~ 17,500 satoshis. If the fees to send 17k satoshis onchain are even as much as 5000, I'm going to wonder to myself if there's not a better way (and for these small values, there is. it's lightning)

[Staff 10116]

  On 11/17/2024 at 11:28 PM, NigelMansell said:

Centralization argument makes no sense.

Hello!
This argument is an issue, for many people THE issue, which must be considered. For a quick introduction to this problem related to LN you can check Investopedia . For a mathematical approach debating even the scaling effectiveness and proving that a decentralized LN is unworkable you can start on medium.com for example.
 

  On 11/17/2024 at 11:28 PM, NigelMansell said:

The channel cheating issue will always exist somehow

Good to know and, as we wrote, another serious issue to consider.
 

  On 11/17/2024 at 11:28 PM, NigelMansell said:

you might end up not being able to accept BTC at all

So be it. If BTC fails as a payment tool if a higher layer of centralization is not implemented then that will be fine. Anyway we were not writing that we completely rule out LN, we wrote that there are serious issues to be considered which make us very cautious.

Kind regards
 

[NigelMansell 3]

  On 11/18/2024 at 9:12 AM, Staff said:

This argument is an issue, for many people THE issue, which must be considered. For a quick introduction to this problem related to LN you can check Investopedia . For a mathematical approach debating even the scaling effectiveness and proving that a decentralized LN is unworkable you can start on medium.com for example.

so these are quite old arguments, many of which have not stood up to scrutiny, and which real world operation has proven to be incorrect. I'm not going to get into the details. although it's good to know that instead of arguing with 2013 arguments ("but Litecoin"), you have an interest in 2019 arguments instead ("but incoming liquidity"). All moot points now, in 2024.

As far as the mathematical analysis to scaling is concerned, don't forget that there are people writing analyses from both perspectives, which we can broadly generalize as:

• Lightning network cannot work at all, because...
• Here's how we can fix the Lightning network so more people can use it with self-sovereignty

Both perspectives exist. You have provided links to only analysis from one side. I recognize that while some of the arguments against have merit, but also that the protocol designers _know_ that too, and are slowly making progress towards improving, mitigating and solving the issues outright.

The alternative is clear to me: Bitcoin's blockchain (the most successful) is now +700 GB, and still growing. The UTXO set is +12 GB and growing.

• It takes > 1 day to download the Bitcoin blockchain data on a typical connection
• It takes a computer with RAM bigger than the 12 GB UTXO set ~ 1 day to compute the UTXO set state using a modern computer

without RAM bigger than 12 GB, it takes alot longer than that to compute the UTXO set. All these numbers are set to grow, although there is a slim chance that the UTXO set might be constrained by economic factors.

tl;dr
15 years of real world use shows us that blockchain needs some kind of happy middle values + good computer science in the codebase to squeeze the most out of it. The arguments that anyone else other than Bitcoin Core are doing a better job at that are not very good.

tl;tl;dr
show me a blockchain that can scale up to hundreds of millions of daily users that doesn't "betray self-custody". It would be nice if it were possible, but it seems clear (at least for now) that it is not possible

 

  On 11/18/2024 at 9:12 AM, Staff said:

  On 11/17/2024 at 11:28 PM, NigelMansell said:

The channel cheating issue will always exist somehow

Good to know and, as we wrote, another serious issue to consider.

I think you guys are in a good position to know better than all of us that keeping internet servers up and online is not easy. But that is the basic discipline needed to handle channel partners cheating: stay up, and online, redundantly if possible. If your lightning node is down, you have days or weeks (depends on the timeout value) to get back up to prevent any cheating.

I've not heard of any high-profile cases of channel cheating, but that doesn't mean it's never happened, and it is of course possible.


Anyway, good luck. I hope we all make wise choices with respect to this issue (improving cryptocurrency tech for more widespread adoption)


 

[Staff 10116]

  On 11/18/2024 at 10:36 AM, NigelMansell said:

so these are quite old arguments, many of which have not stood up to scrutiny. I'm not going to get into the details

Hello!

If you can falsify a mathematical proof please do, otherwise please remain silent as you can't dismiss math with an act of faith. Also, a theorem does not become false when it is a few years old.
We're not worried about our ability to accept BTC payments, so why should you?

Thank you for the suggestions and the insights, they will be carefully considered.

Kind regards
 

[NigelMansell 3]

  On 11/18/2024 at 1:06 PM, Staff said:

If you can falsify a mathematical proof please do, otherwise please remain silent as you can't dismiss math with an act of faith. Also, a theorem does not become false when it is a few years old.

one blogger in one post does not have a monopoly on mathematics or proofs thereof. What I mean is that in the 6 years since that particular post was written (I read it at the time it was originally published), some of what is written there has turned out to be wrong or more nuanced than how it is presented in the article.

just to put it simply:

• blockchains can support ~ millions of users, or sacrifice how many people can use them directly (how many TB can we all really store + download to make that work?)
• 2 party payment channels can support ~ 100s millions of users, and some will choose custodial options because it's easier
• channel factories and other scripting tricks theoretically support +billions of users, but it's not anywhere close to being real yet

so, yes, lightning (2 party channels) "does not work", if you mean "is not the ultimate answer". But it's a stepping stone to get there. And direct blockchain use definitely won't work.

again, good luck

[Staff 10116]

the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution

  On 11/18/2024 at 2:57 PM, NigelMansell said:

blockchains can support ~ millions of users

Hello!

Nobody wrote the contrary. The author proved mathematically that a decentralized (*) LN can't be a Bitcoin scaling solution, hence the mentioned issues and our cautious approach. We have doubts, maybe you haven't even read (or understood) the math proof. Never mind, as we wrote we have taken your suggestions into consideration and they will be re-evaluated in due time, thank you for your time and suggestions. Just remember that we don't care that a centralized LN scales well, because at the moment we do NOT want centralization.

(*) centralization of liquidity and not hashrate
 

  Quote

one blogger in one post does not have a monopoly on mathematics or proofs thereof

A math proof is a math proof, it's not an act of faith. If you found errors or anyway you are able to falsify the proof publish everything according to the math and logic framework as well as the proper formal language. Anything else is a waste of time: this is exactly the power of math and logic against dogmas, beliefs and deleterious chattering.

Kind regards
 

[NigelMansell 3]

  On 11/18/2024 at 9:40 PM, Staff said:

We have doubts, maybe you haven't even read (or understood) the math proof.

as mentioned, I read it when it was published (others refuted it at the time, did you read them?)

since then:

• other mathematical analyses of lightning exist
• they all take different stances
• some are indifferent, analyzing details
• some suggest it's not a good idea
• others present ideas (namely, algorithms inspired by statistics collected from the live system) to help it to function better
• some suggest different networks that have an interface to lightning, so that the system can improve (capacity, privacy etc)

why would you read just one document and decide the matter is settled?


From my own experience (I tried it in 2018, stopped out of uncertainty, then began again in 2023) I can say there is no need to use big nodes on the network at all. Although, the big nodes always have an indirect effect, as all the channels are connected by some degree of separation (your small payment through e.g. 10 different nodes causes a ripple effect, as the channel partners for those 10 might have a reason to react to the change in the state of the network, and so might the channel partners of the channels partners ad infinitum...)

So I would contend that real usage of the real system demonstrates that small nodes can pay small nodes with no big node directly invloved, and that's decentralized. During the 7 years since it's been operating, big nodes and small nodes exist, but there is no dependency on the big nodes (there is nothing we can do to stop people with alot of BTC deploying a big node, it's their money). It sounds as though an AirVPN lightning node would represent the thing you seem not to like: a bigger node among the little nodes (although that's true about your business in the VPN marketplace already, am I wrong?)

anyway, I did not expect you to have such a, well, serious reaction. But I will reiterate: it seems that after more than 7 years in operation, the (hypothetical) scenario of a centralized lightning network has yet to happen. Are you sure that the (many) programmers and protocol designers working on maintaining a decentralized network cannot do the job? From all that I've seen, I think it can be done.

[Staff 10116]

  On 11/19/2024 at 10:34 AM, NigelMansell said:

• other mathematical analyses of lightning exist
• they all take different stances

Hello!

Please feel free to provide at your convenience links or anyway references to the math analysis you mention that falsify, or show the flaws or wrong axioms, of the 2017 proof we linked.
 

  On 11/19/2024 at 10:34 AM, NigelMansell said:

why would you read just one document and decide the matter is settled?

We did not. We linked to you an Investopedia article which includes references and links to other studies on each LN issue we mentioned.
 

  On 11/19/2024 at 10:34 AM, NigelMansell said:

From all that I've seen, I think it can be done.

Good to know.

Kind regards

 

[NigelMansell 3]

The objection alot of people were propounding is that getting channels flowing in 2 directions was impossible or difficult. But even when that was popularly said, swap services already existed.

• direct swaps: send to the service onchain and they fill your empty channel up
• direct swaps: send to the service off-chain and your channel then functions in both directions
• mutual channel creation: two channel operators both contribute funds to open it

And that was the end of that objection, which is cited as a part of your favoured mathematical proof, and which turned out to be wrong (it was already wrong before that article was written).


A mathematician published an article that was influential to me in 2022, I was more confident having read it:
https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/

Balancing the channel flow after 2 directions were successfully flowing was the new "Lightning doesn't and never will work". But the paper states that 30% of channels were already experimenting with flow control, and I expect that number has since increased (there is still no protocol level negotiation of parameters to improve flow control, it's still currently a decision for each channel operator to make on their own)

The author is pretty influential on the subject, sometimes his ideas/algorithms have appeared in the software implementations. He's also not always convinced that Lightning can deliver an ultimate solution to scaling (but as I say, very few people do believe that. It just goes a step above what blockchain tech can do on it's own)

Finally, reality is the world mathematics seeks to describe, and mathematics is also capable of describing phenomena that do not exist in this reality. The real world seems to be showing that while some consolidation of network power has happened in the bitcoin lightning network, it is by no means as simple as that.

[Staff 10116]

  On 11/19/2024 at 1:36 PM, NigelMansell said:

The objection alot of people were propounding is that getting channels flowing in 2 directions was impossible or difficult. But even when that was popularly said, swap services already existed.
[...]

And that was the end of that objection, which is cited as a part of your favoured mathematical proof,

A mathematician published an article that was influential to me in 2022, I was more confident having read it:
https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/
 

Hello!

Please note that the article you linked proposes the usage of "valves" to lower LN's payment rate failure rates and optimize flow, problems that we did not mention and that are loosely related to liquidity centralization. So your conclusion that the mathematical proof we mentioned is falsified should be rejected.

Please note that the proof pertains to decentralized LN implementation: the scalability problem gets solved in a highly centralized environment which we vehemently reject though. In spite of the huge pressures for centralization brought on by big actors (including banks) the menace of such a centralization has been disclosed and denounced numerous times, starting probably from the seminal "Lightning Network: How the Banks bought Bitcoin", by "Decentralized Thought".

As we wrote repeatedly on this thread we will keep a conservative and cautious approach as long as the problems we mention are not resolved and even because too many shady actors push for LN. On chain transaction fees are also a non-secondary pressure to LN adoption: when they increase, LN adoption is encouraged, and vice-versa.

On the other hand, since it has been proved that a completely decentralized LN is unworkable, the challenge is not trivial. We are also aware that if more and more small companies like AirVPN become LN hubs, the path to pseudo-centralization, which could be a mitigation against centralization, can be easier.

The future will tell whether a pseudo-centralized LN can offer an effective scalable and at the same time robust solution that will not fall prey of sinister actors. After all it's "only" a layer 2 protocol so it should be possible to drop it in case of emergency when you close channel and settle all on-chain. 😅

We hope that other readers will write on this thread contributions and thoughts on the matter, please don't be shy.

Kind regards
 

[NigelMansell 3]

  On 11/19/2024 at 3:26 PM, Staff said:

  On 11/19/2024 at 1:36 PM, NigelMansell said:

The objection alot of people were propounding is that getting channels flowing in 2 directions was impossible or difficult. But even when that was popularly said, swap services already existed.

And that was the end of that objection, which is cited as a part of your favoured mathematical proof, and which turned out to be wrong (it was already wrong before that article was written).

A mathematician published an article that was influential to me in 2022, I was more confident having read it:
https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/

Please note that the article you linked proposes the usage of "valves" to lower LN's payment rate failure rates and optimize flow, problems that we did not mention and that are loosely related to liquidity centralization. So your conclusion that the mathematical proof we mentioned is falsified should be rejected.

I did not say "this article proves it wrong", the points are unrelated (sorry if it's not clear enough, one sentence must follow another whether they're connected in meaning or not)

I said, in today's real lightning network:

• large and small nodes exist, with connections between each all of their own choosing
• balance/liquidity issues exist, but are not insoluble

That does refute the objections in your article, not with a model, but with an network that's currently operating. Manifest reality shows that it's not centralized, but subject to some operators (openly) trying to be the biggest node on the network.

I agree that the motives of these big operators on Lightning should be looked at very carefully, and that we already know some ought to be avoided. This is little different to how people avoid BitPay or Coinbase (or Amazon), in my opinion of course (others share that opinion), because they're working against the original self-sovereignty ethos of cryptocurrencies

a simple way to mitigate this would be to compile a list of nodes you don't wish to co-operate with, and use it as an exclude list for payment routing. I do this already, and again, not so different to excluding poor behaving peers on any p2p network (e.g. many people ban certain IPs from connecting to their bitcoin node)

[NigelMansell 3]

re: increased attack surface

one mitigation:

1. create node, balance the channels as you wish
2. do not publicly identify who runs the node at all
3. once any testing is complete, accept only BOLT12 invoices

BOLT12 invoices are a new part of the spec (and so might restrict rollout speed a little, but the main new versions of mobile wallets support it). They have a feature which allows the receiver to stop the payer from learning which node they are paying to ("blinded paths" is the name of the feature). Other types of invoices (BOLT11 and LNURL) inherently inform the payer which node they are paying to. Successfully obscuring the node ID also prevents discovery of the node's IP address.

By doing this carefully right from the very beginning, a node used by a business will still be a known part of the network (available on a graph of all channels), but anyone paying that node cannot use the invoice details to determine which node they are paying to. That will help prevent targeted attacks against a specific adversary of a specific business using data from the invoices. Maybe there are other ways to determine the node you are paying, but well prepared blinded paths and no destination node id in all invoices would remove this cheap class of attack. When I say "well prepared", I mean that it is also possible to specify a minimum number of paths that successful payments need to reach their destination, specifying a high number as the minimum will also help to defeat any network level analysis to discover the node id being paid.