Simulador MPP

Veja como um pagamento multi-parte (MPP) divide o valor em vários HTLCs

O Multi-Part Payment (MPP) permite dividir um pagamento Lightning em vários HTLCs menores, cada um seguindo uma rota diferente, e todos compartilhando o mesmo payment_hash. Isso contorna limitações de liquidez individual dos canais: em vez de precisar de um único canal com saldo suficiente, o pagador distribui o valor por vários caminhos.

A ferramenta apenas simula a divisão didática de um pagamento. Ela não envia pagamentos, não consulta a rede, não verifica liquidez real e não substitui um nó Lightning ou carteira. Use valores fictícios. Não cole seed, mnemonic, chave privada, macaroon, senha nem dados reais de carteira.

Conteúdo

Ferramenta

Defina o valor total e o número de partes. A ferramenta distribui o valor aleatoriamente entre as partes e simula rotas com taxas diferentes para cada uma.

Simulador MPP

Simulador MPP

Simula um pagamento multi-parte (MPP): divide um pagamento em HTLCs por rotas diferentes.

Resultado do simulador MPP

Fonte primária

O MPP é definido na BOLT 4 — Onion Routing Protocol, no TLV tipo 8 (payment_data) que carrega payment_secret e total_msat. O payment_secret em si vem da invoice BOLT 11. O feature bit basic_mpp (bit 17) indica que o nó suporta MPP.

Ideia simples

Sem MPP, um pagamento de 250.000 msat (250 sat) precisa de um único canal na rota com saldo disponível de pelo menos 250.000 msat. Com MPP, o pagador pode enviar 100.000 msat por um canal, 80.000 por outro e 70.000 por um terceiro — contornando a falta de liquidez em qualquer caminho isolado.

O destinatário só revela a preimage (e portanto só recebe o pagamento) quando todas as partes chegam, ou quando o timeout (mpp_timeout) vence e ele decide aceitar o que chegou. Isso evita que o pagador engane o destinatário pagando só parte do valor.

Anatomia técnica

Campos do MPP no payload onion (BOLT 4)
Campo TLV type Função
payment_data 8 Contém payment_secret (32 bytes) + total_msat (BigSize). Presente em cada parte do MPP.
payment_secret (dentro de 8) Impede que um hop intermediário roube o pagamento fingindo ser o destinatário (probing).
total_msat (dentro de 8) Valor total do pagamento. O destinatário confere se a soma das partes recebidas ≥ total_msat antes de liberar a preimage.

O payment_secret é diferente do payment_hash. O hash é o cadeado comum (derivado da preimage); o secret é uma prova de que quem criou a invoice de fato espera aquele pagamento — sem ele, um nó intermediário poderia criar uma invoice falsa com o mesmo hash e roubar o pagamento.

Limites da ferramenta

A ferramenta simula a divisão didática de um pagamento MPP. Ela não leva em conta: liquidez real dos canais, max_htlc_paths (limite de partes que um nó aceita), htlc_minimum_msat/htlc_maximum_msat por canal, mpp_timeout real, probing defensivo, shadow routing, nem a decisão do destinatário de aceitar ou não um conjunto parcial. As rotas são geradas aleatoriamente e não refletem a topologia real da rede Lightning.

Mapa conceitual

Antes de usar esta ferramenta

Depois de usar esta ferramenta

Referências