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

The discussion revolves around the implementation of a MultiPTLC (Multipath Payment Time-Locked Contract) system which is designed to enhance the efficiency and competitiveness among Lightning Service Providers (LSPs) in routing transactions to receivers. The core innovation lies in allowing all LSPs, rather than just one, the opportunity to compete for transaction routing. This competition is facilitated by a modified RAFT algorithm that uniquely incorporates a proof-of-work mechanism to manage leader selection. This approach is necessitated by the constraints of a relativistic universe where the concept of a "global event ordering" is not applicable. In this system, an LSP can only contend for leadership if it demonstrates through proof that the receiver has requested the "receiver-can-pay" scalar from it.

Furthermore, the conversation touches upon the limitations of Spilman channels, highlighting their truly unidirectional nature which prevents a failed Hashed Timelock Contract (HTLC) from being returned to the sender. This characteristic underscores the necessity to adapt the state at the decrementing-nSequence layer to exclude the failed HTLC. To mitigate the risks associated with failed or stuck HTLCs, the proposal suggests that LSPs undertake probing before presenting the results to users. This enables users to dedicate the HTLC to a single LSP, enhancing the likelihood of a successful transaction without the need for trampoline forwarding, especially since these are single-hop transactions.

The inclusion of a reference ([delving into bitcoin](https://delvingbitcoin.org/t/a decker wattenhofer multichannel for reduced inter lsp trust/1994p 5910 ursula to lsp payment hop 7)) provides additional context on the subject matter, emphasizing the technical aspects and potential improvements in transaction routing within the blockchain domain.