"Is there a way we can [see] the number of Bitcoin nodes or downloads, worldwide or per country?"
"What is the difference between reachable and non-reachable nodes?"
Yes, there is a way you can [see] the number of Bitcoin nodes.
One of the places to [see] that is a website called Bitnodes.com.
It shows you an interactive map, which you can zoom [focus] in and out of.
It [displays] little blue dots for where there are Bitcoin nodes running.
As far as downloads worldwide, I believe GitHub has certain statistics, but there are so many different ways...
you can download Bitcoin, from so many different sources,
that it would be difficult to get an accurate number for 'downloads per country.'
"What is the difference between reachable and non-reachable nodes?"
Some nodes have opened, and are advertising access to, the specific TCP port for Bitcoin (8333).
That means other computers can connect to them on the public Internet,
because their Bitcoin port is accessible on the public internet.
In order to do that, you need either a computer that is not behind a network address translation system,
Usually home wireless routers and firewalls have network address translation (NAT).
Or [you need] a network address translation router that has Universal Plug and Play (UPnP),
so that it can open and forward ports inside.
You need to do a bit more setup to make your Bitcoin node accessible from the public Internet.
A lot of people don't do that due to various concerns,
including that [they may not want to] advertise they are running a Bitcoin node.
People can [see] that and correlate it with their IP address, which is not necessarily a big risk,
but it does appear to be a concern.
It is technically more difficult [to set up], so they [might not] figure out how to do it.
Of course, there are nodes which are deliberately hidden, running on top of "The Onion Router" network (Tor).
Bitcoin nodes running [over] Tor, on onion sites, are accessible over the Tor network,
but nobody knows exactly where they are.
Nobody really knows how many reachable vs. non-reachable Bitcoin nodes there are.
In order to find a non-reachable node, it must reach out and connect to you,
or a node that is keeping track of IP addresses.
There are some software projects attempting to count these by [looking at] IP addresses found online.
The bottom line is, we estimate that there are approximately more than ten times the number...
of non-reachable nodes than reachable nodes.
Let me just correct the terminology [here], which is "listening" nodes versus "non-listening" nodes.
Listening nodes are the reachable ones in the public internet; non-listening nodes can make connections out,
but they are not listening for connections coming in, not available on the public internet in that way.
We estimate that, for the approximately ten thousand listening nodes that [run] today,
there are more than a hundred thousand non-listening nodes [running out there].
But again, it is very difficult to get an accurate number.
"Why did the number of Bitcoin nodes drop after March 2018?"
I don't know which chart you are looking at, but I don't really see much of a drop.
Probably the best site for looking at [the number of] Bitcoin nodes, that I know of, is called Bitnodes.com.
[I see] a peak of about ten thousand [nodes] in March, while today's [node count] is 8,207.
It has gradually declined, but not really by that much.
My guess is, part of the reason the [node count] goes up or down is reflective of the interest in cryptocurrencies.
The interest in cryptocurrencies is correlated to the exchange rate of bitcoin.
When the price goes up, everything [seems] to go up.
Excitement, attendances at meetups [and conferences], website hits, views of my YouTube [videos], sign-ups...
for [this massive open online course] (MOOC), and of course the number of nodes that people start.
People try to start nodes to learn more about Bitcoin and want to participate.
Then the price drops, people lose interest, and the number of nodes goes down.
That is not a big deal. [The node count] has been around eight to ten thousand now for several years.
It doesn't vary that much. There is a core of dedicated users who are fairly persistent at running nodes.
Most likely, these nodes are related to professional users and purposes.
I think that is why we saw a slight drop after March.
When the price goes down, there comes a point where the people who have only been holding [bitcoin]...
for a couple of months and hoping for a [quick] rebound, finally give up.
That is what happened in March.
"Since the Bitcoin network highly depends on fully validating nodes, was there or will there ever be...
an option that will implement incentives for people to run full nodes, for Bitcoin or any other altcoin?"
Many other alt-chains do have incentive schemes for running full nodes, in various forms.
Most of them use a process called proof-of-stake, but Bitcoin [does not.] [It uses proof-of-work].
Mostly, there are two reasons why you would run a fully validating node, not even necessarily a full archive node.
The two reasons are: because you want to contribute to the health of the network, and you want to validate...
transactions [independently] yourself, because you don't want to trust a third-party.
If I want to know that one of my recent invoices has been paid by my clients, I will not trust a third-party.
I will ask my own node if the transaction has been confirmed on the blockchain.
I know how my own node is configured and what consensus rules it is running.
Therefore, I trust that validation on my node.
The other reason people would run full nodes is because they are [managing] a business.
If [someone] is doing e-commerce and they want to receive payments,
they can't (or rather, they shouldn't) trust third parties.
[Otherwise], you are not really participating in Bitcoin. You might as well [use] PayPal [instead].
By running a full node [as part of the infrastructure of] an e-commerce store,
when accepting large payments from clients, or any kind of business that depends on [independent] validation...
[of the] system, you are sure that a third-party can't cheat you by presenting false information.
You don't trust anyone, you validate your own [transactions] with software you choose to run,
according to the consensus rules that you choose.
"Are nodes backwards-compatible? If I have Bitcoin Core 0.14.x, and the latest version is 0.17.x,
can I still function or am I forced to upgrade?"
For the most part, yes, [the Bitcoin Core] node [software] is very backwards-compatible.
In fact, that is one of the elements of conservative software development.
It allows you to validate and remain in sync with the network, even with a very old node.
Part of that is the choice to do soft forks instead of hard forks; this allows old nodes to continue...
operating on the network without making them incompatible when syncing the blockchain.
The trade-off, however, is that unless you upgrade them, older versions may suffer from security vulnerabilities.
[What if] you have Bitcoin Core 0.14.x?
Well, if you [are running] 0.14.0 as it was released [originally], you may have a problem.
But Bitcoin Core is maintained for a couple of releases. Recently, for example, I believe 0.14.3 was released,
which fixed the vulnerability that was just discovered; that is something you would want to upgrade, at least...
[to the next] incremental release to fix the vulnerability.
Your 0.14.x node will continue to sync the blockchain. It is compatible and remains in sync [with the network].
The other trade-off is, older nodes validate less.
Because of soft fork changes which have occurred, older nodes will see certain types of transactions...
and not fully validate the details behind them.
In the case of Segregated Witness transactions, a 0.14.x node will misunderstand every [these] transactions...
as one that could be spent by anyone.
It will [mis-interpret] the script [of SegWit transactions] as anyone-can-spend, which isn't the case.
The validation rules of SegWit would prohibit that.
But to an old node, it looks like a transaction with looser rules.
That allows a 0.14.x node to still validate a SegWit transaction without really validating the signature,
while continuing to operate and sync on the network.
That way, it won't become incompatible with the blockchain.
That is a deliberate choice, to do that as a soft fork, which we will talk about more in a second...
"What are the important differences to know about using Lightning wallets, compared to a regular Bitcoin wallet?"
"Are there differences? What is the difference between a Lightning node and a Lightning wallet?"
That is a great question.
Theoretically speaking, if we have an ideal design, there is probably very little difference between...
the user experience of a Lightning wallet and the user experience of a Bitcoin wallet.
In both cases, the fundamental function of the wallet -- which is showing you a balance in different units...
[For example], you have x number of satoshis, millibits, or microbits,
versus expressing [that value] in a fiat currency, "your equivalent balance in U.S. dollars is x."
That is the function of a wallet, and it would be the same in a Lightning wallet or a Bitcoin wallet.
[A wallet asks] whether you want to send or receive.
In terms of receiving, the wallet will present a QR code or an address that you can give to someone else.
When you want to send, it can scan the QR code or you can paste an address that you have received...
through some other channel, and send to that address.
When you decide you want to send, you decide how much you want to send and what fee you want to pay.
Well, in those cases, a Lightning wallet looks very similar [to a Bitcoin wallet].
If you want to receive money with a Lightning wallet, you must say how much you want to receive.
It will generate a QR code or a long address, which is actually called a Lightning invoice.
It looks about 2.5 times longer than a traditional Bitcoin address.
If you give that to someone else, they can make a payment to you. In that way, it is not different than:
"Here is my Bitcoin address. Pay me." It is: "Here is my Lightning invoice. Pay me."
One of the big differences, at least in the current stage of Lightning, is that people can only pay you...
if you generate an invoice for a specific amount, which means there is [usually] an interactive step there.
You can't simply give them a Lightning address and say, "Pay me whatever you want, whenever you want,"
and keep giving out that address to different people.
You need to generate an invoice for a specific amount. There are some proposed changes to get around that.
But for now, that is one difference in the experience that you will find.
For example, if I wanted people to give me donations on Lightning, the same way that people can give me...
gifts with [on-chain] bitcoin, I have an address published on my website and everybody knows what it is.
If somebody wants to give me a gift, they could [copy] that address, send whatever amount they want,
and that is a gift.
If I wanted to [offer] the same with Lightning, for people to send me [bitcoin over Lightning],
[there would be] a couple more complicated steps, at least in the current state of the technology.
[I would need to offer] a form on my website [where] they type in the amount, press 'Submit,'
[which sends a request to] my Lightning node to generate an invoice, [send it back] to their screen,
and then they can send the Lightning payment for that amount [as a donation].
So it is [currently] a bit more complicated, from that perspective.
In terms of sending, it is almost identical to a Bitcoin wallet.
You would scan the QR code, or paste the address (called a Lightning invoice) and hit 'Send.' That is it.
Very similar. You [might] not be able to see a difference.
Ideally, I would like a user experience that combines [on-chain] bitcoin and Lightning wallets into one.
There is no reason why you [need] two different wallets.
You should be able to have one wallet that can make payments either on-chain or off-chain.
If you scan a Lightning invoice, [then your wallet should] make a Lightning payment.
If you scan a regular Bitcoin address, [then your wallet should] make an on-chain payment.
There are even some proposals to include both.
Imagine that you scan a Lightning invoice and it doesn't work for you,
for whatever reason; you can have a fallback Bitcoin address to do an on-chain payment.
It looks [almost] identical to any other method. You could have one interface do both.
I think that would be ideal. There are some minor details that should be carefully abstracted in the user design.
The second part to this question is, "What is the difference between a Lightning node and a wallet?"
At the moment, there isn't much difference. Most Lightning wallets are also Lightning nodes.
Just like in the early days of Bitcoin and Ethereum, if you wanted to have a wallet, you needed to...
download a full node implementation and sync [with the rest of the network].
We didn't have lightweight wallets that used a node somewhere else.
Those didn't exist in the early days of Bitcoin. Now we are in the early days of Lightning.
Most Lightning wallets are closely coupled with a Lightning node [implementation].
Theoretically, you could separate the key management capability of a wallet from the network management...
and protocol of a node.
Your wallet could talk to a node to get information about the network, but sign transactions on the wallet only.
You [will be able to] eventually separate these two elements of the architecture, but for the time-being,
almost all of them are [together].
Every wallet is a node today. We will see how that changes in the future.
There are a few web-based wallets, but those are hosted wallets, where you aren't really running a wallet or node.
That is somewhere on a website and somebody else has the keys.
Guess what? On Lightning, just as much as in Bitcoin: your keys, your coins; not your keys, not your coins.