Autor: 1miau
Tópico Original: Why people should be using SegWit addresses

---

---

O SegWit https://en.bitcoinwiki.org/wiki/Segregated_Witness foi introduzido há 4 anos e a sua principal melhoria são as taxas mais baixas para transações enviadas de endereços SegWit.

Existem diferentes formatos de endereços de Bitcoin. Isso é parcialmente visível observando o seu prefixo:

Prefixo	Categoria	Formato
________	__________________________	_______________________________________________________________________________ _____________________
1…	Legacy-Address	P2PKH (pay to public key hash)
3…	Multisignature-Address	P2SH (pay to script hash)
________	__________________________	_______________________________________________________________________________ _____________________
3…	nested SegWit-Address	P2WPKH-P2SH (pay to witness public key hash - pay to script hash) / P2WSH-P2SH (pay to witness script hash - pay to script hash)
________	__________________________	_______________________________________________________________________________ _____________________
bc1q…	native SegWit-Address (bech32)	P2WPKH-bech32 (pay to witness public key hash) / P2WSH-bech32 (pay to witness script hash)
bc1p…	Taproot-Address	P2TR-bech32m (pay to tap root)

1… endereços começando com 1 são endereços Bitcoin padrão e nunca são SegWit.
3… endereços começando com 3 podem ser SegWit, mas também podem ser endereços de múltiplas assinaturas. Só podemos ver se é SegWit depois de enviarmos Bitcoins do endereço e analisando os detalhes da transação de saída.
bc1… Endereços começando com bc1q (SegWit nativo) e bc1p (Taproot)... são sempre endereços SegWit.


Uma explicação simplificada de como identificar endereços SegWit pode ser encontrada aqui: Endereços BTC começando com “3”, o que são? Explicação simplificada.

---

SegWit nativo ou SegWit “aninhado”?

Depois de ler as linhas cima e descobrir os beneficios de usar endereços SegWit, você pode estar de perguntrando quais são as diferenças entre um endereço SegWit nativo (bech32, começando com bc1q…) / endereço Taproot (bech32m, começando com bc1p) comparado com um endereço SegWit “aninhado” (P2WPKH-P2SH / P2WSH-P2SH, começa com 3….).
Para nós, é importante saber que usar um endereço SegWit/endereço Taproot nativo resultará em taxas ainda mais baixas em comparação com um endereço SegWit “aninhado”.

A economia ao enviar de um endereço SegWit aninhado (3…) em comparação com um endereço Legacy (1…) é de 26% +.
A economia ao enviar de um endereço SegWit nativo (bc1q…) em comparação com um endereço Legacy (1…) é de 38% +.
Dependendo do número de entradas no endereço, a economia é variavel, sendo que um maior número de entradas economizará ainda os percentuais.

Adicionado em novembro de 2022: agora, o Taproot-Adress (bc1p…), também esta disponivel. Em termos de economia de taxas, os endereços Taproot são igualmente eficazes como os endereços SegWit nativos (bc1q..). A economia em comparação com um endereço Legacy (1…) é de 38% +.
Um cálculo detalhado pode ser encontrado  aqui, fornecido por Charles-Tim.
Isso porque o SegWit e o Taproot nativos são tecnicamente muito semelhantes, já que o SegWit e o Taproot nativos fazem parte do Programa Witness (bech32 / bech32m).

---

Quais são as vantagens adicionais de usar um endereço SegWit?

Além das taxas de transações mais baixas, você também ajudará a rede Bitcoin usando endereços SegWit, já que mais transações caberão em um bloco. Como resultado, o Bitcoin poderá processar mais transações por segundo, o que beneficia todos os participantes.

---

Alguma desvantagem?

Se voce usou Bitcoins em alguns serviços centralizados e agora deseja envia-los para o seu próprio endereço bech32 SegWit, é possivel que o serviço centralizado não reconheça o seu endereço bech32 e o rejeite como inválido. Isso ocorre porque alguns sites demoram a realizar atualizações e não aceitem esse novo formato de endereço bech32. No entanto, isso se aplica apenas a endereço bech32, mas não ao SegWit “aninhado”, que é compatível em qualquer lugar, sendo que mais serviços darão suporte total ao bech32, mais cedo ou mais tarde. Isso é apenas uma informação, caso você esteja se perguntando por que não pode enviar BTC para um endereço bech32 de alguns serviços centralizados quando ele é rejeitado.

Aqui está uma lista onde você pode ver os diferentes formatos de endereços suportados por algumas wallets: https://en.bitcoin.it/wiki/Bech32_adoption

---

Estatisticas interessantes sobre o SegWit

