DECODING THE BITCOIN'S LAYER 2 PAYMENT SOLUTION i.e. THE LIGHTNING NETWORK.

DECODING THE BITCOIN'S LAYER 2 PAYMENT SOLUTION i.e. THE LIGHTNING NETWORK.

A beginner friendly about most triggering doubts when learning about Lightning network.

The Lightning Network is a decentralized network built on top of the Bitcoin blockchain that enables fast and secure payments between two parties. It is designed to provide a scalability solution for the Bitcoin network by enabling near-instant transactions with low fees.

It is important to note that the Lightning Network is not a state, drive, or side chain. Instead, it is built on top of the Bitcoin blockchain and leverages its security properties.

The security of the Lightning Network is maintained through several security primitives, including:

  • Quorum of control: Multi-sig of any k of n

  • Time locking

  • Non-expiration

  • Censorship resistance

  • Authorization

  • No double spending

  • Onion routed network

To set up a Lightning channel, you will need to follow these steps:

  1. First, set up two of two multi-sig addresses.

  2. Fund the multi-sig address.

  3. The settlement transaction is executed before breaking the Lightning payment channel.

  4. The funding and settlement transactions are recorded on the main net.

In a Lightning channel, there are two types of balances:

  • Local balance

  • Remote balance

The process of transacting on a Lightning channel involves:

  1. Partially signing a commitment transaction and sending it to the receiver.

  2. The receiver counter-signs the commitment transaction.

  3. The transaction is broadcast across the blockchain network to receive the value.

Transacting with Relative Peers on the Payment Channels

The Lightning Network allows for fast and secure transactions between relative peers on the payment channels. The process involves the use of a Hash Time Lock Contract (HTLC), where value is passed in exchange for the hash from the receiver. Routing fees to forward the payments are generally charged in Satoshi.

The basis of Lightning technology is similar to Request for Comment (RFC) specifications. The use of time locks, such as the CHECKLOCKTIMEVERIFY (CLTV) command, is also an important aspect of the technology. CLTV uses unix time or the block height as a reference until which the Bitcoin script is not valid.

There are some challenges associated with the Lightning Network. For example, the sender must coordinate with the receiver to make a transaction for the hash in exchange for value. The Lightning node must also be online all the time to restrict counter-party risks and to avoid broadcasting the wrong state on the main net.

The majority of the development of a blockchain lies in the development of a wallet for the blockchain. This is because even if a feature is present on the blockchain, it may not be used if it is not included in the wallet and its user interface.

The Diffie-Hellman Shared Secret Key Exchange is a publicly available method for generating a shared secret between two parties. It involves the use of a prime number (P), a generator (G), and a math function for generating public keys. The public key created is then swapped between the users and the math function is applied again by both parties to obtain the shared secret.

