I realize that you are right, and I was wrong here.  There is indeed a solution I didn't realize.  If A, B, C, D and E are linked in a ring, of course, by the direct links, A can pay B only until the AB channel is exhausted.  But I forgot that A can also pay B by sending through the AE, the ED, the DC, and finally the CB channel.  I stand corrected. 
So, half of the time, A pays B though the direct channel AB, and when that reaches its limits, A pays B "the other way around". And then again in the direct sense.
Thank you.

did you mean "impossible" maybe ?  Because it is NOT possible to provide a service with only revocation keys and without other private keys.

Well, usually there's a money flow and an opposite goods/services flow, and these flows tend to be conservative, that is, flow in circles ("div B = 0" if you are mathematically inclined).  

Usually, money flows from my employer to me, from me to the bakery, from the bakery to his supplier, from the supplier to the farmer, from the farmer to the store, from the store to my employer, to make it simple.  I rarely pay my employer, my bakery rarely pays me, the supplier rarely pays the bakery, the farmer rarely pays the supplier and the store rarely pays the store.  Look at your bank account: you usually receive money from certain entities, and you usually spend money to other entities.  There's rarely a back-and-forth motion.  With all these entities, there's no point of opening channels.  They will quickly get exhausted.  It is more interesting for all of these entities to connect to a "single settlement node".

If we want to do this with a LN network, the only solution is to have a central node (a bank).  Otherwise, channels will always get exhausted, because they always need to flow in the same direction.  Yes, you can replace that central node by a "web of central nodes".  But my employer, me, the bakery, the supplier, the farmer and the store have no reason to have links between them, only to that "central web".  And inside that central web, if similar flows have to flow in systematic circuits, they all have also a reason not to connect along the periphery but only to a more central part.  And so on.

The ideal LN structure is hence a single central hub, with all others connected to it.  It is the only structure that can support indefinitely all possible "circles of money flow".  That's not even a criticism.

My comment was for scenario 2, not 1.  You have to have your keys at disposal all the time when people use your node.  There's no way to be an intermediate node on a payment route, without using your keys.  Some formatting of the posts went wrong I think.

One can also think that this kind of image is simply rhetoric.  Association of "the product to sell" with other things that have a positive image is the basis of publicity.

I don't see how this is possible.  After all, "using your node" means: updating your balances, and to update your balances, you have to half-sign transactions with your partners.  For that, you need your keys of course.  If updating your balances were possible without your keys, it would be frankly scary !

If you are Bob, and you are connected to Alice in channel 1 and to Joe in channel 2, and Alice wants to pay Joe through you for, say 0.1 BTC, then you have to exchange updated half-transactions with Alice where your balance in channel 1 increases, and you have to exchange updated half-transactions with Joe in channel 2 where your balance in channel 2 decreases.  In other words, you have to pay Joe.  Obviously, in order to pay Joe, you need your keys !  But also to update the state of the balance in channel 1.

I could give you a simplistic answer, but it wouldn't be the right answer.  The simplistic answer is: yes, of course bigger blocks.  However, I think that a single question, like, "are you for bigger blocks" misses entirely the point, simply because everything influences everything.  That's like asking a doctor "are you for or against chemotherapy".

I think bitcoin has fundamental design issues on the deepest conceptual level, that far overshadow the simple question of "bigger blocks".  I think bitcoin is fundamentally broken on the following points:

- the PoW consensus mechanism that is too wasteful and leads to centralization of power, even though it is a very good consensus (no dispute) mechanism, it doesn't provide the other desired factors, on the contrary.

- the fact that the consensus mechanism is remunerated (which, in itself, is necessary for PoW), which gives rise to a lot of game-theoretical issues and is the motor of centralization, by "economies of scale".

- bitcoin's coin emission curve, which links erroneous monetary theory, market speculation, crazy power consumption and security in one big clusterfuck

- bitcoin's lack of anonymity and hence lack of fungibility

In the face of these issues, the block size question is in fact of minor importance: when the overall structure is ill designed, you don't care about smaller design failures.

