:: [Libbitcoin] testnet conditionality
Inizio della pagina
Delete this message
Reply to this message
Autore: Eric Voskuil
Data:  
To: Libbitcoin
Nuovi argomenti: [Libbitcoin] Liblitecoin plans?
Oggetto: [Libbitcoin] testnet conditionality
The recent set of changes in master removes most, but not all, testnet
conditionality.

libbitcoin/client/explorer are no longer differentiated by build. The
--enable-testnet option still exists in libbitcoin, but only affects
libbitcoin-blockchain (block validation has a small remaining code
variation).

libbitcoin-node/server are configured for mainnet ONLY. In other words,
a node/server --enable-testnet build will have testnet blockchain logic,
but will not operate on the testnet network. So until the next wave of
changes, the node/server testnet option is effectively disabled in the
master branch.

libbitcoin-explorer wallet commands no longer require recompile for
testnet, but there are a couple of commands that are partially limited
to mainnet until the next wave. Specifically (1) hd-public and hd-new
always produce mainnet keys when deriving from any private key, and (2)
the tx-encode --ouputs option is limited to mainnet payment/stealth
addresses (with the exception of an explicit script).

libbitcoin-explorer client-server commands (fetch-*, send-tx,
validate-tx, watch-address) can selectively connect to testnet
libbitcoin/obelisk servers based entirely on configuration (server url).
This is not a change.

libbitcoin-explorer P2P commands (send-tx-node, send-tx-p2p) are limited
to mainnet until the next wave. We just need to pull a couple of network
settings from config to resolve this.

The remaining changes are small to get to elimination of the
--enable-testnet option. Once this is complete code built on the server
or client stack (including bx/bn/bs) will vary its network/chain based
on config (or commandline/API parameterization) alone. There is no
longer a compiled genesis block, as checkpoints serve the same prupose
and are configurable. So the same server will be runnable against
different chains and the same client code will be able to dynamically
connect to different networks and process keys/commands from different
chains. Mitigation of protocol differences, or other semantic
differences are out of scope, with one exception. The logic variation in
testnet block validation will switch dynamically based on configuration.

e