Bitcoin Core :: Bitcoin Core 0.16.0 lançado

Temos o prazer de anunciar o lançamento do Bitcoin Core 0.16.0, a primeira versão do Bitcoin Core a incluir suporte de carteira padrão para testemunha segregada (segwit). A versão também contém várias outras melhorias e correções de bugs, conforme descrito abaixo.

A versão mais recente está disponível para download na página de download

As seções a seguir descrevem as alterações mais significativas nesta versão. Para obter detalhes completos, consulte as Notas de versão.

Carteira Segwit

Bitcoin Core 0.16.0 introduz suporte completo para segwit na carteira e nas interfaces de usuário. Um novo -addresstype argumento foi adicionado, o que apoia legacy, p2sh-segwit (padrão) e bech32 endereços. Ele controla que tipo de endereços são produzidos por getnewaddress, getaccountaddresse createmultisigaddress. UM -changetype argumento também foi adicionado, com as mesmas opções e por padrão igual a -addresstypepara controlar que tipo de alteração é usada.

Um novo address_type parâmetro foi adicionado ao getnewaddress e addmultisigaddress RPCs para especificar qual tipo de endereço gerar. UM change_type argumento foi adicionado ao fundrawtransaction RPC para substituir o -changetype argumento para transações específicas.

Todos os endereços segwit criados através getnewaddress ou *multisig Os RPCs obtêm explicitamente seus resgates adicionados ao arquivo da carteira. Isso significa que o downgrade após a criação de um endereço segwit funcionará, desde que o arquivo da carteira esteja atualizado.
Todas as chaves segwit na carteira recebem um resgate implícito adicionado, sem que ele seja gravado no arquivo. Isso significa que a recuperação de um backup antigo funcionará, desde que você use um novo software.
Todas as chaves do pool de chaves usadas em transações têm explicitamente seus resgates adicionados aos arquivos da carteira. Isso significa que o downgrade após a recuperação de um backup que inclui um endereço segwit funcionará

Observe que alguns RPCs ainda não suportam endereços segwit. Notavelmente, signmessage/verifymessage não suporta endereços segwit, nem importmulti Neste momento. O suporte para segwit nesses RPCs continuará a ser adicionado em versões futuras.

As saídas de alteração P2WPKH agora são usadas por padrão se qualquer destino na transação for uma saída P2WPKH ou P2WSH. Isso é feito para garantir que a saída alterada seja tão indistinguível quanto possível das outras saídas em ambos os casos.

Suporte a endereços BIP173 (Bech32) (endereços “bc1…”)

Suporte completo para endereços segwit nativos (BIP173/Bech32) foi adicionado. Isso inclui a capacidade de enviar para endereços BIP173 (incluindo os não-v0) e gerar esses endereços (incluindo novos endereços padrão, veja acima).

Uma caixa de seleção foi adicionada à GUI para selecionar se um endereço Bech32 ou um endereço encapsulado em P2SH deve ser gerado ao usar endereços segwit. Quando lançado com -addresstype=bech32 ele é verificado por padrão. Quando lançado com -addresstype=legacy está desmarcado e desativado.

Carteiras HD por padrão

Devido a uma alteração incompatível com versões anteriores no banco de dados da carteira, as carteiras criadas com a versão 0.16.0 serão rejeitadas pelas versões anteriores. Além disso, a versão 0.16.0 criará apenas carteiras determinísticas hierárquicas (HD). Observe que isso se aplica apenas a novas carteiras; carteiras feitas com versões anteriores não serão atualizadas para HD.

Substituir por taxa por padrão na GUI

A tela de envio agora usa BIP125 RBF por padrão, independente de -walletrbf. Existe uma caixa de seleção para marcar a transação como final.

O padrão RPC permanece inalterado: para usar RBF, inicie com -walletrbf=1 ou use o replaceable argumento para transações individuais.

Configuração do diretório de carteiras

O Bitcoin Core agora tem mais flexibilidade na localização do diretório de carteiras. Anteriormente, os arquivos de banco de dados da carteira eram armazenados no nível superior do diretório de dados do Bitcoin. O comportamento agora é:

Para novas instalações (onde o diretório de dados ainda não existe), as carteiras serão agora armazenadas em um novo wallets/ subdiretório dentro do diretório de dados por padrão.
Para nós existentes (onde o diretório de dados já existe), as carteiras serão armazenadas na raiz do diretório de dados por padrão. Se um wallets/ subdiretório já existir na raiz do diretório de dados, então as carteiras serão armazenadas no
wallets/ subdiretório por padrão.
A localização do diretório de carteiras pode ser substituída especificando um
-walletdir= opção onde pode ser um caminho absoluto para um diretório ou link simbólico de diretório.

