O SPV poderia suportar um bilhão de usuários de Bitcoin ? Dimensionando uma reivindicação de escala

Jameson Lopp é engenheiro de software na BitGo, criador do statoshi.info e fundador do bitcoinsig.com.

Neste artigo de Opinião , Lopp analisa profundamente as alegações de que é seguro remover o limite de tamanho de bloco do bitcoin e, em vez disso, confiar nos métodos existentes de "verificação de pagamento simplificada" (SPV).

Uma nova alegação está sendo perpetuada no debate sobre o dimensionamento do Bitcoin .

Estamos ouvindo que é seguro remover o limite de tamanho de bloco porque o Bitcoin pode facilmente escalar para tamanhos de bloco enormes que suportariam bilhões de usuários por meio dos métodos existentes de "verificação de pagamento simplificada" (SPV). Supostamente, o SPV é muito escalável devido à pequena quantidade de dados que requer que um cliente SPV armazene, envie e receba.

Vamos analisar essa afirmação e analisá-la sob diversas perspectivas.

Como funciona o SPV

Satoshi

descreveu o design de alto nível para SPV nowhite paper sobre Bitcoin, embora T tenha sido implementado até dois anos depois, quando Mike Hearn criou Bitcoin J- O que é Bitcoin?.

Ao descartar transações que T eram relevantes para a carteira do cliente SPV, ele conseguiu obter economias substanciais no uso do disco. Levou mais 18 meses para BIP 37a ser publicado, fornecendo uma especificação para filtragem Bloom de transações, contando assim com a raiz Merkle do cabeçalho do bloco para provar a inclusão de uma transação em um bloco, como Satoshi havia descrito. Isso proporcionou uso de largura de banda muito reduzido.

Quando um cliente SPV sincroniza com a rede Bitcoin , ele se conecta a um ou mais nós Bitcoin totalmente validados, determina o bloco mais recente na ponta da cadeia e então solicita todos os cabeçalhos de bloco com um comando "getheaders" para blocos do último bloco sincronizado até a ponta da cadeia.

Se o cliente SPV estiver interessado apenas em transações específicas correspondentes a uma carteira, ele construirá um filtro Bloom com base em todos os endereços para os quais sua carteira possui chaves privadas e enviará um comando "filterload" para o(s) nó(s) completo(s) para que eles saibam que devem retornar apenas transações que correspondam ao filtro.

Após sincronizar os cabeçalhos dos blocos e possivelmente carregar um filtro Bloom, o cliente SPV envia um comando "getdata" para Request cada bloco (possivelmente filtrado) que ele deixou de ver desde a última vez que esteve online, sequencialmente.

Depois que o cliente estiver sincronizado, se ele permanecer conectado ao(s) peer(s) do nó completo, ele receberá apenas mensagens de inventário "inv" para transações que correspondem ao filtro Bloom carregado.

Escala de cliente SPV

Do ponto de vista do cliente, a filtragem Bloom é um meio muito eficiente de encontrar transações relevantes no blockchain, usando o mínimo de recursos de CPU, largura de banda e espaço em disco.

Cada cabeçalho de bloco de Bitcoin tem apenas 80 bytes, então, no momento em que escrevo, são apenas 38 megabytes de dados para toda a história de mais de oito anos do blockchain. A cada ano (aproximadamente 52.560 blocos), são adicionados apenas 4,2 megabytes, independentemente do tamanho dos blocos no blockchain.

A árvore Merkle que é usada para provar a inclusão de uma transação em um bloco também escala extremamente bem. Como cada nova "camada" que é adicionada à árvore dobra o número total de "folhas" que ela pode representar, você T precisa de uma árvore muito profunda para provar compactamente a inclusão de uma transação, mesmo entre um bloco com milhões de transações.

através deDominando Bitcoin

A estrutura de dados da árvore Merkle é tão eficiente que pode representar 16 milhões de transações com uma profundidade de apenas 24 – isso é suficiente para representar um bloco de 8 GB. No entanto, a prova da árvore Merkle para tal transação permanece abaixo de 1 KB em tamanho!

📷viaDominando Bitcoin

É bastante claro que, da perspectiva de um cliente SPV, a rede Bitcoin poderia ser dimensionada para blocos de vários gigabytes e os clientes SPV teriam pouca dificuldade em processar as pequenas quantidades de dados necessárias — mesmo em um telefone celular com conexão 3G.

