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

It is. Are you certain that the channels are open? Do you have a link on 1ML where I can see the channels? Node B is CLN and node A is LND? Perhaps it is the common issue when having 2 nodes with different implementations. The routing algorithm differs and sometimes it fails. I am searching the web to find a relevant post and I will guide you to it.

- From node A, I have opened a channel with 1ML in testnet. (electrum node)
- From node B, I have opened another channel with 1ML in testnet. (c-lightning node)

- From node A, I can send about 0.02 and receive about 0.001.
- From node B, I can send about 0.03, and receive about a 0.001.

- I create an invoice of 1000 sat from node B.
- I attempt to pay the invoice from node A and receive "No path found". The log says: "electrum.lnutil.ConnStringFormatError: Don't know any addresses for node: [NODE_PUBLIC_KEY]".

I can pay node A from node B, but not the other way around. Isn't it odd?

So you're saying that the Bitcoin receiving address is not, in fact, static?

I know that some wallets with swap-in functionality use submarine swaps, like Breez, in which case the address does change every single time.

If it changes after every deposit, it's possible that Phoenix switched to this type of swap-ins too and Acinq forgot to update their FAQ, but I would need to check the code to be certain.

---

Lightning addresses are a bit controversial, I'd say. To quickly answer your question: Phoenix has sending, but no receiving support.

Lightning addresses are not part of the standard and I got the feeling that opinions are mixed on this, e.g. because you're going to be dependent on an extra entity and extra software: domain provider, hosting service, and the HTTP server running it. Meanwhile, 'statically' receiving BTC through Lightning is already supported without extra dependencies or trust, e.g. through Offers.

We have a thread about this, where further discussion may make sense.

i have the problem on my phoenix wallet that my generated ln receiving address does not appear permanently valid and after a certain time does not accept the transactions sent by the senders
does anyone know what the problem could be?
and another question, there are ln addresses that look like an e-mail address - can i also create such an address via the phoenix wallet?

Breez Wallet on Iphone – Issue with channel unexpectedly closing  

I was wondering whether to open a new thread or just post my issue here.

About 24 hours ago (from this post), I opened up my Breez wallet, and it said that my channel was closing.  It was like my opening up of the Breez wallet caused my channel to close, because it was pending closing, and then after about 45 minutes, the channel was closed.    Another weird thing is that after the channel closed, the date of the closing shows as October 19, 2023 (which would be about 6 weeks ago.. which surely is strange because I know that I had been opening up the app about once a week or so, just to look at the balance).

While the close was pending, the message said something about the funds getting credited back to a bitcoin wallet address, and I was a little worried because the balance in the account (channel) was close to 2 million sats.  

When the close was pending, I was looking around to try to figure out to where the balance was going to be credited, and I figured out that I had funded the channel from two different sources:  
1) two transactions from a blue wallet lightning wallet
and
2) a relative had sent me a transaction from another Breez account

I do believe that Breez does explain the channel closing question on their website, but I did not find that page until writing this post.  https://doc.breez.technology/Closed-Channel.html

Essentially, the Breez site provides a few reasons that channels might be closed:
1) a peer force-closes
2) nodes hold funds rather than forwarding them
3) inactivity of 45 days or more without executing any LN transaction
4) bugs in lnd - causing inadvertent closings

I should have taken some screen shots of the various screens that I saw on my phone while I was going through this process, but I did not, but it still seems that a description of these kinds of potential issues is mostly addressed by Breez, even though I still do not know why my channel was closed – even though surely I was not using my Breez wallet on a regular basis.  I think that my last transaction prior to the closing of the channel was around 6 months earlier (so that would surely be greater than 45 days of inactivity).  

My initial thoughts were that the refund would end up going back to the address from which they originated, but that did not make a whole lot of sense, and so I was confused about where the funds were to go until once the channel close was complete, a caution triangle icon showed up on the right upper screen of the app.  This part is also contrary to what their website says about the funds being available after 144 blocks (so around 24 hours).

When I clicked on the icon, it showed me that the transaction had refunded to a new bitcoin address that was under my control and they had subtracted about 34,425 sats in the channel closing process. The message stated that I needed to transfer the funds out of that address as soon as possible, so when I transferred the funds to another address, it gave me three options between priority, normal and economical, and I choose economical which cost me an additional 7,820 sats to send.  My total costs for this forced channel closing seems to be around 42,245 sats ($18.55) – which does not seem to be inexpensive.

