Address generation wrong in dash testnet

[plessmann]

I'm using the bip32.php example from latest version but switched the network after the autoloading line by adding Bitcoin::setNetwork(\BitWasp\Bitcoin\Network\NetworkFactory::dashTestnet()); to change to the dash testnet.

At first it looks fine, because the example delivers dash testnet addresses with prefix "y" instead of "X" (for main net) as expected but on the other side, all the addresses are invalid! You cannot use them in dash core latest version. It is impossible to transfer any faucets to it.

And in addition to that (not shown on the screenshot but I noticed that during some experimentation with it): if you use the deriveChild function within a loop or you restart bip32 example several times (about 30x) in a short period, you will create in some situations addresses which starts by "x" (lowercased of the mainnet prefix!) instead of "y"! Really really strange for me because this is not right. I'm absolute not sure if the lib does all the encryption stuff right for dash testnet? Can you confirm the bug or is the way I did my test wrong? Normally dash should be in most ways compatible with bitcoin protocol because dash does lots of work with backports.

Please see my attached screenshot.

[afk11]

Hey @plessmann

This can happen when a cryptocurrency changes it's address prefixes. When this happens, it's usually a disaster for applications because all their stack needs to be compatible.

Look up the Dash PHP code and copy it directly into your project, then look up the version of dash you are using, and see chainparams.cpp. It will have the version bytes defined there.

This issue pops up like once a year, and I can't change defaults without screwing over peoples applications. So I've stopped merging new cryptocurrency definitions to the project, and expect people to research their own cryptocurrencies and find out the bytes to use. Eventually all altcoin networks will be deleted from this project so developers will be forced to provide their own Network implementation, but as you note, most cryptos are compatible anyway besides minor differences in configuration.

So this is a won't fix.

if you use the deriveChild function within a loop or you restart bip32 example several times (about 30x) in a short period, you will create in some situations addresses which starts by "x" (lowercased of the mainnet prefix!) instead of "y"! Really really strange for me because this is not right.

regarding this, it's actually sort of expected - it's how the base58 encoding works. On bitcoin testnet P2PKH addresses start with either m or n, so I'm not surprised it happens elsewhere too.

[afk11]

btw, you can compare addresses if you decode the base58 to bytes - you can see if the prefix is wrong or something else, and compare known valid addresses with it.