Mas, infelizmente, escalar a rede Bitcoin não é tão simples assim.

Dimensionamento do servidor SPV

Embora o SPV seja incrivelmente eficiente para clientes, o mesmo não é verdade para o servidor – ou seja, o(s) nó(s) completo(s) para o(s) qual(is) os clientes do SPV fazem solicitações. Este método exibe baixa escalabilidade por uma série de razões.

Os nós na rede precisam processar uma quantidade extremamente grande de dados para retornar os resultados para apenas um único peer, e eles devem repetir esse trabalho em cada bloco para cada peer que o solicita. O E/S de disco rapidamente se torna um gargalo.

Cada cliente SPV deve sincronizar todo o blockchain desde a última vez que teve contato com a rede ou, se acreditar que perdeu transações, precisará escanear novamente todo o blockchain desde a data de criação da carteira. No pior caso, no momento da escrita, isso é aproximadamente 150 GB. O nó completo deve carregar cada bloco individual do disco, filtrá-lo de acordo com as especificações do cliente e retornar o resultado.

Como blockchains são uma forma de livro-razão somente de acréscimos, essa quantia nunca vai parar de crescer. Sem mudanças extensivas de protocolo, a poda de blockchain é incompatível com o BIP 37 – ele espera que todos os blocos estejam disponíveis em todos os nós completos que anunciam NODE_BLOOM.

Os clientes SPV do BIP 37 podem ser enganados por omissão. Para combater isso, os clientes SPV se conectam a vários nós (geralmente quatro) embora ainda não seja uma garantia – clientes SPV podem ser particionados da rede principal por um ataque Sybil. Isso aumenta a carga na rede de nós completos por um fator de quatro.

Para cada cliente SPV conectado que foi sincronizado com a ponta do blockchain, cada bloco e transação de entrada deve ser filtrado individualmente. Isso envolve uma quantidade não negligenciável de tempo de CPU e deve ser feito separadamente para cada cliente SPV conectado.

Analisando os números

No momento em que este artigo foi escrito, havia aproximadamente 8.300 full nodes em execução que aceitam conexões de entrada; cerca de 8.000 deles anunciam NODE_BLOOM e, portanto, devem ser capazes de atender a solicitações de clientes SPV. Mas quantos clientes SPV o número atual de full nodes de escuta pode suportar razoavelmente?

O que seria necessário para que a rede fosse composta de nós completos que pudessem suportar um bilhão de usuários diários e blocos grandes o suficiente para acomodar suas transações?

O Bitcoin CORE tem como padrão um máximo de 117 conexões de entrada, o que criaria um limite superior de 936.000 soquetes disponíveis na rede. No entanto, a maioria desses soquetes já é consumida hoje.

Cada nó completo se conecta a outros oito nós completos por padrão. O desenvolvedor do Bitcoin CORE Luke-Jr (muito bruto) contagem de nós estima 100.000 nós totais no momento da escrita; 92.000 dos quais T disponibilizam soquetes para clientes SPV. Isso consome 800.000 soquetes disponíveis apenas para nós completos, deixando apenas 136.000 soquetes disponíveis para clientes SPV.

Isso me leva a concluir que cerca de 85 por cento dos soquetes disponíveis são consumidos pela malha de rede de nós completos. (Vale a pena notar que o método de estimativa de Luke-Jr T consegue determinar quanto tempo nós não ouvintes passam online; certamente pelo menos alguns deles se desconectam e se reconectam periodicamente.)

Meu nó que alimentastatoshi.infomédias de 100 peers de nó completo (oito de saída, 92 de entrada) e 25 clientes SPV. Isso é 80 por cento dos soquetes disponíveis sendo consumidos por nós completos.

Se quisermos que até 1 bilhão de clientes SPV consigam usar tal sistema, será necessário haver recursos de nó completo suficientes disponíveis para atendê-los – soquetes de rede, ciclos de CPU, E/S de disco e assim por diante. Podemos fazer a matemática funcionar?

Para dar o benefício da dúvida às reivindicações de escalonamento do SPV, usarei algumas suposições conservadoras de que cada um dos bilhões de usuários do SPV:

– Envie e receba uma transação por dia.

– Sincronize sua carteira com a ponta do blockchain uma vez por dia.

– Consulte quatro nós diferentes ao sincronizar para diminuir as chances de ser enganado por omissão.

