Topic: Lightning bitcoin payment on this forum (Read 381 times)

Apart from what pooya87 has already said, there are some edge cases which not many people know about. For example, if you lose your channel database, you need to initiate DLP (data-loss protection) in order to get your funds back. You can do it as long as you have a backup file which was generated after you have opened all of your channels. That file contains all the necessary information you need to reestablish the connection to your peers and ask them to close your channels. Here are the possible scenarios:

1) Everything goes well and all of your peers immediately broadcast the latest commitment transaction of each channel. You will very likely get your funds back after 144 blocks have been mined.
2) Some peer takes the risk and closes the channel with an old commitment transaction. You cannot broadcast a penalty transaction because you lost all of your data.
3) Some peer is offline and cannot respond to your request. Unless they come back online, the funds are locked up in that channel which means that they are lost in a limbo.


That's why keysend should be required by the campaign manager. Unfortunately, it looks like it is supported only by LND and c-lightning so the participants would have to run either of these implementations 24/7.


Each invoice contains a hashed payment preimage. In order to claim the payment (or HTLC to be more precise), the preimage needs to be revealed to the payer. Thus, the campaign manager could prove that the payment has been claimed by revealing both the invoice and the payment preimage.


Last week, the participants got paid over 0.19 BTC in total. Currently, most nodes reject channels larger than ~0.1677 BTC so CM would have to either open multiple channels or a single channel to a large HUB which supports Wumbo.

If you're thinking about a malicious node broadcasting an older channel state, then yes, your LN client should be online once in a while to prevent that.
I assumed most people keep their devices online most of the time anyway.

Doesn't that require your client to remain online (connected to Lightning Network) to keep the channel open for the duration of multiple weeks?

I've thought about it before: technically, it would be possible to create a campaign that pays a user within seconds after each post (with manual quality check to kick out abusers)! Scraping posts is easy, if you add a LN-node, each participant could receive near-instant payments.
LN isn't really designed to send payments to multiple users at once, but there's no need for that if you automate the individual payments.

You have two good reasons why lightning network can not be used to manage a campaign:

1. The payment is not treaceable just like onchain transactions.
2. No wallet yet support multiple payment.

I think using lightning network should not be suggested for now, a campaign manager can just still go for altcoin like Litecoin or Monero for payment which have low transaction fee. If I am a campaign manager, I can even manage a signature campaign in which I will request users to submit both bitcoin and altcoin (like Litecoin) addresses. I may use altcoin address for payment if the network is congested as it is recently.

---

And as for the question, I just want to see peoples opinions. Having a lighting network bitcoin payment could be the fast reason I may choose lightning network for now, but yet I do not see any good reason I should use it, no friend around me is using it.

Well, there's your problem!

Good luck getting 50 payments request from 50 users to be paid before they expire! I'd like to see this happen though, it's better than creating dust inputs.

Talk to BlueWallet, they're active on Telegram and might be willing to add a feature for this.

Users shouldn't open a channel to the campaign manager, but to a node. There's no need to close the channel each week, they can just keep it open.
If the users plan to move the coins on-chain each week, then indeed using LN makes no sense. For small amounts, even exchanging from LN to some altcoin is cheaper on fees than using on-chain Bitcoin.

---

---

After using LN for a while, with both BlueWallet and Phoenix Wallet on Android, I really like it! I have no need to move funds back on-chain anymore.

---

---

Something to think about for the campaign manager: without on-chain evidence, what will you do when someone claims not to have received his payment?

@pooya87 is near to what I was thinking in terms of open, send, close a LN channel to send payments for a SigCamp.

I see two options.

Firstly say 25% of your participants would prefer to receive via LN, you could either do the above, or, have a funding solution such as the one Phoenix offers whereby funds sent via the block-chain to a Phoenix wallet address are automatically turned into an open channel which you then send via LN to the participants.   The CM knows the amount ahead of time so only send that amount to a Phoenix wallet (plus a little bit of dust to cover the outbound TX).  Regardless of any corresponding inbound channel created by Phoenix, you don't have to close the channel as it's all inbound capacity.

The second option would be to send the (example) 25% participants funds in one block to an Escrow who would probably do the above (open a channel, send funds (keep open/close channel) ) anyway.

---

---

A CM might even open one super LN channel for (example) ten week's worth of payments.  The Campaign funder can see the balance being used to open a channel and that it's still open week-to-week as the campaign progresses.

---

---

In the end, it'd be up to the other side to close the channel as they have to bulk of the channel's funds once payments have been made.

---

---

I haven't used Electum, so can't comment on the available options that program has.

Batch transaction help sender to save transaction fee because they can save the size of transaction.

Instead of making 100 different transactions to 100 receivers, the sender can send only 1 batch transaction to all 100 receivers and save a lot of fee. The lower fee is caused by a lower transaction size.

