Published on: 2018-08-01T18:28:41+00:00
The discussion revolves around the potential issues of abuse and bandwidth in relation to blockchain nodes. One solution proposed is for nodes to discard erroneous messages and broadcast updates wisely instead of after every packet. Christian Decker also suggests tracking an internal UTXO set to avoid asking for full blocks from bitcoind to check a channel's capacity. This could be useful for fresh pruned nodes, who would only fetch relevant blocks when making a payment rather than verifying historical blocks right away.However, this proposal could leave DOS risks if lies are gossiped about useful channels in every historical block, which could force the pruned node to fetch these blocks one by one. One possible way to mitigate this risk is to prioritize channels created after wallet birth and put a cap on how many historical blocks are fetched before giving up.Christian Decker suggests that discussions about different proposals should be judged independently and not grouped together for convenience. He believes that the proposal about htlc_maximum_msat would not be controversial, but it should still have its own separate proposal and discussion.In addition to this, Rusty proposes adding an optional funding transaction and merkle proof to channel_announce or introducing a new channel_announce_with_proof message. He suggests that nodes could use a feature bit to indicate whether they want this or there could be a request/response for specific proofs. Rusty also suggests tunneling bitcoin block headers through the network, which would benefit lite nodes.Christian Decker responded to Robert Olsson's suggestion of adding a maximum HTLC value field, stating that he thinks it would be better and more flexible to append a max to channel_update. However, the idea of adding the total channel capacity to channel_announcement is reasonable as it allows them to save an on-chain lookup and the announcement is exactly the right place to put it. Christian agrees with the addition but believes it should get its own proposal and discussion. The channel's capacity is fixed for the existence of that channel, so it is important to include it in the announcement.In a discussion between Christian Decker and Robert Olsson, the topic of including the exact fixed capacity in channel_announcement was brought up. Robert suggested adding htlc_maximum_msat to the channel_update as well, but Christian clarified that the focus was on adding the total channel capacity to the channel_announcement. This would eliminate the need for an on-chain lookup and is a reasonable idea since the channel's capacity is fixed for the existence of the channel. Christian also mentioned that tracking an internal UTXO set allows them to stop asking bitcoind for full blocks just to check a channel's capacity. Overall, including the channel capacity in the announcement would be beneficial for successful routing.A proposal has been made by Robert Olsson to add an HTLC maximum value to channel_update, along with htlc_minimum_msat, which is already present. Christian responds by saying that this isn't about the maximum HTLC value, but rather adding the total channel capacity to the channel_announcement. He believes that it's a reasonable idea as it saves an on-chain lookup and since the channel's capacity is fixed for its existence, the announcement is the right place to put it. This was the main reason for tracking an internal UTXO set to stop asking bitcoind for full blocks just to check a channel's capacity.The lack of channel capacity information in the channel_announcement message makes it difficult for mobile and light wallets to determine the capacity of channels. This can result in lower routing success rates, particularly for larger payments. The only way to determine channel capacity is to check the blockchain, which is a dependency-laden process that many routing tools cannot handle.To address this issue, one user suggested appending an htlc_maximum_msat value to the channel_update message, which would show capacity minus fees. This would be a simple 8-byte fix with significant advantages and possibilities. Older implementations could handle the added 8 bytes, but simply not read the last 8 bytes. Implementations that look up information on the blockchain could easily discard messages that exceeded channel capacity. Privacy concerns could also be addressed by making the revealing of local balances optional.The absence of channel capacity in the channel_announcement message is being questioned due to difficulties faced by mobile and light wallets in determining it. Currently, the only way to determine channel capacity is by checking the blockchain which is not feasible for these types of wallets. Furthermore, the data available on the blockchain is in the form of short_channel_id, which is incompatible with most block explorer APIs. As a result, not knowing the capacity of channels leads to low routing success rates, particularly for larger payments. This makes route-finding tools complex and dependent on various factors for fetching and parsing transactions. The author seeks to understand if there is a valid reason for this limitation or if it could be improved.
Updated on: 2023-07-31T20:24:40.195433+00:00