ImmutableTransaction/Transaction Split

[braydonf]

Serialization/deserialization of the current Transaction instances will lose information that is needed for many of the methods to work correctly. Separating Transaction into two constructors should help with clarity of supported methods when creating new transactions, and with performance with reading transactions from a block (such as when blockchain syncing).

ImmutableTransaction
This transaction would only have methods that will work from a transaction serialized from a block (without previous output information). All of the properties such as inputs, outputs can be read as objects, and a serialized copy of the transaction will be cached such that calculating the id and hash doesn't need to regenerate the serialized buffer. Instances of transactions within a block will use this constructor, since these transactions are not mutable. Serialization will be a hexa buffer, as per the Bitcoin protocol specification.

Transaction
This constructor would instantiate a mutable instance (the current Bitcore Transaction constructor). However, with the change that serialization is only JSON that includes all previous output information. Methods such as getFee(), getSendingAddresses(), getSendingAddresses(), sign(), to(), from(), change(), and etc. all work as expected. When this type of transaction needs to be broadcast to the network, serialization checks (as is current) can be made and then an instance of ImmutableTransaction can be instantiated for the final serialization.

Related Issues:

• can't broadcast serialized transaction bitcore-explorers#20 (can't broadcast)
• Transaction sign fails #1199 (can't sign)
• Immutable Transaction Optimization #1210 (immutable transaction optimization)
• add Transaction.getSending/ReceivingAddress() #692 (api methods that need previous output information)

[braydonf]

When creating a transaction with unrecognized previous output script, most of the methods will not be usable as abstract methods are invoked: https://github.com/bitpay/bitcore/blob/master/lib/transaction/input/input.js#L162. I'm wondering if we should fail earlier, and then use ImmutableTransaction for all of the other cases.

[eordano]

I'd love to see first a better deserialization of inputs. Right now, deserialization does no attempt to read signatures or script type:

bitcore/lib/transaction/transaction.js

Line 306 in c671a97

var input = Input.fromBufferReader(reader);

calls

bitcore/lib/transaction/input/input.js

Line 91 in c671a97

Input.fromBufferReader = function(br) {

[braydonf]

After adding benchmarks for transaction serialization, there wasn't a large performance (although there was around a 30%) improvement from separate constructors for Transaction or Block.