SegWit

SegWit ou Segregated Witness (Testemunha Segregada), é uma proposta de mudança nas regras do software que rege o protocolo Bitcoin.^[1] Teve como objetivo^[2] sanar os problemas relacionados a maleabilidade de transações,aumentar a capacidade máxima do bloco e implementar recursos necessários para o suporte a outras aplicações como a Lightning Network^[3] (Rede Relâmpago). SegWit se caracteriza como um Soft Fork,^[4] isto é, um enrijecimento das regras do protocolo que leva a uma retrocompatibilidade com os antigos blocos da rede. Logo, ao contrário dos Hard Forks,^[5] seu ativamento não provoca a criação de uma nova blockchain. Sua ativação foi resultado de um consenso entre os usuários na rede Bitcoin, sendo necessário mais de 95% de aprovação da comunidade pela mudança. No dia 24 de Agosto de 2017, o SegWit foi ativado na rede principal do Bitcoin.

Uma transação no protocolo Bitcoin é identificado por um número hexadecimal de 64 dígitos chamado de txid (Transaction ID). Este número é gerado usando as informações do endereço Bitcoin do destinatário e as moedas que estão sendo gastas. O txid(ID de Transação) pode ser usado para rastrear informações sobre a transação na blockchain tais como a quantidade de Bitcoin enviados, os endereços de envio e recebimento das moedas e a data da transferência. Contudo, a maneira como o txid é calculado permite que qualquer um possa fazer pequenas alterações na transação. Estas modificações não mudam o valor de Bitcoins sendo gastos, seu destino ou endereço de origem. Porém, afetam o ID de transação. Como exemplo, imagine que as seguintes transações ocorram dentro de um curto período de tempo:

Exemplo:

1. Ana realiza o pagamento de 1 bitcoin a Roberto.
2. Roberto usa o txid vindo da transação de Ana para pagar 1 bitcoin José.
3. Se a transação entre Ana e Roberto for incluída na blockchain usando um txid diferente do informado por Roberto a José, esta última transação se tornará inválida. Caso José tenha oferecido um serviço ou enviado um produto a Roberto, Roberto poderia agir de má fé e não refazer a transação usando o txid válido.

Este problema poderia ser evitado caso José esperasse por algumas confirmações na blockchain antes de realizar sua parte da transação. Contudo, carteiras de bitcoin necessitavam de código extra para lidar com este problemas. Em meados de 2015, a rede bitcoin sofreu alguns ataques baseados na maleabilidade de endereços.^[6][7]

Devido ao problema de maleabilidade nas transações, não é possível criar serviços que dependem ou utilizem múltiplas transações não-confirmadas em sequência, pois uma mudança no ID de Transação pode acabar quebrando o resto da corrente de transações. Isto se torna um grande problema para os Contratos Inteligentes (Smart Contracts) e diversas outras aplicações mais avançadas^[8] como:

• Rede Relâmpago,^[9] aumentando enormemente o número de transações por segundo;
• Trocas Atômicas(Atomic Swaps)^[10] entre diferentes criptomoedas;
• Assinatura de Schnorr, que iriam prover outro aumento na capacidade de transações por bloco;^[11]
• MAST(Merkelized Abstract Syntax Trees), uma forma de aprimorar contratos inteligentes (Smart Contracts);^[12]
• TumbleBit, um rede de segunda camada anônima;

A Testemunha Segregada (Segregated Witness ou SegWit) é uma modificação ao protocolo do Bitcoin que propõe a separação dos dados de assinatura de uma transação — designados por testemunha (witness) — do restante conteúdo da transação.^[13]

A proposta foi desenvolvida com o objetivo de resolver o problema da maleabilidade das transações, aumentar a capacidade efetiva dos blocos e possibilitar a implementação de soluções de segunda camada, mantendo a compatibilidade com versões anteriores através de um soft fork.^[14]