Routing transactions in the Lightning Network happen in such a way that the intermediary nodes pay for the secret that needs to be routed. They receive payment after the delivery of the pre-image to the sender. A small incentive is given at the time of spending from their state for the pre-image, and state payment is made to the intermediary after the delivery of the pre-image to the sender. If the sender never receives the pre-image, there is a termination block in the commit transaction which terminates the commit and pays back to the intermediary nodes. If communication breaks down, the payment channel must be resolved on the blockchain.

  1. Why is the time stamping system costly for the Lightning Network?

  2. What are hash chains, and how are they different from blockchains?

  3. What is the difference between time locks and hash locks?

  4. Why do we need to wait for the addition of another 3-6 blocks on top of our Bitcoin transaction block, even though our transaction is saved in an immutable Bitcoin block?

    • The waiting period is to prevent the block containing the transaction from being discarded in a CHAIN REORG.

    • This period cannot be used for double spending, as the discarded block is no longer part of the transaction history of the network.

  5. Why do users need to exchange signatures or public keys to make spending transactions?

    • The exchange of public keys is automatic and doesn't require user permission.

    • The exchange of signatures is necessary for data/state transmission.

  6. In the Lightning Network white paper, the statement "The purpose of not signing the transaction is to spend in the payment channel from a transaction that does not exist?" refers to the SIGHASH_NOINPUT mechanism.

    • The funding transaction is not signed because there is no trust established between the counterparty, so the refund commit transaction is signed first under certain rules. The funding transaction is then allowed to be broadcast after some commits.

    • Not signing the funding transaction does not mean that the user's state is not included in the transaction. It is included, but not signed. The user is bound to make commits within the range of their state.

  7. How does a receiver verify the sender as the true owner of the data sent in case of transaction malleability?

    • Either in general cases or in the case of transaction malleability, the receiver can determine that the sender is the original owner.
  8. Why there is a very low usage of P2SH in scripting even though it is the easiest and most secure way to make transactions as it is multi-sig?

  9. How lightning can be used to do atomic swaps, interop, and cross-chain communication?

  10. What does exchanging signatures mean?

  • The exchange of signatures means transitioning the state or transmitting data securely.
  1. Does the size of a micropayment transaction smaller than a regular transaction in the bitcoin mainnet?
  • The size of the transaction will be the same regardless of its size, as the SHA-256 hashing algorithm generates the same 256-bit hash for all inputs.
  1. Why don't both users exchange signatures while making a funding transaction?
  • Signatures are not exchanged because the transaction does not get signed. To spend the UTXO that doesn't exist and to avoid broadcasting the transaction on the main net, signatures will not be exchanged until both come to a consensus on the refund transaction.
  1. If a transaction can be mutated, can signatures be invalidated, making refund transactions and commitment bonds invalid?

  2. How are refund transactions and commitment bonds invalidated?

  3. What happens if a transaction is signed?

  • It is like spending someone else's state. How can you make a funding transaction without ownership? If you don't show ownership by not signing, does it mean anyone can use the channel?
  1. What is the point in terminating a funding transaction if its broadcast time is not set, and it does not update your state?
  • The moment you initiate the transaction, you enter the channel and must broadcast the funding transaction to exit the channel.
  1. Is it correct to say that the process of making a lightning payment channel is: child tx keys exchange, parent tx key exchange, and parent tx broadcasting?
  • It is said that child tx keys exchange, parent tx key exchange, and parent tx broadcasting are the process for making a lightning payment channel, but it is also said that a commitment transaction state cannot be redeemed until the parent transaction is broadcasted.
  1. Does the exchange of keys meant to be the signing of the commitment tx and redeeming the state by the receiver?
  • No, key exchanges are done after signing the commitment tx.

  • Key exchanges are used when there is a need to revoke or redeem the state.

  1. In the Lightning white paper, it is said that to broadcast the funding tx, the following process has to be done:

    1. Create the parent tx

    2. Create the child tx

    3. Sign the child

    4. Exchange signatures for child tx

    5. Sign the parent

    6. Exchange signatures for parent

    7. Broadcast the parent tx, i.e. funding tx

  2. But later on in the white paper, it is said that a child tx state cannot be redeemed by the receiver until and unless the funding tx gets broadcasted on the main net.

  • If the exchange of signatures for the child tx means the redemption of state by the receiver, then why is it mentioned that the redemption of state only happens after the broadcast of the funding tx?
  1. Why is there a need for deferring the broadcast of the funding tx, why don't make an immediate broadcast?

  2. Why does a funding tx need to go through sequence maturity lock time for a broadcast? Why can't it be done immediately at the moment?

  • To establish the refund tx.

  • To break out of the channel if it is not operational.

  1. Can a commitment tx be a broadcasting tx? No.

  2. If you revoke a tx, does that mean you can't publish that commitment tx?

  • No, you can publish the tx, but if it is fraudulent, it gets submitted with the revocation key from the counterparty, which leads to a state grab.

  • You can publish the yourself revoked tx, but it is unworthy, leading to a loss of state.

  1. If Bob acquires the revocation key from Alice in the 2nd transaction, and if he uses that key to revoke his previous commit, does that mean Bob's entire state gets transferred to Alice?

    • Why would he do that if he faces the loss?

    • The revocation that he acquires from Alice will only be applied for Alice's previous commit and not to anyone else.

  2. It is said that a revoked transaction cannot be published, but how can the malpractice revocation be done without getting the revocation key, which requires revoking the transaction, as it has to be published?

  3. In HTLC offered logic, when the HTLC times out, the sender's state gets redeemed back to him. Why should he send a revocation key to the receiver party?

    • To ensure that he is not redeeming the wrong state.

    • It is seen by the receiver/pre-image supplier.

  4. Scenarios where money gets locked in the payment channel:

    • Not signing the refund transaction before the funding transaction.

    • Using ScriptPubKey instead of Segwit, where the funding transaction gets malleated, which leads to commit transactions not getting pointed to the funding transaction.

  5. What's the problem with the presence of pure lock time and sequence time in the commit? Why is there a need to include half of the 24-bit obscured commitment number into the lock time and the other half into the sequence time?

    • In order to know which commit it is at the time of verifying the lock time/sequence time itself, rather than going through the hectic process.
  6. It is said that a second stage HTLC will not be broadcasted until it breaks the lock time in the main HTLC.

    • If that happens, then the self-delay time becomes equal to the lock time break, and it simply breaks as if the pre-image is not submitted?

    • If broadcasting happens after state redemption, then it is valid.

    • If broadcasting is equal to state redemption, then it is invalid.

  7. How can a particular user broadcast to the main net without the settlement transaction which requires the 2 of 2 multi signatures.

  • A user can broadcast the settlement transaction without the presence of other user by including a revocation key in the settlement commitment transaction saying that if I broadcasted a previous transaction state of higher state of myself use this revocation key to revoke my transaction and take away all my state as the compensation for the fraudulent activity on the channel.
  1. Lets say user A made a transaction of 100btc to B with a set time lock. Will the amount that A has spent to B be locked in the escrow payment channel right at the time of making the transaction to B? if not does that lead to double spending?
  • Until and unless the recipient counter signs the commitment transaction the transaction is still ongoing, so can't A double spend the same amount he transacted with B?
  1. Does this payment protocol follows the escrow payments?

  2. How does the sender calculates the routing fee in order to deliver the intended value to the receiver in the lightning network?

  • How will sender get to know the routing fee from each individual intermediary nodes in the network even before he initiates the transaction?

  • It’s okay that signing a message containing the short channel id makes it available on the bitcoin main net. But how will a latter lightning node gets access to it? What are the things he has to do in order to get the access?

  1. The message containing the “short channel ID” will be passed to everyone who are participating in the gossip and it is not a single point of access for accessing the routing graph.
  • Does that mean that one single message containing the “short channel ID” gets signed by each and every lightning channel in the network, thus making addresses of each of and every node available to a person who wants it all at one place?
  1. It is not a single point of access of info, where you go somewhere and do something to get the routing graph. You’ll participate in gossip and you’ll get the routing fee as you participate.
  • Does that mean that the routing fees get decided right at the moment of channel creation? And does that routing does’nt alter, i.e. is it fixed all through the channel existence?

  • Can make a new channel announcement to update the routing fees.

  1. How will the address and other parameters of a particular channel get deleted from that signed message when a particular payment channel gets settled, in order to avoid wrong routing?
  • If the sender gets to know the individual node’s routing fee, does that mean the sender knows the intermediary nodes?

  • If yes, how knowing an individual node is possible in the onion routing used in the lightning network?

  • And does that lead to any consequences or any privacy issues for the intermediary nodes?"

  1. How does shortest route from the sender to the receiver gets traced?

    • Lightning network consists of a BORDER GATEWAY PROTOCOL-like mechanism to trace the routes.
  2. What are man-in-the-middle attacks?

    • Address resolution protocol is used to find the layer 2 address or MAC address.
  3. What is the concept of revocation and revocation key, I’m not getting it even on surfing?

  4. What happens when B is not co-operating for a settlement transaction to break out of the payment channel onto the mainet?

    • Legitimate unilateral close transaction with to_self_delay where the one who initiated the settlement transaction without the presence of the other user has to wait for a particular period of time.

    • That time is the revocation period for the other user or the watch towers.

    • After which, the other user can claim the revocation process.

  5. How can A break out of the channel without B’s intervention for signing the multi-sig?

    • Unilateral close transaction with a to_self_delay.
  6. What's batch 32 encoding and ln?

    • Encoding used on the native segwit address which reduces the script up to 16%, reducing transaction fees by up to 16%.
  7. Do peers on the lightning network have an address other than the multi-sig address?

    • Yes, they have public keys and private keys.
  8. What is referred to as a ledger in the lightning channel? Does the commitment transaction script itself act as the ledger in the LN?

    • Commitment transactions are stored in the user-provided storage devices, and when it is required to be broadcasted, the most recent one gets accessed by the user and broadcasted.
  9. Why can't we do effective privacy on layer 2?

  10. Why is compression of transactions and signatures required in layer 1?

  • To reduce the amount of data transmitted across the network, reducing network latency and preventing centralization caused by limited block size.
  1. What does anchoring transactions to the lightning multisig wallet mean?
  • It refers to the funding transaction for the lightning payment channel.
  1. How does the sender construct the transaction route to the receiver in the Lightning Network?
  • The sender uses short IDs that contain details of each node in the network and can be accessed by participating in the gossip protocol.
  1. Where is the state of each individual in the payment channel stored in the Lightning Network?
  • The state is not stored, it is represented as an integer on the most recent commitment transactions, which are redeemed to the main account when a settlement transaction is broadcasted.
  1. Where are commitment transactions, transaction IDs, and digital signatures stored in the Lightning Network?
  • Commitments are stored on storage devices, transaction IDs are generated by algorithms, and digital signatures are generated using public/private key pairs and converted into hashes.
  1. Can the Lightning Network store the state of every individual after billions of transactions?
  • The state is not stored as a storage, it is only present on the commitment as an integer and does not depend on the number of transactions.
  1. What does capacity of a node mean in the Lightning Network when the transaction size is approaching 4 million satoshis?
  • It refers to the node's storage and network bandwidth.
  1. Why would an intermediary Lightning node waste storage resources for a small reward in satoshis for routing a micro-transaction?

  2. How does having a large amount of currency in a node account attract more channels and transaction opportunities for routing in the Lightning Network?

  • A large amount of UTXOs, high uptime, and more channels to the Lightning Network increase trust among other nodes in the network and attract more routing opportunities.
  1. What are the consequences of identifying the type of payment or address in the Lightning Network (starts with P2SH, SegWit, multi-sig, or lightning payment channel)?

  2. What does censoring of transactions mean in the Lightning Network?

  • It refers to hiding or not making the required transactions and keeping the network unaware of the transaction.
  1. If the state of A in a payment channel is kept private, how would B know the state of A to commit to a higher prior state?
  • The state is not kept private, in fact, the individual commitments are signed by the counterparty first.
  1. Why are time locks below 500 million counted as block height and above 500 million counted as Unix time in the Lightning Network?

  2. Does Unix time get flipped and turn negative after a certain time in the Lightning Network?

  3. How will a participant in the Lightning payment channel access the transaction ID of a past transaction for use in a settlement transaction?

  1. List Channels Command: This command allows the user to view incoming and outgoing channels on their Lightning node. It provides information about the channels, including the channel ID, the node's public key, the amount of funds in the channel, and more.

  2. Websites for Finding Lightning Nodes: There are websites available that help users to find and connect to Lightning nodes. These websites typically provide a list of nodes, along with information about their uptime, channels, and other details.

  3. Lightning Node Autopilot: The autopilot feature in the Lightning node daemon allows the node to automatically open channels with other nodes on the network. This makes it easier for users to participate in the network and route payments.

  4. Allowing Incoming Connections: To allow incoming connections to your Lightning node, there are a few things that need to be done, such as:

    • Port Forwarding: This involves configuring the router to allow incoming connections to reach the node.

    • UPnP Incoming NAT: This involves enabling Universal Plug and Play (UPnP) on the router to automatically configure port forwarding.

  5. Custodial Solutions: For users who are not comfortable managing their own Lightning node, there are custodial solutions available. These solutions typically manage the node on behalf of the user, and provide services such as routing payments and managing channels.

  6. Testing the Network: To test the functionality and reliability of the Lightning network, users can use the Lightning Torch. The Lightning Torch is a payment that is passed from node to node, growing in value as it travels through the network.

  7. Maintenance and Administration: Operating a Lightning node requires ongoing maintenance and administration, including tasks such as updating software, ensuring security, and monitoring performance. This can be done by system administrators, security professionals, and others with the necessary expertise and resources.

Subscribe to our newsletter

Read articles from Ram Ganesh's Blogs directly inside your inbox. Subscribe to the newsletter, and don't miss out.