Lightning has been one of the most talked about subjects in the
bitcoin community for years, its a new protocol built on the Bitcoin block
chain that allows for more scalability.
The problem started when the Bitcoin network was gaining users and
while the needed transactions per second increased, the actual
transactions per seconds didn’t, Bitcoin’s network with the Pre-Segwit 1MB
block size had an upper limit of 7 transactions per second, compared to
Visa’s 65000 transactions per second limit that is quite slow and
definitely not scalable.
The block chain’s protocol is that every node must know about every
single transaction and if we would have just increased the block size,
that would mean that nodes would have to transact and store hundreds of
terabytes of data each year, which would not make it feasible for home
computers and so node operators will decrease, not only hurting the
decentralization of Bitcoin, one of its most fundamental core values, but
also making centralized trusted parties that are relied on for mining and
validating blocks, which in turn hurts the security and the fairness of
the block chain, these centralized sources can agree to charge higher
fees, stop accepting transactions and any other actions that hurt the
network and cause them gain.
To avoid this situation a Bitcoin node must be cheap enough to run
an a personal computer at home but we also want it scalable enough to
handle thousands, millions and maybe billions of transactions per second
and so we have Lightning, Lightning is a protocol for delegating
transactions off chain, it uses a network of micropayment channels between
nodes to defer telling the block chain about every transaction, instead
just telling the block chain about a starting transaction and an ending
one, with some extra transactions in some specific cases, and all
transactions in between are just between the two, or more, nodes involved
in the transaction.
A channel is initially opened with a Funding transaction, the output
of this transaction is a 2 of 2 multisignature script with both parties in
this channel, the signatures of this script are not yet exchanged and are
only exchanged when a transaction refunding the outputs of the funding
transaction back to its users is signed. Bitcoin here uses SIGHASH_NOINPUT
to spend from an unsigned transaction, before the SIGHASH_NOINPUT soft
fork a transaction could only be spent when it was broadcast. So the
channel initialization could go like this
Create the Funding Transaction
Create the child transactions (called Commitment
Sign the children
Exchange signatures for the children
Sign the parent
Exchange signatures for the parent
Broadcast the parent on the blockchain.
This is done to ensure that in case of a disagreement in the
channel, the initial conditions of the channel are not changed and no lock
up of funds can happen.
A problem arises when nodes act maliciously in the payment channel,
lets say I’m Bob and you’re Alice and we both agreed to open a payment
channel with 0.5 btc from each of us, after a few transactions we settle
on a balance of 0.2 to Bob and 0.8 to Alice, but Bob isn’t happy about
this settlement so he’s not going to close the payment channel until he
gets all his money back, the Bitcoin network needs to know which set of
transactions is the real one, on the network it does that by having a time
stamping system, it’s basically blocks following blocks and the later
blocks hold the true values, so if you send 0.3 btc to Alice, you can not
send them again or refund them back. We don’t want to use this time
stamping system until its necessary to avoid crowding the block chain and
so we use the commitment transaction and continue updating the payment
channel signing transactions that is just between the both of us, the
problem here persists, upon closing the channel any single participant can
broadcast any transaction of these to the network and that would be the
final state, even if it is an old one.
We’re trying to devise a script that invalidates all the older
transactions and lets only the most recent transaction be broadcast, but
you can’t actually do that, once a Bitcoin transaction is issued it can
not be “unissued” and here relies one of the core concepts of Lightning.
Lightning uses different security measures to make sure that it penalizes
malicious acting in the payment channel.