Refactor: Store PUSHDATA opcode in ScriptChunk

[GoogleCodeExporter]

I just investigated into writing a patch to show the PUSHDATA opcodes in 
Transaction.toString() but found out bitcoinj isn't keeping them around. When 
serializing, it just picks a new opcode based on the size of data to push.

In terms of transaction malleability this is not nice. I guess we'll never be 
able to implement the PUSHDATA opcodes related isStandard rules (due for 
bitcoin core 0.9.0).

I would volunteer to refactor that code if no one objects. That would mainly be 
Script and ScriptChunk and maybe some tests. It should be transparent to other 
components. Ok?

Original issue reported on code.google.com by andreas....@gmail.com on 8 Mar 2014 at 5:01

[GoogleCodeExporter]

I couldn't wait and implemented it here:

https://github.com/bitcoinj/bitcoinj/pull/24

Original comment by andreas....@gmail.com on 8 Mar 2014 at 9:51

[GoogleCodeExporter]

I just skimmed through this paper about transaction malleability:

http://arxiv.org/pdf/1403.6676v1.pdf

Relevant quote for this pull request: "...there are a multitude of ways to use 
the malleability in the signature encoding to mount a malleability attack. The
most prominent type of modification was replacing the single byte OP_0 with 
OP_PUSHDATA2 which then encodes the length of the data to push on the stack 
with 2 bytes. [...] A total of 28,595 out of the 29,139 confirmed attacks had 
this type of modifications."

We currently do not have any isStandard rule for this type of malleability.

Original comment by andreas....@gmail.com on 27 Mar 2014 at 8:43

[GoogleCodeExporter]

Right, I'm hoping that Gavin or Sipa will implement BIP 62:

http://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

and all those forms of malleability will be made illegal at once.

Original comment by mh.in.en...@gmail.com on 27 Mar 2014 at 9:35

[GoogleCodeExporter]

Implemented on master.

Original comment by andreas....@gmail.com on 1 Jun 2014 at 8:09

• Changed state: Fixed