But if you tell me: "we want to keep all that, and for some or other reason, we think it is the right system", then it is obvious that block size is really not an issue, because, as I pointed out elsewhere, bitcoin is a client/multi-server system, not a P2P system (which itself, is a consequence of PoW and the remuneration of it).

Here's that post: https://bitcointalk.org/index.php?topic=2852931.msg29426613#msg29426613

That doesn't mean that I think that things like the LN are necessarily a bad idea: there can be useful applications of this.   For instance, high frequency trading is a perfect application of it. But not to solve the non-existing scaling problem.  There is no scaling problem in bitcoin's model, and Satoshi even explained that already in November 2008.  You simply have to accept that bitcoin is not a P2P system, but a client/multi-server system.  That is the natural consequence of the design principles of bitcoin, and that is also what is de-facto observed today.  In a client/multi server system, there's no scaling problem, and blocks can be of huge size, because they only need to be kept on servers that have in any case way higher expenses than the data volume it represents.  I repeat that the non-P2P nature of bitcoin is not something that has to do with block size, but is the natural consequence of the PoW design and remuneration of bitcoin, no matter what block size.  You automatically split the ecosystem in "miners" and "users" and you get a power law distribution in the "miner" business, that limits the amount of "servers" to a small number.

PoW was a good P2P thing when people could use their PC.  However, the following aspects of bitcoin rendered it a killer of P2P:
- the all-or-nothing nature of block remuneration.  There are only 52000 blocks to be won per year.
- the increasing difficulty (which in itself is related to the emission curve of bitcoin, which in itself makes it bad money and good speculation)
- the possibility to have specialized hardware outperforming general-purpose computers, leaving it to "specialists"
- the possibility to pool mining, which brings an advantage to flatten out statistical fluctuations.

There has been a lot of disinformation around this entire issue.  People seem to refuse the natural consequences of the design principles of bitcoin (even though Satoshi explained that projection already in 2008), and invented an entirely bogus story about "decentralization".  Mind you, that client/multi server system can work very well !  In fact, there are incentives for the "multi servers" to continue playing by the rules, even if this thing is not decentralized as a true libertarian would dream it.  And that's why bitcoin is functioning even though the power in in the hands of 3 or 4 entities.  All this discussion is about a religious notion of "decentralization" which is not possible in a system like bitcoin, not because of blocks, but because of the design problems I mentioned higher up.  But it works.

I think that the LN invention, in itself, is a good thing, which is why BCH lacking it, is a problem.  But I think that keeping the silly block limit in bitcoin, is a crazy idea too.  The problem with wanting to promote the LN as a "second payment layer", which is in my opinion, a bad application of the LN technology, is self-contradictory for the following reason.  The LN as a second layer only makes sense if the block chain is congested, has high fees, and "pushes people off-chain.  Otherwise, people would use the block chain.  But when  the block chain is congested, the LN becomes less secure !  And if the block chain works well and can easily guarantee you your opening and settling of channels without a hassle, there's no need for it.  I think this has been entirely misguided.  The LN has much better NEW applications, like HF trading, atomic swapping and so on, but also securing your holdings on an exchange.  It can eventually be used for special cases where a lot of fast micropayments have to be made between a limited set of players.  But it is a bad idea IMO to think it should replace the fundamental function of payments on chain.

Only if you give your keys also to that web service.  In other words, your bank.  You have to stay online to be able to sign at any moment with your own keys.  If you want another service to do so while you are offline, you have to give them your keys.  But then, they have your coins.  Like an exchange, or a bank.

In fact, the only safe way is to have the server hardware in your own place (say, an old PC running in your basement).  Even using a VPS service on which you run your own LN wallet is not safe, because of course the administrator can access the keys of the wallet if it has to run.  You cannot keep them encrypted, because the wallet software needs to access them all the time.  So the only safe way to run an LN wallet, is to run it on a clean machine over which you have physical control.  In exactly the same way as you do bitcoin transactions right now.

