Reddit Posts
How to completely destroy your bitcoins spending history (Coin Join alternative)
How To Build Your Own Lightning Node with Lightning Network Daemon (LND)
Bitcoin Optech Newsletter #203: Miniscript in Bitcoin Core, LND 0.15.0-beta.rc4, zero-conf channels in Lightning
How can Strike achieve zero fee transactions using the Lightning Network?
Introducing Zeus: A remote mobile lightning wallet that lets you connect to and manage your own node on the go!
I self-hosted a full node with LND in 5 minutes thanks to Umbrel
Lightning Labs (developers of LND) trying to kill open source and hijack the protocol
Lightning Labs (developers of LND) trying to kill open source and hijack the protocol
Cannot connect BlueWallet lightning with mynode
[ANN] CypherpunkPay (a lightweight alternative to BTCPay Server) adds Lightning Network support
LND 0.14.1 released, includes important bug fix (channel incompatibility with other implementations)
PSA: LND v.0.14.0 is incompatibe with eclair and c-lightning! Please don't upgrade!
Having a time with alt exchanges - Help?
Types of mnemonic seeds that are used in BTC - short info
Was at a party where they had a Bitcoin enabled beer tab (price was super low on purpose)
If you want to connect your mobile to your lightning LND node: Zap Bitcoin Lightning Wallet
Reddit, what will it take to make you give XSN (est. 2018) a fair shot?
Mentions
The Lightning wallet by default is custodial. It doesn't have to be and you xan connect it to your own LND node. All the on chain wallets are non-custodial
Install LND for lightning, too!
Now install LND and make it lightning capable. Or start over and use Umbrel.
Oh wow, I need to check that out, I am able to do some cool stuff with LNbits with LND I do it all on umbrel, but c-lightning sounds worth checking out.
Thanks. I installed BTCPay with a docker. LND lightning was included, running no problem. I really wish that c-lightning was installed rather than LND. So: can I run both implementations on the same node or should I uninstall LND first? Will I lose my channels if I switch?
Centralization: With MPP (multi part payments) and AMP (https://docs.lightning.engineering/lightning-network-tools/lnd/amp) the problem you describe goes away pretty much. AMP was implented in LND only quite recently. Costly: I mean a funding transaction costs a few pennys most of the time and if you want to send $100 worth of bitcoin you will need a channel with at least that much capacity. But you can still "join" the LN with almost 0 bitcoin if you only want to receive bitcoin.
>You keep ignoring the fact the majority of node and wallet implementations are made by private companies that can be regulated. the origin of the node implementation code is completely irrelevant. have a look at the license for LND. it's OSS under the MIT license. thus, you are free to clone & modify it as you please, irrespective of any regulation. https://github.com/lightningnetwork/lnd/blob/master/LICENSE
Just read what it says and make your own decision. The only one I think is concerning for me is npm and it being used as a supply chain attack before. You can avoid this one by setting up Bitcoin Core and LND yourself of course. However, treat it the same as any hot wallet. Keep most of your money in cold storage.
You would be a sovereign lightning user instead of depending on a 3rd party if you run a node. You have your on-chain node, and on top of that is your LN node. They work together. Something like Umbrel or myNode makes it easy for users to be sovereign. But with some research, you could use Bitcoin core, core lightning or LND on a normal computer. I would advise a dedicated machine if you will be using it to hold Bitcoin.
If you use Muun it's not technically lightning, though you can pay lightning transactions. They do some fun trick to make it work. I do love the interface for new people getting into Bitcoin. Opening a channel on lightning is as easy as a single on chain transaction. You will have to wait for a few txns to spend it. The setup is what is a little difficult for people new to Bitcoin and LN. I'd look at using LN in a sovereign way. Install Umbrel on a node at home and run LND hub and Blue wallet. You can have your infrastructure at home and a mobile wallet that connects and works from anywhere.
I use LND. Open channels using triangle swaps so I have equal inbound and outbound liquidity. I have tons of liquidity in and out. I never close channels.
Umbrel changed quite a bit since version 0.5.0. Now you install Bitcoin Core and LND separately and is the seed is part of that process. The tutorials is likely not up to date.
Fabulous! I'm C++/Python trying to learn Go to work with Lightining Labs (LND implementation). What language(s) you use? And your paper wealth from both stocks and BTC?
And RGB stole the idea from Peter Todd's research... Welcome to an open source world. RGB as imagined currently is not better than TARO. Very similar but I'd much rather see TARO because it's certain to be smoother and optimized as Lightning Labs is responsible for the LND implementation on the LN. And because they plan on BOLT spec'ing it. I've heard no such plans from RGB. They probably want to license it and other shit which is why they're complaining.
tldr; This week’s newsletter describes experimentation by developers working on silent payments and includes summaries of new releases and release candidates. Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, and BTCPay Server. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.*
>No, i meant. As i never ran a node LN before maybe there is an amount of btc "required" as a standar to put in. Not sure of this. This is my question. Like, is recommended to put more than ..... etc? > >I know the profits can be very minimum, but just wanted to do it for fun, help the community and to learn more. There is no such minimum as far as I know. Each node sets the minimum (and maximum) channel size that they accept, but in most cases the minimum is quite small so this is normally not a limitation. But you will want to open multiple channels so plan accordingly. ​ >I know the basics of security when transact with btc. Now, when setting up the node, what can make me loss my funds? So i can avoid this risks...Thx for reply With LND (the only software I've used so far) it's a bit hard to lose funds (excluding obvious mistakes like erasing your wallet or things like that). I think there are two main LN-only errors that may be catastrophic: 1. **Restoring a channel state from an old backup.** Both ends of a channel must agree on the balance, so if you restore an old channel state the other party will think you are trying to cheat and will steal all your funds from that channel. 2. **Keeping your node offline for extended periods while channels are open.** Normally if the other party tries to steal your funds your node will punish it. But if your node is offline it can't do it, so it's good to open your node at least once during the punishment window (normally \~2 weeks). But of course an offline node cannot route payments so it's pointless to build an LN node and keep it offline. It would be good if you read the [disaster recovery guide](https://docs.lightning.engineering/lightning-network-tools/lnd/disaster-recovery) so you understand the procedure.
Not sure if you "completely understand". If not, read Mastering Bitcoin and Mastering Lightning Network by A. Antonopoulos. Go learn how the stack-based Bitcoin scripting language works, write some scripts on testnet. Learn how redeem scripts, witness script, multisig scripts works. Learn not just lightning network works, but how the scripts are written and all their possible spending conditions. Understand all the BIPs, ones that are in Bitcoin and ones that aren't. Learn Segwit, Taproot, Graftroot, CTV, RGB, Taro, LNURL, channel factories. Learn how to code C++, Go. Read the mailing lists, discussions, and Bitcoin Optech newsletters. Then go start contributing to one of the Bitcoin open source projects like LND.
A couple of questions: - When you want to access sphinx, it asks you to choose from a [limited set of lightning nodes](https://buy.sphinx.chat/). Why not a generic connection setting so that anyone with any lightning node can use it? Right now there's documentation only for: Greenlight, Umbrel, RaspiBlitz, MyNode. - Which brings me to this point. Based on what I've read I think the core functionality of sending messages through lightning is based on the keysend feature, which initially was found only on LND nodes. But [it's been a while since c-lightning offers keysend as well](https://medium.com/blockstream/new-release-c-lightning-0-8-2-1c84fe0c82fe). Are you guys supporting c-lighnting nodes as well? Thanks!, projects looks nice.
Link to app? I have zap wallet but it is a remote control for my LND Bitcoin node. (Lightning node) AFAIK, zap doesn't let you create a wallet with its own 11/24 words.
LND… lendingblock… old company focused on retail lending with some of the highest rates in the market…. Be careful of their withdraw fees though
I own a Nodl and run a LND node which I custody myself. Genuine question that I've never seen discussed before. As far as I know Chivo all runs on one government node? Does this not give major risk that the government could issue lightning BTC that doesn't exist on chain? Ie inflation. Or steal the on chain BTC while still showing lightning balances to the average Joe in El Salvador? And if this is the case, then that could happen everywhere worldwide if the majority move to non custodial. Thoughts?
There are bots you can run (Autopilot for LND, CLBOSS for CLN) that will handle channel and liquidity management for you, but you do have to deposit some bitcoin for them to work with.
Are you mad? Neutrino was implemented in Bitcoin Core in 0.21.0 so you can use a LND Node with a remote and self-hosted (or any other) Core. No need to rely on Lightning Labs. Again spreading false information. Please stop lol
I run several LND clients without dedicated full nodes. It’s called Neutrino and it has been around for two years now. Please do some reading before embarrassing yourself even more.
I’d suggest using a out-of-the-box solution like BTCPay Server :) If you have a Lightning Node like LND or CLI it can be linked with you BTCPay Server to enable Lightning payments too.
Use LND or another lightning implementation for payment processing
Check out Ruben Somsen's feedback. He has analyzed both RGB and Taro, and came to the general conclusion that they are mostly similar. He sees some value in the idea of client-side validation but believes some claims of RGB are exaggerated. Hence, by extension, the same caveats should hold for Taro. The advantage I'd say is that (the people behind) LND seems to be less opaque and more open to criticism, so hopefully, some of these limitations will be acknowledged.
> Why do you think that even the creators of lightning themselves refer to it as a "layer 2" if they think it can stand on its own why did they not call it a layer 1? Simple - because it can't stand on it's own. It a bunch of mutually beneficial agreements (smart contracts) between people with the guarantee that if they ever stop agreeing for whatever reason, they will get their money back by dropping back to the L1 network. It can't exist without a solid L1 network as it's foundation. > Why do they require AT ALL that you ever use bitcoin to open a channel? The reason it requires BTC is simply because it was designed to provide a way of moving small/medium amounts of BTC around, quickly and cheaply. That's it. Why complicate it with yet another token/coin? It's not another scam designed to pump up yet another LND token or whatever.
Neutrino is a lightweight bitcoin node that can be run on phones. [Blixt](https://blixtwallet.github.io) is a lightning wallet that has Neutrino and LND implemented on the phone itself.
Recover your LND instead, the funds should be there since you closed the channels. If you want to switch to clightning you should set up a new node and move the funds on chain to the new node with its new wallet.
You can’t restore Lightning channels using your seed. The seed is only for on-chain funds. Lightning channel backups need to be stored digitally. Those funds could still be in the channels and accessible with your LND backup.
Accept lightning at your store, bar or restaurant / Send lightning requests to your friends. Bitrequest now supports lightning (POS) payment requests and e-commerce integrations! Connect bitrequest to your lightning node (LND, Eclair or C-lightning). Alternatively connect with LNbits API key. The proxy server generates invoices using Lnurl-pay, unifies RPC calls and sends status updates to your back-end. So it's got all the tools for secure e-commerce integrations. **Features:** ​ * Point of Sale. * E-commerce checkouts * Sharing payment requests * Open source and non-custodial (hosted on github and ipfs) * Automatic exchange rate translation between 170 fiat currencies so it can be used worldwide * Xpub and Bip39/44 key derivations * PDF receipts * CSV Export * Team invites * And more E-commerce Checkout Demo: [https://www.youtube.com/watch?v=MYX5KhxaNqU](https://www.youtube.com/watch?v=MYX5KhxaNqU) Lightning payment requests: [https://www.youtube.com/shorts/zRYl9AhLsWw](https://www.youtube.com/shorts/zRYl9AhLsWw) Website: [https://www.bitrequest.io](https://www.bitrequest.io)
This makes me feel itchy. Should I take down my LND node? Does moving to a different implementation make a difference?
tldr; This week’s newsletter summarizes discussion about the speedy trial soft fork activation mechanism and links to an update of an optimized LN pathfinding algorithm. JoinMarket adds taproot sends and Mercury Wallet adds RBF support. Hexa Wallet adds Lightning support for LND users running their own node. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.*
[Lightning Labs (developers of LND) trying to kill open source and hijack the protocol](https://np.reddit.com/r/Bitcoin/comments/t0e0it/lightning_labs_developers_of_lnd_trying_to_kill/)
Hmm, sounds interesting. Instead of trying to implement a keysend refund you should look into [HODL Invoices](https://wiki.ion.radar.tech/tech/research/hodl-invoice). Sounds similar to what you want, but as of yet HODL Invoices are either all or nothing. You need a HODL invoice implementation with a partial refund. I'm not sure if this has been implemented in C-Lightning or Eclair, but LND definitely has: https://github.com/lightningnetwork/lnd/pull/2022
> Lightning devs are becoming increasingly worried about LND's shortcutting the protocol specification Evidence?
Depends. It's easy to make that divide, and say use this for this, not that. I may be completely wrong in my interpretation, but I'll go ahead and suggest you're alluding to the usage of a hardware wallet - I believe that's a fair understanding given the context. If you're suggesting one should run a hardware wallet, you'll fall prey to exactly the same problem that my suggestion above looks to minimise. Some people do verify the source code of what they run to understand what it does, and what it doesn't. I'll propose something else then. Anything on-chain should remain offline - mobile wallet or not. Anything lightning, aka 'walking-around-money', may be online, in lower amounts and especially considering most people don't run their own LND node anyway, so it's always online regardless. If there's a divide to be made, it's between types of custody, and the ability between TX-signing and broadcasting, and assertiveness of one's education and knowledge over what they run. Never trust, always verify - Buying a hardware wallet alone doesn't protect you from the myriad of problems one can have, not to mention you may be enclosing yourself to a a specific eco-system (open or not). But I digress, I understand how it's easier to just go with the one-stop-shop where mistakes are minimised at the expense of saving time effort.
Yes. It's an open protocol, at least for now. Lightning devs are becoming increasingly worried about LND's shortcutting the protocol specification and doing their own thing that will render LND-based Lightning nodes incompatible with all other Lightning nodes.
LND has windows releases: [https://github.com/lightningnetwork/lnd/releases](https://github.com/lightningnetwork/lnd/releases) So you can run it, but I'm not sure it's a one-click thing. If you are okay with non-node solutions, Electrum has Lightning built into it now. You can run your own electrum server too if you want a complete node solution.
Yes of course: there's lncm/bitcoind for Bitcoin Core and lightninglabs/lnd for LND.
Lendingblock gives 6.5% with only a 1 month lock plus LND airdrops. The rates tier up based on 1/3/6 month locks and the amount of LND held.
They are acting like they own the Lightning Network and people are recommending not to use LND.
Thanks Rusty for chiming in. I definitely got carried away, but LND trying to mix in proprietary elements within their implementation just doesn't sit well with me. Appreciate all the work you are doing to advance the protocol.
A new discussion this week about the "BOLT12" proposal can potentially drop some clarity on development and priorities and what are options around adopting this in-progress protocol concept: "BOLT12" https://github.com/lightningnetwork/lnd/issues/5594 Despite the name BOLT12 it is not really yet a BOLT standard and it is more of an additional feature that isn't necessarily mission critical to many users' experience of Lightning. The way that BOLTs are standardized is also arbitrary, what goes into the standard doesn't require peoples' consent so it's more of an opinionated set of documents controlled by an arbitrary process than it is a treaty between independent implementations. In the current process rulebook, if your side produces Lightning software that only 1 or 2% of the network uses, you still get to set the "standard" for the remaining 98 or 99%. So if developers are focused more on dealing with current problems and the security of funds rather than compliance with ruling bodies, they might be inclined to adjust their development priorities away from compliance with specs and towards solving the immediate problems of the 99%. BOLT11 as a standard was not originally part of LND, there was another serialization of the payment details, and even now there is no real need to serialize your payment data as BOLT11, it's just one format for this. You can think about it like YAML vs JSON vs XML, it's a wrapper on top of data needed to make a payment. Many times that I make payments I don't even bother with BOLT11 and things like KeySend payments never use it. There are lots of good points to think about in the above BOLT12 issue but I can give my own personal take on it, following the outline BOLT12 makes in their marketing materials: \### Onion Messaging and Native In this requirement for the payment protocol, the Lightning Network would carry a new functionality which would be arbitrary point to point free-of-charge message passing. This would let you make a short "invoice" which would be a pointer to your node. Payers would send a request message across the network to your node, so you'd be serving requests and sending back details using the same arbitrary message passing. Message passing would be onion encrypted so there is no way for relayers to know if the messages are invoices or if they are Lady Gaga videos, which may be good or bad depending on your perspective. Since the invoice details are in a response you would also have to have a node around and responsive for people to even get the details of what they are paying, a new requirement. From my perspective private arbitrary message passing is a good goal to have in the long run but as a node operator myself I'm already subjected to a lot of potential DoS vectors and cost burdens and I'm concerned about adding on more. I know about and have known about all sorts of problems I'm not inclined to detail or amplify because they potentially negatively impact my node and my own funds, but I think these security issues deserve prioritizing and we shouldn't expect people to run this software with real funds unless we aren't just hand-waving fixes in the future, we are actively focusing on locking things down. There hasn't been much said in response to this DoS concern other than to say that you can rate-limit, which is kind of a vague and unsatisfying response. I'd also like to see a tighter relationship between resource consumption and compensatory fees, to support sustainable operation and not rely so much on altruism or potential nefarious benefits like traffic analysis. If messaging is trivial to anti-DoS, then that could be demonstrated by addressing existing DoS vectors today. If we can't even rapidly deploy universally agreed upon standards that protect the security of funds like anchors, is it right to assume that we will have the bandwidth for inventing novel ways of rate-limiting traffic that we also deliberately design to be private and hard to stop? Even beyond that, there are other non-technical problems arising from advertising support for arbitrary messaging. Unfortunately Tor relay operators are often harassed despite deliberate technical limitations on their responsibility for traffic they relay. This is not to say that I love other payment protocol solutions that rely on Tor or I2P or regular web traffic to convey the same data, it's more to say that BOLT11 is doing a good job at the moment of saying that it is just a data wrapper and communicating that data is an open-ended problem. I made a system myself to communicate payment request data over KeySend, it was able to use regular BOLT11 inside its delivered packets. Another way I could see to incorporate this new functionality would be in a separate and isolated free protocol, so you could have a clearer line between things that you can rely on and experimental protocols that deliver new functionality but might break.
\## Monitoring One API that is potentially missing in LND is a streaming interface to see what is happening when channels are opening and closing. An issue outlines that it would be interesting to hear closing events to be able to keep tabs on channels as they move through different closing states: "Add pending channel close events to the channel event stream" https://github.com/lightningnetwork/lnd/issues/6290 My current solution for listening to pending opening and closing channels is to simply poll pending channels. That way I can see details of a new pending channel or see a channel that is closing, and all of the details about it. Another approach can be to subscribe to backup updates or regular channel updates, but they are missing details so they could be used to trigger a poll as well. \## New Features The conversion to Taproot is coming along in LND and basic level support is a big priority so I would expect to see this soon: "Bump btcec to v2, use integrated btcutil module" https://github.com/lightningnetwork/lnd/pull/6285 Basic support in LND involves a lot of foundational work to add libraries and data structures to support new Taproot concepts and standards. Existing code that assumes ECDSA needs to be refactored, APIs need to be adjusted, new tests, new design, so just this base levels support is not a trivial integration even though nothing about working with Taproot outputs is fundamentally challenging to support. Adding this basic level of support will also be helpful for future integration of LN Taproot standards, which can themselves be split into pieces so that they build upon each other, this way Taproot adoption isn't a monolithic task, it's more of a gradual integration. I would not say that Schnorr/Taproot is really finished as well considering that MuSig is such an important component of the concept and this standard not 100% settled. Once MuSig2 is fully tested and standardized I think we will see more new standards published that use scripts for fallbacks but leverage the real promise of Schnorr/Taproot for cooperative resolutions. One place that LND has led in terms of LN standards has been the introduction of the anchor channel format as a standard and default format for all channels, but leading the way here has also revealed some edge case scenarios about UTXO tracking when third parties are sweeping anchor outputs and there is a new PR to handle this: "properly remove any unconfirmed descendant chains a to-be-swept input is spent" https://github.com/lightningnetwork/lnd/pull/6274 Anchor channels are a good example of prioritization of feature development where incremental solutions to high priority problems are implemented and deployed, with standardization as a strong goal but not at the expense of usability. We're starting to get to a point where anchor channels should be a strong mandate across the network because of the relative security gain, and if you are peering with nodes that do not support it you should be aware that your funds are at a greater risk. There is still a ways to go on using anchor channels beyond these edge cases to allow for leveraging their ability to minimize chain fees and maximize their ability to get predictable channel closes, related PRs for those aspects are steadily making their way towards merge. There has been a lot of integration pushes for various payment protocol solutions that have arisen in the Lightning ecosystem and it's not something that LND has really been focusing on due to the payment experience being well covered by other team's priorities as they work on making great user experiences on mobile and at the point of sale. There is no need to attack anyone for their support or lack thereof of specific payment protocol standards, the point of open source and open standards is that you can participate yourself, the whole idea here is you don't need anyone to give you permission on how to conduct commerce with other people.
Email from Alex Bosworth: Hi, this is Alex Bosworth from Lightning Labs. LND 0.15.0 still feels like it's a ways off but there is a lot of feedback on scaling bottlenecks in the current LND and there is a lot that could potentially be done for those in upcoming releases. In this week's email I provide some personal opinions on the state of protocol and spec development. \## Scaling It was reported that invoice creation is slower on LND 0.14.2 but I don't know of any reasoning why that would be and I haven't seen that in my own testing. More feedback is probably required from people encountering this issue to be able to find a resolution for it. This week though there is an outline of a reworking of invoice storage in LND to be more optimized for SQL or external backends: "create native SQL schema for invoice storage" https://github.com/lightningnetwork/lnd/issues/6288 In the long run this seems like the way to go, to separate out invoice metadata management to systems more designed for the task of generic metadata storage and manipulation. In the short term though my advice for abstracting away invoice overhead is to use small LND nodes to do your invoicing, with private channels. You can connect those LND nodes to your big public routing nodes or to third party routing nodes, and then just rotate to new small LNDs as they get load or excessive state. Another thing to think about here is capacity testing. If you are thinking about a scenario where you want to do x traffic or make y invoices, etc, this is something that you can simulate and test. Or you can try and scale up to that scenario gradually in production, but closely monitor what is going on as you scale.
It's basically just a disagreement between two camps developing node software, but OP is making it sound like Lightning Labs is part of some grand conspiracy theory because some crypto people speak at the WEF each year. Obviously the players with implementations that are less widely used are angry at Lightning Labs for trying to change the specs without consulting them and there's some legitimate criticism there but making it sound like they're against open source because it's part of some global conspiracy is honestly bizarre. LND is the most widely used and arguably the best implementation and you can also understand it from Lightning Labs side where they may be trying to push Lightning to the next level but people affiliated with the other companies working on Lightning don't want them to run away with the ball. Would be nice if every time folks in Bitcoin had a disagreement we don't try to make the other side part of some grand conspiracy against us.
This is a bit extreme. Lightning Labs have certainly been helped by the perception that they *are* the Lightning Network, and their dominance of nodes in the network is partly due to this, partly due to their excellent documentation and developer support. They haven't been pulling their weight in the spec process since Conner Fromknecht left, and of particular concern is that they haven't even commented on the proposals for splicing or dual funding. The latter is a direct competitor to their proprietary centralized pool service, of course. This isn't a reason to stop using LND, but I think it's a reason to evaluate alternatives IMHO.
after reading LND's (CEO?) replies, this seem FUD what you posted.
I dont understand, no one is forcing anyone into BOLT process changes. If c-lightning doesn't want to provide the same support that LND is, then thats totally fine. There's a TON of legit arguments that further privacy measures shouldn't be prioritized for the lightning network. and that functionality, ease of use, watchtower-like security should be prioritized. **No one is imposing any code on anyone.** And don't come back saying thats your opinion. It's simply a false statement. You are either misinformed or lying. There is 0 daylight to make that a legit argument. There is also no problem if they were to want to accept a bolt and others are not. There's no law saying that we need a consensus on all of this. Preferably I think these devs are wasting a ton of their time instead of working more on eltoo. But I'm not going to be salty that they don't agree.
I’ve had issues operating LND and have worked directly with Roasbeef and Alex Bosworth. They couldn’t have been more knowledgeable or helpful. I don’t plan on running any Lightning implementation other then LND.
Man up and post them in your OP. Also, remove the call to root out LND until we know whats happening
If there is actually a standard in tech then that there is always drama about protocol standards and issues if one company becomes dominant (IE as an example, now google chrome). That's nothing new and to be expected. It's totally fine and part of the process when other devs call that out. But honestly why do you have to mix it together with some dumb WEF conspiracy bullshit and call for an LND boycott? It turns an actual concern into a dumb joke.
The links are to threads, many of which have responses from LND devs and staff. Here are their profiles for reference. But you are right, it is good to do your own research and come to your own conclusions. Cheers. [https://twitter.com/roasbeef](https://twitter.com/roasbeef) [https://twitter.com/starkness](https://twitter.com/starkness) [https://twitter.com/alexbosworth](https://twitter.com/alexbosworth)
Sorry if this comes across the wrong way. But there are legitimate concerns from other Lightning implementation devs like RustyTwit and ACINQ, with corroboration of from trusted devs like BlueMatt. This is what tipped the balance for me. LND devs are being accused of undermining privacy oriented updates, and worse, the BOLT process itself, which is what open source is all about: you want cross-compatibility, you want community input. LND has clearly been trying to establish market dominance, to then unilaterally impose their code and their implementation without community support, without consensus. That's clearly against the spirit of open source. And on top of that, they haven't been able to convincingly explain their relations to the WEF and other centralized institutions. The rumors I can ignore. This behavior on how they write code, can't be tolerated.
Has anyone used Bisq? It's a trading platform that claims to be 100% decentralized as a P2P client. I have it sitting as a virtual machine and am going through the interface. It appears folks do cash deposits and wire transfer. There are money apps, Zeller among them. I super like this idea because all I had to do was verify the file downloaded from the git. I installed on a fresh VM behind a firewall. The Bisq app tunnels through TOR by default. All my BTC has been acquired via PayPal trades with folks on P2P exchanges and the trust has always worked out - sometimes PayPal would delay the funds and yet the trusty PayPal BTC vendor came through correct. I have done a few BTC-ATM "deposits" but this KYC stuff just feels super dirty. I feel like if a platform like Bisq in which a packaged P2P-only exchange as an application in a trusty way that can be mass adopted by normies, then all this could accelerate further. My method: Acquire dark BTC in anyway in which I am able to get it at the lowest price point (I generally try to stay within 3%-7% and only make my moves when the market dips so to recover from loss from fees when converting from my fiat) I have a full node that hosts a LND wallet and a copy of the block chain. This appliance tunnels through TOR where it receives my transactions. Coin is then immediately transferred to a warm wallet and then half of that is put into a cold wallet. I make the wallets using single board computers and keep the SD cards safe. All instances that retain my Bitcoin functions are fresh installations containing packages as recommended by the official Bitcoin projects that are out there. And then I keep everything behind a firewall appliance with IDS/IPS and can inspect what my network is doing to verify what I am doing is safe. Seeds/notes are kept on these cool "indestructible" notebooks I got from the internet (plastic "paper" field books). I don't think anyone needs my level of knowledge and interest but if there were more like myself who will work with these tools and progress them for normies to adopt, then there could actually be a market of knowledge to trade for further decentralization. God damn old money boomers are X'rs are finally catching on, mass adoption will happen when they make it look cool and those with the means to work with the infrastructure will benefit from it. There may be an entire IT field dedicated to offering support for the decentralized mass infrastructure.
## Emergence of Open-source software being sold as hardware Its always been a difficult problem for open source projects to thrive when there's so few ways to generate revenue. Recently there has been a rising popularity in generating revenue by "doing the deployment" part of a self-hosted open source application. Apps such as BTCPay Server, bitcoin-core, LND, NextCloud, Cryptpad, etc require basic Linux terminal skills. Even with Linux being popular, only small portion of humanity is skilled enough to manage their own servers. Projects like Umbrel and Casa node sell their software already installed and setup on a raspberry pi. All the end customer has to do is: - buy their product (software installed on raspberry pi) - connect it to their router with an ethernet cable - ??? - profit ## Why Bitcoin? Bitcoin is one of the most popular FOSS projects out there. Though most people aren't benefiting from the self-sovereignty it is capable of providing. Bitcoin and its applications really shine where the user has complete over them. An ideal way of doing so is self hosting. Selling bitcoind and its applications on a raspberry pi is a really cool idea that can help make self-sovereign bitcoin be available to more people. This also enables an indivisual to do more than just do bitcoin transactions. Apps like BTCPay Server are almost a neccesity for most bitcoin startups. Bitcoin being the pioneer of open source money can move this field forward. So here's the raspberry standard for bitcoin: Bitcoin and its applications should be light and optimized enough that they can run on the most common raspberry pi. We succeed in this regard in most applications. Thanks to great people at Umbrel bitcoind, lnd and btcpay-server can all run in a single raspberry pi 4. Though I understand bitcoin mining is completely different game. ## Benefits Keeping the raspberry pi / Linux standard in vew when building self-hosted applications for bitcoin makes it easier for common people to use bitcoin. It makes the internet more decentralized and allows people to own their data. This extends to other applications as well. However I beleive Bitcoin has the popularity and open-source community to make this mainstream. People can start out using their raspberry pi for umbrel but quickly advance into using it for more things like Solid Pod (own your data), GhostBlog (own your blog), NextCloud (own your cloud storage). ## Will self hosting ever go mainstream? Probably not. But selling hardware instead of expecting users to install it on their own Linux server will definitely make it more popular and more importantly, make open-source profitable.
That's all about doing it on an RPi. Not what I need. We really need to stop assuming everyone is just going to run out and buy Rpis and all the peripherals (which now cost upwards of $400+) because that's ridiculous when I can run all this stuff on hardware that people just give away for free because they don't understand why desktop computers are valuable. I can literally buy gaming machines and old servers for less than the cost of an RPi now. Fuck Rpi. Just give me a goddamn Linux install guide that isn't "for devs eyes only". ​ I can use CLI, and so can anyone else. What I can't do is understand a million pieces of jargon and nuance when all I'm looking for is how to install a fucking binary file. Bitcoin core install is *very* easy. Can we *PLEASE* do that with LND? Or is it even *called* LND?! Is it c-lightning?! I don't even *know* because I've spent a whole day typing different "how to" parameters into various search engines and haven't figured out *SHIT*, except that I think I did a good thing installing Golang... (which was simple, because all I needed to do was "sudo apt install golang". *Why* can't I do that with lightning? Or at the very least get a clear explanation of *HOW* to do that? ​ Almost certainly going to have to delete this angry rant, but *FUCK*... I needed to get that off my chest.
We published a [new guide](https://raspibolt.org/static-channel-backup.html) for LND node operators that explains how to create a simple automatic backup of the SCB: * locally, on a USB stick or mSD card * remotely, to a private GitHub repo For added redundancy, the Telegram BOS bot also send SCB updates, see our set up [guide](https://raspibolt.org/bonus/lightning/balance-of-satoshis.html#optional-connect-your-node-to-a-telegram-bot) here. *(should work on any node with a Debian-based OS)*
No, you can build your own app if you like... The other altenative is to run a full node with LND and then connect [Zap](https://play.google.com/store/apps/details?id=zapsolutions.zap) to it.
tldr; The number of developers working full-time on the Bitcoin reference client, Bitcoin Core, is well below 40, and the number of maintainers is within single digits. There are an even smaller number of Bitcoin developers on the African continent, with the number further shrinking as we go lower in the stack, from the Lightning Network (LND) all the way down to Bitcoin Core. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.*
> Additionally, Lightning has more flaws in that you have to spend to receive on the same channel and need others to open a channel with you. But the biggest issue of all with current L2 for Bitcoin is that the way to solve this issue (and the way it’s currently being handled) is by centralizing channel creation through large node operators with tons of spare capital. Not to mention that if you don’t have a channel large enough to send money for a big purchase, you’re SOL. Centralization and custodial nodes is a problem with LN, creating a hub-and-spoke model. LN’s fast transaction speeds works as advertised when connected to one of these “central hubs” and with decent hardware, but as an owner of my own LND node running on an rPi 4B with SSD and 3 channels open, my transactions of values between $1-$50 rarely go through the first time, and take upwards of 30 seconds to process. I’m sure this would be a different story had I used a custodial node wallet provider like Phoenix, but that again defeats the decentralization aspect that cryptocurrency has going for it. Another point with liquidity is that you have to put all the money you’re going to be spending **And Receiving** into LN before you spend it or receive it, or you’d have to wait for the buyer to open a new channel with you (would be rather hard if you’re both using a custodial node, or worse if you’re using the same one). Lastly, another issue with LN is its reliance on IP addresses as node identifiers. This is a huge privacy concern. The current fix is to use LN over Tor, but this introduces a dependency on another technology, Tor, that has seen and has its own fair share of issues as well as a dwindling relay node count in recent years. Tor also introduces some latency into transaction processing speeds, but I feel that’s a nonissue personally as the latency addition is only a second or two max.
tldr; The number of developers working full-time on the Bitcoin reference client, Bitcoin Core, is well below 40, and the number of maintainers is within single digits. There are an even smaller number of Bitcoin developers on the African continent, with the number further shrinking as we go lower in the stack, from the Lightning Network (LND) all the way down to Bitcoin Core. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.*
A channel open is usually one transaction in my experience (I use LND for my lightning node). A channel close is often two transactions IF it was a forced close. The first tx is the settlement transaction, it has a timelock for the person who closed the channel to ensure there is time for fraud detection and penalty application, but the other person's money is free to spend. The first tx is the settlement tx, it is a pre-signed transaction that moves the money from a 2-of-2 controlled address to two utxos: one bound by a timelock and a penalty clause, the other is spendable by only one of the two partners. The second tx sweeps the funds from that utxo to an address that a standard wallet would be able to find. If you were the partner who was timebound, then LND will sweep the funds after the timelock has expired. If it was a cooperative close (i.e. both partners had healthy nodes with no data loss and you or they initiated a channel close while both nodes were online and available for communication) then the two nodes will cooperate and can simply create a single transaction that sends the funds directly to your respective wallets without any timelocks or penalty clauses which removes the need to send money to a pay-to-script-hash address first. Hopefully that answers your question.
Yes it will be. Lightning is perfect for those amounts. Do you already run a Lightning node or know how to do so? If not get started with that. LND, which is one of the most common implementations, has a REST api you can easily use with Python
That’s bull….My airdrop on lendingblock is 20k LND a month give or take a few thousand and I can sell them directly for usdt.
And if you stake some LND you qualify for the airdrop! Free money. If you open a borrow or earn, your airdrop is higher. It’s a great platform to use. Fully licensed and insured. www.lendingblock.com
Lendingblock.com , competitive rates and users of the platform get a portion of the monthly airdrop of LND. It’s still a smal cap so now is a great time to be getting the airdrop. Young platform means not many users competing for the airdrop yet means more for you, and young token means you get to catch the full appreciation. $LND
Right, but are you using Umbrel or Raspblitz? Or you just have a Bitcoin Core Node? Your best option for running Lightning is to run [LND](https://github.com/lightningnetwork/lnd).
LND…. Lendingblock. Small cap lending exchange coin…. Previously institutional lending only but more recently moved into retail lending….. best interest rates available for lending and according to the very experienced team behind this licensed, regulated and fully insured project there will be a big update coming to the exchange and a massive push in marketing.
**1)** Is there a respectable wordpress plugin for lightning that works without paying a middleman? **2)** If I run a lightning node from the house is that suitable to handle a multiple wordpress stores? If so whats the max amount of stores? **3)** How does one deal with keeping track of transactions for lightning for taxes? **4)** What is the best lightning wallet? and Why? **5)** If using lightning to accept payments is a watchtower service needed? **5)** Which is best implementation of lightning to use? Is LND the most supported or most common?
No you don't have to chose. Most LN implementations such as LND will find the path that works best for you and cost you the least amount.
Holding the LND token can really boost rates - they're airdropping more every month.
Actually 1.5% higher plus when you lock it into a fixed term (an earn) you get LND token airdrop every month.
Have a look at Lendingblock. Fully insured and secured to know your funds are safe. Better interest rates than both Celsius and Nexo. Hold the native token LND on the Lendingblock platform to stake and earn a percentage of the airdrop each month. If you hold enough LND to qualify for better tiers, you get discount on earning and borrowing rates! Big things coming for Lendingblock in 2022.
Great interface for a noob like me. Having LND token means I can boost rates and get the airdrop. Hopefully, more tokens coming on their internal exchange to make it r really useful.
Thanks a lot for the tip! The BTC/sats denomination is coming. It should have been present from the start. Regarding LND vs c-lightning - I am not really LN expert and I don't have any strong opinions at this point. Multiple people already expressed interest in c-lightning so I need to give it a try.
I didn't see any way on your web site to input a donation amount in units of real money. The only options listed were all units of various state-branded toilet papers. So I'll tip you here instead. !lntip 31337 Thanks for recognizing the need for this. I wanted to install BTCPay Server but honestly couldn't figure out how to `git clone` and `./configure ; make ; make install` it. It seemed it was only designed to be deployed as some monolithic binary blob that bundles a whole Bitcoin node and Lightning node along with the payment gateway. Yuck! I ended up going with LNBits, which works fine, but it's great to see more options coming out. One request: add support for C-Lightning back-ends. If you like the lightweight, \*nix philosophy, I'm surprised you'd choose LND over C-Lightning.
This was proven again and again by Steve Jobs. He was a hack when it comes to making tech as others made it, BUT!! He was smart enough to know u need to make tech stupid easy to use. 1 at most 2 clicks and it just….works!!! Once grandma sees a QR code at checkout and knows to scan it and LND pays. That’s when. Once grandma selects from Bitcoin and FedCoin.
If anyone would like to learn how to build your own Lightning node step-by-step, check out the RaspiBolt guide: [https://raspibolt.org/](https://raspibolt.org/) * Build a **Bitcoin Core** node * Install **Electrs** to privately connect your Electrum/Specter/Sparrow desktop wallet * Install the **BTC RPC Explorer** to have your personal and private explorer * Set up a **LND node** * Install **Ride The Lightning** to manage your lightning node from your browser * \+ many **bonus guides** to do much more * DIY, "don't trust, verify": no preinstalled OS, no containers, no scripts! *(disclaimer: I contribute to the project)*
There are many implementations of lightning... LND, c-lightning, Electrum Lightning, and Eclair to name the popular ones. wherever did you hear that? I wouldn't use them as a resource any longer.
Thoughts on expanding the list of applications to include: 1. Electrum Native Seeds - These are actually a break from BIP39 2. SLIP39 Shards - These are in Electrum now too. 3. LND Seeds - LND uses the AEZEED seed gneration 4. Monero Seeds - Altcoin, I know, but if your doing GPG, and RSA, it's not that far.
With Taproot activating soon, and all the benefits it brings to Lightning… what’s the process for using it? Can we only open channels with other taproot-enabled Lightning partners? I’m currently running Umbrel which I believe has support for Taproot in bitcoin core but I’m unsure about the LND part of it.
[Intro](https://lightning.network/) [Documentation](https://lightning.network/docs/) [LND](https://docs.lightning.engineering/) [Not a recommendation, just an option](https://stopanddecrypt.medium.com/a-complete-beginners-guide-to-installing-a-lightning-node-on-linux-2021-edition-ece227cfc35d) Good hunting!
本周比特币核心、C-Lightning、Eclair、LND、Rust-Lightning、libsecp256k1、硬件钱包接口（HWI）、Rust 比特币、BTCPay 服务器、比特币改进提案（BIP）和闪电螺栓的显着变化。
Won’t, BCH will hang in from name recognition is all. But according to that Reddit, Bitcoin Core and LND will die anyway now and the world will see the light.
Thanks again. USD finance and the majority of the rest of the crypto space I'm not so sure about, but Bitcoin I think I have a pretty good understanding of. Just finished setting up the hardware for a full node. I have some more accumulation to do before I'm comfortable setting up LND and opening channels, but it's been an exciting project. My stock portfolio, not so much recently. ;)
tldr; RaspiBlitz has added support for Blockstream’s c-lightning implementation. Users can now choose between running only LND, running only c-Lightning, or running both at the same time. Lightning Labs’ implementation is more reliable for routing payments on the first try, and benefits from more third party applications. *This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.*
Whatever works for you! I'm running a LND node and using RTL as my frontend. !LNTIP 8000
I mean…really? I don’t use checks anymore. I don’t use cash. Traditional banks have no use if we wanted. Have your own wallet, payroll can be sent via LND to your Bitcoin wallet. Loans? New things such as BlockFi, Celsius, Gemini , etc can easily build up to replace Chase, BoA, Wells Fargo, etc. There is zero need for old banks now and we are still early. Chase knows this and why the CEO loathes Bitcoin. They will double down buying politicians to keep their power in place OR the will be required to adapt.
No problem dude. Good luck on LND
Yeah, I knew it was expensive to work with but wasn't really worried about it because I was just planning on holding it for awhile. But I feel like LND is going to rocket over the next year, especially when it hits more exchanges, so I really wanna get in on it early. Have you read anything about it?
You can purchase LND through Coinbase Wallet.