Bitcoinjs-lib: Add network definition for blockcypher test net

[adsc-cloudtec]

Since the official testnet3 is very unreliable, other solutions have to be found for automated testing. Blockcypher manages a separate test network with identical properties of the bitcoin main network. One exception is that they use a different prefix for addresses.

I tried to use their test network with addresses generated with bitcoinjs-lib, but neither the main nor the testnet network definitions from bitcoinjs-lib produce valid addresses for their test network. It would be great if there was a network definition for the blockcypher test network in bitcoinjs-lib.

Here is the information about that network, quoted from https://www.blockcypher.com/dev/bitcoin/#testing:

We offer two different options for testing your blockchain application: Bitcoin Testnet3, and BlockCypher’s Test Chain. We offer automated faucets for both Testnet3 and BlockCypher’s Test Chain, but we recommend using BlockCypher’s Test Chain for a variety of reasons:

It’s nearly identical in characteristics to Bitcoin Main, with a few differences listed below.

• The prefix for standard addreses is ‘B’ or 'C’ (0x1B). The prefix for multisig addresses is ’D’ (0x1F). This is also known as the “address version byte,” which you can read more about here.
• The chain is private (no data is broadcasted, only BlockCypher mines the transactions), making it much more predictable than the Bitcoin’s testnet (which is frequently under attack).
• New blocks get built every minute, confirming the transactions that have been created using our transaction API.

It would be great if someone could add such a network definition, or tell me which values have to be changed (with respect to the quoted information above) in the following code snippet, so I can make a PR myself:

{
  messagePrefix: '\x18Bitcoin Signed Message:\n',
  bech32: 'bc',
  bip32: {
    public: 0x0488b21e,
    private: 0x0488ade4
  },
  pubKeyHash: 0x00,
  scriptHash: 0x05,
  wif: 0x80
}

[dabura667]

TIL.

Doesn't seem too bad, but I'm at a loss as what to name it...

@dcousens @afk11 unless you have some reservations about adding it.

[dcousens]

networks.blockcypher?

[dcousens]

confirming the transactions that have been created using our transaction API.

On second thought, this is a little bit lame... means we could only interact with it really, via their API... meaning, it isn't really suitable for the open source library here.

[dabura667]

well bitcoinjs-lib doesn't really offer a broadcasting endpoint.... does it?

[dcousens]

@dabura667 no, it doesn't. It relies on 3rd party nodes/APIs.

[dabura667]

assuming blockcypher is just basically testnet spec + new address versions + sending to an API instead of a node... I don't see much of a problem.

Testnet3 is unreliable a lot when testing...

If the only part that's closed on their network is the broadcasting and we don't touch that anyways, allowing a quick method to generate addresses sounds fine...

though tbh, if it's just addresses, swapping the version bytes shouldn't be too hard unless you were a complete noob to javascript... or life...

I'm gonna give this a "don't care either way" but I would say there is no clear reason NOT to do it as well as no clear reason TO do it... :-/

[dabura667]

adding it kinda seems like a plug for an external service... so I am starting to lean towards no, actually now that I think of it.

[dcousens]

adding it kinda seems like a plug for an external service... so I am starting to lean towards no, actually now that I think of it.

To me, the scope seems that it should be an external module that accompanies some npm library for their API, or some such.

[adsc-cloudtec]

Personally, I would name it networks.bcytest.

though tbh, if it's just addresses, swapping the version bytes shouldn't be too hard unless you were a complete noob to javascript... or life...

I wanted to avoid a manual hack, so that I can use the same code for testing and prod (just using a different network definition). My problem is that I don't exactly understand yet how the fields in bitcoinjs-lib's network definitions work, otherwise I'd already have made a PR for it. I hoped it would be a simple thing for an informed person, but if it isn't, I can dig into the code and see if I can produce it myself.

[dcousens]

The prefix for standard addreses is ‘B’ or 'C’ (0x1B). The prefix for multisig addresses is ’D’ (0x1F). This is also known as the “address version byte,” which you can read more about here.

{
  messagePrefix: '\x18Bitcoin Signed Message:\n',
  bech32: 'bc',
  bip32: {
    public: 0x0488b21e,
    private: 0x0488ade4
  },
  pubKeyHash: 0x1b, // updated
  scriptHash: 0x1f, // updated
  wif: 0x80
}

But, I don't think I'm inclined to merge this if it was presented in a PR tbh.
If it was a public testnet, an alternative to testnet3, with easy parameters for anyone to jump on and use, then yes, but, their API only? It feels like a plug.

[adsc-cloudtec]

Alright, thanks. I understand your point of view. Although I am not sure how such an alternative to testnet3 would work. It seems to me it would suffer from the same problems as the original one.

BTW: The network definition you provided works great! Thanks again.

[sonaye]

Thanks for the definition!

[sonaye]

Quick update: the version is actually 0x49 not 0x80.

const networks = {
  btc: {
    main: bitcoin.networks.bitcoin,
    test3: bitcoin.networks.testnet
  },
  ltc: {
    main: bitcoin.networks.litecoin
  },
  bcy: {
    test: {
      messagePrefix: '\x18Bitcoin Signed Message:\n',
      bech32: 'bc',
      bip32: {
        public: 0x0488b21e,
        private: 0x0488ade4
      },
      pubKeyHash: 0x1b,
      scriptHash: 0x1f,
      wif: 0x49
    }
  }
};

[afk11]

There's nothing stopping you from publishing another package with that network in it? IIRC only the fromWIF method uses the whole list of networks, and you can override that.. If at least that isn't possible, I'm sure a PR enabling it would be accepted.