We have an almost exact carbon copy of the 2013-2014 situation, except that it is grossly x15 scaled up.  Last year, we didn't come out of a monster-run up.  This is the typical behaviour of a speculative bubble bursting, like it burst in 2013 (and in 2011).  The remarkable thing in bitcoin, is that it keeps coming back.  Usually, an asset that bubbles, is dead afterwards, but bitcoin is like the Phenix, rising from its ashes.

You have to understand the mechanism of speculative bubbles.  Last year at this time, there wasn't any.  This is why short-range price analysis doesn't work.  There wasn't an army of bag holders.  In fact, once we broke the last ATH around $1100, the last bag holders from 2013 got free. You have to understand that after a speculative bubble, there's a whole army of burned newcomer-greater-fools, half-panicked at their stupid move of buying at the top and being a bag holder.  It is the behaviour of that army of bag-holders that determines the crash that follows.  If you look at the volumes last year during the run-up, there must be a huge amount of frustrated bag holders that curse themselves they got into this foolish game, and only want one thing: get out with limited damage.  The more they try to get out, the lower the price gets, and the lower the price gets, the more "early birds" of last year start feeling uncomfortable, cashing out before it is too late.

It is only when this huge, invisible sell wall is eaten, that one can get higher again.  Given the huge amount of money that people spent during the run-up, that wall is huge.   In the beginning, this is compensated by "bargain-buy-the-dips" of others.  But as they get somewhat burned too, they will wait until it "bottoms out".    With a big, and increasing army of burned bag holders, and less and less "dip buyers", more and more "waiting for the bottom", it can only go down until all of this is resorbed.

Yes.  And no.  There is a huge difference between a payment system and a network system, and it is very important to understand this.  The comparison with the TCP/IP stack is tempting, and from a pure engineering viewpoint, it looks like it.  But this is a big misunderstanding of some very fundamental issues.

First of all, even though this sounds like blasphemy, one has to understand that bitcoin and bitcoin-like coins, are not a network, but a data set.  This was already clear in Satoshi's writings in November 2008.  All value in bitcoin, all meaning in bitcoin, resides in a data set.  The network is simply a tool to access and build the data set, but the network as such, has no value. You can do what you want on the network, if it doesn't influence the data set, it has no meaning in bitcoin.   That data set is the block chain.  In bitcoin, a transaction doesn't have meaning if it is not included in the block chain.

So this is already a fundamental difference with the TCP/IP stack.  There's no "underlying data set" in TCP/IP.

The next point to understand, is that bitcoin has a very specific rule to make sure there's only one agreed-upon data set: proof of work.  This system has evolved in such a way, that there are a very limited number of entities that actually (can) MAKE this data set.  There are many, many less entities that actually write in this data set, than there are users of the system.   There are at most something like 20 entities that write the data set (of which 3 or 4 write more than half of it, 10 write about 99% of it).  These few data set writing entities are in a competitive game that makes it necessary to have high-quality data links amongst them.

Users of the system (bitcoin users) need to consult very small pieces of the data set in order to know about their balance, and may need to ask one of these few "data set writing entities" to write something on their behalf into that data set: the first act is verifying one got paid, the second act is paying (sending a transaction).  Essentially, a user wants two things: know for sure he got paid and pay and see that he paid.  That's all there is to know for a user.

As such, the three NETWORK functions that are necessary in bitcoin, are:

1) users need to be able to send transactions to the "data set writing entities".  That's a communication from 1 to something like 20 entities.  The users can pay.

2) the 20 entities writing the data set should make that data set at disposal of the users.  That's classical one-to-many serving: the users can verify they got paid, or they paid.

3) the 20 entities writing the data set should of course also communicate between them in their competitive game which results in the data set expansion.

The first function is a very limited multicast.  This is something akin to sending an e-mail to 20 destinations.

The second function is like a very classical web server: put data at disposal for users

The third function is like a backbone high performance link.

