Unable to generate testnet addresses

[davout]

I used to be able to retrieve testnet adresses...

master_node = "tpubD6NzVbkrYhZ4XhirPF9aBVXJ5jRXqEnvbNYjvT3A2TEJMS1WH98PJCQR7BKeDFm3qdYemwT4xroThSMj3G7s5RcGv1Eona6L2jajST7SRBx"
node_path = "m/0/1"
MoneyTree::Node.from_serialized_address(master_node).node_for_path(node_path).to_address
=> "mvrvQHJuUhXmbBuTJ9oXp34VsCjTQt2W3F"

This doesn't work anymore either with this syntax, or with the new "from_bip32" syntax, which are just synonyms anyway. Main net addresses are returned.

master_node = "tpubD6NzVbkrYhZ4XhirPF9aBVXJ5jRXqEnvbNYjvT3A2TEJMS1WH98PJCQR7BKeDFm3qdYemwT4xroThSMj3G7s5RcGv1Eona6L2jajST7SRBx"
node_path = "m/0/1"
MoneyTree::Node.from_serialized_address(master_node).node_for_path(node_path).to_address
=> "1GLy7EDvfg6Wp5Rqaaq9z7rB1D8kXdFWgo"

[mhanne]

According to #8, the Node doesn't carry its network information around with it anymore. This way you can use the same key tree for multiple networks, and you decide which network you want when you ask it to encode the address.

node = MoneyTree::Node.from_bip32(master_node).node_for_path(node_path)
node.to_address(true, network: :bitcoin_testnet)

I think it's unfortunate that the network information encoded in the bip32 is just lost. Maybe it could be preserved and used as the default network for #to_address?

[thedoctor]

@mhanne is correct – moneytree aims to be a currency-agnostic library.
Magic prefixes like xpub and tpub

• don't scale well if there are arbitrarily many networks
• can be misleading if you want to use one wallet for multiple currencies
• and have no effect on the behavior of the actual HD wallet – only network-specific serialization which is subject to change

We find it better to use the path structure to indicate network per bip44 unless you're running in a constrained environment where the key derivation operation is very expensive (and if that's the case, why use ruby?) and to be explicit when (de)serializing.

[jvergeldedios]

That's also why this was released as a minor version with a breaking change.

[davout]

Ok, I'll guess I'll stick with a sane version of the gem then.

It's still not very clear why such a breaking change was released as a minor version bump, because being backwards-compatible usually means "the same stuff will keep working", and not "you'll still be able to achieve similar functionality by doing things in different way" as it seems implied here.

[thedoctor]

Per semver.org:

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

We use minor versions to indicate breaking changes for all versions < 1.0.0 — sorry for your confusion.