This discussion took already partly place in -ck's self-moderated thread concerning the Barry Silbert segwit2x thread, where -ck considered this off topic.
Here are the last few posts related to this:
https://bitcointalk.org/index.php?topic=1928093.msg20316377#msg20316377and
https://bitcointalk.org/index.php?topic=1928093.msg20317250#msg20317250Now, of course this isn't discussing *directly* the Barry Silbert agreement, but it does discuss the underlying aspects. After all, what is "special" in the segwit2x, is the 2x, the fact that one proposes to break out of this 1 MB limit, and hence all the arguments for and against touching the block limit.
Segwit, all by itself, is:
a) an improvement on some technicalities modifying the way transactions are done in bitcoin
b) also a "trick" to keep some essential cryptographic data within a 1 MB block, while extra data of the transactions is now made available outside of that 1 MB block, but in such a way that old clients wouldn't recognize it, and hence, wouldn't complain about "too big blocks".
As "more transactions for the same network and computing infrastructure resource usage", Segwit is very similar to a modest block size increase: the TRUE burden on computing and network resources increases somewhat, and it can also allow somewhat more transactions - exactly as a block size increase would do. The only thing that has been done, is to split the transaction data in two chunks, one that goes into an old block less than 1 MB, and the rest that goes "next to it". If you don't want to understand the transactions in detail, you can keep only the old blocks and then you remain within the 1 MB limit. But that's a cheap trick, nothing more. In as much as a block size increase can be repeated, and repeated, the "segwit trick" is a single shot trick, and you cannot "segwit, and segwit more, and segwit even more" until we have 500 times more transactions in the same 1 MB block than now.
So, as a transaction-increasing "solution", this is a very small and single-shot improvement that is much more complicated, and much less flexible, than simply changing one single parameter in the bitcoin core client: the maximum block size.
However, segwit's technical modification makes it much simpler to ADD LAYERS to bitcoin, from side chains to the lightning network.
The argument goes that these extra layers will make the "scaling problem" go away. The "scaling problem" is that the *technical burden* of resource usage for individual users contributing to the decentralization of the bitcoin system becomes too large when too many transactions are to be voted over, and that individual users will "stop running full nodes" and hence let bitcoin's consensus "centralize" in the hands of a few power users. Indeed, if bitcoin's model were that all users were to contribute to the consensus, then bitcoin's resource usage would grow as N^2 where N is the number of users (at an average amount of transactions per user), and bitcoin's burden per user would grow with N.
At a certain N, so the story goes, users will stop contributing to the consensus, leaving the decision to bigger boys. ==> this is the main argument for leaving the block limit in place, and be "careful" in touching it.
This argument is entirely false, for the following reasons:
1) the consensus decisions are not taken by full nodes, but by miners. This is done on purpose in bitcoin, to avoid the easy sybil attack on "number of nodes". Proof of wasted economic value (proof of work) is what secures bitcoin. The amount of wasted economic value needed to secure bitcoin is many, many of magnitude larger than the technical burden to run full nodes ; hence, whenever you can contribute somewhat to the bitcoin consensus,
the main part of your cost is not running a node, but wasting work. And if you don't waste work and prove it, you have nothing to say in bitcoin's consensus, and hence, you don't contribute to the decentralization.
2) "poor Joe with his node in his basement", as a bitcoin user, has to pay for the wasted value on proof of work, like all bitcoin users. So if he cannot afford his node, maybe he cannot afford using bitcoin all together, because he's paying, like anyone, for the proof of wasted value.
3) Bitcoin uses "remunerated hash cash" in order to stimulate decentralization. That's something that doesn't work. Hash cash prevented people from "pretending they are many", because when they pretended to be many, their COST (the value they needed to waste) was proportional to the number of people they pretended to be. So at a certain point, hash cash made it too expensive to pretend to be 10 000 voters. But of course, you totally kill that idea if you REMUNERATE people proportionally for pretending to be many voters. In fact, whether "pretending to be many" becomes lucrative or not, depends on whether you can out-compete others in your "cost per unit of pretended voter". And here, we get economies of scale, making this MORE LUCRATIVE for those that do MANY SYBIL attacks. This is now even so accepted, that 5 or 6 entities can vote as if they are half the number of bitcoin users (the 5 or 6 biggest pools). So bitcoin's remunerated hash cash leads in any case to an oligarchy of voters pretending to be most of the users: the miner pools we have seen. That's because "remunerated hash cash" is a failed idea against sybilling. Bitcoin has in its heart, a mechanism that "makes bigger boys emerge" in any case in the decision process.
But there IS a good reason to keep the number of transactions scarce !
Indeed, in the long run, all this proof of wasted value will need to be paid by the fees of people wanting to do bitcoin transactions. As this amount of wasted value needs to be HUGE (because that is what bitcoin's protection is about: it has HUGE wasted economic value proved, and if you want to attack it, you need to prove MORE wasted economic value), the fees need to be important. And people will only pay important fees if transactions, the cheapest possible transactions, are nevertheless scarce, so that they are expensive.
One way is keeping the blocks small. That obviously will render transactions scarce. But one shouldn't, then, put a second layer on top of bitcoin. Because if one does, these transactions may become cheaper, and they will crash the market of "on chain transactions". So off-chain transactions must ALSO be scarce and expensive, or bitcoin breaks down !
It doesn't matter whether your transactions are on chain or off chain: they must be expensive ! Because it is this price that pays for bitcoin's security, its continuous waste of economic value. And, as I said, this price is MUCH MUCH larger than any technological cost of resource usage of block chains. So at no point, the resource cost (of "big chains and big blocks") comes into play in this thing.
That is, by the time that blocks would become so big that they generate a significant *technical* cost (disk space and so on) as compared to the cost of proof of wasted value that needs to be paid, bitcoin would have become insecure because not enough PoW in any case. The waste on PoW will always be orders of magnitude larger than any waste on technical resources, or bitcoin is dead.
So, yes, one has to be very careful, not with the SIZE of the block chain, but with the SCARCITY OF TRANSACTIONS. All of them, off chain and on-chain. Bitcoin can only keep working if transactions remain scarce and expensive.
For the moment, and still in the coming decade, bitcoin's wasted economic value is still mainly paid for with inflationary tax, so we haven't seen the difficulty yet.
Organizing the scarce transactions in several layers is hence rather useless, because even though one would win something on the side of technical costs, this doesn't contribute anything to decentralization (bitcoin is designed to centralize due to economies of scale in remunerated hash cash), and it doesn't have any significant effect on the true cost of bitcoin, which is mainly due to proof of wasted value, much larger than the technical costs.
However, organizing transactions in several layers DOES have an effect: one gets hierarchies of power, and layers of delegated trust. In other words, exactly how the modern financial system is layered, with different layers of trust and of power. Decentralization is already gone, cheap transactions are not possible because they need to pay for proof of wasted value as a security, and now, permissionlessness will be the next thing that fades away from bitcoin, where we get complicated layers of power where Joe needs to ask permission to layer N to participate before he can transact. His node in his basement was going to be the least of his worries !
TL;DR
bitcoin needs scarce and expensive transactions in the long run to keep financing his "remunerated hash cash" security. It doesn't matter in how many layers these scarce transactions are distributed: they all need to be scarce so that people pay enough fees.
The techical costs of bitcoin (disk space, network access....) are minuscule as compared to the cost of using it (because of the need of having to pay for proof of wasted value).