Before, my funds ended up showing up, I had been considering contacting Breez, but when I went to their homepage, it showed that I needed to enter my personal information, which did not seem like a good idea..
 


Anyone have any ideas regarding what happened here?  Previously, I had seen warnings that if the app was not running on the phone (presumptively in the background) then the channel could be closed, and I have no reason to believe that my Breez app had not been running in the background, like I mentioned I tended to open the app about once a week, and then why is it showing October 19th as the closing date when it appeared to have had closed on December 7th?  Anyone? Anyone?

Yes.  I did put that linked thread on my list of "threads to get to," so I will be taking a look at the discussion in that thread, and sure it is possible that I might end up changing my mind in terms of what I already stated in my above post.  I surely don't claim to know a lot of technical matters, and sometimes the various projections of what could happen end up being more true than anticipated.

Let's just take the milli-sats rounding off as an example, if a channel closes that is imbalanced, then it seems that if 501 milli-sats belong to Bob and 499 milli-sats belong to charlie, then when the channel closes, bob would end up receiving the sat and charlie would not... so it is still the dividing of 1 sat into sub-units and the resolution of who owns the sat is resolved when the channel closes..

..and sure maybe at some point, on-chain bitcoin will start to recognize more than 8 decimal places in order for that sat rounding to not be necessary.. and if there are some rules that are proposed that end up creating new sats, then it does not seem too likely that those rules will end up being followed absent some changes in the ways that people (nodes) want to think about bitcoin.. and if for some reason people (nodes) might want to recognize some kind of tail-emission, then that surely would not be out of the realm of possibilities even though currently receptivity to the idea of employing tail-emissions in bitcoin does not seem to be the way very many nodes are currently thinking about bitcoin's scarcity and whether or not a tail-emission might become justifiable (and even conscientiously acceptable) at some point in the future.

FUDdie? No, it's a mere discussion that started in this topic, https://bitcointalksearch.org/topic/m.62860173

The confusion, from my side, started when vjudeu posted that millisats vanish into thin air when Bitcoins in the Lightning Network are settled on-chain. Because from what I learned, they don't technically "vanish". The channel closer's millisats go to the channel's peer, rounding up his/her Bitcoins to the nearest sat.

Although, he's also right from an on-chain viewpoint, they do "disappear".

What you guys are talking about sounds a bit FUDdie to me, and maybe that has to do with my not trying to analyze all the various technical nuances.. (even if I could), but if the actual situation is that current the addition (or recognition of three extra digits) in lightning network does not create any additional bitcoin, but it could have created extra bitcoin if the software developers would have developed it in such a way... but they didn't... so that sounds like a BIG SO FUCKING what.

The addition of extra digits does not create additional bitcoin unless somehow the resolution does not peg back properly and sure there seems to be some rounding up and rounding down going on.. but in the end, no extra bitcoin are create or lost.

Any time second or third layer solutions are created, there are potentials for creating extra coins (such as the creation of a tail emmissions like you said, and without having to do a hardfork), but that still seems like fantasy landia if you believe that miners and/or nodes are going to take the chances of recognizing those extra bitcoin that were created through such process... the incentives are not present for the creation of new bitcoin.. so saying that it could happen, seems like the fantasizing of something that could happen but is way the fuck out there.. .not likely and if it becomes an issue in 50-100 years, then that bridge could be crossed 50-100 years from now rather than acting like there is any real and/or meaningful threat that such a thing might happen.

Surely there are all kinds of shitcoins and all kinds of ways that value is created out of thin air, including those kinds of claims could be made about ordinals and inscriptions, but still seems like a BIG nothing burger.. if the underlying satoshis retain their same value, even if some people might choose to place higher value on some of them or attach some cute pictures or some inspiring text to them in order to attempt to cause them to be recognized as being more valuable.

I guess deploying it. Because you can deploy it as a hard-fork, but then it would be just another altcoin. You can try to deploy it as a soft-fork, but then you have to ask mining pools for support, and create a pull request, to get it officially merged into Bitcoin Core. Sidechains didn't pass through the whole soft-fork process, and you want a tail supply to pass it? It simply won't happen. So, what kind of deployment people are left with? No-forks, of course. And Lightning Network is a no-fork network, because since Segwit, you can deploy many different LN-like networks, with many different rules, and you can do that in a permissionless way. And obviously, you can also make your own sidechain with tail supply, but as long as they are not yet decentralized, you are left with centralized federations, similar to RSK or Liquid.