Right now, there is a P2P grid of nodes that performs the first and the second function, which is far from optimal.  There's a P2P network that takes care of the communication between the user and the data set producers, transmitting transactions from the users to the data set producers, and caching/proxying the data set to serve it to users.   So network-wise, it is as if there were no ISP, but we all connected our PC to our neighbours, and we are accessing servers through our PCs.

It is the misunderstanding of this, not seeing that it is essentially client/multi-server structure, which is at the origin of the claims of unscalability.  This system scales perfectly, and it was already described by Satoshi in November 2008.

Proof of work splits the system in a small set of competing servers/data builders, and a large set of users.  The difference between this system, and a classical client-server system is essentially simply that the "server" is a "multi-server" of a relatively small number of entities.  Instead of 1, there's something like 20, but with 10 you cover already 99% and with 3, you cover 50%.

In such a system, you could, even though it is somewhat clumsy, forget about the bitcoin network.  You could have these 20 entities, still connected by a high-performance back bone, and having set up some FTP server of the data set (preferentially, something somewhat more sophisticated, that allows searching and only downloading parts: an SPV kind of server).  You could send your transactions by e-mail to some, or all of these entities.  That would work too.  People who want, could download the full block chain from some of these FTP servers.  Some would only download the header chain.  Some only one block.  Some only one transaction, a Merkle tree, and the full header.
Bitcoin would work just as well, and there's no need for a P2P network.

This is why the 'base layer' in bitcoin is not a network layer.

Comes now the LN network.  The LN network is also not comparable to a TCP/IP kind of routing protocol, for two reasons, both due to the "locking in of funds in a channel".   In a communications network, you can set up and break links at essentially no cost, and once a channel is set up, you can send as much data in one direction as you want.  You can open many links simultaneously.   With the LN network, however, "opening a socket" is a costly operation, and opening a socket limits your ability to open another one: funds locked into one socket, are not available any more for another one.  In as much as "setting up a TCP link" was essentially risk-free, "setting up an LN channel" stops you from setting up another one with the same funds.  If you see that your link is "dead", you will have to wait for a day or a week to be able to set up another one and it will cost you a fee.  Next, TCP connections can be used to send data in one direction, or in both.  With LN channels, you can exhaust all intermediate links.  There's only so much that can go in one direction.  In other words, the LN network is not comparable to the flexibility of TCP AT ALL.

For a payment system, this is actually quite problematic, because the essence of a payment system is that "money goes round in circles".  If there's one thing the LN cannot do, that is to make money go in circles.  The LN network can only make money "oscillate" back and forth.  But going around in circles exhausts all links along the circle.  However, where this is interesting, is in trading.  Trading is indeed "going back and forth".  So in as much as the LN network is quite a bad "money transporter", it can be a good "high frequency trading system".  An electrical engineer would say that the LN network is "AC coupled".  You cannot push a DC stream through it, but you can push oscillations through it.  In fact, the only way in which the LN network can "make money go round in circles" is if all users in the circle are connected to the same central hub.

So this analogy breaks down entirely.  Bitcoin is not a network but a data set, and bitcoin's functioning is not "broadcast", but client/multi-server in reality.  There is not really a scalability problem in a client/multiserver architecture, as we know. Moreover, this doesn't form a basis of a network.  And the LN network is way, way, way less flexible than the TCP layer.

The scaling problems in bitcoin find their origin in not understanding (or not wanting to understand) the real data flows in bitcoin and the real nature of the system.

You pinpoint an issue with the LN, of which people, of course, have to be aware: as long as you have an open channel on the LN, you have to remain on-line.  And this for two reasons:

1) if you're offline, you make life difficult for your channel partner, because at any moment, he might want to transact through the channel you both have, eventually to transmit it further over the LN network.  If you are off-line, you've frozen his channel coins (and yours as well, but that's of course evident).  That's not very nice to your partner, who has now no access to his coins, whatever he does, for at least the lock-out time.  So your partner, seeing that you are offline and wanting to do a payment with the coins he has locked up in his channel, has now the dilemma: should he wait for you to come on-line again (maybe you've just rebooted your machine, maybe you have a network issue, or maybe you're on a world trip, maybe you just dropped dead ?) ; or should he settle one-sided, but then he's sure he cannot access his coins for the lock out time ?  So, being offline when you have an open LN channel is not nice to your partner.  As you have a stake in that channel, he might become less nice too.

2) if you're offline, you cannot continuously check whether your partner didn't send a previous settlement: you have to be online all the time in order to be able to send a punishment transaction.

