Blockchain & network enumeration

[dr-orlovsky]

In many applications we face the need to specify a network and/or a chains (one of testnet, mainnet, sidechains etc) for which some piece of information applies. This is related to invoices, consignments, addresses, node connections, and so on.

Some time ago a dedicated library for addressing the issue was created: lnpbp_chain. However, it used a sub-optimal approach not taking many factors into a consideration, and its serialization format was too verbose to be used in invoices.

This is a proposal for a new, short, easy-to-read and to use in different forms of text and binary representation identification for both chain and network information.

Considerations which should be kept in mind:

• chain != network; there might be multiple networks operating the same chain (for instance with a new bitcoin P2P protocol);
• chain != genesis hash, since hard forks like bcash has the same genesis id;
• network is identified by a magic 32-bit number, but some of the hard forked chains use the same number opening space for a reply attacks;
• there might be permissionary chains not opened for public (like different regtests or signets).

To address all this issue we at LNP/BP Standards Association may provide a registry of chains and corresponding networks, where items are identified by an either short string (for text encodings) or a u32 number (for binary encodings), which can be resolved via simple library (a new version of lnpbp_chain) to all necessary information.

Chain identifier (lowercase)	Definition	Is testnet?	Network magic byte1	Bech32(m) HRP	Base58 prefix	Genesis hash
"bitcoin", 0x00000000	no	Bitcoin mainnet	0xD9B4BEF9	bc	1, 3	``
"testnet3", 0x80000002	yes	Bitcoin testnet v3	0x0709110B	tb	m, n	``
"signet", 0x80000003	yes	Bitcoin globnal signet	0x40CF030A	tb	m, n	``
"regtest<ID>"2	yes	Bitcoin permissioned regtest	0xDAB5BFFA	bcrt	m, n	``
"signet<ID>"2	yes	Bitcoin permissioned signet	0x40CF030A	tb	m, n	``
"liquidv1", 0x70000000	no	Liquid mainnet of v1	?	?	?	``
"liquidt1", 0xC0000000	yes	Liquid testnet of v1	?	?	?	``

If some composed data contain items each of which provide some form of chain/network information, including this standard, boolean (indicating testnet), or one of other identifiers (address HRP in Bech32(m), address first byte in Base58 address format etc) a parser must fail on each and every inconsistency between those identifiers according to the registry defined in this standard.

When a chain identifier is absent, a software must use identifier given as a part of the related data. If none of the data contains any chain identifier, a bitcoin mainnet must be assumed.

Footnotes

1. Magic number is sent over network in little-endian encoding, meaning that 32-bit magic 0xD9B4BEF9 is represented by a byte sequence of [0xF9, 0xBE, 0xB4, 0xD9]. ↩

2. Regtest and permissioned signet setup uses:

   • for binary representation it takes 32 least significant bits of a genesis hash, puts them into a least-significant-encoded u32 integer, masks with 0x7FFFFFFF and xors with testnet flag 0x80000000.
   • for text representation, it concatenates a hexadecimal representation of the binary id to a "regtest" (or "signet") string, for example getting "regtest8cafe79a".
   ↩ ↩²

[dr-orlovsky]

@crisdut can you confirm that different regtests has different block ids

[crisdut]

I don't know if there's a need for this kind of feature for regtest networks, as it's always short-term and is continually being recreated.

I always keep the block id the same, for example.

[fedsten]

The proposal looks good to me, ACK