After experimenting for some time trying to set up a bitcoin full node using BTCD, an alternative full node implementation, I discovered a bug that in my opinion is a dealbreaker until the devs invest some effort into fixing it. While trying to sync my node to the network, I noticed the time to sync blocks continued to increase as the block height rises. My fear is that eventually the time to sync a block will exceed the rate that new blocks are generated. You can see this behavior in a plot of sync times collected from the log files - the two day gap in the data is from where I stopped syncing to mess with config files.

Community member l0k1verloren explains in the github issue thread that he believes the fixes required are quite extensive. The main developers have not said much on the issue.

Hello Zapread,

I'm trying to set up a lightning node in a docker container. But I run into an issue when starting LND at the unlock wallet step. When prompted to type 'lncli create' to create a new wallet, the input seems to hang and nothing happens. Does anyone know why this is happening? It's probably something trivial that I'm overlooking

Steps to reproduce the problem

• git clone https://github.com/matt24smith/arch-lightning
• make build && make run                      # from inside the cloned repo
• lnd --bitcoin.active --bitcoin.testnet      # start lnd inside the container
• lncli create
  

I have the .lnd and .btcd folders configured as separate docker volumes for persistent storage of the blockchain history, I'm not sure if this is part of the problem

"It`s easy to send btc on-chain to someone. You just need their address and nothing more. You can send to it as many times as you want. This hurts privacy, but makes everything really easy for the sender. A charity can simply put their Bitcoin address on their website for example and anyone could donate to them. It`s not the same for Lightning. Since a different invoice is required for every single payment, a youtuber would not be able to accept donations over the LN easily, just on-chain. The goal of this proposal is to make it possible to do both.

Since any message can be routed and sent through the LN we could also make a request and ask our recipient`s node to generate an invoice for an amount chosen by us and then send it to us, just like those text messages. Then we can decode this invoice and if everyone is OK (the amount is correct) we can attempt to pay it. All of this can happen under the hood. The UI/UX doesn't even need to change much. Instead of pasting an invoice in the "send" field of a wallet, we just paste a node's public key.

Allowing anyone to make our node generate invoices is a bad idea. They could send a million requests and crash it. To prevent denial-of-service attacks, we should implement the following measures:

1. Auto-Generated invoices should be with short expiration times. 10 minutes for example.

2. A maximum of X invoices can be generated for a given node at a time. Let`s say X = 10. Once a node has requested 10 invoices it can request another one only when a) at least one of the previous 10 invoices has been paid or b) at least one of the previous invoices has expired.

3. Nodes which have requested Y invoices, but haven't paid any of them could be banned from requesting new invoices for a day. If this behaviour continues the node could be permanently banned and any channels opened with it could be closed. Maybe an option to manually override this ban would be nice to have. A good value for Y might be 30.

4. Nodes which have no channels open should not be allowed to request invoices. This prevents an attacker from spinning up 1000 nodes and requesting 10000 invoices from us.

The idea is to be able to send bitcoins over the Lightning Network to a static node`s public key, instead of having to ask for an invoice each time. The LN itself could be used to route requests for new invoices and the answers to those requests between the sender's and the recipient's nodes. The recipient`s node still needs to be online though. Maybe if we combine this with something like Lightning Rod we could achieve the same experience as with on-chain Bitcoin payments.

It`s also worth mentioning that one would not be able to do this for every node. Older nodes which have not upgraded to newer software which supports this new protocol addition simply won't know what to do when they get such a request and they won't reply with an invoice. If we want consistency we need everyone to upgrade. Or the vast majority at least."

=== === ===

Nice series about lightning and the protocol development:

https://www.youtube.com/playlist?list=PLpLH33TRghT17_U3as2P3vHfAGL8pSOOY

enjoy.

I've noticed more activity recently on the LND github page.

Particularily here: https://github.com/lightningnetwork/lnd/tree/master/watchtower 

Watchtowers are coming!

What is a watch tower?

A watch tower watches transactions on the LN for you and checks for counter-party cheat (which reveals a cryptographic secret).  Using this, the watchtower is then able to transmit a punishment transaction and sweep the funds from the cheater into your wallet.  

Of course, your node can be online to watch for this, but a watch tower serves as a backup in case your node is offline for a long time.

Watchtowers are already available for the Lightning Bitcoin Wallet on android.

With this security feature, LN will be even easier and safer to use!

Saw the other post about creating channels with each other and thought it was a good idea but it's been 2 months since last activity. Hope you all don't mind a new thread.

I'd be happy to create channels with others. Please let me know which node is yours. I can create the channel first.

My mainnet Lightning node is at 027[email protected]23.239.23.44:9736

Don't care about capacity amounts or if they match. Say hello and let's make the lightning network stronger!

More features coming to lightning hopefully soon.

Hey Everyone, I have been fortunate to be invited to the BOLT1.1 spec meeting in November in Australia. There is an ongoing open agenda out with the topics that one would expect to be be discussed there like:

• Dual funded channels
• Splicing
• autopilot
• AMP
• watchtowers

and a few more technical points. If anyone here has some features missing in the lightning network it is now the time to state them and I can try to put them on the list for BOLT1.1. I will probably focus most on splicing and autopilot features but I am looking for your input.

This is a live stream I did a few moments ago. I am also a gamer so I just continued into gaming after. I'm down for LAPP development,  I need to watch more on programming. 

Lightning Network Node Update