There's an exception to this: if your channel is completely exhausted in the direction of your partner, you would like to settle, but you're not in a hurry, and you want to test your partner's nerves so that he takes the fee on him.  He has now a big stash in the channel, you, zero.  If you're not interested in keeping that channel or remaining online for that, just go offline.  He will have to settle and pay the fee.  It doesn't matter what he does, you don't risk anything any more (apart from a slightly less nice relationship with that partner).  Note that this is only if you want to stop that channel: you could keep it open to allow your partner to pay through you again.

If you remain online, and if the block chain is not saturated, however, the LN is quite safe to use. 

It is a different story when the block chain is saturated, and broadcast transactions do not necessarily get in the chain quickly.  That's a dangerous situation because you have no guarantee that you will be able to get your punishment transaction in on time if you see that your partner got a previous settlement transaction in.  It is my critique of the LN on a limited-block size block chain: the potential danger of not being able to transact on time.  Most probably, unless there's a kind of "bank run" on the block chain, with high enough fee you can always do this - but as the LN was meant for micro-transactions, needing to pay a very high fee to punish your scamming partner is maybe strange.  The real danger is however, a "bank run" on the block chain.  Suppose that the LN has an immense success, and that there are BIG LN hubs, that have many, many channels open.  Let us assume that the lock out time is one day.  At a certain point in time, it may become very attractive for a big hub to:
1) settle with scammy previous transactions massively (preferentially near-exhausted channels towards the customer)
2) spam the block chain with relatively-high-fee transactions during a day