Deve-se ter cuidado ao escolher o local do diretório da carteira, pois se ele ficar indisponível durante a operação, os fundos poderão ser perdidos.

Suporte para sinalização de nós podados (BIP159)

Os nós removidos agora podem sinalizar NODE_NETWORK_LIMITED do BIP159 usando bits de serviço, em preparação para suporte completo ao BIP159 em versões posteriores. Isso permitiria que os nós removidos atendessem os blocos mais recentes. No entanto, a mudança atual ainda não inclui suporte para conexão com esses pares removidos.

Desempenho: montagem SHA256 habilitada por padrão

As otimizações de hash SHA256 para arquiteturas que suportam SSE4, que levam a aproximadamente 50% de aceleração no SHA256 em hardware suportado (sincronização e validação de bloco ~5% mais rápidas), agora foram habilitadas por padrão. Nas versões anteriores eles eram habilitados usando o --enable-experimental-asm flag durante a construção, mas agora são o padrão e não são mais considerados experimentais.

Mudanças na GUI

Os usos de “µBTC” na GUI agora também mostram o termo mais coloquial “bits”, especificado no BIP176.
A opção de reutilizar um endereço anterior foi removida. Isto foi justificado pela necessidade de “reenviar” uma fatura, mas agora que temos o histórico de pedidos, essa necessidade deverá desaparecer.
Foi adicionado suporte para pesquisa por TXID, em vez de apenas endereço e etiqueta.
Uma opção “Usar saldo disponível” foi adicionada à caixa de diálogo de envio de moedas, para adicionar o saldo restante da carteira disponível a uma saída de transação.
Foi adicionada uma opção para desobstruir os campos de senha na caixa de diálogo de senha.

Novo RPC de rescanblockchain

Um novo RPC rescanblockchain foi adicionado para invocar manualmente uma nova varredura do blockchain. O RPC suporta argumentos de altura inicial e final para a nova verificação e pode ser usado em um ambiente multiwallet para verificar novamente o blockchain em tempo de execução.

Novo RPC savemempool

Um novo savemempool Foi adicionado RPC que permite que o mempool atual seja salvo em disco a qualquer momento para evitar que seja perdido devido a travamentos/perda de energia.

Modo de segurança desativado por padrão

O modo de segurança agora está desabilitado por padrão e deve ser habilitado manualmente (com -disablesafemode=0) se desejar usá-lo. O modo de segurança é um recurso que desativa um subconjunto de chamadas RPC – principalmente relacionadas à carteira e ao envio – automaticamente caso sejam detectadas certas condições de problema na rede. No entanto, os desenvolvedores passaram a considerar essas verificações não confiáveis o suficiente para serem executadas automaticamente. Mesmo com o modo de segurança desativado, eles ainda causarão avisos no warnings campo do getneworkinfo RPC e iniciar o -alertnotify comando.

Script renomeado para criação de credenciais JSON-RPC

O share/rpcuser/rpcuser.py script foi renomeado para share/rpcauth/rpcauth.py. Este script pode ser usado para criar rpcauth credenciais para um usuário JSON-RPC.

Validar melhorias de endereço

O validateaddress A saída RPC foi estendida com alguns novos campos e suporte para endereços segwit (P2SH e Bech32). Especificamente:

Um novo campo iswitness é verdadeiro para endereços P2WPKH e P2WSH (endereços “bc1…”), mas não para endereços segwit encapsulados em P2SH (veja abaixo).
O campo existente isscript agora também reportará True para endereços P2WSH.
Um novo campo embedded está presente para todos os endereços de script onde o script é conhecido e corresponde a algo que pode ser interpretado como um endereço conhecido. Isto é particularmente verdadeiro para endereços P2SH-P2WPKH e P2SH-P2WSH. O valor para embedded inclui muitas das informações validateaddress reportaria se invocado diretamente no endereço incorporado.
Para scripts multisig, um novo pubkeys foi adicionado um campo que informa as chaves públicas completas envolvidas no script (se conhecidas). Este é um substituto para o existente addresses campo (que relata as mesmas informações, mas codificadas como endereços P2PKH), representado de forma mais útil e menos confusa. O addresses O campo permanece presente para endereços não-segwit para compatibilidade com versões anteriores.
Para todos os endereços de chave única com chave conhecida (mesmo quando agrupados em P2SH ou P2WSH), o pubkey campo estará presente. Em particular, isto significa que invocar validateaddress na saída de getnewaddress sempre reportará o pubkeymesmo quando o tipo de endereço for P2SH-P2WPKH.

Mudanças de baixo nível

