"Do you see a danger of the sidechain market being dominated by a very few big companies?"
Since I just talked about side chains... No, I don't. There are very few barriers to entry [with sidechains].
There are [even] fewer advantages to being a big company in this particular space.
"Could you please [talk] more [about] the topic of side chains?
"In simple steps, how would one go about creating a separate blockchain...
and connecting it to the Bitcoin blockchain?"
Sidechains can be implemented in a number of different ways.
The most common way is called a two-way peg. That [means] creating a special type of transaction...
in one blockchain [to lock] up coins.
[These coins] can then be referenced to unlock an equivalent amount, or based on an exchange rate,
of coins in the other blockchain.
You can think of [a two-way pegged sidechain] as one form of atomic swap, because that is what [it does].
A bi-directional [swap] would [be like] a two-way peg [to] move back and forth between two [blockchains].
So when you lock [up coins] in one blockchain, you can then release coins in the other blockchain.
You can do that with a two-way peg implemented [with] a Simplified Payment Verification (SPV) proof,
and some multi-sig smart contract.
You can also implement it with the Lightning Network, [by] sending a payment in [interoperable channels].
For example, if you own bitcoin, you [can send] it on a payment channel where [it is exchanged for Litecoin].
now you can use [Litecoin] at whatever exchange rate you secured, and move money between them.
Now you can seamlessly move coins to another blockchain in the decentralized fashion,
without any intermediaries.
A sidechain is just another blockchain, but secured by different mechanism.
You shift and transmogrify [value] into other coins.
Anita asks, "What is Liquid and which use cases do you see [for it]?"
Liquid is a [sidechain] solution offered by Blockstream that uses a federated signing model, proof-of-authority.
It is a sidechain that [does not use mining in its security model], but instead has a group of federated signers...
[to] approve transactions.
Liquid has a couple of features developed by Blockstream, including confidential transactions,
which allows transaction amounts to be encrypted but [still] verifiable.
Participants can transmit value without revealing [how much] value they are transmitting.
The primary reason Liquid was created, and [what it is promoted for],
is as a backend network connecting large exchanges and payment providers to each other, so they can do...
exchange-to-exchange transfers of liquidity without using on-chain space in the Bitcoin blockchain.
Liquid is intended to tie lots of large exchanges and payment providers together with a backend network.
[In terms of decentralization], it is effectively at the other end of the scale [from the Lightning Network].
Lightning network is for decentralized micropayments, [currently routed through thousands] of participants.
Liquid is for more centralized, federated, very large payments, through a few large providers.
It is a commercial product [from] Blockstream, [which] sells [access] and manages the network,
allowing exchanges to use it for a fee.
Liquid is open-source, but it is still a commercial product.
Ironically, one of the arguments [used] against the Lightning Network, is that...
it is somehow a trojan product by Blockstream,
and they are "sabotaging" the scaling debate in order to promote and profit from Lightning.
First of all, Lightning isn't a Blockstream product. It is an open protocol with multiple implementations.
Second, Lightning undermines Liquid, the actual commercial product from Blockstream.
The more successful Lightning is, the less need you have for Liquid.
The bigger the Lightning Network [becomes], the more exchanges can use it...
to run payment channels between each other directly, on Lightning, without [needing] to use Liquid.
That makes the argument fall apart.
In any case, Liquid is a sidechain project by Blockstream, probably the first commercially available sidechain.
"What do you think about Delegated Byzantine Fault Tolerance (dBFT) as a consensus algorithm?"
"Do you think this kind of federated governance model can become effectively decentralized?"
I think the Delegated Byzantine Fault Tolerance consensus algorithm is...
a form of [proof-of-authority], where you assign votes to different parties in a federated model.
It is a signing versus mining algorithm.
The fundamental problem with consensus algorithms like that,
is ability of the parties to collude and reverse the history of the chain.
With Bitcoin's proof-of-work consensus algorithm, one of the important characteristics is,
even if 100% of the miners decided they wanted to re-write the chain from last year,
they would still [need] to re-mine a year's worth of blocks and produce proof-of-work.
They would still [need to do so] by consuming approximately the same amount of energy...
that they consumed over the past year, on mining chips that have not [become] much more efficient.
They would [be using] all of that energy twice, assuming it is the same miners, but only be rewarded once.
Even if 100% of the miners decide to re-write the chain,
they can't do it without expending a large amount of energy, and it would take a very long time.
At the current rate of difficulty, if they go back one year [in the chain's history],
it [will] take them less than a year because the hash rate has increased significantly, but not much less.
Maybe it takes them six months to re-write the chain.
During those six months, they [must] allocate 100% of their hashing power in the network to re-write the past,
without moving forward at all.
All of this, just to re-write a one-year old transaction.
That is a very effective floor or backstop against attempts to alter the history.
That form of immutability is much stronger than simply assuming miners won't collude in [these] systems.
In proof-of-work systems, even if 100% of the miners collude, they [still must] expend energy...
and produce the proof-of-work.
Otherwise, none of the other nodes in the system will accept these blocks as valid.
They cannot re-write the chain simply by decree, by fiat you might say.
In federated governance systems where signing has replaced mining, Delegated Byzantine Fault Tolerance...
and various forms of proof-of-stake, there is no backstop if 100% of the signers collude.
In some cases, maybe only 51% of the signers [must] agree between themselves to re-write everything...
since the genesis block, at zero cost.
It doesn't cost them anything.
It [probably won't] take them more than a few seconds to re-calculate the entire blockchain,
arrive at a new present, with a rewritten history that no one could independently verify has changed.
As in, if a new node joins the system, they can't tell the difference between the original history and new history.
They both look the same. But you can't do that in proof- of-work systems. [When] a new node joins the [network],
[it] immediately knows which history is true -- the one with the most proof-of-work behind it.
In Delegated Byzantine Fault Tolerance, or some other federated consensus algorithm,
all of the well-known and named federated signers [could] receive a subpoena that says,
"We would like you to please rewrite or erase this transaction that funded the WikiLeaks organisation."
"Remove that transaction, [as if it] never happened," or "remove funding from that organization."
Under a court order, they [must] comply.
More importantly, it is not just a matter of [whether] they would comply; they would be able to comply.
[If you had] the same scenario in a proof-of-work system, and hand all of the miners (if you can even find them)...
a subpoena [that] says, "Change this transaction,"
they simply cannot [do that] without expending at least six months of energy.
Most likely, courts would not even approve [that subpoena], under a variety of legal concepts.
That doesn't mean federated governance models and Delegated Byzantine Fault Tolerance are not useful.
They are just different and not immutable in the way that a proof-of-work [system] is.
If you don't need immutability, if you are trying to have a consortium of banks that don't trust each other...
[with the ability] to do wire transfers [between] each other, and if you don't mind that a government could...
come in, compel them all to change a transaction in the past and rewrite history,
then [federated signing] is a perfectly good system.
In that case, you don't need a blockchain.
If you look at most of the systems that have delegated signing, they don't use a blockchain.
They don't need a blockchain.
They can use something else: a hash graph, a tangle, a series of linked transactions without blocks.
You don't need to aggregate things in blocks if you don't have proof-of-work.
You can basically sign every transaction independently. It is more efficient [for centralized systems].
At that point, you are not in the blockchain space. [Maybe] you are in the "distributed database space."
That's fine, but it is not what I'm interested in.