Bitcoin Technology Weekly 丨 Lightning Network usher in a major update, the 0.168 BTC channel limit will disappear

Note: The original text is from Bitcoin Optech

In this week's Bitcoin technical briefing, we first introduced the research work of simplifying ECDSA adapter signatures (adaptor signatures), then summarized the discussion content of the regular Bitcoin Core PR review club, and finally, we will also introduce the three major customers of the lightning network The latest R & D progress of Eclair, C-Lightning and LND at the end. Among them, the new Eclair client has supported the lightning network channel with an amount of more than 0.168 BTC, and C-Lightning is also following development.

It is reported that before this, all major LN clients have set a channel limit of about 0.168 BTC, and liberalizing the limit means that developers have greater confidence in the security of the protocol.

• QKL123 market analysis | BCH computing power switch, BTC computing power soars, what will happen to BSV tomorrow? (0409)
• Depth | How to invest in blockchain infrastructure in a macro cycle?
• Yangchun has arrived in April, and cryptocurrencies continue to rise against the trend?

(Picture from: tucheng.com)

1. Use the simplified version of the ECDSA adapter signature scheme to repair the security risks of the lightning network

Point Time Locked Contract (PTLC) is currently an alternative method to enable Hash Time Locked Contract (HTLC) for routable payments in the Lightning Network. The problem with the existing HTLC mechanism is that every hop on the payment path uses the same hash digest to ensure its conditional payment. This means that users who control two nodes along the same path know that any hops between these nodes are not the final payer or payee, and this not only reduces the privacy provided by the lightning network onion routing It also allows malicious users to steal the routing fees paid to intermediate hops (this is called a wormhole attack) . For example, in the following path, Mallory can steal the routing fees of Bob and Carol and conclude that neither of them is the payer or receiver of the final payment.

Alice → Mallory → Bob → Carol → Mallory '→ Dan

Rather than using a hash value, PTLC uses an adapter signature (representing a point on an elliptic curve) so that each hop can use a different identifier for payment. Adapter signature (Adaptor signature) was originally proposed for the schnorr signature scheme. We already know that the adapter signature can be used with Bitcoin's current ECDSA signature scheme (see Newsletter No. 16 for details), but the process relies on both parties' ECDSA signature ( 2pECDSA), and this is complicated, and its required security assumptions exceed what Bitcoin ECDSA signatures usually require. However, Lloyd Fournier recently published a paper describing how to securely use adapter signatures with only conventional 2-of-2 Bitcoin multi-signatures (such as OP_CHECKMULTISIG ) and simple discrete logarithmic equivalence (DLEQ). In November last year, developers also summarized this on the Lightning-Dev mailing list.

At the Lightning Network HackSprint event last week, several developers studied these 2-of-2 multi-signature adapter signatures, and then Adam Gibson wrote an excellent topic on the C language libsecp256k1 and Scala bitcoin-s library theme and proof of concept implementation. Article, at present these codes have not been reviewed and may be unsafe, but it can help developers try to use adapter signatures on the main network, which can be used for PTLC in the Lightning Network or other contracts without trust protocol.

2. The discussion points of Bitcoin Core PR evaluation club

In this section, we summarize some important questions and answers discussed at the recent Bitcoin Core PR Review Club meeting.

The discussion begins with the root cause of establishing PR (Pull Request).

Question 1: Why is it helpful to retry notfound faster?

A: Prevent DoS, transaction propagation speed, privacy, and future mapRelay deletion.

Question 2: What is a potential DoS attack problem?

Answer: A node with a small storage pool (mempool) may inadvertently slow down the relaying of transactions to peer nodes by announcing a transaction and then failing to deliver it.

Question 3: Why is the speed of transaction spread important?

A: A short delay of a few seconds is not a problem (even for privacy), but a large delay of a few minutes may damage the propagation of transactions and the relaying of BIP152 compact blocks.

Question 4: When and why was the maprerelay initially added?

Answer: mapRelay appeared in the first version of Bitcoin. It ensures that if a node announces a transaction, the transaction can be downloaded even if a confirmation has been made between the peer node that announced the transaction and the request transaction.

Question 5: What problems will I encounter when deleting mapRelay ?