This will avoid the punishment transactions mostly to get in, and the LN hub runs with most of the full channel contents.  The price to pay is the spam campaign and the losses due to those punishment transactions that got in (that's why it is best to only do this with near-exhausted channels, where most of the risk is on the side of the customer).

I half agree with that.  PoW uses an INACCEPTABLE amount of energy, to establish a kind of security that is not needed, and only becomes truly secure if half of human's production capacity of electricity and/or hardware is devoted to it.   Whenever much less than this amount is used for PoW (even if still extremely wasteful) the security of PoW is based upon limited game-theoretical arguments of benefits and costs to attackers, but the attack is provably possible, even if its "motivation" may be put into question.  Given this relativity of security in PoW, the HUGE waste and damage done to the environment most probably doesn't justify the relative limited security it procures.

PoW has a game-theoretical advantage as to the uniqueness of its consensus, but on the other hand, has, apart from its huge waste, also an evident problem of centralisation.

PoS can be for all practical purposes be secure, if we drop the strict requirement of absolute, offline trustlessness, which is in any case not a real practical case: everyone is obliged to put trust *somewhere*.  Especially in monetary affairs, where "belief in other's belief in value" is a fundamental issue.   There's no need for a "majority" to be online.  There's a need for a sufficiently decentralized, half-trusted set of entities to be online at any time.  In all human activities, trust is part of the game.  In as much as blind trust is foolishness, trustlessness is madness.  There's a compromise to be found in sufficient decentralization, while at the same time allowing sufficient trust in "known peers" in order not to diverge into impossible or impractical situations.   The winning system is the one that puts sufficient trust in reliable partners, while at the same time putting sufficient cross checks to avoid being gullible.  

Most of the problems of PoS come from the assumption that PoS needs to be rewarded in a similar way that PoW needs to be rewarded.  In fact, in as much as rewards are an essential feature of PoW (otherwise, nobody is going to do so), PoS is rendered less secure by rewards, because it stimulates otherwise honest consensus deciders to go to strategies to be awarded more rewards.

In my opinion, PoW is the right way to *create* coins (to burn seigniorage, and to limit price increase), but it is the wrong way to provide consensus (as it is too wasteful, and has automatic centralisation as a consequence).  Consensus is supposed to be quite straight forward: confirming the broadcast set of transactions, making a deterministic choice between double spend alternatives.  Apart from some limited network delays, it should be something most online nodes in the network can agree upon.  There's no need to go to extreme measures to do this.  

I know the argument of the "underground" kind of robustness.  Requiring to be publicly online is not exactly what one would consider a robust system that can survive government attacks and go underground.  The point is, a system that needs to spend 10 GW of power cannot go underground either.   Any large-scale financial system needs to be socially accepted - if it isn't, it will crumble in any case.  You can't need to consume 10 GW of power, hold a market cap of several hundreds of billions and be at the same time a half-secret underground grass roots thing.

My point was that in the unlikely event of the observation of a consensus split, which only can happen by a concordance of a very sophisticated attack and a full network split, the best solution is to merge both consensus and accept the double spends as an extra coin creation.  In reality, it will not happen, because to succeed the full split of a large network, and at the same time, propagate in both halves an accepted, different, consensus with two different spends, is very difficult to pull off.  But if ever it happens, there must be a response to it, and the best response it to merge both "account states" - that is, to accept the creation of some extra coins by the double spend that was successfully incorporated in the two otherwise legitimate accepted half-consensus parts.  As I said, it is essentially impossible to pull off.  You would expect that there's a well-known backbone of nodes most of the network is connected to.  In order for it to work, there must be a significant part of the network YOU trust, that has adopted ANOTHER consensus even though you thought you were on the network, while another significant part of the network YOU trust, has adopted the same consensus than you did.  It would be something like you seeing that Bitfinex, Amazon and Coinbase had accepted one consensus (yours), while at the same time, the dev's node, Kraken, Poloniex and Google had accepted another consensus.  This would be not even possible if you were connected to all of them at that time, because you would have relayed them the consensus proposals of both sides, and there would have been an obvious single choice.  It is only when suddenly, say, the dev's node, Kraken, Poloniex and Google seemed "offline" to you, just to come back 20 minutes later with a different consensus history, and lo and behold, their different consensus history has double spends with regards to yours (and Bitfinex's, Amazon's, and Coinbase's), which means that an attacker had succeeded in splitting them off, be on the split, and moreover, propose a different winning consensus on both halves.  Hard to pull off.

As to latency and outages, the whole idea is that the network doesn't propose a next consensus round, as long as most of the trusted participants haven't "checked off" this one within sufficient latency time.  One uses real world time, and a given sequence of events: a slot for sending proposals, a moratorium when they should propagate which is long enough for all network delays, a slot for sending acceptance, and a moratorium when these acceptance signatures should propagate.  There can be a whole network protocol to see what nodes are slow, spamming etc...  and eventually exclude them.  Point is, for sufficiently slow slices of time, for all practical purposes, network propagation delays are smaller than slot times and we can take it that for most nodes, proposals have arrived, and signatures of approval have been sent.

I am with you on your $4000.  Even though I keep a larger range, from something like $2000 to $4000.  This is because the two previous bitcoin bubbles, in 2011, and in 2013, crashed down respectively a factor of 10, and a factor of 6.  Coming down from $20 000 this time, that would bring us more or less in that range.  On the other hand, this up-run was less spectacular than the uprun in 2011 and 2013 (x300 and x400 respectively, this one was only x100), which could hint at a less severe crash.

Or it could have been the last bubble, and it is finally over, down to $1 or lower.  I think that if ever we go below $1200, it is over.  The last crash never crashed below the previous ATH.  The bubble of 2013 didn't crash down to the $30 (the 2011 ATH).  So if this one crashes below the 2013 ATH, it is most probably finished.

