Yes.

And you still will-- by relaying blocks to the nodes you connect out to.

Right now there is no way to distinguish nodes that can serve blocks near the tip with ones that can't serve blocks at all.

And there are plenty of nodes that can serve everything, so adding more flags hasn't been the highest priority.  Though there has been recent progress on that.

Pruning does affect your incoming connections. If you are pruned, you are no longer able to serve historical blocks, so nodes are less likely to connect to your node. When you prune, you also remove the NODE_NETWORK service (which indicates that you can serve historical blocks) so DNS seeders will no longer give out your node to nodes that need to connections.

It really all comes down to being forced to accept things they didn't like. The things they were forced to do were:

Hold an asset they didn't understand.
Transact according to rules they had no say in.
Rely on third parties they had no contract with.
Have no guarantees regarding reliability.
Have little or no say over the way the rules might change.

And there were a lot of objections relating to the specifics of particular proposals.

For example, for bitcoin, many didn't like the involvement of the Chinese. For all they knew, North Korea might have a major investment in mining. And, of course, Ripple couldn't guarantee that people wouldn't trust validators run by North Korea.

The particular proposal Ripple was making used on-ledger, non-XRP assets. The major specific objections to this system largely boiled down to its complexity. Having to mirror part of your private ledger into a public ledger coupled with the uncertain legal status of obligations on the ledger was a problem. Did RCL actually represent a legally valid debt? Or was the debt a separate thing from the ledger entry? Could they legally hold a volatile asset like XRP, even to pay fees? And so on.

Many of these objections have faded over time. Some of them are still just as prevalent today as they were then. ILP answers almost all of these.

The rise gradual rise in PPS over the past month or so is due to years of development and now finally adoption by multiple banks.

The fact is these banks collectively could buy out the XRP surplus at these prices and that very well may be happening.

Ripple has introduced a platform and a coin for banks & it makes sense users/banks would maintain use of the XRP.

This is incredible and the value of this project has not yet been realized, just a matter of time before Google kicks in, if I recall they were involved in this project from the very beginning.

For those that called a P & D last time good luck not making any money.    

Our initial approach was to pitch to FI's to do all their transactions on a public ledger. Most of them saw the advantages, but they didn't like the loss of privacy, scalability, ability to customize rules, and so on. So we changed our approach.

But the opposition to crypto currencies is slowly changing. We're finding that FI's are becoming more and more receptive to crypto-currencies. Being able to use them off-ledger helps a lot. Most of what they're opposed to comes from the blockchain/ledger part, not the crypto-currency party. And, who knows, they may even come around on that part over time.

There are a lot of different problems all tangled up. You don't have to solve all of them to have a viable product. For example, just the lack of pre-transfer setup is a big enough problem that you could have a viable banking payment product just by solving that. Just the lack of transparency into the status of a payment is a big enough problem.

Right, and the point of ILP is that the intermediary doesn't have to be trusted, so you can use *any* intermediary. Likely, day one the intermediary for almost all payments will be whatever intermediary it is today. Maybe that's the sending bank's FX desk. Maybe it's a correspondent. So you'll get the setup/transparency benefits, but not FX/intermediary cost savings.

But the point is that you've changed the ground rules. You could argue that the Internet won't really change anything -- the same customers will access the same data, they'll just do it more quickly and in a standardized way. First, that's a big win. But second, once you have a common way to plug customers into data, you can add all kinds of new customers and new data that you didn't have before. Same here. Day one, the funds will take the same rails. But very quickly, new intermediaries and new services will pop up because they have a framework to plug into.

Just as the Internet made it possible for anyone to provide data to any user, Ripple could make it possible for any intermediary to bridge payments between any endpoints.

We've been pretty clear that our strategy is to eliminate obstacles to payments being bridged with XRP. The obstacles are eliminated whether the payment takes place on the public ledger or off it.

It's precisely the same situation with bitcoin. People using colored coins on ledger don't really help the value of bitcoins much. But companies exchanging bitcoins, even off ledger, do.

Really the location of the payment doesn't much matter.

We spent several years trying to convince FIs to make transactions on a public ledger. We had some success, but the requirement to use a single, public ledger brought huge downsides. It reduces privacy. It limits throughput. And it means everyone has to transact by the exact same, inflexible rules even though people really do want different things.

It is way, way better to have the option to use a public blockchain where its benefits make sense and avoid it where they don't.

So we changed our approach. Now, we have a software product that takes care of everything that has to happen around a payment. The actual payment itself can take place on a public ledger or it can take place using ILP. FIs seem to like this approach a lot. The objections to being forced to hold a crypto-currency, forced to transact in public, forced to rely on third parties whose performance can't be guaranteed, and so on are lifted. Now, if XRP can bridge that payment, there's no technical obstacle.

The beauty is that banks can use this system even if XRP can't bridge a single payment. And then, when it can effectively bridge one in a thousand payments, it will. And if it can ever effectively bridge one in a hundred payments, that will happen. It's a path to solve the various chicken and egg problems where nobody will invest in a system that makes using a crypto-currency even possible until there's enough volume/capacity to handle a significant fraction of payments.

Then, we can pick the best corridors and target them, and the payments will flow.

Thank you 2112 and gmaxwell!

The variable BlockMap mapBlockIndex is defined in validation.cpp

I couldn't find where it is initialized.

There is only a comment here:
https://github.com/bitcoin/bitcoin/blob/86ea3c2ff247bb2ba0fb50013c8ecdbaf8a9fe8f/src/txdb.cpp

Well technically it would still be possible if the fees were a lot smaller, but that's mostly due to spammers filling up blocks and forcing fees higher, which gets everyone sending higher fees, etc. It's not like there's much that can be done beyond that aside from increasing block size really. More transactions with fees still gives roughly a similar return, with enough volume it all works out properly.

Though Satoshi Nakamoto wanted bitcoin to be used in micropayments but because he has left bitcoin behind many unwanted developments have occurred and micropayments will no longer be possible with bitcoin. The problem lies with the high miner fees per transaction that are being a burden to bitcoin holders. If we do micropayments it is a waste since the miner fees will be much bigger than the bitcoin you send.

No doubt how is satoshi think to make it becomes possible in the future as long as bitcoin to be the right answer for the micropayments. But facing the problem of bitcoin, especially a technical solution for the bitcoin itself. It needs to get fixed asap.
Looks bitcoin still being the best answer to be a micropayment method. We are still able to send a dollar through the bitcoin.

The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.
The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.

Well the concept of BU goes against that of bitcoin - at least in practise.
With BU, you rely on some giants with their own nodes in order to transact.
Originally there was no need to depend on ANYONE but BU says no, please rely on these giants to make transactions faster... or whatever it is they really are after.
The bilderbergs don't want an economy they can't influence.