O RPC obsoleto getinfo foi removido. Recomenda-se que sejam usados RPCs mais específicos:
- getblockchaininfo
- getnetworkinfo
- getwalletinfo
- getmininginfo
O RPC da carteira getreceivedbyaddress retornará um erro se for chamado com um endereço que não esteja na carteira.
O RPC da carteira addwitnessaddress foi descontinuado e será removido na versão 0.17, defina o address_type argumento de getnewaddressou opção -addresstype=(bech32|p2sh-segwit) em vez de.
dumpwallet agora inclui scripts codificados em hexadecimal da carteira no dumpfile e
importwallet agora importa esses scripts, mas os endereços correspondentes podem não ser adicionados corretamente ou uma nova verificação manual pode ser necessária para encontrar transações relevantes.
O RPC getblockchaininfo agora inclui um errors campo.
Um novo blockhash parâmetro foi adicionado ao getrawtransaction RPC que permite que uma transação bruta seja obtida de um bloco específico, se conhecido, mesmo sem -txindex habilitado.
O decoderawtransaction e fundrawtransaction RPCs agora têm opções iswitness parâmetros para substituir as verificações heurísticas de testemunhas, se necessário.
O walletpassphrase o tempo limite agora está limitado a 2 ^ 30 segundos.
Usando endereços com o createmultisig O RPC agora está obsoleto e será removido em uma versão posterior. As chaves públicas devem ser usadas em seu lugar.
As novas varreduras do Blockchain agora não bloqueiam mais a carteira durante todo o processo de nova varredura, então outros RPCs agora podem ser usados ao mesmo tempo (embora os resultados dos saldos/transações possam estar incorretos ou incompletos até que a nova varredura seja concluída).
O logging O RPC agora foi tornado público em vez de oculto.
Um initialblockdownload booleano foi adicionado ao getblockchaininfo RPC para indicar se o nó está atualmente em IBD ou não.
minrelaytxfee agora está incluído na saída de getmempoolinfo

Outras opções de linha de comando alteradas

-debuglogfile= pode ser usado para especificar um arquivo de log de depuração alternativo.
bitcoin-cli agora tem um -stdinrpcpass opção para permitir que a senha RPC seja lida na entrada padrão.
O -usehd opção foi removida.
bitcoin-cli agora suporta um novo -getinfo sinalizador que retorna uma saída como a do agora removido getinfo RPC.

Testando alterações

A porta JSON-RPC padrão do regtest foi alterada para 18443 para evitar conflito com o padrão 18332 do testnet.
O Segwit agora está sempre ativo no modo regtest por padrão. Portanto, se você atualizar um nó regtest, precisará -reindexar ou usar as regras antigas adicionando vbparams=segwit:0:999999999999 para o seu regtest bitcoin.conf. Não fazer isso resultará em uma falha de asserção CheckBlockIndex() que será semelhante a: Asserção `(pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)’ falhou.

Hashes para verificação

f51392e0cbf7940627944602a64890ed65cf44838fc4795d493cf12aafe37012  bitcoin-0.16.0-aarch64-linux-gnu.tar.gz
59f95da96f40b3a9acfeda9085e6389f2075ee40ef1fe7f023031f86c946c3ea  bitcoin-0.16.0-arm-linux-gnueabihf.tar.gz
d7c173e2921e39df3631b7cd652ae7330c2735b0b221f9dc8f7c899887b4fb59  bitcoin-0.16.0-i686-pc-linux-gnu.tar.gz
ade85a8e39de8c36a134721c3da9853a80f29a8625048e0c2a5295ca8b23a88c  bitcoin-0.16.0-osx64.tar.gz
df0036bae9f40536095908c9944ed66c0946f178ae8ef07639caf25a390b2ee7  bitcoin-0.16.0-osx.dmg
8cbec0397d932cab7297a8c23c918392f6eebd410646b4b954787de9f4a3ee40  bitcoin-0.16.0.tar.gz
7558249b04527d7d0bf2663f9cfe76d6c5f83ae90e513241f94fda6151396a29  bitcoin-0.16.0-win32-setup.exe
60d65d6e57f42164e1c04bb5bb65156d87f0433825a1c1f1f5f6aebf5c8df424  bitcoin-0.16.0-win32.zip
6d93ba3b9c3e34f74ccfaeacc79f968755ba0da1e2d75ce654cf276feb2aa16d  bitcoin-0.16.0-win64-setup.exe
42706da1a95b2db8c5808529f73c2063a0dd770f71e0c8506bfa86dc0f3403ef  bitcoin-0.16.0-win64.zip
e6322c69bcc974a29e6a715e0ecb8799d2d21691d683eeb8fef65fc5f6a66477  bitcoin-0.16.0-x86_64-linux-gnu.tar.gz