Um bilhão de transações por dia, se distribuídas uniformemente (o que certamente não seria), resultaria em cerca de 7 milhões de transações por bloco. Devido à grande escalabilidade das árvores Merkle, seriam necessários apenas 23 hashes para provar a inclusão de uma transação em tal bloco: 736 bytes de dados mais uma média de 500 bytes para a transação.

Adicione mais 12 KB de cabeçalhos de bloco por dia e um cliente SPV ainda estaria usando apenas cerca de 20 KB de dados por dia.

No entanto, 1 bilhão de transações por dia gera 500 GB de dados de blockchain para nós completos armazenarem e processarem. E cada vez que um cliente SPV se conecta e pede para encontrar quaisquer transações para sua carteira no dia anterior, quatro nós completos devem ler e filtrar 500 GB de dados cada.

Lembre-se de que atualmente há cerca de 136.000 soquetes disponíveis para clientes SPV na rede de 8.000 nós completos que atendem SPV. Se cada cliente SPV usar quatro soquetes, então apenas 34.000 clientes poderão estar sincronizando com a rede a qualquer momento. Se houvesse mais pessoas online ao mesmo tempo do que isso, outros usuários tentando abrir suas carteiras teriam erros de conexão ao tentar sincronizar com a ponta do blockchain.

Portanto, para que a rede atual suporte 1 bilhão de usuários SPV que sincronizam uma vez por dia, enquanto apenas 34.000 podem sincronizar a qualquer momento, são 29.400 "grupos" de usuários que devem se conectar, sincronizar e desconectar: cada usuário precisaria ser capaz de sincronizar os dados do dia anterior em menos de três segundos.

Isso representa um BIT de enigma porque exigiria que cada nó completo fosse capaz de ler e filtrar 167 GB de dados por segundo por cliente SPV continuamente. Com 20 clientes SPV por nó completo, isso é 3.333 GB por segundo. Não tenho conhecimento de nenhum dispositivo de armazenamento capaz de tal rendimento. Deve ser possível criar uma enorme matriz RAID 0 de discos de estado sólido de alta qualidadeque podem atingir cerca de 600 MB/s cada.

Você precisaria de 5.555 drives para atingir a taxa de transferência desejada. O disco de exemplo vinculado custa US$ 400 no momento da escrita e tem aproximadamente 1 TB de capacidade – o suficiente para armazenar blocos equivalentes a dois dias nessa rede teórica. Assim, você precisaria de uma nova matriz de discos a cada dois dias, o que custaria mais de US$ 2,2 milhões – isso equivale a mais de US$ 400 milhões para armazenar blocos equivalentes a um ano e ainda atender à taxa de transferência de leitura necessária.

Claro, podemos brincar com essas suposições e ajustar vários números. Podemos produzir um cenário em que o custo do nó seja mais razoável?

Vamos tentar:

E se tivéssemos 100.000 nós completos, todos rodando discos giratórios mais baratos e de alta capacidade, e de alguma forma os convencêssemos a aceitar conexões de clientes SPV? E se também conseguíssemos modificar o software do nó completo para suportar 1.000 clientes SPV conectados?

Isso nos daria 100 milhões de soquetes disponíveis para clientes SPV que poderiam suportar 25 milhões de clientes SPV simultâneos na rede. Assim, cada cliente SPV teria 2.160 segundos por dia para sincronizar com a rede. Para um nó completo KEEP a demanda, ele precisaria manter uma velocidade de leitura consistente de 231 MB/s por cliente SPV, o que resultaria em 231 GB/s, assumindo 1.000 clientes SPV conectados.

Um disco rígido de 7.200 RPM pode ler cerca de 220 MB/s, então você pode atingir essa taxa de transferência de leitura com uma matriz RAID 0 de um BIT mais de 1.000 unidades.

No momento da escrita, você pode comprar umUnidade de 10 TB por US$ 400, portanto, um conjunto RAID de US$ 400.000 dessas unidades permitiria que você armazenasse blocos suficientes para 20 dias — o que equivale a US$ 7,2 milhões, muito mais administráveis, para armazenar blocos suficientes para um ano e ainda atingir os requisitos de rendimento de leitura do disco.

Vale a pena notar que ONE em sã consciência executaria um array RAID 0 com tantas unidades porque uma única falha de unidade corromperia todo o array de discos. Portanto, um array RAID com tolerância a falhas seria ainda mais caro e menos performático. Também parece incrivelmente otimista que 100.000 organizações estariam dispostas a desembolsar milhões de dólares por ano para executar um nó completo.

