Cá estou eu novamente com uma duvida!
Estou pensando em adquirir uma hardwallet, para ser mais especifico, uma Trezor
Minha pergunta é, será que vale a pena em adquirir uma dessa wallet no exterior?
Por exemplo, comprar na Amazon/BestBuy e etc nos EUA?
Falo isso pois infelizmente o preço das hardware wallets aqui no Brasil estão bem carinhas e nem vale tanto a pena
Não acho que vá sair mais barato, a menos que você consiga um portador pra trazer. A Amazon vai cobrar de voce o impsoto adiantado, e vai sair praticamente o mesmo preço que comprar aqui. Se for pra comprar la fora, eu compraria direto no fabricante. Com alguma sorte, eles mandam pelo correio e vc não é taxada. Mas normalmente mandam por transportadora, que sempre cobra o imposto.
Para dar uma animada aqui no tópico
Valendo 1 merit
"O que é a atualização Taproot e quais são os seus pontos positivos e pontos negativos relacionado a atualização?"Eu tava justamente estudando isso ontem. O taproot consiste em 3 etapas:
1- Uso de assinaturas de schnorr
2- Use de merkel trees para scripts
3- permitir que pay to public key e pay to script sejam indistinguíveis entre si.
O que são cada um desses caras ali em cima?
1- Bom, as assinaturas de schnorr são assinaturas também baseadas em curvas elipticas, igual as assinaturas normais do bitcoin, que permitem a combinação de chaves. Hoje para fazer uma tx multiassinada, você precisa acrescentar na transação TODAS as assinaturas, uma pra cada chave. Isso faz a transação multiassinada ficar enorme! Quanto mais pessoas assinando, maior a tx. Com schnorr, você pega todas as chaves publicas, e combina elas em uma unica chave publica, e o memso acontece para a assinatura. Então para quem vê a transação, uma assinatura schnorr com 1000 pessoas assinando é indistinguível de uma assinatura com apenas 1 pessoa assinando. E ocupa o mesmo espaço.
2- Merkel trees são arvores de hashes onde você não precisa mostrar todas as ramificações da arvore para validar se uma das hashes pertence a arvore. basta mostrar a raiz, a hash que vc quer validar, e a posição dela na arvore. Elas são extremamente eficientes de se calcular e validar, e ocupam pouco espaço. O bitcoin ja usa elas para validar as transações dentro de um bloco. A ideia aqui é o seguinte: você constroi um smart contract com varias condições para aceitação, e se apenas uma delas for cumprida, a transação pode ser gasta. A idéia é que você gere uma transação que possa ser paga tanto para uma chave publica quanto para um script, e que, na hora de resgatar essa transação você não precise mostrar o script para a parte que não foi usada. Por exemplo:
A e B estão fazendo uma transação, mas se B não resgatar o dinheiro após 24h, ele é estornado de volta pra A. Para isso voce constroi uma arvore com duas folhas. Uma folha contem "A paga para B" e a outa contem "A paga para A com lock de 24h". Na hora de receber, basta B assinar com sua chave publica. Como isso está na merkel tree (é a primeira folha), B apresenta sua chave publica e resgata a transação. Essa opção esta na merkel tree, então a transação é confirmada. Como não há como saber o que mais está na merkel tree, ninguem nem mesmo fica sabendo que havia a opção de estorno após 24h. Da mesma forma, se passarem 24h sem que B resgate, A pode solicitar o estorno. Para isso, A apresenta sua chave publica e o script de estorno. O script está na merkel tree, então a transação é confirmada. E ninguem fica sabendo que A poderia ter resgatado isso antes de 24h, porque essa parte da transação nunca via ser publicada.
Com isso você tem mais flexibilidade em smart contracts, com mais privacidade e, graças as assinaturas de schnorr, usando menos espaço.
3- e por ultimo, ao permitir que pay to public key e pay to script sejam indistinguíveis, você consegue fazer com que ao publicar uma transação, as pessoas não saibam se ela é multiassinada, assinatura simples, ou um smart contract (ou mesmo uma merkel tree, como descrito em 2), antes da transação ser resgatada. Isso aumenta a sua privacidade, pois vc pode esconder smart contracts ou endereços multiassinados como se fossem endereços comuns.
Além disso, você tem uma grande vantagem nas assinaturas de schnorr que é a validação em lotes! Validar centenas (ou milhares) de assinaturas de schnorr simultaneamente é mais rapido do que validar as assinaturas uma a uma! Isso aumenta a eficiencia dos full-nodes, que precisam validar os blocos assim que chegam, antes de transmitir novamente para os proximos nodes na rede. A estimativa é que a validação de um bloco fique até 4x mais rápida do que é hoje se a validação for feita em lote.
Com tudo isso, o taproot consegue aumentar a privacidade e flexibilidade de smart contracts, reduzir o tamanho das transações, e acelerar a validação delas.
Quanto as desvantagens, o taproot é uma extensão do segwitt. Por causa disso, a binance já fez uma c*gada quando um usuário inseriu um endereço taproot (
https://livecoins.com.br/binance-com-problemas-de-saque-em-bitcoin/ ). A binance ao inves de rejeitar o endereço como incompativel, ignorou o numero de versão do protocolo (o que não deveria fazer) e mandou para um endereço segwitt. Como o taproot paga para uma merkel tree e o segwitt para uma chave privada, e é impossivel achar uma chave privada a partir do endereço (ou o bitcoin estaria quebrado), esses fundos foram definitivamente queimados.
Mas isso é um risco EXTERNO ao protocolo. Foi uma implementação errada feita pela binance, que desrespeitou a especificação do protocolo segwitt e "traduziu" um endereço que não poderia ser traduzido (os 5 ultimos digitos do endereço são um código verificador, e a simples mudança da versão do protocolo invalida esses digitos, ou seja, se a binance estivesse verificando esses digitos veria que o endereço traduzido era inválido).
Dentro de uma carteira bitcoin implementada de forma correta, não há risco disso acontecer, e de modo geral, não lados negativos par ao taproot.