So that's a 0.5% fee. I'd say it's still quite cheap for an instant, uncensorable payment. Of course you probably would have paid less using on-chain Bitcoin right now, but that may not always be the case. And you'd still not have the instantaneity of Lightning.
I think it's different use cases. Lightning's first appeal should be instantaneity, not cheap transactions. Of course, Lightning also enables low fees, but that's a contingency, not something that is hard-written in the protocol. It ultimately depends on the liquidity market.
Given that the scarce resource on Lightning is liquidity, it only makes sense that node operators price theirs accordingly. Lightning fees are more and more tightly coupled with the transaction's amount, making the network more appealing for small to mid-size payments, while on-chain remains cheaper for larger payments. But, once again, on-chain lacks instantaneity. Which you rarely need for a $1000 purchase (at least I don't, but maybe I'm just too poor!).
$1k doesnt buy you that much with current inflation rates imo. Also, if we want people to use bitcoin for payments, the wallet should chose the best way to transact automatically. Nobody wants to think about which network to use when doing a payment.
I agree on the second point - I think it's being worked on by several wallets.
I personally don't need instantaneous transaction for more than $1k a month I'd say. The rest of my expenses (rent, insurance, energy, etc.) can take a few minutes to pass through, even hours, without any problem. I could even batch them into one single transaction to save on fees, since they're not time sensitive (although I'm not sure of the implications privacy-wise). On-chain makes more sense here.
As you can see that's one of the difficulties of having an automated network selection. It can't be solely based on amounts and/or fees, because what matters is actually whether the user is in a hurry or not. So we still need to ask the user that, and then automatically choose the network accordingly, which is better than what we currently have but no as smooth as not asking any question at all.
how do you batch them manually and with which wallet?
sure, the transaction speed is something which needs to be communicated to the user. Also that the lightning QR does not contain a onchain address as a backup is making the process of switching the different payment methods less comfortable.
with time there will surely be solutions for that, i just wanted to post this to get some awareness for the problem.
There are many wallet that support sending to multiple addresses in one single transaction. In fact, there is even a Bitcoin Core RPC for that. I know Sparrow and BlueWallet support it, to name only a few.
Why did you use the lightning network for that! I can't be the only person telling people that lightning is for money you'd have in your pocket. Do you go to the gas station with a $1,000 in your pocket?
i think it is pretty ridiculous to think a normal user has to chose a payment network depending on the transaction size and the current onchain fees vs. the lightning fees. If we dont solve that problem fully automatically, everybody and their mom are laughing their asses off about bitcion payments.
There's a lot thats being worked on. Shut the mom and pop arguments. Mom and pop would have been using muun just a year ago and then crying about on-chain fees for something that was supposed to be a lightning wallet.
We have wallets that script out channel management for the user. A few years ago you would have said something like "we can't expect the average person to open channels and manage their liquidity on their own" and you'd be right, but you either did that or you didn't use the lightning network back then. You've chosen to use the lightning network now, so you have Bitcoiners around you trying to help you understand how to use it in a way that won't cause you problems
We now have wallets that have channel management scripted out and yes I foresee wallets that do on-chain or lightning based on fee estimation for each method all on its own.
So that's a 0.5% fee. I'd say it's still quite cheap for an instant, uncensorable payment. Of course you probably would have paid less using on-chain Bitcoin right now, but that may not always be the case. And you'd still not have the instantaneity of Lightning.
I think it's different use cases. Lightning's first appeal should be instantaneity, not cheap transactions. Of course, Lightning also enables low fees, but that's a contingency, not something that is hard-written in the protocol. It ultimately depends on the liquidity market.
Given that the scarce resource on Lightning is liquidity, it only makes sense that node operators price theirs accordingly. Lightning fees are more and more tightly coupled with the transaction's amount, making the network more appealing for small to mid-size payments, while on-chain remains cheaper for larger payments. But, once again, on-chain lacks instantaneity. Which you rarely need for a $1000 purchase (at least I don't, but maybe I'm just too poor!).
$1k doesnt buy you that much with current inflation rates imo. Also, if we want people to use bitcoin for payments, the wallet should chose the best way to transact automatically. Nobody wants to think about which network to use when doing a payment.
I agree on the second point - I think it's being worked on by several wallets.
I personally don't need instantaneous transaction for more than $1k a month I'd say. The rest of my expenses (rent, insurance, energy, etc.) can take a few minutes to pass through, even hours, without any problem. I could even batch them into one single transaction to save on fees, since they're not time sensitive (although I'm not sure of the implications privacy-wise). On-chain makes more sense here.
As you can see that's one of the difficulties of having an automated network selection. It can't be solely based on amounts and/or fees, because what matters is actually whether the user is in a hurry or not. So we still need to ask the user that, and then automatically choose the network accordingly, which is better than what we currently have but no as smooth as not asking any question at all.
how do you batch them manually and with which wallet?
sure, the transaction speed is something which needs to be communicated to the user. Also that the lightning QR does not contain a onchain address as a backup is making the process of switching the different payment methods less comfortable.
with time there will surely be solutions for that, i just wanted to post this to get some awareness for the problem.
There are many wallet that support sending to multiple addresses in one single transaction. In fact, there is even a Bitcoin Core RPC for that. I know Sparrow and BlueWallet support it, to name only a few.
Why did you use the lightning network for that! I can't be the only person telling people that lightning is for money you'd have in your pocket. Do you go to the gas station with a $1,000 in your pocket?
GAHHHHHH
i think it is pretty ridiculous to think a normal user has to chose a payment network depending on the transaction size and the current onchain fees vs. the lightning fees. If we dont solve that problem fully automatically, everybody and their mom are laughing their asses off about bitcion payments.
There's a lot thats being worked on. Shut the mom and pop arguments. Mom and pop would have been using muun just a year ago and then crying about on-chain fees for something that was supposed to be a lightning wallet.
We have wallets that script out channel management for the user. A few years ago you would have said something like "we can't expect the average person to open channels and manage their liquidity on their own" and you'd be right, but you either did that or you didn't use the lightning network back then. You've chosen to use the lightning network now, so you have Bitcoiners around you trying to help you understand how to use it in a way that won't cause you problems
We now have wallets that have channel management scripted out and yes I foresee wallets that do on-chain or lightning based on fee estimation for each method all on its own.
i agree with you, i just post this here to point out a problem which needs to be looked at.
Also, a few days prior i transferred the same amount for 1/20th the lightning fees, so it is stunning to me how much that can vary.
Also with exchanges enabling lightning deposits and withdrawals this will be a problem which occurs more frequently.
Generous in many ways.
deleted by author