Outro ponto a ser observado é que essas estimativas conservadoras também assumem que os clientes SPV de alguma forma se coordenariam para distribuir seus tempos de sincronização uniformemente ao longo de cada dia. Na realidade, haveria picos e vales cíclicos diários e semanais de atividade – a rede precisaria ter uma capacidade bem maior do que a estimada acima para acomodar a demanda de pico.

Caso contrário, muitos clientes SPV não conseguiriam sincronizar durante os horários de pico de uso.

Curiosamente, verifica-se que alterar o número de soquetes por nó T afeta a carga geral em nenhum nó completo – ele ainda acaba precisando processar a mesma quantidade de dados. O que realmente importa nessa equação é a proporção de nós completos para clientes SPV. E, claro, o tamanho dos blocos na cadeia que os nós completos precisam processar.

O resultado final parece inevitável: o custo de operar um nó completo capaz de atender à demanda de SPV de um bilhão de transações diárias na cadeia seria astronômico.

Buscando um meio termo

A essa altura, está bem claro que um bilhão de transações por dia coloca o custo de operação de um nó totalmente validado fora do alcance de todas as entidades, exceto as mais ricas.

Mas e se invertermos esse cálculo e tentarmos encontrar uma fórmula para determinar o custo de adicionar carga à rede aumentando o rendimento das transações na cadeia?

Para que a rede Bitcoin suporte um número alvo de transações por segundo (adicionando capacidade para 86.400 novos usuários diários líquidos), podemos calcular os requisitos de rendimento de disco por nó como:

Isso nos dá o throughput mínimo de leitura de disco por segundo para um nó completo para atender à demanda de clientes SPV. Com as características existentes da rede e a Tecnologia disponível, podemos extrapolar um custo estimado de operação do nó usando o throughput do disco como o gargalo assumido. Observe que certamente há outras restrições de recursos que entrariam em jogo, aumentando assim o custo da operação do nó completo.

Para oseguintes cálculos, usei estas suposições:

– Tamanho médio da transação em bytes = 500 bytes com base emstatoshi.info.

– Número total de usuários do SPV = um por transação por dia.

– Sockets consumidos por um cliente SPV = padrão de quatro.

– Número de soquetes disponíveis para clientes SPV em cada nó completo = número calculado anteriormente de 20.

– Total de soquetes de rede disponíveis para clientes SPV = número calculado anteriormente de 136.000.

– Custo de rendimento e espaço no disco rígido = US$ 400 Unidades de 10 TB e 7.200 RPM em configuração RAID 0.

Infelizmente, os requisitos de throughput de disco e, portanto, o custo para operar um nó completo aumentam quadraticamente em relação ao número de transações por segundo. Os custos rapidamente se tornam insustentáveis para a maioria das entidades.

Para referência, lembre-se de que a Visa processa cerca de 2.000 transações por segundo. No Bitcoin, isso exigiria quase US$ 200.000 em discos apenas para KEEP a demanda do SPV. Um ponto que vale a pena notar é que esses gráficos KEEP o número de nós completos constante em 8.000 – na realidade, eles provavelmente diminuiriam conforme o custo aumentasse, aumentando assim os requisitos de rendimento e o custo de operação dos nós restantes para aumentar ainda mais rápido.

Isso parece ser uma força agravante da centralização dos nós.

As pesquisas (não científicas) que realizei um ano antes mostraram que 98% dos operadores de nós não pagariam mais de US$ 100 por mês para executar um nó, mesmo que estivessem altamente investidos em Bitcoin. Eu estaria disposto a apostar que aumentar as transações on-chain do bitcoin em uma ordem de magnitude resultaria na perda da maioria dos nós completos, enquanto um aumento de duas ordens de magnitude resultaria em uma perda de 90% ou mais nós.

Acredito que é seguro assumir que muito poucas entidades estariam dispostas a se dar ao trabalho de construir matrizes RAID para executar um nó completo. Se esse for o caso, é insustentável alegar que tais aumentos seriam bons para o usuário médio, porque T haveria rendimento de disco de nó completo ou soquetes disponíveis para atender à demanda de SPV.

Outras fraquezas do SPV

O SPV é ótimo para usuários finais que T exigem a segurança ou Política de Privacidade de um nó de validação completa. No entanto, há muitos motivos que podem ser considerados empecilhos para uma rede Bitcoin majoritariamente SPV, independentemente de sua escalabilidade.