0.001175241 BTC as transaction fee is not a big one. You can randomly check batch transactions from Binance and get transaction fee they paid.

How about making a batch of transaction sending the fund to the receiving addresses and pay less fee than the other services used to sendnthe funds. I have seen a transaction made by a campaign manager about the amount of the fee used to pay is not less which is  0.00175241 btc.

For starters it could be categorized under "hot wallets" since your keys are on an a machine that is connected to internet and can be similarly compromised. Secondly, lightning network is still in its early development stage and the implementations of it are still in beta and can contain bugs which could lead to your funds being lost.

I believe if a campaign manager makes it as the method of payment, people will find it easy to open and close a channel. For people that do not know about bitcoin, to even make a payment onchain can be very difficult for them, but yet we members here know how to. I do not think lightning payment should be a problem unless the offchain payment is not safe to use.

People still believe it is still at its experimental stage, that is why wallets like electrum do warns people not to use huge amount for it. But lightning network has been existing since many years ago, it is getting low adoption, this still surprising me.

I know Lightning networks would reduce transaction fees. But there are some issues if I use Lightning networks for my participant's rewards. First of all, I have been using Ledger to secure escrow funds where Lightning isn't supported as far as I know. So it's difficult to manage the funds on Lightning networks. Second thing is, most campaign participants aren't familiar with Lightning networks and don't know how to use them. They would face problems later on during moving funds to any exchange. You know very well many exchanges still didn't consider implementing SegWit deposit address. We can't expect they will implement deposits or withdraw via Lightning networks. It will take more time to become popular.

There are users that don't want to instantly spend their weekly payment. Thus, the manager could save lots of funds from those. Everything else you said is true. Although, using LN for signature campaigns could be a great adoption, IMO. I doubt if the majority of the participants have used LN before.

Why is it dangerous to hold a great amount of coins with LN? You're locking your funds on a multi-sig address that you can withdraw the final result cooperatively or uncooperatively whether your node wants it or not. Am I missing anything?

Sending payments via the lightning network will complicate matters further because many members withdraw their coins as soon as they receive it, either because they want to pay their expenses or because they want to increase their privacy.
This option would be suitable for those who want to hold currencies for a long time, but relying on the lightning network for huge sums is still dangerous.

Generally, if the user is going to keep his coins for a period of two or three months, then using the lightning network will greatly reduce the fees.

Fee #2 will not be necessary because the payor can receive a LN payment to make the following week's payment. Similarly, Fee #1 will only be required the first time a payment is made.

Fee #3 will apply to anyone not intending on keeping the bitcoin in the LN network, in which case a LN payment would probably not be appropriate.

The same could be said with people not familiar with Bitcoin back then. How to setup a wallet, customize those fees, etc... now everyone is doing them like a pro

If you've sent XLM before that has an additional Memo field, LN is pretty similar with its Invoice.

That may be a small reason at this point but the main reason is that using LN doesn't make sense here. LN is useful if you are going to send/receive multiple payments with the channel you open. But if it is a one time payment every week/month then it makes no sense and it also costs more than the on-chain transaction.

Lets say your signature campaign wanted to do this, they have to:
1. Open a channel for this week/month 's payment which means sending an on-chain transaction to that channel (fee #1)
2. Send out the payment to each user on LN (a tiny LN fee for each tx)
3. Close the channel since there won't be any payment until next round (fee #2)
4. Each user (or at least most of them) that receives the payment has to close their channel and move the coins to their wallets (fee #3)
This means using LN in this case replaced 1 on-chain fee with 3 on-chain and a tiny LN fees which makes no sense.

Yes LN payment is safe. The current bitcoin economy does not currently allow for LN payments to be efficient.

In order to receive a payment via LN, you need to either have spent money on LN or have someone else open a channel with you that gives you inbound capacity (usually for a fee). Also, if you receive a payment via LN, it will generally mean you intend to spend most of that payment in the near term, otherwise you will deplete, and eventually exhaust your receiving capacity.

Some bitcoin merchants accept LN payments, but most do not. Personally, I would be open to receiving LN payments if I had inbound capacity, and intended to spend bitcoin at a merchant that accepts LN shortly after receiving the payment, but absent these two requirements, I would tend to prefer an on-chain transaction. 

i once read a piece on bitcoin lightning network when the cryptocurrency exchange that was available in my country made a blog post about adopting bitcoin lightning to make payments faster. i however didnt pay much attention to it afterward when he transaction and confirmation speeds were still slow as compared to when they hadnt adopted the technology. probably there was something that i did not fully understand.

Basics of the Lightning Network
Bitcoin Lightning Network
Lightning network explained. What is Lightning network? (Binance Academy)
Understanding the Lightning network. Part 1: Building a bidirectional Bitcoin payment channel

Eclair application for Android