A: It may cause the requested transaction to be more likely to encounter a notfound situation in an honest situation, with a delay of up to 2 minutes, thereby compromising the spread.

In the second half of the conference, developers also discussed the TxDownloadState data structure:

Question 6: Describe the role of the TxDownloadState data structure?

Answer: This is a peer-to-peer state machine with a timer that is used to coordinate request transactions from peers.

Question 7: How can we improve the TxDownloadState structure to reduce the possibility of introducing transaction relay errors in the future?

Answer: Add an internal consistency check to the structure, or replace it with a well-defined interface class.

The developers then delved into PR implementation, potential issues, future improvements, and their interaction with the wtxid transaction relay proposal . For more detailed information, please refer to the meeting study notes and diaries.

3. The three major clients of Lightning Network usher in major updates

Last week, the lightning network client Eclair ushered in a new version of 0.3.4 , which supports setting up a lightning network channel of more than 0.168 BTC , and also fixed some vulnerabilities, as well as some other improvements. For details, see its release notes.

Similarly, C-Lightning, a lightning network client developed by Blockstream, is also trying to loosen the 0.168 BTC channel amount limit. Its C-Lightning # 3612 adds startup parameters --large-channels and --wumbo (both are equivalent), if these parameters are used, the node will announce support for option_support_large_channel in its init message, which means it Channels with higher values ​​than the previous upper limit (about 0.168 BTC) will be accepted. If the remote peer node also supports this option, C-Lightning's fundchannel RPC will allow users to create channels that exceed the previous limit. See also Eclair's support for this option described in the Newsletter No. 88.

In addition, C-Lightning # 3600 also uses a blinded path to add experimental support for onion messages.

What is onion news ? In the 86th Newsletter, we call it "Lightning Network Direct Message", which allows nodes to send encrypted messages through the network without using the Lightning Network payment mechanism. This can replace the message-payment mechanism used by applications such as Whatsat. Compared with the message-payment mechanism, onion message has several advantages:

1. They have draft specifications, and if adopted, it will make it easier for multiple implementations to support them;
2. They do not require onchain to implement the security of payment channels, so Onion messages can even be routed between peers who do not share an established payment channel;
3. They do not require two-way transmission of information such as HTLC or error messages, so once a node forwards a message, it does not need to retain any information related to the message. This statelessness minimizes the memory requirements of the node. If the sending node wants to receive a reply, the draft specification allows it to include a blind reply_path field that the receiving node can use to send a reply in a new message.

What is a blinded path ? Blind path is called "lightweight set routing" in the 85th Newsletter. At present, it is still a draft proposal that allows initiators to route payments or messages without knowing the destination's network identity or the complete path used . This is done in a few steps:

1. The target node selects the path from the intermediate node to itself, and then uses onion to encrypt the path information so that each hop in the path can only decrypt the identifier of the next node that should receive the message. The target node provides this encrypted ("blind") path information to the sending node (for example, through the BOLT11 invoice field or using the onion message reply_path field mentioned earlier).
2. The sending node uses ordinary onion routing to relay its messages to intermediate nodes;
3. The intermediate node decrypts the next hop to be used from the blind path and sends the message to it. The next node decrypts its next hop field and further relays the message. This process continues until the message reaches the target node.

Unlike ordinary routing, neither the originating node nor the destination node needs to know the identity of the other node or the exact path used. This not only improves the privacy of these end nodes, but also improves the privacy of any unannounced nodes on the blind path.

Finally, another major lightning network client LND also welcomed some updates, including:

1. LND # 4087 added support for automatically creating watchtower hidden services (if enabled on the command line).
2. LND # 4079 adds support for partially signed Bitcoin Transaction (PSBT) financing channels, thereby allowing any PSBT compatible wallet to fund the opening of the channel. Before this, it could only be achieved through the LND's internal wallet. After the channel received funds, LND would manage all other operations as usual. Users can provide the --psbt flag to lncli openchannel to start the interactive dialog box to complete Money flow (see the document for details).
3. LND # 3970 adds support for multi-path payment in the LND payment lifecycle system, which brings LND closer to its goal of fully supporting multi-path payment in its 0.10 version.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!