LND has the option to use Bitcoin Core as the full node backend.

bitcoind will default to server=1. bitcoin-qt will not. So if you want to use the RPC server while running bitcoin-qt, you need to set server=1

This argument relies on a model where the Lightning Network is in a degenerative case where it is a linked list and not a well connected graph. From current testing and use of the Lightning Network on both testnet and mainnet, we can clearly see that the Lightning Network is not this degenerative case and is instead a well connected graph. If a channel is chosen as part of a route going one direction, it can also be chosen for a similar transaction going the other direction, and that would re-balance the channel.

Furthermore, you can limit how much you allow in routes through your channels. So if B wanted to ensure that he still had money to pay C, he can refuse to route A's transaction of 10 BTC. A would instead have to find another route, which, given a well connected graph, is not very hard.

I would suggest that you not try these as those are things that can get you in trouble with the law. Well, having an insult is fine, but distributing malware is not.

No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.

Merit sources tend to be higher ranked and trusted members who have a history of making quality posts. A newbie does not have that history of quality posts nor are they trusted. Those come with time and experience. Thus it is unlikely that a newbie would become a merit source.

Unless you are using uncompressed public keys (and very few wallets do this anymore), the input multiplier will be 148 instead of 180.

Channels do not have an expiration time. The commitment transactions are not timelocked, nor are they HTLCs. The HTLCs are used for routing payments, and those are timelocked.

Looking through my open channels and through the network graph, it seems like a timeout of 144 blocks (aka 1 day) is the most common.

Bitcoin Core is written in C++ which is a compiled language. Thus it needs to be compiled in order to be run. Compiled languages are used because they give more control over memory management and are more efficient and optimized/optimizable than scripting languages which do not need compiling.

That's not at all how lightning works.

Neither. It does neither.

The fork would presumably use the witness program versioning thing that segwit introduced. This would mean that it uses a new witness program version, so older software will just ignore it as it is a new version it does not understand.

No. It is not a sub-blockchain. LN is not a sidechain. LN is not a blockchain in any way, shape, or form.

LN does not require any consensus changes. It itself has no consensus protocol. Thus there is no way to have a fork because there is no consensus to change. The LN protocol is extensible, and changing it just means bumping a version number. There is no forking.

The lightning network is not a fork nor does it do anything with Bitcoin's consensus rules. It can't really be hard forked unless the underlying asset (aka Bitcoin) is forked. LN works on top of the blockchain; it is not its own separate coin with its own consensus rules.

It will likely be the same as that is just following the BIP 9 specification.

Again, there currently is not BIP nor is there an actual proposal for using this in Bitcoin yet. We won't know the actual details until that happens.

There are already people using LN on mainnet. There does not need to be a release of LN (whatever that means) or for it to "go live". It's not a central thing where one group can announce that it has "gone live".

Some stats about the LN mainnet can be found here: http://lnstat.ideoflux.com:3000/dashboard/db/lightning-network?refresh=5m&orgId=1. A graph of the nodes can be found here: https://lnmainnet.gaben.win/

Multiple people are accepting LN mainnet payments such as TorGuard: https://twitter.com/TorGuard/status/950383059735646209 and Blockstream: https://store.blockstream.com/

Deployment will need another soft fork, and it will be BIP'ified as usual.

You can always stop a node after syncing to a certain block height, backup the datadir, and then resume syncing. Now you will have a copy of the datadir before any forks and just copy and paste that datadir into the datadirs of forked clients to sync their forked blockchain. Since the pruned datadir is small, there isn't much additional disk space taken up by doing this, and way less than if you didn't prune the blockchain.

Thus far the only fees that I have observed have been only one satoshi per hop. Granted that's on testnet.

One problem I see is that if a lot of people are buying stuff at the same price, there may not be enough unique numbers that can be generated that have a negligible effect on the amount that the customer is actually paying.

It will likely only be available for addresses beginning with bc1, and even then it won't work with all addresses that begin with bc1. Rather it will likely only work with those addresses which encode another witness program version (the current ones are for witness version 0). This is because introducing signature and key aggregation will need to use new script opcodes which are more easily introduced via a soft fork in a new witness version. Basically, since Bitcoin does not currently support key or signature aggregation, new script opcodes will need to be created that do support those things and the only way that they can be used is if new outputs use them. Thus all current outputs that do not use those currently nonexistant opcodes will not be able to use signature or key aggregation.

Note that this is not a guarantee. There has not yet been a proposal for implementing this in Bitcoin. All that we have so far is just the cryptography itself. So perhaps someone will think of a way to make key and signature aggregation work with old outputs.

If the other party in all of your channels has a balance of 0, then you cannot receive Bitcoin. What would need to happen is that you either transaction and send money to someone else thus moving funds to the other person in your channel, or someone opens up a channel with you and they fund the channel.

AFAIK, currently you cannot do that. But there's no reason why that can't be implemented in the future.

No. So long as you have channels established with other people and have active connections to other nodes, you can be chosen to be part of a route without accepting incoming connections.