Topic: The Lightning Network FAQ - page 25. (Read 33426 times)

Today, I wanted to fund my Phoenix Wallet. An on-chain deposit takes 1% (and a minimum of 10,000 sat) in fees to open a new channel. Since I already have open channels with sufficient incoming capacity, I found the best solution to be CoinPlaza.it: A 2 mBTC (the minimum) on-chain deposit results in 1.998 mBTC LN funds. Including on-chain fees, I saved over 95% compared to a direct deposit to Phoenix.

You can do the same (without an account) from FixedFloat.com, which has a lower minimum amount (but fees are higher).

So the other day one of my nodes had an issue and I shut it down:
https://bitcointalksearch.org/topic/m.58486063

Then a couple of posts later @Rath_ did point out that you could tweak the config files of both LND and c-lightning to change the lock times that you create and accept. I knew that but never really thought about it. We should probably come up with a list of "things you might not want to leave at default" that can be discussed.  Timelock / fees / min and max channel size /

-Dave

I have actually tried it out some time ago and I really liked that it supports keysend payments. Thanks for reminding me about it; I will add it to the list.

By the way, in case some of you missed it, I created The Lightning Network node experience thread in which I and a few other members shared our statistics and feelings about running a Lightning Network node.

OP, another wallet for Lightning to include in your list. It’s non-custodial, https://blixtwallet.github.io/

I haven’t tried, or downloaded it, but it claims to be a wallet that focuses on good UX/UI for usability, and for users who want to try the Lightning Network for the first time.

There's a great entry in the documentation about various backup practices. You will probably end up using the backup plugin with a remote directory or some removable drive.


You could simply copy your hsm_secret and lightningd.sqlite3 files to your new node. This way, you wouldn't have to close your channels. Just make sure to copy lightnind.sqlite3 while your node is not running and don't turn it on afterwards.

I love your solution, it's the kind of hacky thing I like to do as well!
Since the syntax would be $ mrkd my-file.1.md my-file.1, your shell script just creates an empty file with the correct name so c-lightning is happy about the file's existence and the compilation runs smoothly! I don't use the manpage of it anyway, so that will be fine.

Yeah, I'm not sure / confident about the whole backup & restore of the channel states and all, though.. I would just get the new drive, close my channels and reinstall (I have a guide now, right ) in the worst case, so let's open a channel after that. As for the capacity, 1M is not the amount I'd put on this old & worn out drive either, to be completely honest. Also one reason for swapping to a new SSD..

I don't mind if your node is offline for a couple of days after we open a channel. We can do whatever you are more comfortable with. Would you like to try opening a dual-funded channel with me? I could contribute at least 1M satoshi to the channel.

I wondered the same, especially after I noticed that the mrkd I get from pip3 install mrkd in Devuan/Debian 9 doesn't work with the installed Python 3.5.3.
After some fruitless digging through the Makefile and configure (for something like --no-docs) I gave up and just did:

This whole mrkd thing is a unnecessary annoyance IMO.

Alright, thanks!

It's running fine now; this node just uses Tor, nothing else, since it's simpler and (in my opinion) safer than exposing personal IP and stuff. Especially since for a while now, I don't get the usual 'new IP every 24h' anymore that I did in the past.

But I had some issues with my Tor config in the beginning. We can connect now, but maybe I'll swap out the drive for a larger one, so in that case it would be better to postpone the process

Is is possible to just not generate docs using a compile flag? Seen that before but not sure if it's supported here. I usually only install pips into virtualenv's; not sure if this would work here if I activate the environment before running make.

you don't need the ./configure step if you don't change anything with configure

mrkd is used to generate the documentation (manpages) from markdown files and before this release, the generated files were part of the source code. now you need to generate them yourself with mrkd

I believe there will come a point when we will truly sorry for the developers building Lightning, because they might be working veey hard for something that no one really wants. How many years has it been in development? Everyone is throwing money in shitcoin DeFi.

That's also how I have been doing it. This time, I can't compile the update and I am getting the following error ~1 minute after running make.


Edit: It looks like sudo pip3 install mrkd solved the problem. I am not sure why I didn't need it before.

By the way, how is your node n0nce?

How do you recommend to update C-Lightning? I think this is how I did it so far, after having installed by compiling myself and checking out the correct release via git previously.

c-lightning v0.10.2 has been released. You should upgrade your nodes as this update patches the CVE-2021-41592 vulnerability. LND users should also update to v0.13.3-beta.

i wrote their support an email and they confirm what you said. in my own words: they are working on it and they will support it soonish (whatever soonish means). the support basically said nothing new...

You left out #3 withdrawal fees are a source of profit for exchanges.
https://support.kraken.com/hc/en-us/articles/360000767986-Cryptocurrency-withdrawal-fees-and-minimums
So at the moment $9.30 to withdraw. And according to mempool.space and a few others 4 sat/vb will get you into the next block.
And you have to have at least $30 in there to withdraw. How many people will just pay the fee or if they don't have 0.0005BTC trade it for something else (they get the trading fee) and then withdraw that (whatever that coin fee is)

Where if they are doing lightning they can't get away with charging that much. Because, if they do a lot of people will scream.

-Dave

In December, they announced that the Lightning Network support was expected to be available in the first half of 2021. It looks like they are still working on it.


They probably don't feel any pressure to do so because: 1) The transaction fees have been extremely low for quite some time now. 2) Even if any large exchange implements Lightning late, there still will be a lot of people willing to open a channel with their node.

Does it say that Jesse Powell be implementing Lightning for Kraken soon, or is it just an article? It’s been years. Exchanges should start becoming some of the main liquidity providers, and client-side UI providers for the Lightning Network, and bring it to a higher point of growth.

wanted to share with everyone here another interesting article about the lightning network, which was published today by the Kraken exchange


https://www.kraken.com/learn/lightning-network

Sorry for a late reply. I have been slightly busy lately.


This explanation should help you understand it. Here you can find the formulas which are used to calculate revocation public and private keys

revoke_and_ack message looks like this:


Your node must provide per_commitment_secret associated with the next_per_commitment_point which you sent previously in either funding_locked or revoke_and ack message.


An HTLC is basically an additional output of a commitment transaction with a specific locking script. If an HTLC is below the dust limit then it is added to the transaction fee (only when the payment has not been settled yet). There is no real incentive for the other party to cheat in this particular case. If you are not comfortable with that, you can always refuse to route payments below the dust limit.

I am still not sure why you mentioned it. If Alice broadcast the first commitment transaction (the one which refunds her 10 BTC), Bob could simply publish a penalty transaction because Alice revealed the secret needed to derive the revocation key for her outdated commitment.

It wouldn't make sense for Bob to broadcast the second commitment transaction if Alice broadcast the first one because: A) It would be rejected by most nodes due to double-spend B) It would probably be more expensive


You're right. I assumed that they managed to sign the second commitment transaction successfully. If we assume that they failed to sign it, there is no need to worry about that HTLC. If Alice refuses to revoke her previous commitment and sign Bob's new transaction, Bob should not reveal the payment preimage needed to claim that HTLC.