MultiChannel and MultiPTLC: Towards A Global High-Availability Consistent/Partition-Tolerant Database For Bitcoin Payments

The proposed MultiPTLC scheme significantly reduces the complexity and communication overhead traditionally associated with payment transactions in a network by using a novel approach that requires only 1.5 roundtrips for a transaction to be completed. This efficiency is achieved through a mechanism where the Lightning Service Provider (LSP) selects a receiver-can-claim scalar after the MultiPTLC has been irrevocably committed, eliminating the need for the initial request roundtrips. The pivotal insight here is that the LSP does not need to know the receiver-can-claim scalar or its corresponding point ahead of time. Instead, the LSP adds this scalar to the incoming P branch's point and sends an outgoing plain PTLC to the receiver, which then needs this scalar to claim the funds.

This method allows for bypassing the need for TCP's acknowledgment system by potentially utilizing UDP combined with forward error correction, reminiscent of compact block encodings in previous protocols. This adaptation could further reduce the necessary communication to effectively half a roundtrip in certain hops, such as from Ursula to Alice, Bob, and Carol. Such an improvement underscores the scheme's potential to enhance the efficiency of transmitting payment information across multiple parties without necessitating direct acknowledgment packets.

Furthermore, the MultiPTLC inherently encodes the sender's intention that only one payment path succeeds, directly aligning with the user’s needs while simplifying the system design compared to parallel plain PTLCs. The latter requires additional mechanisms, such as incorporating a receiver-can-claim scalar, to ensure that only one PTLC can be successfully claimed by the receiver. This simplicity and directness make the MultiPTLC an attractive option for system designers.

Lastly, the scheme introduces a novel way for LSPs to prove that a payment has reached the receiver through the use of a challenge nonce included in the final onion payload. This nonce can be used similarly to how a payment secret works in stateless LDK, serving as proof of payment delivery. The inclusion of different nonces for different paths and the requirement for the winning LSP to show the preimage of the nonce as evidence for the completion of their specific path add an additional layer of security and trust to the MultiPTLC setup. This mechanism not only assures other LSPs involved but also streamlines the process of claiming the provided funds by releasing the corresponding receiver-can-claim secret.