multi-byte version number

[karelbilek]

From what I hear, zcash (upcoming bitcoin clone, with added anonymous zero-knowledge proof transactions) will use address version/prefix with 2 bytes.

Will bitcoin.js "survive" this?

There is some discussion here - zcash/zcash#812 - and it seems they are going forward with the idea.

[dcousens]

It would break, but not by much.

https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/address.js#L30 would be 22 bytes, not 21.

https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/address.js#L31 would need to be writeUInt16LE (or writeUInt16BE, depending on what zcash decide)

and https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/address.js#L8-L10 would need to account for a 22 byte address (2 + 20), rather than 21,

and finally https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/address.js#L12 would need to be readUInt16LE (or readUInt16BE)...

That is all AFAIK.

[dcousens]

Ultimately there is going to be a bit of a shake up in that code soon with SegWit addresses, so, it could be adapted to then.

[karelbilek]

Thanks. I will keep this issue up until zcash actually adds this to code.

I just wanted to let you know up front :) so the code can be adapted (if you want to support zcash once it's done).

[dcousens]

@Runn1ng I really don't know how much effort it is worth keeping compatibility with other cryptocurrencies.
It is only by chance they are all so similar that we can "get away" with it.

I do want to make sure that any forks that occur can easily rebase off our code, so I try to do things generically, but I don't ever want to compromise some of the strict decoding/encoding rules to allow for arbitrary addresses that may not be standard for bitcoin.

[dcousens]

Another effort in this area would probably include #554

[dcousens]

Thanks. I will keep this issue up until zcash actually adds this to code.

@Runn1ng I'm not sure what you intend to wait on in regards to bitcoinjs-lib? Any reason to keep the issue open?

[karelbilek]

I thought you will be interested in supporting other coins; if you won't (as you implicated), I will close this issue.

[dcousens]

I thought you will be interested in supporting other coins

Well, I am. But I don't think we should compromise on good software design for it.
If the library can be generalised without over-engineering, then absolutely.

But, if a fork is a better option to avoid copious technicality and bike-shedding, then that is the better option IMHO.

Thoughts?

[karelbilek]

OK, I am now going to do changes necessary for zcash, since they updated to multibyte already (and we want to add zcash to mytrezor). So I will let you know how that works.

[afk11]

Bitcoin set a number of things as a convention, which numerous altcoins deviated from.. Since zcash isn't a line-for-line copy of Bitcoin Core I expect you'll be adding a lot of new code which wouldn't belong here!

It's definitely worth watching how you adapt this code to something so different, go to town with it!

[karelbilek]

If you are interested, my zcash adaptations are here

master...runn1ng:zcash

It is not a full support (I don't strive for that) and there might be some bugs

What do I need is

• parsing + serialization of tx to work
• I need some basic info about the joinsplit "inputs" (in quotes, since they are not normal inputs)
• I want the same code to still work on bitcoin transactions