You can create mining inside LN, some people wrote about it, some people tested that to some extent, there are some private channels, where you can receive single millisatoshis (or even smaller units) if you mine even on your CPU. So, some kind of such networks are tested, but they are not yet deployed in the wild, so you have to directly talk to their operators, because all of that is not yet public (and I guess, this is one of those things that garlonicon had in mind, when he said "I put some quote in my signature, as a reminder, to start sharing some of my not-yet-published code, but we will see if I will be ready for that").

OK, I might have confused one post for another and I thought you were talking about LN, not a hypothetical network.


Yes, sorry. It's three decimal places.


Understood.

My only question is, what would be the purpose of a tail supply offchain if it can't truly be it's own token onchain? Because isn't the debate for a tail supply is to give the miners "extended" incentives for them to keep securing the network?

It's off-topic, I made the same question in this topic before, https://bitcointalksearch.org/topic/m.61685470

You should distinguish two different things: what was done, and what could be done. Those things are separated. LN in the current form handles millisatoshis correctly. However, it does not change the fact, that it is technically possible to create another LN-like network, with different properties (for example tail supply).

Partially, because there are three additional decimal places, not four.

Yes. The whole misunderstanding comes from one simple fact: the topic about tail supply is not about what was done, but about what could be done. And as garlonicon put in the signature, "making a comment on a thread is a much lower investment than actually designing and deploying something that people will use in production". And if you read other comments in the same tail supply thread, you will notice, how people proposed solutions, if some tail supply would be deployed.

So, to sum up, the current Lightning Network is safe. No coins are created out of thin air, because millisatoshis are always sent somewhere, and not simply burned, when you close your channel. And currently, I cannot see someone wise enough to deploy tail supply properly, even on LN-like network. So, we are safe, at least for now.

Lightning users, read my post and the posts above for context, https://bitcointalksearch.org/topic/m.62874374

Am I wrong in my understanding about millisats? I always understood that millisats were merely +4 decimal places going down, that doesn't affect Bitcoin as a unit. One 8 decimal Bitcoin onchain = One 12 decimal Bitcoin offchain. But this post leads me to believe that more units were added just because 4 more decimals were allowed, https://bitcointalksearch.org/topic/m.62866429

It still adds to ONE whole pizza even if the slices were merely made smaller, no? Or am I wrong?

it goes on - today the v23.08.1: satoshi's successor II of cln was released.
there were no major fixes, but many minor ones (especially renepay!). also, the documentation has been improved!

https://github.com/ElementsProject/lightning/releases/tag/v23.08.1

after the two rc-releases at core lightning have now been released and the 'beta' phase is finished, the release, v23.08, codenamed 'Satoshi's Successor' has now been rolled out.
the major update includes numerous new features for the users, for the network as well as for the developers
all further infos as well as the dl-files can be found in the two links below :
https://blog.blockstream.com/core-lightning-v23-08-satoshis-successor/
https://github.com/ElementsProject/lightning/releases