As I said, I should make a write-up of how one can solve this.   The whole misunderstanding is that money is about an offline ledger, while it is a common agreement of parties.   Most usage of crypto right now is between users and exchanges.  But maybe one day, that will be between users, exchanges, stores, etc....   Most professionals in this game will remain online all the time.  As such, they cannot be talked into rewinding something.  You will not be able, no matter how many nodes you have, to convince, say coinbase, to rewind.  Coinbase has been on the network all the time, and has acknowledged all consensus decisions on the network.  Of course, coinbase by itself cannot be fully trusted.  But Bitfinex will also have been online all the time.  They will ALSO have acknowledged all consensus decisions.  Maybe some banks will too.  Maybe some day, Amazon will accept coins too.  Maybe Google.  Maybe your local supermarket.  In any case, your coins are only useful with these partners, and if all of them give you the same chain, you may fire up one million nodes saying something else, this one million nodes will not convince, because they are in disagreement with a backbone of trusted nodes.  So their keys are immediately tagged as untrustworthy, because they tell bullshit. It doesn't need to be just big companies that have trusted nodes.  You can have the devs running some trusted nodes too.  There's no chance that all of them, if they adhere to the principle of no wind-back, suddenly accept another chain.  The idea is that you fill up a list of keys of trusted nodes - but you can know them publicly too.

The only danger is a global net-split, a kind of a MITM attack on global scale.  That's not so easy to pull off.  And then, if ever that happens, the solution is to accept a merge, and accept double spends.  Accepting exceptional double spends in the case of a global network split is the best solution.  Nobody is hurt.  The only thing you get is a bit of inflation.  Not much, because you can only have some double spends of spendings during the split.

The fundamental rule is simply: you never wind back.  You never accept to "erase" a former observed consensus.  At best, you accept double spends.  Most of the time, and in reality, all of the time, all online nodes will be aware of all propositions of consensus in a given time lapse.  Especially if here are relatively central hubs most of them connect to.  The only way to be able to obtain a double accepted consensus, is if you can succeed in propagating a consensus proposal on one half of the network while the other half propagates another consensus proposal, and never gets to see the first one.
If there is the slightest leak of the first proposal to the second network block, all nodes in the second part of the network will be aware of it, compare it to the first, and come to the same consensus conclusion.  As there are no rewards attached to the proposition of the consensus, there are no motivated preferences apart from the rule that tells you which consensus to accept.  If you see that you are in check with a lot of trusted nodes, like the dev's nodes, big commercial nodes,  your buddies and so on, that's just as good as being in sync with some obscure Chinese mining pools.  It is essentially impossible to split the backbone of big, known nodes, and as most probably all user nodes are somehow also connected to some of these backbone nodes, it is essentially impossible to split the network.  If the network is not split, there's no way to have a split in consensus.  And if ever it happens, the idea is not to rewind, but to merge, and accept eventual double spends as the price to pay for the split.

Note that a split is not enough: you also have to have stake holders signing, and you can only bring confusion over the time lapse you arrive at keeping the network split.  


Absolutely not.  Like the dollar is not destroyed because exceptionally, there have been some counterfeiters.  


Nope, because you will not be a stakeholder according to my latest records, so your propositions of new consensus are not even valid, and I never wind back.  I might be convinced in accepting a double spend, if enough stake has proposed it, and enough of my trusted nodes have acknowledged it, in which case I assume there has been a network split.  But I never wind back.  If I see that important nodes like exchanges and all that have accepted those other spends simultaneously, I accept them too.  But I don't wind back.  Never.  So at most, we all accept some legacy double spends, which are then simply some extra coins, in those cases where there was a network split.  It won't happen, because a backbone of important nodes will not do so.

Not yet, but the 2013 crash lasted until 2015 to go down from 1200 all the way to 200.  With bull traps, yes.
In fact, what is remarkable in this crash, was not so much the downward motion.   The truly remarkable aspect was that after the pyramid game collapsed, it took of again.  So there's hope for yet another bubble, but first, we'll have to go really seriously down, and "lose all hope".  When all hope is gone, bitcoin will look like "money" again, people will gain interest, and the next bubble can start.