No formato tradicional das transações Bitcoin, os dados de assinatura fazem parte da informação utilizada para calcular o identificador da transação (txid). Como as assinaturas podem ser alteradas sem invalidar a transação, é possível modificar o txid, originando o problema conhecido como maleabilidade de transações.

A solução proposta pelo SegWit consiste em mover os dados de assinatura para uma estrutura separada do bloco, denominada testemunha. Dessa forma, o txid passa a ser calculado apenas com base nos dados principais da transação, excluindo as assinaturas.^[13]

A Testemunha Segregada foi concebida para ser ativada como um soft fork. Nós que não reconhecem o novo formato continuam a considerar válidas as transações SegWit, uma vez que os dados da testemunha são estruturados de modo a parecerem dados não relevantes para esses nós. Os nós atualizados, por sua vez, validam explicitamente a testemunha e aplicam as novas regras de consenso.^[15]

Para garantir a integridade dos dados segregados, é utilizada uma árvore de Merkle separada para a testemunha. A raiz dessa árvore é incluída no bloco, assegurando que os dados de assinatura fazem parte do consenso da rede, apesar de não integrarem a árvore principal de transações.^[13]

A separação da testemunha elimina a maleabilidade das transações, permitindo que o identificador de uma transação permaneça imutável após a sua criação. Além disso, o SegWit introduz o conceito de unidade de peso, no qual os dados da testemunha têm menor impacto no limite de tamanho dos blocos, aumentando a capacidade efetiva da rede sem alterar diretamente o limite histórico de 1 MB.^[16]

Esta abordagem facilita também a introdução de futuras melhorias no protocolo, como novas versões de scripts e mecanismos de assinatura mais eficientes.

Para que um Soft Fork ou Hard Fork^[17] seja ativado, é preciso haver um consenso na rede sobre qual versão do software do Bitcoin será utilizada. A forma de ativação escolhida para o SegWit foi o MASF(Miner Activated Soft Fork), descrito pelo BIP 9^[18] (Bitcoin Improvement Proposal). De acordo com o BIP 9, a atualização começará a ser implantada a partir de uma data inicial e a cada 2016 blocos (em torno de 2 semanas) é feita a quantificação de quantos mineradores sinalizaram acordo sobre a mudança das regras. No caso do SegWit, um minerador indicava acordo com as mudanças sinalizando com o número 1 no campo de versão do bloco, dando assim prova de sua concordância. Para que o SegWit fosse ativado com sucesso, mais de 95% dos mineradores deveriam mostrar acordo entre um período de 2016 blocos (em torno de 2 semanas). Contudo, na ativação através do BIP 9 também existe uma data final definida. Se, até a data final, não houvesse consenso suficiente por parte dos mineradores, a mudança não seria adotada. A data de início do SegWit foi de Novembro de 2016 e se estenderia até Novembro de 2017. No dia 24 de Agosto de 2017, o SegWit foi ativado na rede principal do Bitcoin.^[19]

Dentre os principais custos ^[20] relativos a implantação da Testemunha Segregada temos:

Custos de Serialização

Transações e informações de bloco são serializadas por três motivos principais:

• Transmissão através da rede peer-to-peer;
• Armazenamento da blockchain no disco; e
• Avaliação do limite dos blocos

Testemunha Segregada afeta a serialização em duas formas:

1. O comprometimento da testemunha é incluído na transação da moeda base, adicionando entre 38 e 47 bytes, ou algo em torno de 0,005% de um bloco.
2. Uma nova serialização de transação que inclui os dados de testemunha segregada é definida. Isto adiciona uma sobrecarga de 2 bytes por transação para permitir que os formatos de serialização sejam mais facilmente distinguíveis, e um overhead de 1 byte por entrada para contagem dos itens da testemunha para cada entrada. Isto combina cerca de 1% por transação.

