Add PoS coins (e.g. Peercoin) support

[visvirial]

About

bitcoinjs-lib supports alt-coins (e.g. Litecoin, Monacoin and Dogecoin) by passing coin network configurations through its API.
However, for Proof of Stake (a.k.a. "PoS") coins such as Peercoin, Blackcoin and Peercoin-derived cryptocurrencies have slightly different binary format (see below) of transactions and blocks (it is represented as CTransaction or CBlock respectively, in the original source code), which bitcoinjs-lib cannot understand.

The difference of binary formats of blocks and transactions between Bitcoin and Peercoin-like cryptocurrencies are:

• Creation time in transaction: unsigned int nTime field in class CTransaction (Peercoin: src/main.h L431)
• Block signature: std::vector<unsigned char> vchBlockSig field in class CBlock (Peercoin: src/main.h L893)

In this pull request, I have added some codes regarding PoS coins support.

Summary of Changes:

• Added "network.isPoS" in network option
• Added Peercoin network configuration (in "networks.peercoiin")
• Can understand nTime field in CTransaction
• Can understand vchBlockSig field in CBlock
• Added test cases for PoS-type blocks, transactions
• Customized test code in order to support PoS-type coin tests
• Added "network" field in test/fixtures/(block|transaction).js

[dcousens]

This is great code @visvirial, I'm just not sure if it is in scope.
Thoughts @weilu / anyone?

We've been doing our best to remove the network specific aspects of bitcoinjs-lib over the last few months. (See #325, #383 and #402 for a start).

I wonder if this can be managed in such a way that we can maintain modularity?

[weilu]

Interesting. I do agree that this is a bit out of scope, but I don't see how we can provide a clean entry point for such extension of the library, due to the procedural nature of deserialization/serialization. To implement support for PoS networks without modifying this library itself, one'd have to extend classes like Transaction and Block. Let's leave this open and see if anyone has better ideas.

[ghost]

When in doubt, fork and make a new project... Then just link to it in the readme. We don't have to accommodate every cryptocoin out there, but we can still point people in the right direction.

[visvirial]

If the goal of this project is just providing a simple and short library for cryptocurrency,
and customizations like this pull request should be done externally, I suggest the following.

Add a new network option network.binaryFormat.transaction and network.binaryFormat.block that tells how bitcoinjs-lib should read the binary data.
The structure of this new option will be:

networks.bitcoin.binaryFormat.transaction = [
    // nVersion
    {
        name: 'version',
        type: 'int32',
    },
    /*
    // nTime for PoS coins
    {
        name: 'time',
        type: 'uint32',
    },
    */
    // vin
    {
        name: 'vin',
        type: 'CTxIn[]',
    },
    // vout
    {
        name: 'vout',
        type: 'CTxOut[]',
    },
    // nLockTime
    {
        name: 'locktime',
        type: 'uint32',
    },
]

And then, in Transaction.fromBuffer():

Transaction.prototype.fromBuffer = function(...) {

    (snip)

    var read = function (type) {
        switch(type) {
            case 'int32':
            case 'uint32':
                return readUint32();
                break;
            case 'CTxIn[]':
                var len = readVarInt();
                tx.ins = [];
                for(var i=0; i<len; i++) {
                    tx.ins.push(readTxIn());
                }
                break;
            (... and so on)
        }
    }

    network.binaryFormat.transaction.forEach(field) {
        tx[field] = read(field.type);
    }

    (snip)

}

I think this style of modification is much simpler, easier to maintain and more flexible
than to fork bitcoinjs-lib to create a new project or re-defining Transaction.fromBuffer externally.

How do you feel my suggestion?

[urbien]

another case where support for a different transaction structure is needed: Sidechain Elements. I suspect Sidechains will go mainstream quickly.

@mvayngrib, @pgmemk and I started working on a project where we need to support Asset transactions on Sidechains.
It would be awesome to use bitcoinlib-js for that, or at least have a good way of patching it for this use case.

[dcousens]

@urbien what features would be needed to support Elements Alpha for example?

[dcousens]

How do you feel my suggestion?

@visvirial I think that is an OK suggestion. Maybe not 2.0.0, but, 2.x.y possibly.
I'm not 100% on the syntax though.

Also, how do you enforce support with TransactionBuilder?

[dcousens]

Targeting 3.0.0, for which we'll re-consider how we are currently doing serialization/deserialization.
Simplicity is key, and I don't want to discount how important it is that we don't become too generic.

[dcousens]

@visvirial do you use IRC?

[visvirial]

@dcousens What is the channel and server?

[dcousens]

freenode, #bitcoinjs-dev

[mvayngrib]

@dcousens re: elements alpha, it would likely have to be a fork, rather than augmenting this repo. Transaction and TransactionBuilder would need to change pretty seriously to support confidential transactions, and the elements built on top of it like asset issuance/transfer. Have you played with elements yet?

[dcousens]

I think I'm going to lean towards closing this. Peercoin is still around, but, to keep up with development we'd have to massively re-write the library and highly generalize it where generalization isn't really necessary.

@visvirial if you're still interested in this, please re-open, I'm just not sure what the best approach is.

[dcousens]

It would be awesome to use bitcoinlib-js for that, or at least have a good way of patching it for this use case.

@urbien if this is still a case, please keep don't hesitate to submit patches that may make patching simpler, provided the changes are in scope for bitcoinjs-lib too.

[dcousens]

@visvirial that said, I think #428 (comment) is spot on and might still be worth while doing.

[visvirial]

Hi @dcousens .

I hope bitocinjs-lib to be more generic, so I think implementing #513 should be done first
and your decision seems reasonable.
If there are something I can help, please mention me as above !

[priestc]

Someone should take these changes and port them over to bitcore, then make a pull request to the altcore project: https://github.com/priestc/altcore-lib

Altcore wants to support all crypto currencies, especially ones like PPC that have many forked currencies descended from it.