"Even with the Lightning Network, [will] Bitcoin need a hard fork to increase the block size?
Is that conversation happening?"
It's likely.
I've said before that I think we're going to see all different approaches used for scalability.
That [includes] second-layer technology, optimisation of how transactions are produced and stored,
various forms of compression (if you like) such as signature aggregation and various
other things like that.
All of these things are needed.
Among those is an increase in the block size limit.
At the moment, the Bitcoin Core roadmap is to prioritise optimisations such as MAST,
Schnorr signatures, and signature aggregation over block size increases through a hard fork.
But that doesn't mean there isn't research going on.
In fact, there's quite a bit of research.
There are a number of proposals.
You can find these on the bitcoincore.org website.
There's a section on fork research that has quite a few things going on.
There's a couple of proposals by Johnson Lau, if I remember correctly, called Spoonnet.
They've now evolved into Spoonnet 2 and Spoonnet 3.
It's a funny name, but it's meant to be an alternative for hard forks.The idea behind
Spoonnet is to do a hard fork in such a way [that] changes the structure of the block
header, in order to implement a couple of very important features.
[This includes] the ability to add more commitments into the block header, in addition to the
Merkle root of the transaction tree.
One example of that would be to incorporate the Merkle root of the witness tree into the
block header explicitly, rather than sticking it in the coinbase transaction.
Other recommendations for changing the header to increase the space available for the nonce,
which would make the manufacture of mining equipment easier, allow for some better scalability,
and avoid some kludges that are being used in order to expand the nonce space.
Part of the idea here is, a hard fork is a fairly big upgrade.
It requires a lot of preparation in order to prepare all of the participants in the
space and software that expects a specific format for the block.
You need to do a lot of preparation to change things like that.
Otherwise it can lead to various problems, bugs, and unanticipated consequences.
The research into hard forks is more about this: if we're going to [go through] all of
that, we should do a few more things than simply increase the base capacity.
It's going to take a lot of time to prepare anyway, it's going to require software changes
anyway.
Why not also implement some changes that are absolutely important and necessary, that also
[might] require a hard fork?
You have to [be balanced] there between doing the minimally viable, one-off hard fork (which
is unlikely to give you much of a boost in capacity and will have to be repeated), versus
thinking more long-term and doing a few more things, versus throwing everything in the
kitchen sink into a single hard fork that increases the risk [of disruption] tremendously.
That balance is subtle.
The conversations and the research about that are ongoing.
I don't expect we'll see a hard fork in 2018, at least not on the core roadmap, because
I think we're going to see sufficient advancement using MAST or Schnorr signatures or signature
aggregation, and the Lightning Network, to not need one in order to increase the capacity
of the network.
We'll see what happens after that.
"Wouldn't it be a better solution to raise the block size limit, like BCH did, rather than
use Segregated Witness (which will add more data, 38 - 47 bytes in the coinbase transaction)?"
Well Riccardo, the solution that is created by Segregated Witness isn't just about scaling.
While raising the block size limit, like BCH did, creates more capacity on each block and
therefore attempts to solve the scaling issue in a different way, it doesn't fix transaction
malleability -- which was really the primary reason for Segregated Witness.
Segregated Witness is first and foremost a transaction malleability fix.
Secondarily, it is a scaling fix.
BCH's increase of the block size limit hasn't solved transaction malleability, which means
that you can't build complicated and sophisticated smart contracts on top of BCH.
Those [transactions] would not be secure because of transaction malleability.
You can't do things like payment channels that are open-ended and persist [for a long time].
The current implementation of the Lightning Network, for example, can't run [on BCH].
BCH has a plan to fix transaction malleability as well.
On the BCH side, they decided to [attempt] to fix scalability first and transaction malleability second.
The Segregated Witness approach fixed transaction malleability first, did a bit of scaling [with
a block capacity increase], and anticipates a [potential] future block size increase and
changes to the block header format as part of a hard fork.
More scalability increases in the future.
It was simply a difference in the order in which things have been done.
Whether it's a better solution or not, that's really up to you to decide.
You get to choose.
If you think that what BCH did was a better solution, then you can use BCH.
If you think that what Bitcoin did with Segregated Witness is a better solution, then you can
use Bitcoin.
In fact you can use both.
You can use Bitcoin, BCH, ETH, Litecoin, Monero, Zcash, and all of the other systems.
Because of the Lightning Network, we'll soon be seeing the possibility of routing payments
across all of these blockchains simultaneously, so that you could send a payment in bitcoin
and it could arrive at the other end in Litecoin, ETH, or something like that.
This is about choice.
You have the choice to use whatever you think is the best approach to scaling.