Filtros Bloom são usados para filtrar as transações (e os blocos que as contém) que um nodo VPS recebe de seus pontos. Os nodos VPS irão criar um filtro que corresponde somente aos endereços contidos na carteira do nodo VPS. O nodo VPS irá então enviar uma mensagem filterload para o ponto, contendo o filtro bloom para ser usado na conexão.
Após um filtro ser estabelecido, o ponto irá então etestar cada output da transação contra o filtro bloom. Somente as transações que correspondem ao filtro serão enviadas para o nodo. Em resposta a uma mensagem getdata vindo do nodo, os pontos irão enviar uma mensagem merkleblock que contém somente os cabeçalhos de bloco para os blocos correspondentes ao filtro e um caminho merkle (ver [merkle_trees]) para cada transação correspondente.
O ponto também enviará mensagens tx contendo as transações que correspondem ao filtro. O nodo definindo o filtro bloom pode adicionar padrões ao filtro de maneira interativa ao enviar uma mensagem filteradd. Para limpar o filtro bloom, o nodo pode enviar uma mensagem filterclear. Como não é possível remover um padrão de um filtro bloom, um nodo tem que limpar e reenviar um novo filtro bloom se um padrão não é mais desejado.
Pools de Transações
Quase todo nodo na rede bitcoin mantém uma lista temporária de transações não-confirmadas chamada de pool de memória, mempool ou pool de transações. Os nodos usam esse pool para manter um acompanhamento das transações que são conhecidas pela rede mas que ainda não foram incluídas na blockchain.
Por exemplo, um nodo contendo uma carteira de usuário utilizará um pool de transação para acompanhar os pagamentos para essa carteira que foram recebidos na rede, mas que ainda não foram confirmados.
As transações são recebidas e verificadas, sendo adicionadas ao pool de transações e transmitidas aos nodos vizinhos para serem propagadas para a rede. Algumas implementações de nodos também mantém um pool separado de transações órfãs.
Caso um input de transação referir-se a uma transação que ainda não é conhecida, como um pai desconhecido, a transação órfã será armazenada temporariamente no pool órfão até que a transação pai chegue. Quando uma transação é adicionada ao pool de transações, verifica-se o pool órfão para quaisquer órfãos que sejam referenciados para esses outputs de transação (seus filhos).
Quaisquer órfãos correspondentes são então validados. Se válidos, eles são removidos do pool órfão e adicionados ao pool de transação, completando a cadeia que iniciou com a transação pai. Na presença de uma transação recém-adicionada, que não é mais uma órfã, o processo é repetido recursivamente em busca de quaisquer outros descendentes, até que não se encontre mais nenhum descendente.
Através desse processo, a chegada de uma transação pai desencadeia uma reconstrução em cascata de uma cadeia completa de transações interdependentes ao reunir os órfãos com seus pais ao longo de toda a cadeia.
Tanto o pool de transação quanto o pool de órfãs (quando implementado) são armazenados na memória local e não são salvos em um armazenamento persistente; ao invés disso, eles são populados dinamicamente a partir das mensagens de rede que chegam.
Quando um nodo é iniciado, ambas as pools são esvaziadas e são gradualmente populadas com as novas transações recebidas na rede. Algumas implementações do cliente bitcoin também mantém um banco de dados de UTXO (um pool de UTXO), que é o conjunto de todos os outputs da blockchain que não foram gastos.
Embora o nome "pool de UTXO" pareça semelhante ao pool de transações, ele representa um conjunto de dados diferente.
Ao contrário dos pools de transação e órfãs, o pool UTXO não é inicializado vazio, ao invés disso contém milhões de entradas de outputs de transações não gastos, incluindo alguns antigos, que datam de 2009.
O pool UTXO pode ser armazenado na memória local ou como uma tabela de banco de dados indexada em um armazenamento persistente. Enquanto a transação e os pools órfãos representam uma perspectiva local de um nodo isolado, e podem variar significativamente de nodo para nodo dependendo de quando o nodo foi iniciado ou reiniciado, a pool de UTXO representa o consenso emergente da rede e logo irá variar pouco entre os nodos.
Além disso, a transação e as pools órfãs contém somente transações não-confirmadas, enquanto a pool UTXO contém somente outputs confirmados.
Mensagens de Alerta
As mensagens de alerta são uma função raramente utilizada, mas mesmo assim são implementadas na maioria dos nodos. As mensagens de alerta são um "sistema de alerta de emergências" do bitcoin, um meio através do qual os desenvolvedores do bitcoin core podem enviar uma mensagem de texto de emergência para todos os nodos bitcoin.
Essa funcionalidade foi implementada para permitir que a equipe de desenvolvedores do core possa notificar todos os usuários bitcoin de problemas graves na rede bitcoin, como um bug crítico que exija a ação do usuário para ser corrigido.
O sistema de alerta só foi utilizado poucas vazes, mais notavelmente no início de 2013, quando um bug crítico de banco de dados causou uma bifurcação de múltiplos blocos na blockchain do bitcoin. As mensagens de alerta são propagadas pela mensagem alert.
A mensagem de alerta contém vários campos, incluindo:
ID
Um identificação do alerta, de maneira que alertas duplicados possam ser detectados
Expiration
Uma hora a partir da qual o alerta expira
RelayUntil
Uma hora após a qual o alerta não deve mais ser transmitido
MinVer, MaxVer
A faixa de versões do protocolo bitcoin a qual esse alerta se aplica
subVer
A versão do software de cliente a qual esse alerta se aplica
Priority
Um nível de prioridade para o alerta, atualmente não sendo utilizado
Os alertas são assinados criptograficamente por uma chave pública. A chave privada correspondente é controlada por alguns membros selecionados do time de desenvolvimento do core.
A assinatura digital garante que alertas falsos não sejam propagados na rede. Cada nodo que receber essa mensagem de alerta irá verificá-la, checar pela expiração e propagá-la para todos os seus pontos, dessa maneira garantindo a rápida propagação através de toda a rede.
Além de propagar o alerta, os nodos podem implementar uma função de interface de usuário para apresentar o alerta para o usuário. No cliente Bitcoin Core, o alerta é configurado com a opção da linha de comando -alertnotify, que especifica um comando para ser executado quando um alerta for recebido.
A mensagem de alerta é passada como um parâmetro para o comando alertnotify. Mais comumente, o comando alertnotify é definido para gerar uma mensagem de e-mail para o administrador do nodo, contendo a mensagem de 26 alerta.
O alerta também é exibido como uma caixa de diálogo pop-up na interface gráfica do usuário (bitcoin-Qt), caso ela esteja sendo executada. Outras implementações do protocolo bitcoin podem manejar o alerta em maneiras diferentes. Muitos sistemas de mineração de bitcoin que usam hardware não implementam a função de mensagem de alerta porque eles não tem uma interface de usuário.
É fortemente recomendado que os mineradores que executem esses sistemas de mineração inscrevam-se nesses alertas através de um operador de pool de mineraçõ ou ao executar um nodo de peso leve (lightweight) apenas com o propósito de ter a função do alerta.
FONTE - Esse é um trecho do livro 'Mastering Bitcoin'
EmoticonEmoticon