Mas em qual derivation path que será gerado esse endereço que vai receber os fundos?
Essa é a parte complicada.. eu dei uma lida no BIP, mas sou burro e não consegui entender muito bem a ponto de explicar..
Pelo que entendi, os endereços silent NÃO SÃO iguais outros endereços como segwit, p2sh, p2pk, etc.. ele cria um novo tipo de endereço mesclando as informações do endereço que você forneceu com informações privadas do remetente (chave pública?) para gerar esse novo endereço.
Aqui a estrutura dele:
Por que os endereços de silent payments precisam de pelo menos 117 caracteres? Um endereço de silent payment é uma codificação bech32m composta pelas seguintes partes:
HRP [2-3 caracteres]
separador [1 caractere]
versão [1-2 caracteres]
payload, 66 bytes de chaves públicas concatenadas [ceil(66*8/5) = 106 caracteres]
checksum [6 caracteres]
Para um endereço de silent payments versão 0, isso resulta em um endereço de 117 caracteres ao usar um HRP de 3 caracteres. Versões futuras dos endereços de silent payments podem adicionar ao payload, por isso é sugerido um limite de 1023 caracteres.
Aqui tem uma explicação do ChatGPT:
Construção Dinâmica: Um endereço de silent payment não é um endereço fixo como os anteriores (citou p2pk, p2sh, segwit, etc. antes). Ele é gerado dinamicamente, de forma única, para cada pagamento, com base nas chaves públicas do receptor (uma chave de varredura e uma chave de gasto).
Bech32m: A codificação do endereço final é feita no formato Bech32m, que é semelhante ao Bech32 usado em SegWit, mas com diferenças específicas para suportar as características dos silent payments, como o comprimento maior e suporte a versões mais altas.
Nessa parte do BIP eles falam um pouco sobre o endereço:
https://en.bitcoin.it/wiki/BIP_0352#Address_encoding , pelo que entendi, começa com "sp" na mainnet e "tsp" na testnet.
Aqui um exemplo:
tsp1qq0u04ck46vgktprldj3seh9ndrk5wcahfl4qfvsxp8f5kd8n7kzquqhvtlswaek65zcvndmnxs rqsalrxlm7yksecd9cp62xhcu0r7gqvcphvz5pFonte:
https://medium.com/@ottosch/how-silent-payments-work-41bea907d6b0Imagino que nenhum explorador de blocos já está trabalhando com eles.
edit: Por isso a necessidade de uma carteira que lide com isso.. o derivation path parece ser o mesmo do Taproot (m/86), mas não tenho certeza, dá uma lida:
Como cada endereço de saída de silent payment é derivado de forma independente, backups regulares são recomendados. Ao recuperar a partir de um backup, a carteira precisará fazer uma varredura desde o último backup para detectar novos pagamentos.
Se estiver utilizando um backup apenas no estilo seed/seed phrase, o usuário pode recuperar os outputs não gastos da carteira a partir do conjunto de UTXO (ou seja, apenas escaneando transações com pelo menos uma saída taproot não gasta) e pode recuperar o histórico completo da carteira escaneando a blockchain desde o aniversário da carteira. Se a carteira usa rótulos, essas informações DEVEM ser incluídas no backup. Se o usuário não souber se rótulos foram usados, é fortemente recomendado que ele sempre pré-compute e verifique um grande número de rótulos (por exemplo, 100 mil rótulos) para usar ao reescanear. Isso garante que a carteira possa recuperar todos os fundos a partir de um backup de seed/seed phrase. O rótulo de troco deve sempre ser escaneado, mesmo quando nenhum outro rótulo foi usado. Isso garante que o uso de um rótulo de troco não seja crítico para os backups e maximiza a compatibilidade cruzada.