Os formatos das transações de Testemunha Segregada tem o seguinte impacto quando serializados (para compreender os termos abaixo olhar , BIP141:

1. Comparado a P2PKH, P2WPKH usa 3 bytes a menos (-1%) in the scriptPubKey, e o mesmo número de bytes de testemunha assim como a assinatura de script P2PKH.
2. Comparado a P2SH, P2WSH usa 11 bytes adicionais (6%) na scriptPubKey, e o mesmo número de bytes que a assinatura de script (scriptSig) P2SH.
3. Comparado a P2PKH, P2WPKH/P2SH usa 21 bytes adicionais (11%), devido ao uso de 24 bytes na scriptPubKey, 3 bytes a menos na scriptSig do que na scriptPubKey da P2PKH, e o mesmo número de bytes de testemunha assim como na scriptSig P2PKH
4. Comparado a P2SH, P2WSH/P2SH usa 35 bytes adicionais (19%), devido ao uso de 24 bytes na scriptPubKey, 11 bytes adicionais na scriptSig comparada a P2SH scriptPubKey, e o mesmo número de bytes de testemunhas da scriptSig da P2SH.

Os percentuais acima são baseados em uma transação de 180 bytes com um entrada e uma saída. Estas proporções permanecem as mesmas à medida que o número de entradas/saídas aumenta, mas decresce se scripts de transações complicadas estão em uso.

Fundamentação A sobrecarga do tamanho da transação é dada por dois fatores:

1. Usando um hash de 256 bits para P2WSH é melhor que o hash de 160 bits para P2SH; e
2. Codificação via P2SH a fim de que as carteiras antigas que não tem suporte a Testemunha Segregada possam enviar fundos que podem ser gastos usando segWit, permitindo ao usuário que recebe ganhar os benefícios de segWit.

Sem esses dois fatores, a sobrecarga seria negligenciada em 3 bytes a menos para P2WPKH e 1 byte a mais para P2WSH.

Custos de validação de blocos

Com a Testemunha Segregada, processamento adicional é apresentado quando se valida um bloco, com o fim de verificar a Árvore de Merkle da Testemunha, e lidar com as transações de testemunha codificadas por P2SH. Isto requer cerca de 5 hashes SHA256 adicionais por transação, um SHA256 adicional por entrada P2SH-codificada-P2WSH, e um HASH160 adicional por saída P2SH-codificada-P2WPKH. Isto entretanto é apenas cerca de 6 execuções de SHA256 sobre a maioria dos 4MB de dados, ou praticamente cerca de 24MB de dados SHA256 ao todo, o que deveria ser traduzido em no máximo 15 segundos adicionais por bloco em um Raspberry Pi v1, ou menos de um décimo de um segundo em um hardware mais capaz.

Riscos de introduzir bugs

O conjunto de ajustes é uma grande mudança para o Bitcoin, e foi lançada, apesar de não ter sido ativada na rede de Bitcoin principal, no Bitcoin Core 0.13.0. Qualquer grande mudança como esta corre uma variedade de riscos, tais como:

• Bugs definitivos: erros podem ser cometidos no projeto ou implementação levando a resultados inesperados e prejudiciais
• Erros de usuário: mudanças no sistema podem ocasionar em confusão para os usuários, resultando no uso incorreto do sistema, que por sua vez podem levar a resultados prejudiciais.
• Interações no ecossistema: partes diferentes do ecossistema Bitcoin podem ter premissas de codificação rígida que serão violadas com a atualização. Por exemplo, aplicações que analisam o armazenamento dos blocos de bitcoin precisarão ser atualizados para compreender a nova serialização.

Riscos devido a blocos maiores

Testemunha Segregada atualizou o limite de bloco de 1MB para um limite de unidade de peso de bloco de 4MB, contando os dados serializados de testemunha como uma unidade, e os dados do bloco central como quatro unidades. Com as transações que usam as características Testemunha Segregada sendo usadas, esta mudança permitirá mais dados a serem incluídos por bloco (com 100% das transações usando características da Testemunha Segregada é esperado cerca de 2MB de dados por bloco, entretanto no pior caso poderia subir para 4MB de dados por bloco). Na medida que permite um maior volume de transações, pode-se esperar que ocorra o aumento da base de dados UTXO (Unspent Transaction Output) mais rapidamente (com 100% das transações usando as características de Testemunha Segregada, a taxa de crescimento poderá dobrar; no entanto, por causa da Testemunha Segregada ser soft-fork ^[21], o pior caso do crescimento UTXO é inalterado). Estes resultados podem ter atributos positivos, mas também podem ter possivelmente pontos negativos significantes:

• Blocos maiores podem resultar numa transmissão de blocos mais devagar, resultando em taxas maiores para os mineradores - dessa maneira pode resultar em menos segurança ou aumentar a centralização.
• Blocos maiores resultarão em requerimentos de recurso ainda maiores para os nós completos, potencialmente causando aos usuários desativarem seus nós, o que resultaria em uma maior centralização.
• Conjuntos maiores de UTXO resultariam em requerimentos de recurso ainda maiores para os mineradores, potencialmente causando aos mineradores compartilharem recursos de validação, o que resultaria em uma maior centralização.

Riscos relacionados a escalonamento de longo prazo

Como descrito acima, com a adoção completa de Testemunha Segregada por todas as transações é esperado que aproximadamente dobre a capacidade ^[22]. Isto provê um aumento significante na capacidade, em curto e médio prazo, dependendo de quão rápida será essa adoração. Além disso, pelo adição de características que possibilitem duas camadas de rede, algum escalonamento a médio e longo prazo pode ser alcançado. Pelo conserto do bug de escalonamento quadrático da assinatura de hash, a Testemunha Segregada também reduz o risco de impactos negativos devido ao aumento futuro de capacidade. Testemunha Segregada, entretanto, não provê nenhum mecanismo direto para escalonamento de um volume de transações on-chain além daquela com duplicação única. Isto gera o risco de que as abordagens de escalonamento à longo prazo possam ser prevenidas ou atrasadas: as partes interessadas podem considerar que Testemunha Segregada como sendo “suficiente” para que se recusem a trabalhar ou apoiar novos esforços.

A Testemunha Segregada inclui uma ampla gama de características ^[23][24] que vão além de simplesmente aumentar a capacidade das blockchains. Podemos citar algumas dessas características:

Ajuste de Maleabilidade

As transações Bitcoin são identificadas por um hash hexadecimal de 64 dígitos chamado de identificador de transação (txid) que é baseado em ambas as moedas gastas e que será capaz de gastar os resultados da transação. Infelizmente, a maneira que o identificador da transação é calculado permite que qualquer um faça pequenas modificações na transação que não mudará seu significado, mas mudará o seu identificador. Isso é chamado de maleabilidade de terceiros. A BIP (Bitcoin Improvement Proposal) 62 tenta endereçar essas emissões de uma maneira fragmentada, mas foi bastante complicado implementar como o consenso checa e portanto foi retirado. Por exemplo, você poderia submeter uma transação com identificador de transação eb32...f001 para a rede mas descobre que uma terceira parte, tal como um nó na rede retransmitindo sua transação, ou o minerador que inclui sua transação em um bloco, modifica suavemente a transação, resultando em uma transação que ainda gasta as mesmas moedas e paga os mesmos endereços, mas sendo confirmado sobre um identificador de transação completamente diferente(79f3...132b, por exemplo). De uma maneira mais geral, se um ou mais assinantes da transação revisam suas assinaturas então a transação permanece válida e paga as mesmas quantidades para os mesmos endereços, mas o identificador de transação muda completamente porque ele é incorporado às assinaturas. O caso geral das mudanças para os dados de assinatura (mas não saídas ou escolha das entradas) que modificam a transação é chamado de maleabilidade da scriptSig. A Testemunha Segregada impede a maleabilidade de terceiros e scriptSig permitindo que usuários Bitcoin movam partes maleáveis da transação nas testemunhas transação, e segregando tais testemunhas para que as mudanças na testemunha não afetem o cálculo do identificador de transação.

Benefícios:

Autores de carteiras podem rastrear bitcoins gastos: esta é a maneira mais fácil para o monitor de status de suas próprias transações de saída simplesmente olhar para elas pelo identificador de transação. Mas em um sistema com maleabilidade de terceiros, carteiras digitais devem implementar um código extra que seja capaz de lidar com mudança de identificadores de transações. Qualquer pessoa que gasta transações não confirmadas: se Alice paga Bob na transação, Bob usa este pagamento para pagar Charlie na transação 2, e então o pagamento de Alice fica maleável e é confirmado com um diferente identificador de transação (txid), então a transação 2 é agora inválida e Charlie não foi pago. Se Bob é confiável, ele irá re-emitir o pagamento para Charlie, mas se ele não for, ele pode simplesmente manter esses bitcoins consigo mesmo. A Rede Lightning: com a maleabilidade de terceiros e da scriptSig consertados, o Rede Lightning é menos complicada de implementar e significantemente mais eficiente em seu uso do espaço na blockchain. Com a maleabilidade da scriptSig removida, isto também seria possível para executar clientes leves da rede Lightning, que terceirizam monitoramento da blockchain, ao invés de cada cliente Lightning precisar também ser um nó Bitcoin completo. Qualquer usando a blockchain: contratos inteligentes hoje, tais como canais de micropagamentos, e novos contratos inteligentes antecipados, tornam menos complicados para projetar, entender e monitorar.

Escala linear de operações sighash

O maior problema com abordagens simples para aumentar o tamanho do bloco do Bitcoin é que para certas transações, o tempo de verificação da escala de assinatura hashing cresce quadraticamente, ao invés de linearmente. Em essência, dobrar o tamanho de uma transação pode dobrar tanto o número de operações de assinatura, como a quantidade de dados que tem que ser embaralhados (hashed) para cada uma das assinaturas a serem verificadas. Isto tem sido visto na prática, onde um bloco individual requer 25 segundos para validar, e transações projetadas maliciosamente poderiam levar mais que 3 minutos. A Testemunha Segregada resolve isto trocando o cálculo do hash da transação por assinaturas para que cada byte de uma transação precise apenas se embaralhado (hashed) no máximo duas vezes. Isto provê a mesma funcionalidade com mais eficiência, de modo que maiores transações possam ainda ser geradas sem correr problemas devido a hash de assinaturas, mesmo se elas são geradas maliciosamente ou blocos (e portanto maiores transações) ainda maiores são suportados.

Benefícios:

Removendo a escala quadrática dos dados embaralhados (hashed) para verificação das assinaturas faz aumentar o tamanho do bloco com mais segurança. Fazer isto sem também limitar o tamanho das transações permite que o Bitcoin continue a suportar pagamentos que vão ou vêm de grandes grupos, tais como pagamentos de recompensa para mineradores ou serviços de crowdfunding. O hash modificado apenas se aplica às operações de assinatura iniciadas a partir dos dados da testemunha, então as operações de assinatura do bloco base continuarão a requerer limites cada vez menores.

Assinatura dos valores de entrada Quando uma carteira de hardware assina uma transação, isto pode facilmente verificar a quantidade total que está sendo gasta, mas pode apenas determinar com segurança a taxa tendo uma cópia completa de todas as transações de entradas que estão sendo gastas, e deve aplicar o hash em cada um dessas para garantir que não está se alimentando de dados falsos. Desde que transações individuais possam ter mais que 1MB de tamanho, isto não é necessariamente uma operação cara, mesmo se a transação que estiver sendo assinada é em si muito pequena. Testemunha Segregada resolve isto fazendo explicitamente hash nos valores entrada. Isto significa que uma carteira de hardware pode simplesmente ser obtida pelo hash da transação, índice e valor (e dizer qual chave pública foi usada), e pode com segurança assinar a transação de gastos, sem se importar no quão grande ou complicada a transação que está gasta foi.

Benefícios:

Fabricantes e usuários de carteiras de hardware são os beneficiários óbvios; no entanto isto provavelmente também faria ser mais fácil assegurar o uso de Bitcoin em um dispositivo pequeno embarcado para aplicações de “Internet das coisas”. Este benefício é apenas disponível quando as transações de gasto enviam à Testemunha Segregada endereços habilitados (ou endereços segwit-via-P2SH).

Aumento da segurança para multi assinatura via processo pay-to-script-hash (PS2H) Pagamentos multi assinatura atualmente usam P2SH que é assegurada por um algoritmo HASH160 de 160 bits (RIPEMD de SHA256). No entanto, se um dos assinantes deseja roubar todos os fundos, eles podem encontrar uma colisão entre um endereço válido como parte de um script multi assinatura e um script que simplesmente paga a eles todos os fundos com apenas 80 bits (280) de trabalho, que já está incluso no domínio de possibilidade para um hacker extremamente bem munido de recursos. Testemunha Segregada resolve isto usando HASH160 apenas para pagamentos diretos a uma chave pública única (onde este tipo de ataque é inútil), enquanto usa hashes SHA256 de 256 bits para pagamentos a um hash de script.

Benefícios:

Todos que pagam contratos inteligentes ou multi assinatura, via Testemunha Segregada, se beneficiam da segurança extra provida pelos scripts.

Versionamento de script

Mudanças para o script Bitcoin permitem melhorar a segurança e também melhorar a funcionalidade. Entretanto, o projeto do script permite apenas mudanças compatíveis com versões anteriores (soft-forking) a serem implementadas pela troca de um dos 10 opcodes OP_NOP extras com um novo opcode que possa talvez trazer falha ao script, mas que por outro lado não faz nada. Isto é suficiente para muitas mudanças - tal como introduzir um novo método de assinatura ou uma característica como OP_CLTV, mas ambas são suavemente hackeáveis (por exemplo, OP_CLTV normalmente tem que ser acompanhada por um OP_DROP) e não pode ser usada para habilitar até mesmo características tão simples como unir duas cadeias. Testemunha Segregada resolve isto incluindo um número de versão para os scripts, para que opcodes adicionais que teriam um hard-fork a ser usada em transações sem Testemunha Segregada possam então ser suportadas simplesmente aumentando a versão do script.

Benefícios:

Mudanças mais fáceis nos opcodes do script farão com que o processo de scripting avançado no Bitcoin seja mais fácil. Isto inclui mudanças tais como introdução das assinaturas de Schnorr, usando chave de recuperação para escolher tamanho das assinaturas, suportar sidechains, ou criar até mesmo de contratos mais inteligentes usando Árvores de Merkle de Sintaxe Abstrata e outras ideias a nível de pesquisa.

Compactação de fraudes de prova Como a base de dados do Bitcoin aumenta, validar a blockchain inteira naturalmente se torna mais caro. Para a descentralização, natureza sem confiança do Bitcoin, é importante permitir aqueles que não podem pagar para validar a blockchain inteira para pelo menos ser capaz de validar da forma mais barata possível dentro do que eles possam pagar. Testemunha Segregada melhora a situação aqui permitindo uma soft-fork futura para ampliar a estrutura da testemunha incluindo dados de compromisso, que permitirão clientes leves (SPV^[25]) estabelecer regras de consenso tal como o número de bitcoins introduzidos em um bloco, o tamanho do bloco, e o número de sigops usados em um bloco.

Benefícios:

Provas de fraude permitem usuários SPV ajudar a estabelecer regras de consenso no Bitcoin,que potencialmente aumentará a segurança da rede Bitcoin como um todo, bem como reduzir as maneiras ao qual usuários individuais possam ser atacados. Estas provas de fraude podem ser adicionadas à estrutura de dados da testemunha como parte de uma futura soft-fork, e elas ajudarão clientes SPV a estabelecer as regras nas transações que não fazem uso das características de Testemunha Segregada.

Ganho de eficiência ao não se verificar assinaturas Assinaturas para transações históricas podem ser menos interessantes que assinaturas para futuras transações - por exemplo, Bitcoin Core não verifica assinaturas antes do ponto de verificação mais recente por padrão, e alguns clientes SPVs simplesmente não verificam eles mesmo as assinaturas, confiando que já foi feito por mineradores ou outros nós. No momento, entretanto, dados de assinatura são partes integrantes da transação e devem estar presentes com o fim de se calcular o hash da transação. Segregar os dados de assinatura permite que os nós que não estão interessados dos dados de assinatura podarem a partir do disco, ou evitar fazer o download em primeiro lugar, economizando recursos.

Benefícios:

Com mais transações usando endereços segWit, as pessoas que executam nós podados ou nós SPV serão capazes de operar com menos largura de banda ou espaço de disco.

Endereços SegWit são diferentes dos endereços tradicionais usados no Bitcoin. Existem 2 formatos diferentes para os Endereços SegWit. Um destes formatos é empacotado dentro de um P2SH(Pay To Script Hash), estes endereços começam com um "3" e se parecem com um endereço MultiSig. Este tipo de endereço pode ser usado em qualquer carteira, tenha ela suporte para transações SegWit ou não. No BIP 173,^[26] foi introduzido um segundo formato para endereços SegWit chamado Bech32. Neste formato, os endereços começam com os dígitos "bc1". O Bech32 não é empacotado em um P2SH(Pay To Script Hash), sendo considerado uma implementação nativa de SegWit.

Para usufruir dos benefícios trazidos pela implementação do SegWit, se faz necessário o uso de uma carteira que adote esta implementação. Ao gastar bitcoins através de endereços SegWit, o valor nas taxas de transações passam a ser menores do que as taxas de um endereço Bitcoin tradicional. Isto ocorre porque a parte da transação que contem a assinatura (a "Testemunha") não precisa ser acessada rapidamente, logo SegWit permite aos mineradores armazenar até 4 vezes mais bytes com informações de assinaturas em um bloco. Isto melhora a eficiência na criação de um bloco de transação, reduzindo os custos operacionais do sistema que gera os blocos, e por sua vez, reduzindo os custos com taxas de transação.^[27]

Na tabela abaixo estão algumas carteiras que possuem suporte a endereços Segwit.^[28]

Depois da ativação do SegWit na rede do Bitcoin, a adoção das mudanças passou a ser feita por grandes casas de câmbio(Exchanges), usuários comuns usando carteiras com suporte a endereços SegWit e outros serviços do ecossistema Bitcoin. No final de Fevereiro de 2018, a adoção do SegWit já beirava os 30% de toda a rede. Grandes casas de câmbio como CoinBase, BitStamp, BitFinex, Kraken,que são responsavéis por realizar uma grandíssima quantidade de transações de Bitcoins, já oferecem suporte ao SegWit em seus serviços.^[29][30]

Ver artigo principal: SegWit2x

Ao contrario do SegWit, que é um Soft Fork e apresenta retrocompatibilidade com a blockchain do Bitcoin, o SegWit2x foi uma proposta de Hard Fork na criptomoeda, o que levaria a criação de uma blockchain paralela em que os usuários da rede deveriam escolher em qual das duas blockchains permanceriam. A proposta do SegWit2x é duplicar o tamanho do bloco de transações, indo de 1 Megabyte tradicional para 2 Megabytes por bloco, tendo assim o foco de aumentar a escalabilidade do Bitcoin, melhorando o número de transações por segundo. A integração do SegWit2x esta prevista para o dia 16 de novembro de 2017, porém foi suspenso por falta de consenso por parte da comunidade.^[31][32]

• Bitcoin
• Soft fork
• Hard Fork
• Lightning Network
• Contrato inteligente
• SegWit2x
• Assinatura de Schnorr

• Proposta do SegWit
• Rede Relâmpago
• Proposta para o formato Bech32