One nice bit of info for our CL friends here... if you ever get in trouble this is what the respiblitz devs are suggesting. I assume if you are using the backup plugin the sequence would be similar.
https://gist.github.com/openoms/3516cd8f393d69d52f858c3d47c9e469
Topic: Lightning Network Observer - page 32. (Read 13552 times)
LN Finally crossed the 4,000 BTC threshold for the first time.
for the first time.. (treat next sentence as humour)
so you are predicting it will DROP and it might hit 4000 a second time, seems your not confident in future growth
Total capacity is something that will fluctuate naturally. But the overall trend is clearly upwards.
Perhaps you could do with a little less confidence and a little more modesty, given how completely and utterly wrong you are half the time you say anything. You act like a know-it-all but you're mostly just an obnoxious windbag with a petty grudge. Current capacity is currently 4012 BTC, but there's nothing written in stone which says it'll never drop below 4000 again.
~
Yuck! Good luck with the recoveries!As for LND, I have no idea; for Core Lightning did you use its backup plugin? If not, I'd prefer to prevent running the risk of losing one (or more) channel's full balance and rather ask counterparties to force close them (or wait until that happens). If you are 100% certain that the backup doesn't differ from the latest channel state, you can restore it safely and prevent any losses. But honestly at current mempool sizes, force closing channels isn't too expensive and it's the safer route, in my opinion.
I am not 100% certain as to the integrity of my CL backups. I have them. I have the hsm_secret and a database backup. But I will need to finish with the LND recovery first. And that will require the node be brought back up. Looks like that will be end of the week.
To be honest, I also trust my channel partners (a few of you are right here) and am entirely comfortable with them force closing the channels as they see fit. I also realize I am vulnerable now, and those partners could decide to broadcast a channel state I may not be able to argue with. I am hoping they will not. But honestly my main hope is I can still produce the private keys to the addresses the close transactions will send my funds to.
We will see.
And I see the logic you are saying about the channels being force closed before I try my backup. I really only have three risks right now.
1. I have the wrong hsm_secret (no idea)
2. The backup script, which runs at shutdown, was not able to do so in a way the completed the database backup. (No way to tell if it is good until I get far enough that it is decrypted by the hsm_secret, I presume)
3. My channel partners decide to take advantage of me.
~
Yuck! Good luck with the recoveries!As for LND, I have no idea; for Core Lightning did you use its backup plugin? If not, I'd prefer to prevent running the risk of losing one (or more) channel's full balance and rather ask counterparties to force close them (or wait until that happens). If you are 100% certain that the backup doesn't differ from the latest channel state, you can restore it safely and prevent any losses. But honestly at current mempool sizes, force closing channels isn't too expensive and it's the safer route, in my opinion.
Ugh... massive hardware failure. Two nodes down. Might need a little advice and moral support for what to do...
Going to try to recover the LND channels first.
LOL.
LND:
Seed words (verified them by checking the zpub with an azeed tool)
Static Channel Backups, including a recent one since the last change
I am assuming with this set of things I will see the blockchain download (gonna take a moment) and then all my channels will attempt to close, and hopefully funds start to make their way back on chain.
CL:
Have seed words, and hsm_secret (99% sure these are the right ones)
Have a very recent lightningd.sqlite3.backup file from right before the drive died.
Just hoping with the above nothing is incorrect, and I am not sure what recovery looks like on this node.
I will do the LND node first... and then the CL node.
If I have channel(s) with you, PLEASE do not force close them yet. Some folks think if the channel DB is good, and the hsm_secret is right I might be able to bring the CL node back up. I doubt this, but time will tell...
*sigh*
Going to try to recover the LND channels first.
LOL.
LND:
Seed words (verified them by checking the zpub with an azeed tool)
Static Channel Backups, including a recent one since the last change
I am assuming with this set of things I will see the blockchain download (gonna take a moment) and then all my channels will attempt to close, and hopefully funds start to make their way back on chain.
CL:
Have seed words, and hsm_secret (99% sure these are the right ones)
Have a very recent lightningd.sqlite3.backup file from right before the drive died.
Just hoping with the above nothing is incorrect, and I am not sure what recovery looks like on this node.
I will do the LND node first... and then the CL node.
If I have channel(s) with you, PLEASE do not force close them yet. Some folks think if the channel DB is good, and the hsm_secret is right I might be able to bring the CL node back up. I doubt this, but time will tell...
*sigh*
LN Finally crossed the 4,000 BTC threshold for the first time.
for the first time.. (treat next sentence as humour)
so you are predicting it will DROP and it might hit 4000 a second time, seems your not confident in future growth
When I checked the news and opened 1ml.con myself, the capacity was actually below 4,000. It was at 3,999.53.
So yeah, I am not certain of future growth, extrapolating is going to zero, or it will cross 4,000 again (multiple times).
Treat the previous sentence as humor.
LN Finally crossed the 4,000 BTC threshold for the first time.
for the first time.. (treat next sentence as humour)
so you are predicting it will DROP and it might hit 4000 a second time, seems your not confident in future growth
LN Finally crossed the 4,000 BTC threshold for the first time.
Lately, the growth has been slow, but steady.
People are starting to get the details of the implementation, rather than raw growth metrics.
Anecdotal evidence tells me channel size comes second to channels management (liquidity balances , routing fees etc).
Lately, the growth has been slow, but steady.
People are starting to get the details of the implementation, rather than raw growth metrics.
Anecdotal evidence tells me channel size comes second to channels management (liquidity balances , routing fees etc).
I believe that we have only started to scratch the surface with "what Lightning is". It might not be merely for cheap/fast payments as originally advertised. Bitcoin was first conceptualized to be a "Peer-to-Peer Electronic Cash System" too, but obviously it has become much more as we started going deeper in understanding of what it can truly be.
Shower thought, NO KYC exchanges built on Lightning, with NO KYC as the value proposition. Is this possible?
Do you mean crypto exchanges or fiat on-/off-ramps?Shower thought, NO KYC exchanges built on Lightning, with NO KYC as the value proposition. Is this possible?
The latter is happening with Bisq (hopefully soon)!
FEES AND CHANNEL BALANCE... thoughts and questions!
Hello lightning observer!!!
OK. It's time for a post in here, isn't it?
I have some questions that some of you galaxy brains might be able to answer. I have been running an LND node since 2019 (not counting the one I had in 2018 that I killed), and only recently added a CLN node about 6 months ago. My questions have to do with both, but the LND node sees much more traffic with between 200-2000 transactions routed a day generally.
I have 4 channel state scenarios I see. But only want to really consider the LAST one.
I see two ways to deal with these:
1. Once the liquidity is over to their side, then just close the channel, and open a new one. Lather, Rinse, Repeat.
2. Coax the liquidity back over to the dry side of the channel.
(3. Well I could also just leave it alone and end up with a channel that is effectively #3 up there. And that is pretty much what has been happening.)
So. The easy solution is to close and reopen the channel. I have even notice that certain commercial LSPs you open channels to, once the liquidity has all rushed over to the other side then slam the channel closed themselves. Wham, bam, thank you mam. And actually, I plan to start setting those channels back up with a fee structure that will make more sats than it costs to open and close the channel, and start being that kind of liquidity... In fact these sorts of things may be the most profitable of all.
But my bias is to basically run as much liquidity as I can without losing money. So I am glad to charge NO FERES AT ALL if I can figure out how to keep the liquidity moving back and forth...
So that's the question. What strategy would you guys use to, once all the liquidity has flowed to one side, coax it back over to the other? In fact some of my channels with various bitcointalk forum users are the main ones that work this way... I honestly do not need to make any money off a channel we share. I just want to help make the LN be a success. I would even consider closing and reopening the channel over and over... but in that case I would probably want to make a couple thousand sats on the the life of the channel to make that worth doing... So I am more interested in sustaining open channels without closing at all (which, frankly is the point right?)
Hope you are all well!
Any ideas?
PS. I forgot to mention one thing. I am biased towards ZERO FEES. Like I said I just want the damn lightning network to actually succeed. But I do not want to LOSE money. So though I prefer very low fees, I do not mind tweaking them for the sake of accomplishing the ability to keep a channel open definitely... The incentives for running a lightning node are actually somewhat elegant the more I think about them!
Hello lightning observer!!!
OK. It's time for a post in here, isn't it?
I have some questions that some of you galaxy brains might be able to answer. I have been running an LND node since 2019 (not counting the one I had in 2018 that I killed), and only recently added a CLN node about 6 months ago. My questions have to do with both, but the LND node sees much more traffic with between 200-2000 transactions routed a day generally.
I have 4 channel state scenarios I see. But only want to really consider the LAST one.
- Some channels seem to want to almost auto balance themselves. In this case I assume my channel partner is a little OCD and is doing that. I have tried some of that myself, but it does not suit my personality really. I am more interested in using passive techniques to balance my channels more organically.
- A few channels seem to slosh back and forth entirely. I have some fairly large (~0.16BTC) channels with the exchanges that have come on board, Bitfinex, Kraken. And these channels like to slosh back and forth wildly. Makes sense. Someone wants to deposit $3k worth of bitcoin on Kraken? Well my channel can handle that, and then same with withdrawals.
- Some of my channels just don't do much. I assume these are nodes with low traffic and low use. I have begun to close these to instead open channels with folks that fall into the other three categories. Waste of time, these.
- Then there is my fourth type I would like your help with! There are the channekls that see great deals of action in ONE DIRECTION, then stop. In general, I open a channel to an channel partner, and the all the liquidity rushes over to one side then just stops. Boom. Done. It can go either way, but generally it goes to their side.
I see two ways to deal with these:
1. Once the liquidity is over to their side, then just close the channel, and open a new one. Lather, Rinse, Repeat.
2. Coax the liquidity back over to the dry side of the channel.
(3. Well I could also just leave it alone and end up with a channel that is effectively #3 up there. And that is pretty much what has been happening.)
So. The easy solution is to close and reopen the channel. I have even notice that certain commercial LSPs you open channels to, once the liquidity has all rushed over to the other side then slam the channel closed themselves. Wham, bam, thank you mam. And actually, I plan to start setting those channels back up with a fee structure that will make more sats than it costs to open and close the channel, and start being that kind of liquidity... In fact these sorts of things may be the most profitable of all.
But my bias is to basically run as much liquidity as I can without losing money. So I am glad to charge NO FERES AT ALL if I can figure out how to keep the liquidity moving back and forth...
So that's the question. What strategy would you guys use to, once all the liquidity has flowed to one side, coax it back over to the other? In fact some of my channels with various bitcointalk forum users are the main ones that work this way... I honestly do not need to make any money off a channel we share. I just want to help make the LN be a success. I would even consider closing and reopening the channel over and over... but in that case I would probably want to make a couple thousand sats on the the life of the channel to make that worth doing... So I am more interested in sustaining open channels without closing at all (which, frankly is the point right?)
Hope you are all well!
Any ideas?
PS. I forgot to mention one thing. I am biased towards ZERO FEES. Like I said I just want the damn lightning network to actually succeed. But I do not want to LOSE money. So though I prefer very low fees, I do not mind tweaking them for the sake of accomplishing the ability to keep a channel open definitely... The incentives for running a lightning node are actually somewhat elegant the more I think about them!
Problem with open/drain liq/close/reopen is, that you lose inbound, so your entire node will be unbalanced until up to a point where you have no inbound left and your node`s routing capability is dead. To keep it balanced I prefer rebalancing nodes, like bfx or even loop. As long as the rebalancing fee is less than my earnings I would prefer this strategy to keep the channels open and my whole node balanced as much as possible.
What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
Absolutely. For me, Lightning is about cheap and fast payments as well as privacy. It's definitely possible that you also have legal advantages when building something fully off-chain instead of using on-chain payments, but I'm not sure about that.
In general, it's been proven that crypto-only casinos are easier to run long-term and I believe it's actually the standard model today. I may be wrong, though, since I'm not a big betting man.
I believe that we have only started to scratch the surface with "what Lightning is". It might not be merely for cheap/fast payments as originally advertised. Bitcoin was first conceptualized to be a "Peer-to-Peer Electronic Cash System" too, but obviously it has become much more as we started going deeper in understanding of what it can truly be.
Shower thought, NO KYC exchanges built on Lightning, with NO KYC as the value proposition. Is this possible?
I don't see why it shouldn't work; every move could be encoded in a mSat-amount payment - unlike smart contracts on Ethereum for instance, more or less activity in a channel doesn't put more strain on the network (channel / blockchain respectively), so you can absolutely use payment channels for high-frequency 'data transfers'. The utility or need for it, can be questioned, but it's fun from a technological perspective.
I guess the rub would be failed payment. So if the site required you to open and fund a channel? Then I think it would work well, but that's not going to be what most users do. On the other hand if people using hosted wallets wanted to play then things like WoS would usually be reliable, AND most likely have that channel open too.
That said... I think it makes the most sense to have a "deposit" like payment to be made with a withdrawal when you actually take the chips off the table.
Yes, the traditional 'deposit > play > withdraw' scheme will be the most reliable, but definitely not as cool as actually sliding the chips over mid-game. I don't see why it shouldn't work; every move could be encoded in a mSat-amount payment - unlike smart contracts on Ethereum for instance, more or less activity in a channel doesn't put more strain on the network (channel / blockchain respectively), so you can absolutely use payment channels for high-frequency 'data transfers'. The utility or need for it, can be questioned, but it's fun from a technological perspective.
I guess the rub would be failed payment. So if the site required you to open and fund a channel? Then I think it would work well, but that's not going to be what most users do. On the other hand if people using hosted wallets wanted to play then things like WoS would usually be reliable, AND most likely have that channel open too.
But wouldn't that be a trip to have the chips, when they are slid over to you be actually money in your pocket so to speak?
That said... I think it makes the most sense to have a "deposit" like payment to be made with a withdrawal when you actually take the chips off the table. Thereby avoiding people going south etc.
Anyway... some day
What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
Absolutely. For me, Lightning is about cheap and fast payments as well as privacy. It's definitely possible that you also have legal advantages when building something fully off-chain instead of using on-chain payments, but I'm not sure about that.In general, it's been proven that crypto-only casinos are easier to run long-term and I believe it's actually the standard model today. I may be wrong, though, since I'm not a big betting man.
One of my first channels I ever opened was to them! 
I don't play much just because I am not a great fan of -EV games... But it's fun to dump a few sats at it from time to time. But it is STILL open and has routed afew million SATS. Not my busiest channel, but been up since 11/2019!
This sounds great; I'll open one with them as well, then! I meant to try their platform anyway, ever since I saw it in Breez's 'apps' section. I don't play much just because I am not a great fan of -EV games... But it's fun to dump a few sats at it from time to time. But it is STILL open and has routed afew million SATS. Not my busiest channel, but been up since 11/2019!I was thinking a poker game that is 100% lightning would be cool... My original thought was all the hands would literally pay out to lightning addresses each time. But I suppose that would never be foolproof. Someone DID make one that works in a more standard fashion.
https://lightning-poker.com/
I don't see why it shouldn't work; every move could be encoded in a mSat-amount payment - unlike smart contracts on Ethereum for instance, more or less activity in a channel doesn't put more strain on the network (channel / blockchain respectively), so you can absolutely use payment channels for high-frequency 'data transfers'. The utility or need for it, can be questioned, but it's fun from a technological perspective. https://lightning-poker.com/
Shower thought. I saw this roulette game built on top of Lightning, https://lightning-roulette.com/
NO KYC, No registration required, No privacy-leak risks. It's just the casino, you, and the Lightning Network. It's like DirectBet, but off-chain. What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
NO KYC, No registration required, No privacy-leak risks. It's just the casino, you, and the Lightning Network. It's like DirectBet, but off-chain. What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
One of my first channels I ever opened was to them!
I don't play much just because I am not a great fan of -EV games... But it's fun to dump a few sats at it from time to time. But it is STILL open and has routed afew million SATS. Not my busiest channel, but been up since 11/2019!And yes. If the lightning network can work, I believe we will see non-KYC types of services a major driver.
Well would ya look at that?!? I am having dinner tonight!
I was thinking a poker game that is 100% lightning would be cool... My original thought was all the hands would literally pay out to lightning addresses each time. But I suppose that would never be foolproof. Someone DID make one that works in a more standard fashion.
https://lightning-poker.com/
Shower thought. I saw this roulette game built on top of Lightning, https://lightning-roulette.com/
NO KYC, No registration required, No privacy-leak risks. It's just the casino, you, and the Lightning Network. It's like DirectBet, but off-chain. What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
NO KYC, No registration required, No privacy-leak risks. It's just the casino, you, and the Lightning Network. It's like DirectBet, but off-chain. What if NO KYC services built directly on top were the value proposition of Lightning? Many people in the community don't like KYC, no? Would that help onboard more users?
has anyone of you already had these lightning nfc cards in the hands and in the best case already tried somewhere?
I haven't, but from their demos it looks very nice and easy to use. However I don't fully understand how the technology works. Since it runs on Lightning, compared to something like SatoChip, there needs to be a Lightning node up and running at all times, somewhere. This could be in the phone app or in a box / node at home. Worst case though, they're just running a custodial wallet for you, on their servers. That would be pretty bad and I'd then much rather just use my non-custodial setup with either a node-in-an-app implementation or an application that's just a remote for the node at home. Through LNURL this is pretty easy to do. FEES AND CHANNEL BALANCE... thoughts and questions!
Any ideas?
PS. I forgot to mention one thing. I am biased towards ZERO FEES. Like I said I just want the damn lightning network to actually succeed. But I do not want to LOSE money. So though I prefer very low fees, I do not mind tweaking them for the sake of accomplishing the ability to keep a channel open definitely... The incentives for running a lightning node are actually somewhat elegant the more I think about them!
Any ideas?
PS. I forgot to mention one thing. I am biased towards ZERO FEES. Like I said I just want the damn lightning network to actually succeed. But I do not want to LOSE money. So though I prefer very low fees, I do not mind tweaking them for the sake of accomplishing the ability to keep a channel open definitely... The incentives for running a lightning node are actually somewhat elegant the more I think about them!
There is a big issue with 'rebalancing' via reverse direction payments in a different route.. lets call it snowballing (to stick with the weather themed buzzwords)
edited to remove big numbers, walls of text because some people cant cope with details
i used small numbers and images for those that hate reading/thinking
oh and i forgot to add.. what if any other node on the loop also wanted to correct their balance
causing them to affect others, which then requires those others to correct themselves. which then needs further corrections
enjoy playing that little scenario out.. and please dont use utopian dream fantasy scenarios. try rationale and logic when running scenarios. it will enlighten you..
need i also forget.
that if its assumed that when making a payment. it has fee's. where by having to do later re-balance (which also incurs fee's) means nodes then have to account for the rebalance fee as a extra charge to add into the payment side to break even.
EG
if fee's were normally. 1msat per 20 per hop meaning normally
A->B1->L = 1msat
then B would have to include a fee for its future inevitable re-balance
(remember K charges more)
meaning
although shifting 100 via BAKLB would be
B->A5->K10->L5->B = 20msat fee for 100 payment
for B to rebalance its whole channel.
so knowing it costs 20msat to rebalance 100. he would charge a extra 4msat per 20
to cover the future rebalance of an allotment of 20msat payment used. plus his usual 1msat for the payment itself
thus fee's increase.
also. this would then make A-B L more expensive than say A-K-L
so you will see different route used and then those new routes would need to rebalance and adjust their fee's accordingly. which snowballs into more nodes charging more.
and more re-balance events happening rather that product/good purchase events happening.
has anyone of you already had these lightning nfc cards in the hands and in the best case already tried somewhere?
find these cards with the motifs in any case successful
find these cards with the motifs in any case successful
Quote
The Bolt Card is a physical card that you can use to pay for goods via the Lightning network
Features
https://www.coincorner.com/TheBoltCardFeatures
- Lightning payments
- NFC/Contactless
- Send BTC payments, funded from any currency
- Easy setup via CoinCorner app
- Use as a Gift Card to give BTC to a friend
~
Interesting topic! I'm also interested to hear how others deal with it. A question though: how long did you observe those channels (where all the liquidity moved to one side and stayed there)?Since I don't have a lot of time to manage my nodes, whenever I've faced this, I kind of 'waited it out'; some channels eventually started to get some activity both ways, other didn't - those I just closed.
What I'd do differently from you is that opening channels to big hubs like exchanges is surely a pretty guaranteed way to get activity in them, however incentivizes / increases centralization of the network. That's why I don't have such channels except of a small one with the 'zerofeerouting' node, since I had some change on a node.
From time to time, I like to call lightning-cli rebalanceall or even do it manually sometimes. It shifts everything around a bit and tends to route more after I do that. I'm sure something like this also exists for lnd.
Jump to: