Published on: 2016-08-18T06:47:49+00:00
The Lightning Network is a solution to improve Bitcoin's scalability and speed, offering both encrypted and non-encrypted approaches for designing channels. However, when Hashed TimeLock Contracts (HTLCs) are involved, information about them can easily be observed by others. To address this, the author proposes sending HTLCs in an encrypted form, using truncated TXIDs as identifiers for observers and decryption keys for constant-time lookups. Non-HTLC data can be sent unencrypted, while HTLC data can be stored separately and indexed by state number.In email exchanges between Joseph Poon and Rusty Russell, they discuss using HMAC-of-tx instead of txid. They agree to use SHA256(txid) instead and outline a strawman spec that includes changes to the protocol using shachain/elkrem. They also discuss the use of hash trees in Bitcoin transactions and the possibility of using revocation keys in shachain/elkrem for log(n) storage.On the Lightning Network development mailing list, Joseph Poon and Rusty Russell discuss different schemes for reducing space and communication requirements per new commitment transaction. They consider using shachain/elkrem, SIG_NOINPUT, and a MAST scheme. They also discuss the use of revocation keys in relation to shachain/elkrem and the ability for Alice and Bob to predict each other's future revocation hashes/pubkeys. They agree to stick with hash trees for simplicity.Rusty Russell raises concerns about the security of the Lightning Network, particularly the eye-witness script used in LN. He suggests using an HMAC of the non-witness transaction as the final step in shachain/elkrem to establish a single leaf. Joseph Poon agrees with the simpler solution and suggests using a hash function to prevent fund theft.The conversation between Alice and Bob revolves around building a revocable pubkey and improving privacy. They discuss the possibility of a bi-directional trap door function and changing the timeout key. Tadge Dryja proposes a scheme that uses a revocation key and is compatible with shachain/elkrem, omitting hashing in the commit script. This reduces the script size and makes previous commit transactions untraceable.In conclusion, various discussions and proposals aim to enhance the Lightning Network's scalability, speed, and security. The use of encryption, hash trees, revocation keys, and different schemes are explored to optimize the system's efficiency and protect against potential attacks.In a discussion about the Lightning Network, Tadge Dryja suggests using HMAC to compare transactions against the key-value store. This method is effective for watching one channel with many states but becomes inefficient when watching multiple channels. To solve this problem, the watcher can put all the watched txids into the same tree and use seek access time. In a mailing list thread, Rusty Russell and Joseph Poon discuss the need for a "filter hint" to avoid excessive outsourced work. The proposed solution involves pre-computing HMAC by the outsourcer and encrypting the blob. There are suggestions for inserting randomness in the transaction or using the input signature from the witness as a filter to address malleability issues.The email conversation also discusses methods of outsourcing work and reducing computational cost when watching multiple channels. One method involves using HMAC to check transactions against a key-value store, which can be effective for a single channel. Another method involves sending encrypted state information to the observer, but most of the necessary information is already available in the observed commitment tx. Reconstructing messages from hashes and/or signatures is not possible.Joseph Poon and Rusty Russell discuss the need for a "filter hint" to prevent excessive outsourcing work. They propose options such as using an index based on txid or HMAC-ing the transaction itself. The latter option is preferred due to its low computational cost, although there is a risk of reintroducing malleability if the witness is included in the HMAC. To address this, randomness can be inserted into the transaction or the input signature from the witness can be used as a filter.The email exchange also covers the obscuring of funding transactions. Various suggestions are made, including sending the "steal" transaction to the observer every time there is an update, encrypting and hashing it with the txid of the commit tx or the SHA256() of the signature on the commit tx. It is noted that the key for encryption cannot be directly derived from the txid with a single HMAC/sha256 due to the need for identifying when the transaction occurs as an index for outsourcing services. Tadge Dryja discusses the issue of channel utilization in the Lightning Network and the problem of states with in-flight HTLCs. Rusty Russell suggests capturing those HTLCs and proposes his method for sending the observer the "steal" tx every update, encrypted+HMAC with the txid of the commit tx or SHA256() of the signature on the commit tx.
Updated on: 2023-07-31T19:11:08.634664+00:00