As @vjudeu already wrote, I was referring here to decentralized sidechain models, and these need 2-way pegs. So you would have basically always the chance to "return" to the "real" Bitcoin without having to use a middleman like an exchange (and also aren't in need of a trade partner like in atomic swaps).

The rollup model which got a lot of attention on Ethereum is a good example and perhaps has more chances to be implemented on BTC than drivechains (see here for a proposal with also some info about the requirements for Bitcoin Script). Rollups are a particular type of sidechains where the information about transactions is not exclusively stored on the "alternative" chain, but also on the main chain but in compressed form. Blocks could at least double or triple their capacity when using rollups compared to normal mainchain transactions.

LN has still some advantages compared even to those decentralized 2-way-pegged sidechains. LN is a system based on pure Bitcoin transactions, there is no other blockchain you can attack - and as Paul Sztorc has written extensively about on truthcoin.info, sidechains can have security problems, as they can implement lots of new features, some of them could open new attack vectors (He of course still supports them, because according to him, it's good that "bad sidechains" can get bust). And the problem of securing the sidechain is also still not 100% solved. You can do it with PoS of course but that again has its own centralization risks.

Those BIPs mentioned above are a good start, but they were rejected, so more work is needed to create a proposal that could be accepted. In general, the devil is in the details, the main reason why I didn't publish my own altcoin/sidechain/network yet, is that in the current state, I can still see some potential attacks, and I don't want to release something that will be abused and turned into a scam, like a lot of other altcoins and networks were in the past. First, I have to convince myself to put some real BTC on it, and only then publish it officially under my name. And I am not there yet, everything is still in "discussion, ideas and proposals" state. There are some articles I agree with, some source code, you can test it, and talk with some developers, but there is a long way to get it running on Bitcoin, also because some people reject sidechains as a concept, no matter how they will be implemented, and for that reason I think it may not pass the soft-fork process (and then no-fork will be needed, or in the worst-case-scenario it will happen on altcoins first, if Bitcoin community will reject all proposals).

For that reason, N-of-N multisig is a nice base for Taproot. In general, you can always start from a Schnorr signature, where all N parties are needed to move those coins. Then, if you have 20 users, you just need a single Taproot address with 20-of-20 multisig, and then a single signature can be pushed to the mainchain to reflect the state of the sidechain every sometimes.

And then, by using TapScript, you can extend this N-of-N multisig, to weaken some assumptions, and deal with the network, where N is equal to one thousand, one million, or more, because in the perfect world you want it to be non-interactive, or at least reduce the number of nodes involved, and preserve the non-custodiality of your network.

But still, you cannot be a miner, just because you want that, and because you have the proper hardware. Decentralized sidechains should be mineable by anyone willing to do so. And that problem is even unsolved for the test network, because in signet, blocks are signed to prevent blockstorms. Currently, like it or not, testnet3 is the only official test network, where anyone can test mining in a decentralized way. Also, because Merged Mining is not active, this work is "wasted", because you can mine on testnet3 OR mainnet OR signet. In the perfect world, you could just pick some real mainnet output with some unspent BTC, and say "I want to move it into this test network", then test it, and then destroy it on testnet, and move it back to the mainnet.

Speaking of future, how do you plan to do that? Is there one proposal which describes in detail how you can opt-in and out of a sidechain without federation needed?

Federations are decentralized in some sense. Liquid for example relies on the coordination of lots of companies. To formulate it better: they're distributing the centralization in various companies, probably with reputation as the primary consideration?

The biggest problem with LN is that you cannot move coins between Alice and Bob if they don't have a channel. In sidechains, you can send any coins you have to any other sidechain user, without touching on-chain coins.

This is the difference between sidechains we have here and now, and sidechains we want to have in the future. We need decentralized sidechains, where anyone could say "here is my new sidechain with feature X", and where people could trustlessly put coins in and out, and even mine that sidechain, without trusting the creator. Currently, we don't have decentralized sidechains, we only have federations, where sidechains creators are still needed to maintain the connection between the mainchain and the sidechain.

They should be. Think about future sidechains like in Lightning Network, where anyone could send anything to anyone else, exactly as it works in the mainchain.

Other sidechains are also federations, because to change that, you need some implementation, where you can trustlessly do a peg-out. And one of the ways is explained in BIP-300 and BIP-301, but those proposals are not perfect, and for some reasons they were rejected, so we need something more unstoppable, maybe some no-fork if soft-forks will be too difficult to activate.

How would a sidechain be a true alternative to LN? A sidechain is a completely different currency, which happens to partly rely on the mainchain's currency, in just the order of transactions. Sidechains aren't pegged in both directions, as with lightning. You do have the option to buy 1 sBTC for 1 BTC, but you can't get your bitcoin back trustlessly if you ever want to leave the sidechain. At least not for RSK, I'm not aware for the policy of other sidechains.

I expect this whole section about "why not simply use Xaltcoin" to be deleted, but these are my reasons why LN can be preferrable over altcoins in many cases:

1) You don't have to deal with different currencies. LN is simply another way to use Bitcoin. You don't have to deal with different risks, not stare at different charts, not exchange coins all the time, etc.
2) Bitcoin is less volatile than most altcoins, so to use "Xaltcoin" just because it has lower fees is always more risky.
3) You could use a wrapped Bitcoin or "Bitcoin stablecoin" on the alt chain to benefit from its fees and to circunvent the disadvantage #2. But then you would need probably a centralized intermediary. If not, we are talking about a decentralized sidechain - in this, and only in this case, we have a true alternative to LN. But this does still not exist (closest thing are rollups, but don't exist on Bitcoin yet, and those on ETH are highly centralized themselves).

But most importantly:

4) Lightning is much more scalable, also in the long term. If for example Litecoin became really popular, then it may get a similar blockchain congestion than Bitcoin, like it happened with ETH already. Lightning needs in general less block space per 1000 transactions than on-chain transactions of any chain.