Published on: 2019-07-24T12:20:03+00:00
The discussion focuses on the number of choices needed for lightning network commitments. It is suggested that having multiple options may not be necessary, and one choice could be sufficient. Local commitments are not typically used, but remote commitments come into effect when a node drops out. However, there is an opportunity for unexpected actions due to refund delays after a local commitment. The idea of a recovery tool to retrieve funds from a pre-lightning wallet is considered beneficial, with the possibility of support from the Electrum team. Nonetheless, uncertainty remains regarding the specifics of the close and whether it will appear in the user's wallet.In a conversation about bruteforcing on the CSV delay, Pierre raises a question about its difference from a BIP32 wallet with look ahead keys. He suggests trying the most probable values first. The response clarifies that the use of CSV can be determined by the counterparty, leading to a significant increase in the number of variants to search for per key. However, restricting CSV delays to specific multiples between 144 and 2016 would reduce the variants to only 14. It is recommended that choices like 6, 36, 144, 432, or 1008 would likely be adequate. The discussion then addresses the unfortunate limitation of normal bitcoin wallets in dealing with this situation. Nevertheless, Rusty highlights the improvement of recoverability with just the seed compared to the current scenario. While local commitments are not commonly used, remote commitments become important if a node goes offline. Finally, it is acknowledged that the ability to retrieve some funds from a pre-lightning wallet is valuable at present but may have reduced utility in the future.The conversation between Pierre and Rusty revolves around the distinction between bruteforcing on the CSV delay and a BIP32 wallet with look ahead keys. The multiplier effect of CSV, which can be determined by the counterparty, significantly increases the number of variants to search for per key. The example of accepting up to 1024 and offering 144 results in 880 variants per key. However, this issue can be mitigated by restricting CSV delays to specific multiples between 144 and 2016, resulting in only 14 variants. Notably, regular bitcoin wallets do not possess the capability to handle such scenarios. Rusty emphasizes that funds can still be recovered with just the seed, representing a substantial improvement compared to the current situation.The conversation between Pierre and Rusty delves into the difference between bruteforcing on the CSV delay and a BIP32 wallet with look ahead keys. Pierre queries how these methods differ, particularly when prioritizing the most probable values. Rusty explains that the multiplier factor associated with bruteforcing on the CSV delay is significant because it can be specified by the counterparty. For instance, if the counterparty accepts up to 1024 and offers 144, there would be 880 variants to consider per key. Unfortunately, regular bitcoin wallets are incapable of handling this type of bruteforcing. However, the effectiveness of trying the most probable values first is not addressed. The discussion concludes without reaching a definitive conclusion regarding the superiority of either method.In an email exchange between Rusty and Pierre, the focus is on the distinction between bruteforcing on the CSV delay and a BIP32 wallet with look ahead keys. Specifically, Pierre seeks clarification on how these approaches differ, especially when considering the most likely values first. Bruteforcing on the CSV delay involves repeatedly guessing a password until the correct one is found, while a BIP32 wallet with look ahead keys generates a sequence of public keys in advance for transactions without revealing the private key. Pierre's suggestion of prioritizing the most probable values aims to expedite the bruteforcing process, but whether this strategy would be effective is not addressed. The conversation ends without a definitive consensus on which method is superior.The discussion touches upon the proposal in Adelaide to make CSV delays symmetric. The rationale behind this was to avoid confusion where both parties wait for each other to close. However, Roasbeef points out that this undermines the usefulness of option_static_remotekey, which allows for easy disaster recovery using only a master seed. Some individuals may delete everything except their seed, and they could still use the maximum value of the two sides' CSV. Rusty suggests abandoning the proposal entirely and seeks input on this matter.
Updated on: 2023-07-31T21:49:39.369023+00:00