Pruning nodes are described in the sourcecode thusly:
-prune=<n>: Reduce storage requirements by pruning (deleting) old blocks. This mode is incompatible with-txindexand-rescan.
I’ve watched that my node has been consistently uploading less than it has been downloading since I set it to run in pruning mode.
From release notes https://bitcoin.org/en/release/v0.11.0 :
For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.
In the current version pruning nodes don't advertise themselves as having any blocks, so they don't upload blocks. So that explains your big reduction in upstream data. A future update will re-enable block relay in such a way that your nodes can efficiently let its peers know which blocks it owns and which it doesn't.
Yes your pruning node will do full validation and it will service lightweight nodes.
Pruned nodes do not advertise NODE_NETWORK. Thus, peers will not request buried blocks from them. However, pruned nodes relay blocks at the chain-tip and newly received transactions to their peers.
In 2017, BIP159: NODE_NETWORK_LIMITED service bit (Pull Request) proposed an additional service flag with which pruned nodes could advertise being able to serve the latest 288 blocks and thus most of the lightweight client requests. Support for NODE_NETWORK_LIMITED was then added in 2018 with Bitcoin Core v0.16.0 signaling NODE_NETWORK_LIMITED and Bitcoin Core v0.17.0 starting to make outbound connections to nodes signaling NODE_NETWORK_LIMITED.
A pruning node will trim the number of transactions you need to store. In the most extreme cases, they can store just the UTXO set and the most recent couple blocks, but the degree of pruning is variable, and up to the node operator. Think of it like this:
Alice sends 5 BTC from address 1www to Bob, at address 1xxx.
Bob sends 2 BTC to Carl at address 1yyy, and 3 BTC to Dave at address 1zzz.
Carl sends his 2 BTC to Dave at address 1zzz.
A normal node would need to store all the intermediate data, that is, (Alice -> Bob), (Bob -> Carl), (Bob -> Dave), (Carl -> Dave).
A pruning node, however, only needs to store the final link in each step. If Alice has no more coins in her address, there is no need to keep it around, you can safely discard it. The pruning node would only contain the data for the UTXO set, in this case, the 5 coins that Dave has.
Pruning nodes can validate transactions, verify that the sender does in fact have coins to send, and relay them to the rest of the network. They can also be used by the owner to check their balance completely privately, no need to ask someone else who has a copy of the pruned chain.
bitcoind that does have the utxo set and n MiB of the blockchain. In my case that is 20,000 MiB. I'm wondering whether my node serves these blocks to peers as full nodes without pruning do, and especially whether it can serve SPV clients - which I doubt, but if they are asking about recent nodes would be a possibility.
prune doesn't advertise itself as able to serve blocks.