东方不败 |labitbu

RLN v0.0.10 Development Updates 1. Multi-LSP Provider Connectivity github.com/bitlightlabs/rgb-… Users can connect to multiple LSP providers simultaneously, no longer being restricted to a single service provider. By connecting to different providers, users can access different RGB assets, fee structures, and channel specifications. The system supports both channel purchases in advance (LSPS1) and Just-in-Time (JIT) channel provisioning upon receiving payments (LSPS2). 2. LSPS2 RGB JIT Channels github.com/bitlightlabs/rgb-… LSPS2 enables users without an existing channel to receive RGB assets. Users request a JIT invoice from an LSP and share it with the payer. When the payment reaches the LSP, the LSP automatically opens a channel and forwards the assets to the user. No upfront payment is required from the recipient. - Fees: The payer settles the invoice in BTC. The LSP deducts the channel opening fee, while the remaining BTC is included as the necessary Bitcoin funding for the RGB asset transfer and forwarded to the recipient along with the assets. The amount of RGB assets received by the user remains unchanged. - Channel Reusability: The JIT channel remains usable throughout its lease period. As long as sufficient inbound capacity remains for the asset, subsequent transfers of the same asset can use regular RGB invoices without incurring another channel opening fee. - BTC JIT Support: LSPS2 also supports BTC JIT channels, allowing new users without existing channels to receive BTC. 3. Production-Ready Swap Improvements Swap is now more reliable and robust in production. Key improvements have been implemented: - Integration with Real Swap Execution Logic and Improved Persistence Reliability: The payment hash is now used as the execution_id. Actual parameters, rather than idealized values, are used to calculate CLTV, intermediary fees, and other execution parameters. Bidirectional routing paths and fee limits are also bound to the corresponding quote records. Any parameter changes require a new quote to be generated. - Decoupling Routing Versions from Payment Attempts: Routing version numbers are now independent of payment execution attempts. An Attempt record is created only when a payment is actually initiated. Routing plans and execution attempts are persisted separately. - Hardened Pending-State Handling: A new reconcile interface has been introduced to support verification and reconciliation of pending transactions. The system will not blindly retry a payment unless definitive evidence of its terminal state has been obtained. Make Bitcoin Smart.