SIGHASH_ANYONECANPAY (0x80) is an invalid hashType

[lightswarm124]

transactionBuilder.sign( 0, alice_keypair, redeemScript, transactionBuilder.hashTypes.SIGHASH_ANYONECANPAY, originalAmount );

returns the following error:

error: Error: Invalid hashType 192
at ECSignature.toScriptSignature (/home/lightswarm/project/bitcoinbay/atomicBCH/node_modules/bitcoincashjs-lib/src/ecsignature.js:95:51)
at /home/lightswarm/project/bitcoinbay/atomicBCH/node_modules/bitcoincashjs-lib/src/transaction_builder.js:722:37
at Array.some ()
at TransactionBuilder.sign (/home/lightswarm/project/bitcoinbay/atomicBCH/node_modules/bitcoincashjs-lib/src/transaction_builder.js:713:30)
at TransactionBuilder.sign (/home/lightswarm/project/bitcoinbay/atomicBCH/node_modules/bitbox-sdk/lib/TransactionBuilder.js:80:26)
at run (/home/lightswarm/project/bitcoinbay/atomicBCH/src/index.js:57:24)
at processTicksAndRejections (internal/process/task_queues.js:93:5)

It seems that 0x80 ANYONECANPAY needs to append one of SIGHASH ALL/ONE/NONE. The following hashType values work:

• 0x01 SIGHASH_ALL
• 0x02 SIGHASH_NONE
• 0x03 SIGHASH_SINGLE
• 0x81 SIGHASH_ALL | SIGHASH_ANYONECANPAY
• 0x82 SIGHASH_NONE | SIGHASH_ANYONECANPAY
• 0x83 SIGHASH_SINGLE | SIGHASH_ANYONECANPAY

[christroutner]

@lightswarm124 could you provide an example script that generates the error?

bitbox-sdk v8.11.2 includes a new Script.encode2() function that I think will fix this issue.

I believe the error you're seeing is because the TransactionBuilder is calling Script.encode which is mangling to OP code. If you provide an example that generates the error your seeing, I'd like to play with it and see where I should make the Transaction Builder call the new encode2 function.

[christroutner]

The example you give jives with this part of the code.

Looks like that list should be expanded so that users don't need to OR values to get the value they're expecting.

[lightswarm124]

The example you give jives with this part of the code.

Looks like that list should be expanded so that users don't need to OR values to get the value they're expecting.

I'm not sure where this list lives, but I think it may be part of the overall network consensus. One quick-fix would be to add the value of the other hashtypes into ANYONECANPAY (0x80 + 0x*)