O SPV faz suposições importantes que resultam em segurança e Política de Privacidade mais fracas do que um nó de validação completa:

• Os clientes do SPV confiam nos mineradores para validar e aplicar corretamente as regras do Bitcoin; eles assumem que o blockchain com a maior prova de trabalho cumulativa também é uma cadeia válida. Você pode Aprenda sobre a diferença entre os modelos de segurança SPV e full node neste artigo.
• Os clientes SPV assumem que nós completos não mentirão para eles por omissão. Um nó completo T pode mentir e dizer que uma transação existiu em um bloco quando ela T existiu de fato, mas pode mentir dizendo que uma transação que existe em um bloco não aconteceu.
• Como os clientes do SPV buscam eficiência, eles só Request dados de transações que pertencem a eles. Isso resulta em uma perda massiva de Política de Privacidade.

Curiosamente, o coautor do BIP 37, Matt Corallo,lamenta ter criado isso:

"Um grande problema hoje para a Política de Privacidade dos usuários no sistema são os filtros bloom do BIP37 SPV. Desculpe, eu escrevi isso."

Os clientes do SPV filtrados pelo Bloom do BIP 37 têmbasicamente nenhuma Política de Privacidade, mesmo quando usando taxas de falsos positivos irracionalmente altas. Jonas Nick [um engenheiro de segurança na Blockstream] descobriu que, dada uma única chave pública, ele poderia então determinar 70% dos outros endereços pertencentes a uma determinada carteira.

[incorporar]https://www.youtube.com/watch?v=HScK4pkDNds[/incorporar]

Você pode contornar a baixa Política de Privacidade do SPV dividindo os filtros Bloom entre muitos pares, embora isso torne a escalabilidade do SPV ainda pior ao colocar mais carga em mais nós completos.

O BIP 37 também é vulnerável a ataques triviais de negação de serviço. O código de demonstração édisponível aquique é capaz de paralisar nós completos ao fazer muitas solicitações rápidas de inventário por meio de filtros especialmente construídos que causam busca contínua em disco e alto uso da CPU.

O autor da prova de conceito do ataque, o desenvolvedor CORE Peter Todd, explica:

"O problema fundamental é que você pode consumir uma quantidade desproporcional de largura de banda de E/S de disco com muito pouca largura de banda de rede."

Até hoje, os alertas de fraude que Satoshi descreveu no white paper não foram implementados. Na verdade, os esforços de pesquisa nessa área mostraram que pode nem ser possível implementar alertas de fraude leves.

Por exemplo, um alerta de fraude só funciona se você realmente puder obter os dados necessários para provar a fraude – se um minerador não fornecer esses dados, o alerta de fraude T poderá ser criado. Como tal, os clientes SPV T têm o nível de segurança que Satoshi imaginou que teriam.

De uma perspectiva de alto nível, um mundo consistindo principalmente de nós SPV torna as mudanças de consenso, como o limite total de moedas ou mesmo a edição do livro-razão, muito mais fáceis. Menos nós de validação completa significam uma aplicação mais centralizada das regras de consenso e, portanto, menos resistência à mudança das regras de consenso. Algumas pessoas podem considerar isso um recurso; a maioria certamente considera isso uma falha.

Melhorias potenciais

A segurança e a escalabilidade do SPV poderiam ser potencialmente melhoradas de várias maneiras por meio de provas de fraude, dicas de fraude, provas de entrada, provas de gasto e assim por diante. Mas, até onde sei, nenhuma delas passou da fase de conceito, muito menos está pronta para implantação em produção.

Compromissos do filtro Bloom

poderia melhorar a Política de Privacidade, mas há uma compensação pela utilidade entre o tamanho do filtro e sua taxa de falsos positivos: muito grosso significa que os pares baixam muitos blocos de falsos positivos, muito fino significa que os filtros serão absolutamente gigantescos e impraticáveis ​​para qualquer um baixar com um cliente SPV.

Isso reduziria a carga no rendimento do disco de nó completo, mas a compensação seria o aumento da largura de banda tanto para clientes SPV quanto para nós completos, porque blocos inteiros teriam que ser transferidos pela rede.

Esse filtragem compacta do lado do cliente proposta recentemente elimina problemas de Política de Privacidade , mas exige que blocos completos sejam baixados se houver uma correspondência com o filtro (embora não necessariamente pela rede p2p!).

