The side-chains was a good idea, but the implementation and the tutorials for this was too technical for the average person to understand. It should be a 2 step process.. (Example : Download the wallet / Install App / Use the App) .. no constant tweaking.  You can use a custodial wallet like BlueWallet if you don't want to bother with "constant tweaking". As the time goes by, wallets will become smarter thanks to features like autopilot, automatic inbound channels, splicing and so on. Also, The Lightning Network is an off-chain layer; not a side-chain. |
|
|
|
My question is... do I update all first... before I do the update firmware? Or the other way around?
As far as I remember, apps need to be reinstalled after firmware update so it would be pointless to update them first. I saw some people on reddit ask how they want to rollback to the old one but that certainly isn't possible right?
Yes, you cannot rollback an update. So would you recommend to do this firmware update now or not?
Just do it, Jerry... just do it. |
|
|
|
Could someone confirm it using Linux?
Same result. OpenStego keeps asking for a password on Ubuntu 20.10. I also tried embedding a message without password on Linux and extracting it on Windows and it worked fine. |
|
|
|
Any channel update that maintain or increase the overall balances would always be allowed, but decreasing that balance would not be allowed unless (3) explicitly "gives permission" to do so with a signature.
Keep in mind that if you are the channel founder, you always pay the closing fees. Commitment transactions are periodically updated so that they could be confirmed within reasonable time frame. If the mempool gets full, your balance will shrink to compensate for the higher fee. This approach will also make your node incapable of payment routing. What does Electrum connects to for lightning? I searched, watch some videos, and failed to grasp some necessary detail.
By default, Electrum uses trampoline routing which means that it delegates payment route calculation to the node which is the first hop. In this mode, Electrum connects only to some Electrum server just like it would normally. You can open a channel to a limited number of nodes because hardly any of them support trampoline routing. If you turn off trampoline routing, you can open a channel to any Lightning node, but you will have to wait for your client to sync the network graph, which is used to calculate payment routes, from some random Lightning Network nodes. In this mode, Electurm also connects to a few Lightning nodes. Does any wallet do "proper remote instant backups" already? That is, full backups, that are updated such that a node failure at the worst time doesn't mess up channel state or require to force close any channel.
LND does not have any native backup functionality (there might be some decent third-party tools). C-lightning documentation covers various backup strategies. I personally use a backup plugin which replicates the channel database to a remote directory whenever it's updated. I successfully restored such backup when I was moving my node between different machines. I didn't have to close my channels in the process. |
|
|
|
TL;DR Can I have a lighting node that does not hold my keys, and have a lighter weight wallet that does the signing required?
Yes, it is possible. LND can run in watch-only and singing-only modes. Here you can find a detailed documentation about it. At the moment, both modes require to be connected to a full Bitcoin node, but there is a pull request which will address that problem. While I have some fair understanding of how channels work and how lightning network is supposed to work, but I am completely lost (maybe not, but close enough) regarding what the actual implementations are doing or not doing.
Make sure to visit The Lightning Network node experience and The Lightning Network FAQ threads. I heard that some mobile app connect to non-custodial servers that do the routing for the client. I also came across a feature consisting of uploading an encrypted backup of im-not-so-sure-what-exactly.
For example, BlueWallet is a custodial Lightning wallet which accepts on-chain deposits from users and credit them balance on the Lightning Network. All payments are sent from/received to BlueWallet's node which manages the channels for the users so that they don't have to worry about inbound/outbound liquidity. Eclair Mobile, which is a non-custodial wallet, allows users to make and upload an encrypted backup of their channel database, which consists of data needed not only to reestablish channels with peers but also to construct penalty transactions if the other party ever attempts to cheat. The (unencrypted) backup itself should be useless to a third-party as it shouldn't contain any signed transactions that could result in a fraudulent force-close. And I want a separate (desktop) wallet that will do the signing, as well as whatever else it needs to do, ideally not much more.
You should be able to connect to your LND node using Zap Wallet. |
|
|
|
Is there a way to determine what Electrum's onion address is so I can pass that to c-lightning in <pubkey>:<address>:<port> format?
You could try connecting to your c-lightning node from Electrum. Open the console and type in: add_peer("id@ip_address of your c-lightning node")Copy the output and use it in the lightning-cli openchannel command. |
|
|
|
Did it connect with my node, but run a command that isn't recognized?
Maybe you also need to run Electrum through Tor proxy? I am not sure because I used Electrum only with clearnnet nodes, but it would make sense. |
|
|
|
he is talking about the "payment success" rate thing.. like the near 100% for sub$1 amounts, the 10% success rate for pizza amounts in 2018.. [...]
We have already talked about it. 1500 invoices were generated, 10% of which were successfully paid. One person might have generated multiple invoices without ever trying to pay them. [...] because from your own experience of 389 fails.. your experience is not a "doesnt matter just use LN whenever you want" thing, is it?.. heck you even had 5 channels and still had a 73% fail rate
I am sure that you know that wallets try multiple routes before failing the payment completely. If my node failed to route a payment, it doesn't mean that it wasn't routed by someone else. I don't know if its really the fixed amount to transfer in the lightning network but that's 20~ish cents USD as of writing and it's too small to be considered. I guess there's no need to worry about how small the transaction is but how large and frequent is.
546 satoshi is the dust limit on the main layer. Lightning payments can be as low as 1/1000th of a satoshi. |
|
|
|
I can see if an amount too big, it could really mess up the channel's liquidity, is there an amount that the community agree on that's the limit I should use on lightning?
It doesn't matter if you send many small payments or few large ones. Just use the Lightning Network whenever you need it. If your channel becomes unbalanced, you can use third-party services to refill your channel. My node routed quite a few large payments (up to 900k satoshi) so there are people who don't care about the size. Also, large payments can be split and routed through different channels. |
|
|
|
Is that plugin just an alias for rsync?  Or how is it more sophisticated than that? I'll look it up in the code later; I guess you can schedule it more simply to run periodically, right. Still, if lightningd updates the database while rsync is running, it could result in a corrupted backup. The backup plugin uses a special hook which prevents the database from being modified. |
|
|
|
Zrezygnowałem z serwera domowego, więc musiałem przenieść swoje węzły z powrotem na Raspberry Pi. Całość przebiegła bez problemu. Szczegóły możecie przeczytać tutaj. Chciałbym tylko zwrócić uwagę na to, że, gdybym korzystał z LND, a nie c-lightning, to prawdopodobnie musiałbym zamknąć wszystkie kanały i otworzyć je na nowo. LND oficjalnie nie wspiera migracji pomiędzy różnymi architekturami. |
|
|
|
Manager: HhampuzNazwa kampanii: Arcona.Space | X-Reality Metaverse | Signature CampaignIle do zarobienia: (Senior Member - $10 w BTC/tydzień, Hero Member - $15 w BTC/tydzień, Legendary - $20 w BTC/tydzień) + NFT Jakie rangi: 5x Senior Member, 10x Hero Member, 15x Legendary Dodatkowe informacje: Minimum 20 postów tygodniowo. Lokale liczą się. |
|
|
|
It's nothing to worry about. It's just a bug which has already been fixed. It does not impact the security of your wallet in any way. You might see inaccurate currency conversion rates, though. |
|
|
|
- Added battery.
That would be totally pointless without Bluetooth or a microSD card reader and re-designed software. They have already denied this guess on Twitter. |
|
|
|
But I get "mpp_timeout" and "transaction failed". What could be the reason?
Since you used that channel in the past and it worked, it looks like some node in the selected routing path fails to route a part of your payment. If there was some other route available, your wallet would probably try it. |
|
|
|
Interesting. When I backed my C-Lightning node up and restored it recently, I just had to back up hsm_secret and the database. But I just copied the files after shutting down the service. No tools necessary. Worked flawlessly  Just copied them to the new installation after it was done, and before starting it up; that's it. I could have done the same, but I wanted to test out the backup plugin in case I ever need to use it due to drive failure. Hopefully, this never happens. |
|
|
|
I decided to scrap my home server so I had to move my Bitcoin and Lightning nodes back to a Raspberry Pi. The migration process was painless. Here's what I did: 1) I made sure that my old VM won't boot anymore. You really don't want to accidentally run two instances at the same time or an outdated database. 2) I copied my hsm_secret to .lightning/bitcoin folder on my Raspberry Pi. 3) I ran ./backup-cli restore file:///mnt/external/location ~/.lightning/bitcoin/lightningd.sqlite3 to restore my channel backup. 4) I had to remove my backup file and initialize the backup plugin again: ./backup-cli init --lightning-dir ~/.lightning/bitcoin file:///mnt/external/location/file.bkpMy node is up and running with the same Tor address and channels. It is worth mentioning that LND docs explicitly state that migration between different operating systems and system architectures might lead to data corruption. I guess that's another legitimate reason to choose c-lightning over LND. |
|
|
|
czy istnieje również sposób na zwiększenie liczby połączeń wychodzących? Nie wydaje mi się, żeby była taka możliwość, bo nie ma to większego sensu. Bloki oraz transakcje są przesyłane przez oba rodzaje połączeń. Liczba węzłów akceptujących połączenia przychodzące jest ograniczona, więc zajmowałbyś niepotrzebnie sloty, z których mogliby skorzystać inni. |
|
|
|
|
Show Posts