There's no accepting other's votes.  My trust in you has more to do with you behaving correctly on the network for a long time while I watch you (like you watch me).  Note that you are not a staker, you cannot propose anything.  You can only confirm a proposed consensus by a staker, for which the confirmation should be automatic.  You add your signature to that proposition if it is the right one, and everyone online can SEE it is the right one.  The more you sign correct propositions, the more I can trust you that you will have continued doing so if I am absent.  Even though I shouldn't be absent in my own interest.

Given that no online node winds back, if you do that, you've simply created a clone and the newcomer will be on your clone.  But what happens on your clone will not be accepted by the "older nodes" that don't accept your alternative history, simply because they were there.  Exchanges that remain online all the time will not recognize your history.   So you've simply created another P2P money all by yourself, but with no link to the existing one.  Newcomers may be tricked in using YOUR P2P coin, but they will not be able to buy or sell their coins on an exchange, simply because that's another chain that doesn't rewind.


Well, you may have successfully created a different coin, yes.  It wouldn't be an "attack".  Because there's no rewinding.  You may trick some newcomers into your coin, thinking it is another one.  They will find out.  Your difference will be noted.   You will have a hard time having constant online entities like exchanges believing your nonsense coin.  And I will most probably put some trust in different exchanges.  Not one, but several.  If you don't give up, and if you keep sufficient followers for a sufficiently long time, your version may be listed on exchanges too.  And the market will take care of it.

How can he trust these clients ?  If we assume trustlessness, you don't trust any client by itself.  You do not distinguish the bitcoin core client from the bitcoin cash client from the monero client from the ethereum client from the litecoin client from the DASH client.... all these are untrusted pieces of software of course.  

You only have a list of untrusted ledgers, and untrusted pieces of software.  No trust in a trustless system.  You can match them.  That's not trustless.  You can see that the bitcoin ledger "works" with the Core client.  You can see that the monerod client works with the monero ledger.  But you do not trust anything.  What's the "true" ledger (and hence, what's the "true" client) ?  --> The one with the most remarkable pair of numbers that required the biggest economic effort wasted on it.

No, that's not the case.  Every consensus decision on-line will have picked one of the double spends and not the other one - otherwise, the online nodes wouldn't have accepted it as a consensus - YOU wouldn't have accepted it as a consensus !  If you don't rewind, you'll never re-consider.  Of course, in order to even be accepted as consensus decision, it needs to be correct.  Double spends are not correct.  So no consensus proposal containing double spends is to be accepted by the online deciders.
Given that one doesn't rewind, you need online stakeholders to sign for it even to be a proposition of consensus, and you need online nodes to acknowledge (by signature) that they accepted it.  Only then, the consensus is acted and no online node will wind back.

You cannot prove that to an offline party afterwards of course, but that's the concession that is needed.  You can only witness the emergence of the consensus if you were online.  However, you can register the consensus that was reached.  Normally, all online nodes will register that (and its hash).  If there is enough diversity in online nodes, and none of them is willing to "wind back", there's no way for an attacker to "overdo past consensus".   Of course, if you've been offline, you need to check with all your "former online buddies" what is their list of consensus hashes.  Normally, all of them will give you the same list.  At worst you get different lists and you know there's something fishy.  But it is impossible for an attacker to give you a false list not have you find the right list somewhere.  For that, the attacker would need to overthrow your entire list of former buddies, and he doesn't know them all, doesn't know what you know (when you were online and when not), and doesn't know the different trust scores you've attached to different buddies.  You will not have much difficulties establishing what was the right list by cross-checking what you know, and your different buddies.  You can then also know who is not to be trusted and who is.  People build a "web of trust" that way.

Note that if you consider that stake holders and online entities could nevertheless decide upon proposing and accepting an erroneous consensus, you can just as well assume this to be done by the PoW consensus deciders.  In as much as this harms other stake holders is their fault: they simply had to be online.  If they aren't, they take this risk.  Everybody will see of course that people decided upon a double spend.  So be it.  Exactly as if you'd discover that there was a double spend in bitcoin's block chain, 50 blocks ago.  So be it.