Compromissos UTXO

poderia permitir que clientes SPV sincronizassem seu conjunto UTXO atual e, assim, o saldo da carteira sem exigir que o nó completo escaneie todo o blockchain. Em vez disso, forneceria uma prova da existência dos UTXOs.

Pode ser possível se proteger contra ataques DoS do filtro Bloom exigindo que os clientes do SPV enviem prova de trabalho (insustentável em um dispositivo alimentado por bateria, como um telefone) ou micropagamentos baseados em canais (impossíveis de inicializar se um cliente ainda T recebeu dinheiro), mas nenhum dos dois oferece uma solução direta.

Os requisitos de leitura de disco para nós completos provavelmente poderiam ser reduzidos de diversas maneiras por meio de indexação aprimorada de dados e processamento em lote de solicitações de clientes SPV.

Ryan X Charles destacou nos comentários abaixo que usar o protocolo de pagamento do BIP70 para informar diretamente a alguém o ID UTXO do pagamento que você está enviando removeria a necessidade de usar filtros bloom, já que eles poderiam Request os dados diretamente de nós completos. Isso é incrivelmente eficiente se você estiver disposto a aceitar a troca de Política de Privacidade .

Basta dizer que há muito espaço para melhorias - muitos desafios precisarão ser superados para melhorar a escalabilidade na cadeia.

Soluções de dimensionamento adequadas

Se ignorarmos a infinidade de outros problemas diversos com o dimensionamento para tamanhos de bloco maiores, como latência de propagação de bloco, dimensionamento de conjunto UTXO, tempos de sincronização inicial de blockchain e compensações de segurança e Política de Privacidade , pode ser tecnicamente possível dimensionar o Bitcoin para um bilhão de usuários diários na cadeia se houver entidades dispostas a investir recursos significativos para desenvolver melhorias de software e operar a infraestrutura necessária.

Parece altamente improvável que o Bitcoin evolua organicamente dessa forma, no entanto, porque há maneiras muito mais eficientes de escalar o sistema. A mais eficiente é uma forma de escala já sendo usada: consolidação em torno de provedores de API centralizados. Tende a haver enormes compensações de confiança e Política de Privacidade ao empregar esses métodos, mas muitas dessas interações envolvem acordos contratuais que mitigam alguns dos perigos.

Em termos de escala de forma confiável, protocolos de Camada 2 como o Lightning oferecem escala muito mais eficiente porque os altos volumes de dados transferidos estão sendo enviados apenas entre o pequeno número de partes diretamente envolvidas em uma determinada transação off-chain. Você pode pensar nisso como a diferença entre uma camada de comunicação ethernet broadcast-to-all versus uma camada IP roteada – a internet T poderia escalar sem roteamento e nem a Internet of Money.

Embora essa abordagem de dimensionamento seja muito mais complexa tecnicamente do que o dimensionamento centralizado tradicional e exija a superação de alguns desafios específicos, o investimento inicial de recursos para pesquisa e desenvolvimento desses protocolos de roteamento renderá enormes dividendos a longo prazo, pois eles reduzem a carga que precisa ser suportada por toda a rede em ordens de magnitude.

Há também muitas opções intermediárias que podem ser exploradas:

– Esquemas de custódia centralizados com Política de Privacidade perfeita que usam tokens Chaum, como HashCash.

– Sistemas centralizados não custodiais de prova de conhecimento zero, comoTumbleBit.

– Sidechains federadas (multiassinatura semiconfiável)https://elementsproject.org/sidechains/.

– Garantido por minerador (semi-confiável)correntes de transmissão.

Eu sou ainda convencido que a longo prazo, o Bitcoin precisará de blocos muito maiores.

Mas sejamos pacientes e diplomáticos, tentando dimensionar o sistema da forma mais eficiente possível, mantendo suas propriedades de segurança e Política de Privacidade .

Um PayPal auditável e ligeiramente descentralizado certamente teria utilidade se fosse funcional do ponto de vista do usuário médio, mas não ofereceria o nível de soberania financeira que os bitcoiners desfrutam hoje.

Obrigado a Matt Corallo, Mark Erhardt e Peter Todd por revisar e fornecer feedback para este artigo

Aviso Importante: A CoinDesk é uma subsidiária do Digital Currency Group, que possui participação acionária na Blockstream.