I feel like you are using "send traffic" as if it were a "score", but the point is that it is a "currency". A disconnected group of eight nodes can't "earn a lot of traffic" because to move packets you have to spend currency. The network prints new currency in the same way bitcoin does (through mining): its a zero-sum (multi-party) transaction at the packet level, with new currency coming only from mining. The disconnected group of eight nodes is just going to be transferring data between each-other, not "earning" anything.
This is covered in the FAQ as well as the paper, so I'm not certain why this is confusing. I guess I will just paste the information here, to encourage people to actually read it.
FAQ:
> Each node keeps a small ledger for all its direct neighbors, with the total packets received/sent to and from each. The node also keeps count of all the packets it sent and received for its own consumption. When the balance of a neighbor hits a certain threshold, a payment request is initiated. The neighbor in question is required to sign the payment request with its Peer Address to make the payment legitimate. The signed payment is then forwarded to a payment processor (a mining node), which will verify and add the payment to the public ledger. The miners are special nodes that use a modified version of the Bitcoin Algorithm and require huge amounts of processing power. They earn free traffic for their efforts as well. Read more on Bitcoin for more information on how this works.
Paper:
> Accounting is calculated at Layer 3 packet level. Since transaction validation is computationally intensive and adds to the network overhead, it is obviously impossible to issue payments on a per-packet basis. Nodes will aggregate routed packets and only initiate a payment request when a set threshold is reached.
> Since neighboring nodes are more likely to owe each other packets than farther away nodes and are therefore more likely to reach that threshold, payment is only initiated between neighbors.
> The payment procedure is straightforward. Each node keeps accounting information for each of its neighbors and updates their balances as packets flow to and from each. Once a threshold limit is hit, the peer that is owed traffic initiates a payment request by sending a Payment Request packet to the neighbor that owes it traffic. The neighboring peer validates the requested amount against its own books. If the transaction is deemed valid, the Payment Request is signed and returned to the initiating peer. The initiating peer now has proof that the payment has been approved by the payer and is therefore valid. It then forwards it to any Payment Processing Peer (miner) it chooses and waits for the transaction to be approved. Ideally, the reciprocal balances of two neighbors should match, unless the protocol on one of the nodes is maliciously tampered with, or due to packet loss. We will cover those cases in more detail later.
On the other side (bills) you are taking into account the currency nature, but clearly the ISP could never be in the position to pay the bill because it is just in the middle: it extracts a transaction fee for transferring the data, but whether you feel the sender or the receiver should be the one that pays for bandwidth, they would never be in the position of being on the hook for the money required, it would always be up to one of the endpoints.
As for who pays for bandwidth, the paper quite clearly and unambiguously states that it is the sender. If you think about it, it pretty much has to be the sender, as (even on the current Internet!) the sender is generally the person who can "wreak havoc" by sending large quantities of unwanted traffic at some people, whereas the receiver is by definition passive. If this is expensive for YouTube they might have to charge you a subscription fee, or charge per download, to cover their costs. (One could imagine this price being paid either in dollars, which YouTube could then barter for bandwidth currency, or in the bandwidth currency itself: the network allows random payments to be made in this fashion.)
Finally: if you upload data to YouTube and download data from YouTube, in the same amount, you and YouTube will be passing a bunch of data between each other, and the ISP will keep taking a cut of the payments. Eventually you and YouTube will be broke, and the ISP will own all of the transfer currency, for being so kind as to sit there receiving and forwarding packets all day. This might seem to cause some kind of problem (like, "now ISPs own all of us, where do we get currency"), but this is a mesh network, so there's no such thing as an "ISP". Instead, everyone is forwarding packets for everyone else, and both you and YouTube are going to be serving as "ISPs" for all of your neighbors, so while you are downloading YouTube and your friend John is your "ISP", while he's streaming Netflix, you might become his "ISP". Sometimes the bandwidth flow to Netflix might even be going through YouTube (and vice versa).