No Script

[dcousens]

Ref: #407 (comment)

I didn't realise before, but Script is a major component which could be simplified down to a Buffer for interop.
With modules like https://github.com/bitcoinjs/bip69 coming up, the ability to reduce this part of the API would be asimilar to the changes made to Address.

Overall, this is part of #407.
The performance is the same, we just stopped using Script as a data interchange.
You are now either explicitly dealing with the decompilation result of a script (aka, chunks) after a scripts.decompile, or you are dealing with a Buffer which is a script.

This also means you can now pass your script directly to Transaction without having to decompile it first.

I also merged Script and scripts, which makes the interface smaller and cleaner IMHO, open to feedback though.

Chained on #434 , but not dependent.

Comparison link: noassert...noscript

[dcousens]

My motivation for this is mostly interchange between libraries. I wanted to be able to agnostically work with scripts, and yet most of the bitcoinjs-lib interface requires me to "pre-parse" the script using Script.fromBuffer or what not.
This was especially annoying if I had no need to actually decompile the script anyway, so it was just a fruitless operation for the sake of an abstraction.

[jprichardson]

All of the assert changes / typeforce changes to this PR makes this more painful to review... granularity ftw :)

While I've always thought Script was a useful abstraction, I understand the motivation, especially regarding interoperability. So I am OK with this. Would like to know what @weilu thinks.

[dcousens]

All of the assert changes / typeforce changes to this PR makes this more painful to review... granularity ftw :)

Did you check the comparison link? (See noassert...noscript)

[dcousens]

Waiting on ACK for #434 before merge.

[weilu]

Where does the name compile/decompile come from? Would it help inferring the input and output types better by calling them chunkArrayToBuffer and bufferToChunkArray?

[dcousens]

chunks are essentially uncompiled byte code, which is then compiled to a Buffer for serialization in a Transaction.
Seeing as we have to parse a Buffer to de-serialize it, using the OP_CODE byte codes, it seemed like a fitting analogy.

[weilu]

From my point of view, it's not obvious what are the input and output types just by reading the function name.

[dcousens]

A script in this sense should be synonymous with a Buffer.
In all cases a Script was a valid, a Buffer should now be used.

compile is the only exception to this, it takes an Array of chunks to be serialized into a Buffer.

chunks are the byte codes in their uncompiled form.
toASM takes a Buffer and transpiles it back to its human readable equivalent (ASM).
fromASM takes a string of human readable opcodes (ASM) and compiles it to a Buffer.

For internal usage and performance reasons, it is also possible to interchangeably use a chunks Array to avoid constant decompilation/compilation.

[weilu]

Overall this change does enable the use of primitive/native types, but at the cost of abstraction. It used to be Script is an abstraction with two forms of representation -- chunks and buffer. Now that's no longer the case. I personally still find the version with the Script abstraction easier to reason, but it could be just me.

[weilu]

Granted I don't work with script enough, so if @dcousens feels strong enough to merge this, then go ahead :)

[dcousens]

After further discussion of compile v decompile with @weilu, I'm now on the fence as to whether compileToBuffer would be a better name to indicate the target type more clearly.

I think if we are going to change getPublicKey to getPublicKeyBuffer, then compileToBuffer is also reasonable.

The questions I wonder then, are there any other places where the return type is ambiguous? Should we being doing this consistently? How much is this just a symptom of there being no documentation?

[dcousens]

Rebased on master

[dcousens]

All nits/tests fixed.
Last remaining question is compile v compileToBuffer.
If no response within 24 hours or so, will merge as compileToBuffer.

[weilu]

compileToBuffer is better IMO

[dcousens]

@weilu undecided about that, so I opened #442 so I can move on and hopefully just have it resolved before 2.0.0.