You cannot verify bandwidth sharing in a global money supply. You need long lived nodes with reputation and credit. Each node must issue its own money and then trade these credits on automated markets.
There is no block chain in this model. You really need a ripple like model for the nodes but I suspect it will be too inefficient.
I spent months designing tornet to find a workable economic model and you would do well to understand my design as a starting point for improvement.
I try to understand it fully, but I have some doubts.
Supposing that connections are never made directly from peer to peer, but they always pass through a chain of nodes like in Tor, each node can verify the amount of bandwidth that it delegates.
Propagation can happen in chunks (for example, 100K each), and every chunk comes signed from both the originator and the reciever, and all the nodes it traverses. For every block traversed, there is an amount of coins generated.
Now, I know what you are thinking: any malicious attacker can create a short circuit and become itself the originator, the nodes, and the receiver, creating money from nothing. I suppose this attack can be called "self-fake-serving". That is why I've been thinking about a solution that I have not yet written because there are some issues, but bassically it can be described this way:
Not a single node can choose the nodes it connects to, the receivers or the originators. Receivers and originators cannot, too.
A list of nodes and their IPs will be in a signed pool in the cloud, and downloaded by every single server every 10min. This pool must be signed by every server that wants to enter into the system, so for every IP listed there, there is a signature corresponding to the public key of the node using that IP. We can make this pool to be efficent to download updates, just by sending diff requests every time a new node is connected.
Now, when a reciever wants something, it is given a random node it must connect to. How to make it really random? We use a mathematical formula (I haven't thought about it yet) that relates his public address to the obtained hash of the full pool. Users trying to connect to a node which is not assigned are banned from the pool.
Nodes that doesn't transmit anything or transmit something which is not requested are banned from the pool and they can't earn nothing.
Recievers and nodes check that the node before it in the chain is acting correctly. If not, it marks that node "banned" in the pool, and then other nodes comes and verify that is true by checking what was solicited and what was served by the conflicting node. If it is true that the node is trying to scam, then the node is marked banned permanently (or for some period of time). If it is false that the node is not trying to scam, then the denouncing node is marked as banned.
Well, and how this relates to a block chain? I have yet to think it, but I'm thinking that every update to the pool could represent a new block. We can make the blockchain space-efficent by only storing changes from previus blocks. We could also protect IPs in some way so to make this fully anonymous, and I have to think about this too.
I'm wondering how your Tornet and Proof-of-Stake ideas could be related to this.