One would imagine that the whole point of working with a protocol similar to bitcoin is that this is not possible: you can't fork the network and rejoin at a later time; that would be modeled as a blockchain fork, and your chain would be shorter than the main chain when you tried to rejoin the rest of the peers and your history would be erased.

Sure, but that doesn't make any sense in the context of a network.

You're saying that if my link goes down, or if my neighborhoods link goes own ... or if my city link goes down ... I can never rejoin the network ? Or perhaps I can never spend my traffic currency ?

Of course the links will go down all the time and various (large and small) segments of the network will be "islands" from time to time (as parts of the Internet sometimes are) ... and I wonder how currency accumulation behaves at these times.

If you read the FAQ and skim the paper, the idea is that a ledger is used between neighbors for temporary imbalances, with the hope that the routing mechanisms generally lead to bandwidth in both directions being fairly equal; when this is not the case, and one node owes a non-negligable sum to another node, it requests payment, and sends the signed transaction to a miner for inclusion in the blockchain (the document states that it purposefully doesn't go into the bitcoin parts of the mechanism, only documenting three changes, none of which are to the centralized blockchain). So, yes: if your city gets disconnected from the Internet, you will be unable to spend currency (but you will still hopefully be able to transfer some packets, at least temporarily, as long as you don't reach the de minimis accounting threshold).

I still don't understand.

First, it's not very clear, but in some cases you must consume the "traffic" you have stored, by using the network or buying it with money. If not everyone will be have plenty of "traffic". "The payment system ensures everyone is doing what they’re supposed to."

So the 8 interconnected computers earned a lot of "traffic" but also consumed a lot of "traffic". (This can work even if the 8-computer network is connected by a small bandwidth connection to the main network.)

If node A sends a lot of packets to B and B sends a lots of packets to C, who will earn the "traffic", A or B? Who has to pay for the "traffic"?

If I download a full 3 hours movie from Youtube, who has to pay the bills? I, my "ISP" or Youtube?

If I upload a full 3 hours movie to Youtube, who has to pay the bills? I, my "ISP" or Youtube?

If I download a full 3 hours movie from Youtube while I upload another full 3 hours movie to Youtube while, is it free for all?

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).

Thanks. This is a more sensible model. I think I misunderstood the word "balance" in the sentence:

> 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.

as payment is requested when "#sent-#received > threshold" (or "#received-#sent > threshold"), but it didn't make sense.

If your city goes down you'll probably not have much use of that internal network, the majority of services you access will be outside of your city, so you'll only go there and change that broken cable.

I think the solution for this problem is a single blockchain of network traffic. If your libernet is isolated from the rest, then the computing of the network traffic wouldn't make it into the shared global blockchain.

This is why the only two options we have right now are a) volunteer-based carriers and b) market-based carriers. Some in-between probably won't work very well.