Submarine Swap

Num swap normal, o utilizador bloqueia bitcoin on-chain e o serviço paga a sua fatura Lightning. Em Reverse Submarine Swap fornece um pagamento Lightning condicionado e resgata uma saída on-chain. Não é necessariamente uma troca para outra moeda nem o simples fecho do próprio canal. [Boltz — Swap types and states]

Uma preimage correspondente ao hash SHA256 permite liquidar o pagamento ligado e resgatar a saída bloqueada. No sentido inverso, o cliente cria a preimage e o serviço mantém o HTLC Lightning pendente antes da revelação. Um claim on-chain pode revelar o segredo; a via cooperativa pode entregá-lo ao serviço fora da cadeia. Um pagamento pendente não é liquidação final. [Boltz — Swap types and states] [Lightning Loop — Architecture]

Antes de financiar, o cliente deve verificar rede, valores com taxas, hash, chaves, prazo e ligação do script ou árvore Taproot ao endereço de destino. A fatura tem de corresponder ao hash e valor acordados. Criptografia correta não ajuda se a aplicação pagar cegamente um endereço arbitrário fornecido pela API. [Boltz — Client verification]

Swaps Taproot podem usar uma assinatura MuSig2 key-path de ambas as partes, poupando espaço e ocultando o script. Se a contraparte não cooperar, o cliente tem de suportar o claim ou refund script-path apropriado. O reembolso cooperativo rápido acrescenta uma opção; não elimina a condição temporal da recuperação unilateral. [Boltz — Claims and refunds] [Lightning Loop — Architecture]

Num swap normal falhado com fundos on-chain já bloqueados, o cliente constrói e transmite ativamente uma transação refund; a via unilateral espera pelo timelock. Num pagamento Lightning inverso não liquidado, o HTLC pode ser cancelado e os fundos libertados sem essa transação do utilizador. Depois de revelar a preimage, porém, não se deve presumir que um pagamento já liquidado regressa automaticamente. [Boltz — Swap types and states] [Boltz — Claims and refunds]

Um swap tem custos de serviço, encaminhamento e on-chain; um swap normal falhado pode acrescentar uma taxa de reembolso. Revelar a preimage antes de confirmar o claim cria uma corrida contra o prazo. O Loop documenta que aumentar a taxa de sweep perto do timeout pode ultrapassar o limite original. Uma estimativa não limita incondicionalmente todos os riscos. [Lightning Loop — Fees] [Lightning Loop — Sweep fee limits]

Guarde a chave refund ou rescue key e os dados do swap conforme o cliente utilizado; a seed comum de outra carteira não recupera universalmente um swap. Boltz restore deriva chaves e procura swaps, mas um xpub sozinho não assina. Script, saída e timeout também importam, não apenas o identificador do serviço. [Boltz — Swap restore] [Boltz — Claims and refunds]

No processo inverso do Boltz, invoice.settled pode significar liquidação da fatura Lightning após revelar a preimage, enquanto o Boltz não acompanha se o cliente transmitiu o claim. Verifique a saída de destino e as confirmações necessárias antes de concluir ou repetir o pagamento. Taproot key-path reduz a visibilidade do script, não o conhecimento do fornecedor sobre valores e tempos. [Boltz — Swap types and states] [Boltz — Client verification]