Configuração de Pool de Mineração XBT DATUM com Codex: Guia para Todos os Mineradores de XBT
Configuração de Pool de Mineração XBT DATUM com Codex: Guia para Todos os Mineradores de XBT
Um minerador sem experiência em Linux pode construir um nó DATUM privado e conectar mineradores XBT? Sim. Este guia abrange ASICs XBT/BLAKE2b compatíveis de diversas marcas, com instruções do Codex que podem ser copiadas e nossa implementação do iBeLink BM-S3 como um exemplo.
Nossa implementação utiliza um VPS americano de baixo custo e um nó Bitcoin Knots otimizado. A configuração de gateway planejada utiliza CONVOY, com Lazarus como pool de mineração XBT DATUM principal e AlphaPool e XorPool como perfis de espera. Nossa frota de teste possui cerca de dez unidades BM-S3 em um local sem IP público fixo; o mesmo layout de rede se aplica a outros mineradores XBT compatíveis.
Situação da implantação, 12 de outubro de 2026: O nó ainda está validando a cadeia XBT. Na última verificação, ele havia validado o bloco 883,719 de 976,785 cabeçalhos conhecidos, com
initialblockdownload: truee cerca de 78.5% de progresso na verificação. O Gateway DATUM foi intencionalmente interrompido. Os handshakes da pool, o failover e os resultados da participação dos mineradores ainda não foram testados. Os passos 9 a 14 abaixo são as próximas ações e seus respectivos prompts do Codex (que podem ser copiados), e não afirmações de que esses testes foram aprovados. Atualizaremos este artigo com os resultados obtidos após a verificação.
Este é um guia operacional, não uma promessa de lucratividade. Pontos de acesso, chaves, taxas, software e preços estão sujeitos a alterações, portanto, o Codex precisa verificar as fontes oficiais.
Nota sobre a nomenclatura: Aqui, “XBT” significa o fork BLAKE2b comumente chamado de BTCB2; algumas listagens de mercado usam BTC2B. Esses rótulos podem ser confundidos com o ticker XBT do Bitcoin comum, portanto, verifique a cadeia e o algoritmo BLAKE2b antes de configurar qualquer minerador.
Resposta rápida: Um iniciante consegue construir um nó XBT DATUM?
Sim, com pontos de controle bem definidos.
Você gerencia a identidade, o pagamento, o CAPTCHA ou a autenticação de dois fatores e seu endereço público para recebimento de pagamentos. A Codex cuida da pesquisa, configuração, instalação, testes, solução de problemas e documentação.
Nunca forneça à Codex — ou a qualquer pool — a frase mnemônica ou a chave privada da sua carteira. A mineração requer apenas um endereço público para pagamentos. Senhas, códigos de uso único e detalhes de pagamento devem ser inseridos diretamente na interface segura do provedor, e não colados em um chat.
Trata-se de uma sequência de etapas baseadas em evidências, não de um comando mágico. Corrija qualquer verificação com falha antes de prosseguir.
O que é um pool de mineração XBT DATUM e o que o DATUM altera?
Em uma conexão de pool convencional, um ASIC se comunica diretamente com um servidor Stratum. O pool normalmente constrói o modelo de bloco e decide quais transações serão incluídas. O minerador realiza a prova de trabalho, mas grande parte da decisão de construção do bloco permanece a montante.
O DATUM altera essa relação por meio de três camadas:
- Um nó local compatível com Bitcoin valida a cadeia XBT e constrói modelos de bloco.
- Um Gateway DATUM converte esses modelos em trabalho que os mineradores ASIC existentes podem consumir através do Stratum.
- Um pool compatível com DATUM coordena ações e pagamentos agrupados sem ser o único criador de modelos de bloco.
Bitcoin Knots valida, CONVOY serve para trabalho e Lazarus é o principal pool de mineração de XBT DATUM. AlphaPool e XorPool são opções de reserva; mineradores individuais não precisam de um nó completo.
Cada minerador XBT compatível inicia uma conexão de saída com o VPS, portanto, a mudança do IP público do site de mineração não é um problema. Um domínio é opcional.
Se você ainda está comparando o ecossistema, leia BTCPools de mineração B2: como descentralizar o hashrate e o mais amplo Guia de Mineração de Forks BIP-110 em primeiro lugar.
O que você precisa antes de começar
Prepare o seguinte:
- Um ASIC BLAKE2b compatível com XBT para o primeiro teste, independentemente da marca ou modelo.
- Firmware oficial do minerador e acesso à interface web do minerador.
- Um XBT público/BTCEndereço de pagamento B2 — nunca uma frase mnemônica ou chave privada.
- Uma conta na nuvem e um orçamento mensal para VPS de aproximadamente US$ 8 a 15.
- Um computador executando o Codex com terminal e acesso a arquivos.
- Chegou a hora da sincronização nativa do blockchain e do período de observação de um único minerador.
Nosso servidor de teste é um Contabo Cloud VPS 4 dos EUA rodando Ubuntu 24.04 LTS. Na compra, custou cerca de US$ 8.20 mensais e incluía capacidade SSD suficiente para um nó otimizado, aproximadamente 8 GB de RAM e uma margem de segurança de 2 GB para swap. Verifique os termos atuais antes de efetuar o pagamento.
Você pode navegar pelos modelos compatíveis em BTCColeção de mineiros B2. O Especificações do iBeLink BM-S3 Este texto descreve nosso modelo de teste; outras marcas podem usar rótulos de interface web e configurações de firmware diferentes.
Passo 1: Forneça ao Codex um briefing mestre de segurança.
Inicie uma nova tarefa no Codex dentro de uma pasta de projeto dedicada. O primeiro prompt define o resultado, os limites e as regras de aprovação.
Copie este prompt do Codex
Help me deploy an XBT/BTCB2 DATUM node for my XBT-compatible BLAKE2b miners. My current fleet is approximately 10 iBeLink BM-S3 units, but the setup guide must work for other compatible brands and models too.
Requirements:
- Use a low-cost US VPS with a fixed public IPv4 address.
- Use Ubuntu LTS, a pruned Bitcoin Knots node, and the official CONVOY DATUM Gateway.
- Lazarus will be the primary pool. AlphaPool and XorPool should be manually selectable standby profiles.
- The mining location has no fixed public IP, so miners must make outbound connections to the VPS.
- Keep node RPC and the gateway management API on loopback only. Expose only SSH and the miner-facing Stratum port.
- Use official sources, verify checksums, pin software versions or commits, and keep a sanitized deployment record.
- Do not start the gateway until native initial block download is complete and getblocktemplate is verified.
- Test one miner before migrating the rest.
Safety rules:
- Never ask me for a wallet seed phrase, private key, payment card, password, or one-time code in chat.
- I will complete payment, CAPTCHA, 2FA, and sensitive form fields myself.
- Explain any irreversible or security-sensitive action before taking it.
- Never publish my VPS IP, payout address, usernames, credentials, or account identifiers.
- Do not publish the final blog article until I have reviewed and approved a preview.
First produce a staged implementation plan, a risk list, and a list of facts that must be verified from current official sources. Do not change any system yet.
O Codex deve retornar um plano de execução em etapas, e não instalar o software imediatamente. Interrompa a execução se ele solicitar segredos da carteira, expor o protocolo RPC, ignorar a verificação de checksum ou iniciar todos os mineradores antes de testar um.
Passo 2: Selecione e compre o VPS
Peça ao Codex para comparar os planos atuais. Como os preços são voláteis, ele deve usar as páginas atualizadas dos provedores em vez de dados armazenados na memória.
Copie este prompt do Codex
Compare currently available monthly US VPS plans for this deployment. I want month-to-month billing for the first test, a fixed public IPv4 address, Ubuntu 24.04 LTS or another supported Ubuntu LTS release, enough SSD storage for a pruned XBT node, and at least 4 GB RAM.
Show the real checkout price, renewal price, storage, bandwidth, region, IPv4 terms, and cancellation conditions. Recommend one plan, but stop before purchase. I will create the account, enter personal and payment information, complete CAPTCHA/2FA, and confirm the charge myself.
Verifique o armazenamento, as taxas de IPv4, os custos de instalação e a duração do contrato — não apenas o preço inicial. Registre as especificações e a cobrança de forma privada; publique apenas detalhes gerais.
Etapa 3: Estabeleça o acesso SSH antes do reforço da segurança.
O provedor do servidor pode fornecer inicialmente uma senha de root. Não a copie e cole em uma mensagem de chat comum. O ideal é instalar uma chave pública SSH, comprovar que o login com chave funciona em uma segunda sessão, criar um administrador sem privilégios e somente então desabilitar a autenticação por senha.
Copie este prompt do Codex
Prepare secure SSH access to my new VPS.
Requirements:
- Generate a dedicated Ed25519 SSH key locally with a descriptive filename.
- Show me only the public-key fingerprint and where the private key is stored; never print the private key.
- If the provider requires an initial password, give me a secure local method to enter or store it temporarily without revealing it in chat or command history.
- Install the public key, create an unprivileged sudo administrator, and verify key login in a separate connection before changing SSH settings.
- Disable root login and password authentication only after the key test succeeds.
- Verify the effective configuration with sshd -T and perform a real negative password-login test.
- Keep one working session open until the second key-authenticated session succeeds.
Stop immediately if key login fails or if disabling passwords could lock me out.
Por que um teste eficaz é importante?
Em nosso servidor, um arquivo cloud-init anterior sobrescreveu o comportamento SSH pretendido. O Codex detectou isso com sshd -TAdicionamos um teste de regressão, corrigimos a ordem de carregamento e comprovamos que o login somente com senha falhava, enquanto o login com chave funcionava. Evidências são mais importantes do que a conclusão bem-sucedida de um comando.
Etapa 4: Pesquise e identifique o software XBT atual.
As implementações do DATUM estão em constante evolução. Antes de baixar qualquer coisa, faça com que o Codex verifique os repositórios autorizados, as versões, os endpoints do pool, as chaves públicas e os requisitos específicos da cadeia.
Copie este prompt do Codex
Research the current official software and connection data for this XBT/BTCB2 DATUM deployment.
Use primary sources only where possible. Verify:
- The current official Bitcoin Knots release suitable for the XBT chain and its published SHA256 checksums.
- The official AwokenLazarus XBT/Bitcoin repository and chain parameters.
- The official CONVOY DATUM Gateway repository and a specific commit to pin.
- Current Lazarus DATUM endpoint, port, public key, payout or username rules, and fee information.
- Current AlphaPool and XorPool DATUM endpoints and public keys for standby profiles.
- Whether any old direct-Stratum endpoint has been retired or replaced.
Create a source table with URL, value found, access date, and confidence. Flag disagreements instead of guessing. Do not install anything yet.
Nossa construção fixou os nós do Bitcoin. 29.4.2.knots20260508 e um commit específico do CONVOY. Verifique versões mais recentes em vez de copiar estas versões. A rota SV1 descontinuada do AlphaPool não deve ser confundida com sua implementação DATUM.
Etapa 5: Criar um pacote de implantação testado
Não use o servidor de produção como rascunho. Peça ao Codex para preparar primeiro os modelos de configuração, validação, testes e documentação localmente.
Copie este prompt do Codex
Build a reusable local deployment package before changing the VPS.
It must include:
- A validated manifest for ports, pruning, memory, service users, and file paths.
- Separate Lazarus, AlphaPool, and XorPool profiles.
- Secure rendering of RPC credentials and my public payout address without committing live values to Git.
- systemd services for the node and gateway.
- A default-deny firewall policy.
- An atomic manual pool-switch command that validates the new profile and automatically rolls back if restart or health checks fail.
- A redaction tool that removes IPs, payout addresses, credentials, and account identifiers from evidence.
- Automated tests for configuration validation, secret handling, service files, firewall exposure, SSH hardening, switching, and rollback.
Use example values in tracked files. Put live configuration and secrets in ignored local files with restrictive permissions. Show the test results before touching the server.
Mantenha apenas os exemplos no controle de versão. Senhas RPC, o endereço de pagamento em produção, o endereço VPS e as informações da conta do provedor não devem entrar no Git.
Etapa 6: Instale e verifique o Bitcoin Knots e o CONVOY.
Após a aprovação nos testes locais, implante os artefatos fixados no VPS. Os binários baixados exigem verificação de checksum; as compilações a partir do código-fonte exigem um commit registrado e o hash binário resultante.
Copie este prompt do Codex
Deploy the tested package to the VPS using the verified SSH key.
Installation requirements:
- Update Ubuntu packages and install only required build/runtime dependencies.
- Download Bitcoin Knots from the verified official source and compare the archive SHA256 with the published checksum before extracting it.
- Build the official CONVOY DATUM Gateway from the pinned commit.
- Record installed versions, source commit, archive hash, and final binary hashes in a sanitized deployment record.
- Run both services as a dedicated unprivileged user, not root.
- Configure approximately 4 GB pruning, a reasonable database cache for the VPS memory, and a small swap safety margin.
- Do not start the gateway yet.
After installation, show version output, ownership, permissions, systemd validation, and listening ports. Stop on any checksum mismatch, build warning that affects compatibility, or unexpected public listener.
Nossa configuração utiliza um alvo de poda de 4 GB e um cache de banco de dados de 2 GB; ajuste e documente esses valores para o seu servidor.
Etapa 7: Configurar regras privadas de RPC, API e firewall
A porta Stratum voltada para o minerador deve ser acessível, mas os serviços de gerenciamento não devem ser públicos. Nosso projeto permite a porta TCP 22 pública para SSH e a porta TCP 42334 para mineradores. O RPC do nó na porta 8332 e a API do gateway na porta 7152 se vinculam somente a 127.0.0.1.
Copie este prompt do Codex
Apply and verify the network-security design.
Requirements:
- Default-deny unsolicited inbound traffic.
- Allow SSH TCP 22 with sensible rate limiting.
- Allow the miner-facing DATUM/Stratum TCP port 42334.
- Bind Bitcoin RPC 8332 and the gateway management API 7152 to 127.0.0.1 only.
- Do not publicly expose RPC, the gateway API, database ports, or unnecessary Bitcoin peer ports.
- Keep outbound traffic available for node peers, software updates, DNS, and DATUM pool connections.
- Enable automatic security updates and log rotation.
Verify with local socket inspection and an external reachability test. Show a concise table of intended versus actual listeners. Do not reveal credentials in logs or the report.
A porta pública 42334 permite que mineradores com conexão dinâmica acessem o VPS. Posteriormente, o WireGuard pode reduzir a exposição caso a mineradora possua um roteador ou gateway sempre ativo.
Etapa 8: Deixe o nó concluir a sincronização nativa.
Inicie apenas o nó. Um download nativo do bloco inicial valida a cadeia desde a gênese e evita confiar em um snapshot de terceiros. A poda limita os dados de bloco retidos, mas não elimina o tempo de validação.
Copie este prompt do Codex
Start the XBT Bitcoin Knots service and monitor initial block download safely.
Do not start or restart the DATUM Gateway while initialblockdownload is true. At reasonable intervals, record only:
- local block height and header height
- verification progress
- initialblockdownload status
- peer count
- pruning status and prune height
- service health and disk usage
Compare the local header or block tip with an independent current Lazarus XBT explorer. If synchronization is progressing normally, remain quiet. Notify me only for completion, a stalled or failing service, abnormal disk pressure, or required user action. Never use an unverified blockchain snapshot.
A sincronização pode levar horas ou mais. Uma porta de mineração aberta não comprova que o nó possa gerar trabalho válido; mantenha o gateway parado.
Etapa 9: Verificar a identidade da cadeia e getblocktemplate
Este é o ponto de verificação crítico específico da cadeia. Um nó Bitcoin genérico que funciona sem erros ainda pode estar incorreto para a rede XBT BLAKE2b/header-v2.
Copie este prompt do Codex
Now that initialblockdownload is false, perform the pre-gateway verification.
Verify:
- local height agrees with the current independent Lazarus explorer
- the node has multiple healthy peers
- pruning is active and consistent with the configured target
- chain identity and network parameters match XBT/BTCB2
- getblocktemplate succeeds with the required BLAKE2b/header-v2 rules
- node RPC remains loopback-only
- the node service is stable after a clean restart
Save sanitized evidence with timestamps. If any check fails, keep the gateway stopped and diagnose the cause. Do not weaken validation to make the test pass.
Resultado atual: O download inicial do bloco ainda está em andamento. A comparação final de altura, contagem de pares, identidade da cadeia e BLAKE2b/header-v2. getblocktemplate O resultado será adicionado após a sincronização.
Passo 10: Inicie o Lazarus como o pool primário.
Somente após o nó passar pelo ponto de verificação anterior, o Codex deve ativar o perfil Lazarus e iniciar o CONVOY.
Copie este prompt do Codex
Activate the verified Lazarus DATUM profile and start the gateway.
Before starting, re-check the current official Lazarus endpoint and pinned public key. Then verify:
- the systemd service starts under the unprivileged service account
- the gateway authenticates or handshakes with Lazarus as expected
- it can obtain a current template from the local node
- the miner-facing port 42334 listens publicly
- RPC 8332 and API 7152 remain loopback-only
- logs contain no RPC password, payout address, private key material, or other secrets
If the handshake fails, stop the service and diagnose the endpoint, public key, DNS, clock, and configuration. Do not disable identity checks merely to connect.
A URL do minerador normalmente terá a seguinte aparência:
stratum+tcp://YOUR_VPS_IP:42334
Substitua o marcador apenas na interface privada do minerador. Remova-o das capturas de tela.
Passo 11: Conecte primeiro um minerador XBT
Teste primeiro um ASIC e mantenha suas entradas de backup comprovadamente boas.
Copie este prompt do Codex
Guide me through connecting one XBT-compatible BLAKE2b miner to the new gateway. Ask me for its brand, model, and firmware version; do not assume every miner uses the same settings menu.
First verify the pool URL and worker-name format against this miner's documentation, the gateway, and Lazarus requirements. Give me the exact fields to enter, using placeholders for my private VPS address and worker name. I will log in to the miner and save the settings myself.
After connection, help me compare:
1. miner status: connected, hashrate, accepted shares, rejected shares
2. local gateway logs or statistics: worker connection and accepted shares
3. Lazarus pool dashboard or payout-address view: credited work
Observe one miner for at least one hour before recommending batch migration. Never request the miner admin password in chat, and tell me how to redact screenshots.
Um indicador verde não é suficiente. Confirme as participações aceitas no ASIC, gateway e pool. Investigue rejeições por latência, trabalho obsoleto, formatação do worker, firmware ou incompatibilidade de cadeia.
Resultado atual: Nenhum minerador foi migrado para este gateway ainda. Confirme o URL e o formato do worker no gateway ativo, no pool de mineração XBT DATUM selecionado e no firmware do dispositivo antes de alterar o minerador. Adicionaremos observações de share e pool-credit de uma hora após o primeiro teste.
Para um processo de validação de hardware mais abrangente, consulte o Guia de Teste do Minerador SC do Fork BLAKE2b do Bitcoin.
Etapa 12: Migre os mineradores restantes em pequenos lotes.
Após o primeiro minerador estar estável, mova os outros em pequenos grupos para que um problema não tire a fazenda de servidores do ar.
Copie este prompt do Codex
Create a controlled migration checklist for the remaining XBT-compatible miners. Record each device's brand, model, and firmware so model-specific differences are visible.
Use small batches. For each miner, record a non-sensitive device label, firmware version, start time, connection state, observed hashrate, accepted shares, rejected shares, and backup-pool status. Do not record admin passwords.
After every batch, compare total gateway hashrate and worker count with the sum expected from the miners. Pause the migration if rejection rate rises, workers flap, the gateway becomes resource constrained, or pool-side accounting does not match. Keep a rollback path to the previous known-good miner pool settings.
Dez mineradores não exigem dez nós. O VPS valida, constrói modelos e distribui o trabalho; monitore seus recursos e latência à medida que unidades são adicionadas.
Etapa 13: Teste AlphaPool e XorPool com reversão automática
As configurações de espera só são úteis após um teste real de comutação e reversão.
Copie este prompt do Codex
Test the AlphaPool and XorPool DATUM standby profiles one at a time using the atomic switch tool.
For each profile:
- re-verify the current official endpoint, public key, and pool requirements
- validate the local profile before activation
- record the current known-good profile
- atomically switch, restart the gateway, and check service health, DATUM handshake, template flow, and miner-facing port
- if any check fails, automatically restore and restart the previous profile
- save sanitized evidence of the result
Also run a deliberate rollback test with a harmless invalid test profile. When all testing is complete, return the active profile to Lazarus and verify it again. Do not move production miners during a failed or ambiguous test.
A troca manual é intencional: taxas, latência, regras de pagamento e confiabilidade são fatores importantes.
Resultado atual: Os testes de handshake e rollback do pool ativo estão pendentes. Os perfis de espera foram preparados, mas um perfil preparado não comprova a conectividade.
Etapa 14: Execute a Revisão Final de Segurança e Regressão
A última etapa cria uma transição sustentável.
Copie este prompt do Codex
Perform the final deployment review and produce a sanitized handoff.
Verify again:
- SSH key login works; root login and password authentication are effectively disabled
- the firewall is default-deny and exposes only intended ports
- RPC and management API are loopback-only
- services run unprivileged and restart correctly after reboot
- secrets and live configuration have restrictive permissions and are ignored by Git
- package updates, log rotation, disk usage, pruning, swap, time sync, and backups are healthy
- Lazarus is the active profile after standby testing
- the full automated regression suite passes
- the deployment record contains versions, hashes, dates, decisions, test evidence, and rollback instructions but no secrets
Then give me a concise weekly/monthly maintenance checklist. Show me the final blog preview, but do not publish it until I explicitly approve publication.
Lista de verificação de segurança XBT DATUM
Antes de considerar a implantação concluída, confirme todos os itens abaixo:
- A frase mnemônica da carteira e a chave privada nunca foram compartilhadas.
- Foi utilizado apenas um endereço público para pagamento.
- O pagamento do VPS, a senha, o CAPTCHA e a autenticação de dois fatores permaneceram sob controle humano.
- A chave SSH dedicada funciona e sua metade privada permanece local.
- As configurações SSH efetivas foram verificadas, não presumidas.
- RPC e API de gerenciamento vinculam-se a
127.0.0.1 - O firewall expõe apenas as portas necessárias para o minerador e a administração.
- Os checksums de download e os commits de origem são registrados.
- O nó e o gateway são executados como usuários sem privilégios.
- Sincronização nativa concluída antes da inicialização do gateway
- A altitude local corresponde à de um explorador independente.
- BLAKE2b/cabeçalho-v2
getblocktemplateconsegue - Um minerador passou por um teste monitorado antes da migração em lote.
- Cada perfil de espera e caminho de reversão foi testado.
- Documentos públicos foram expurgados de IPs, endereços, credenciais e IDs de contas.
Perguntas frequentes
Preciso de um endereço IP público fixo no site de mineração?
Não. Os mineradores de XBT iniciam conexões de saída para o VPS. O VPS precisa de um endereço IP estável e acessível; o IP público do site de mineração pode mudar.
O DATUM aumenta o número de nós de validação?
Isso pode incentivar mais mineradores a executarem sua própria infraestrutura de validação e construção de modelos, mas esse não é seu único propósito. A principal mudança é aproximar a construção de modelos de bloco e a seleção de transações dos mineradores, mantendo a contabilização de ações agrupadas.
Considerações finais da análise do Fortune Dragon
Um nó DATUM pessoal permite que os mineradores construam trabalho a partir de uma cadeia validada, mantendo as recompensas agrupadas. Um VPS com IP fixo também atende a mineradores sem um endereço estático.
Não ter experiência com Linux não significa necessariamente confiar cegamente. O Codex transforma a implementação de um pool de mineração de XBT DATUM em etapas revisáveis, evidências, testes e documentação.
Comece com um único minerador. Mantenha os segredos fora do chat e do Git. Exija comprovação em cada etapa de segurança. Teste o rollback antes de precisar dele. Só então mova o restante da fazenda de mineradores.
Se você está planejando uma implementação de mineração XBT ou precisa de ajuda para selecionar hardware BLAKE2b compatível, entre em contato com a BT-Miners para obter informações sobre a disponibilidade atual de hardware e orientações de implementação.
