Published on: 2016-09-11T04:04:34+00:00
The speaker in the given context acknowledges making a mistake and advises to hold onto the "r-hash" longer, which may refer to a specific type of hash function or algorithm. The exact meaning or significance of this statement is unclear without further context. In an email thread from September 2016, Christian Decker explains that splitting a payment is not a problem as long as the recipient knows the total amount and can delay the release of the secret until all funds are guaranteed. Partial payments are collated using the r-hash, but there may be concerns about using the same r-hash across multiple channels due to potential exposure to colluding intermediaries.The issue of fragmented payments in Lightning Network (LN) channels is discussed between Ryan Grant and Christian Decker. Grant suggests that accounting procedures for recipients like Bob might need time-based heuristics to join separate LN transactions. To address this, support for a reassembly protocol should be available, with every wallet assisting in the accounting. Decker notes that using the r-hash to condition the release of funds is not special, and the private key release would work in the same way. A timeout could be added to ensure safe retrying if a partial payment gets stuck. It remains uncertain if arbitrary splitting and merging along payment paths is possible when onion routing is added.When making payments using multiple LN channels, it is important to have reassembly protocol support available for managing fragmented payments. This is because such payments are more difficult to handle than transactions spending multiple UTXOs. Every wallet should assist with accounting, and a varint could be used as a low-level protocol. A payment_id could help identify fragmented payments and aid in joining separate LN transactions. If no payment_id is provided, it could be considered a "don't fragment" request, if tolerated at all.In a discussion about how a payee instructs a payer on making a payment, Joseph raises a critical issue. Rusty presents his wishlist, including minimal state required on the client and server, minimal network queries by the client, and presentation of a standard QR code for one-way communications. Rusty discusses three possibilities to address this issue. The first option involves presenting only the amount and public node address, relying on the routing protocol for the client to reach its destination. The second option presents chains of channels from landmarks, with fee information represented as blocknum and txnum pairs. The third option is similar to the second but includes IDs for each hop in the chain. Rusty notes that option C is more scalable, while option B would work for the first million or so nodes.
Updated on: 2023-07-31T19:11:46.534990+00:00