Assim como muitas coisas em torno do Bitcoin, existem várias estatisticas e gráficos valiosas sobre o SegWit, como por exemplo o https://transactionfee.info/.

Entre outras categorias, você pode encontrar a porcentagem de transações de Bitcoin que estão usando SegWit:


https://transactionfee.info/charts/payments-spending-segwit/
Porcentagem atualmente em torno de 86%.


Uma visão geral sobre as porcentagem de SegWit “aninhado” e SegWit nativo:


https://transactionfee.info/charts/inputs-types-by-count/
Nota: os números totais de SegWit nativo (bech32, roxo e azul escuro) são relativamente baixos em comparação com o SegWit “aninhado” (azul claro e laranja).

---

Conclusão

Escolher um endereço bech32 SegWit será a melhor decisão no longo prazo e isso trará diversas vantagens para você e para a rede Bitcoin de um modo geral  

---

---

Alguma informação sobre isso? Que eu saiba não tem previsão.

O ultimo foram os taproot, bech32m
Mas não trazer necessariamente trás ganhos significativos em taxas.


Realmente isso já está meio antigo, e a adoção do seegwit é bem alta já.
Realmente chega a ter 50% de ganhos nas taxas.

Oloca... sério mesmo que já esta nesse patamar? Eu sabia que já tinha ocorrido uma melhora nessas taxas e especulava que estivesse em torno de uns 42% ~ 45%
Imagino que teve essas diferenças nos números porque quando o 1miau criou esse tópico, foi há quase 3 anos atras (2021) por isso deu essa diferença significativa nas fees de transação!

Mas mesmo assim obrigado por essa observação @bitmover

O problema é que essa diminuição do tamanho é apenas superficial (é apenas para os mineradores).. para os full-nodes não muda nada..

Tem alguns caras como o Luke Dashjr que são até "contra" o segwit, fonte: https://twitter.com/LukeDashjr/status/900764121532174340

Assunto polêmico.

Como assim, só para o lado dos mineradores se sente a diferença?
Se o tamanho da transação é mais pequena quando entra na mempool, como é que fica maior quando chega ao bloco?

Qual a fonte dessa informação? O luke não está falando exatamente isso.

Não sei se isso é verdade.

Segwit significa segregated witnesses,  ou seja,segrega os dados da assinatura (witness) da transação.

Esses dados nunca entram nos blocos, e assim não oneram os nodes.

Fonte
https://en.bitcoin.it/wiki/Segregated_Witness
Daí o bloco fica virtualmente maior, pois as transações segwit são menores.

Bem, se isso for verdade será um aprendizado pra mim

Sempre tive uma dúvida quanto a essa segregação.

Com SegWit, o que entendo é o seguinte:
- Um nó constrói a transação com todos os dados necessários (inputs, outputs, assinatura, etc);
- Esse nó propaga a transação para seus vizinhos (gossip) que irão verificar se a transação cumpre os requisitos;
- Se não cumprem, os nós vão descartando e não propagando mais a transação, do contrário continuam propagando e a transação passa a fazer parte da mempool;

E aqui que eu não entendo: Ao chegar na mempool, a transação já chega em duas partes: Dados das transações e dados de assinatura?

Se sim, os nós mineradores podem utilizar apenas os dados de transação para construir a merkle tree?


Quanto ao uso do bloco:
O que entendo é que com o SegWit, o limite de tamanho de bloco deixou de ser contabilizado apenas em size (ex: 1mb) e passou-se a poder contabilizar também em weight (ex: 4 million weight units (WU)).

Lembrando que não são proporcionalmente correlatos:
Investopedia:

(obs: Tem um typo: Não é 720399 e sim 720339)

E aqui vem o meu entendimento quanto a essa segregação e uso dentro do bloco:

Imagina que temos um avião onde sempre foi possível os passageiros e suas respectivas bagagens irem na cabine. E o limite para encher era de 1 ton. Atingindo-se esse limite, não era mais possível passageiros nem bagagens mesmo que houvesse espaço físico.
Então resolveram dividir a cabine entre área para passageiros e área para bagagens e a partir daí, passou-se a poder acomodar mais de 1 ton desde que fosse possível alocar as malas e os passageiros de maneira otimizada.

Então nesse caso, o avião pode sim passar a voar com mais passageiros, porém a tendência é que ele carregue mais peso.


E agora mais uma variável:
A forma como uma transação SegWit é criada deve ser mais enxuta que uma non-SegWit. Algo como os passageiros que viajam no avião compartimentado terem o costume de levar malas menores.
Assim como o bitmover indicou que existem registros de blocos contendo transações SegWit que caso fossem construídas non-SegWit seriam maiores e ocupariam mais capacidade de um bloco.