TL;DR:
No, the end is not near—we're just getting started. 2× is boring, let's figure out how to do 1,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.

While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.

For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.

Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.

By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a few times only delays the necessary work. However, after exploring other avenues, and squeezing the most out of a small base layer, we can always come back to talk about increasing the base layer capacity, eventually.

TL;DR:
No, the end is not near—we're just getting started. 20× is boring, let's figure out how to do 100,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.

While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.

For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.

Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.

By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a few times only delays the necessary work. However, after exploring other avenues, and squeezing the most out of a small base layer, we can always come back to talk about increasing the base layer capacity, eventually.

TL;DR:
No, the end is not near—we're just getting started. 2× is boring, let's figure out how to do 1,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.

While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.

For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.

Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.

By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a couple times only delays the necessary work. However, after exploring other avenues, and squeezing the best out of a small base layer, we can always come back to talk about just increasing the base layer capacity.

TL;DR:
No, the end is not near—we're just getting started. 2× is boring, let's figure out how to do 1,000×.

Let's first talk about what we are trying to achieve. We are not actually trying to increase just the number of transactions. What we're actually trying to do is to grow the network's utility: allow more people to use Bitcoin with better privacy, UX, features, and security.

While increasing the count of transactions would increase the utility, it would do so only linearly. Ten times the cost for ten times the utility—it's a bit trite. It also leads down a path that endangers other properties that we relish about Bitcoin: e.g. financial privacy, rules without rulers, censorship resistance, and the ability to validate the blockchain individually. So, instead, we aim to get leverage on the cost.

For example, stop thinking in terms of transactions, but rather think in terms of payments. By batching multiple payments into one transaction, the transaction count doesn't increase, but for a slight increase of the transaction weight, we can increase the payment count. You mentioned segwit which introduced new output formats that have less transaction weight for equivalent effect. The upcoming taproot soft fork will add another weight efficiency improvement in the same vein.

Networks scale in layers. We can use the base layer of Bitcoin as a foundation to build other services on top. These other layers can operate with different trade-offs and make use of the base layer as a "court" to resolve contracts and settle disputes. An example is the Lightning Network which facilitates instant payments and enables a user to perform manifold payments via a single base layer transaction to open their channel. Timestamping of events and documents has moved from one nulldata output per timestamp to off-chain data structures that anchor to a single output per batch. Sidechains like Liquid and Rootstock provide new scripting and privacy capabilities, but limit the on-chain cost by performing most transactions in their own blockchains.

By being restrictive in the use of the base layer, the network forces us to do the hard work to make efficient use of a scarce resource. It's also honest in setting expectations: we would never be able to put every imaginable payment on the base layer, so kicking the can down the road by doubling the payments a few times only delays the necessary work. However, after exploring other avenues, and squeezing the most out of a small base layer, we can always come back to talk about increasing the base layer capacity, eventually.