Also, the following transaction shows correctly as fully signed on coinb.in but still throwing (Non-canonical DER signature) error
-snip-
The signatures for that second transaction are all invalid.-snip-
Some info:
He's trying to spend this P2PK output: 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
Funded this Public key: 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee
And these two P2PKH outputs: d6be34ccf6edddc3cf69842dce99fe503bf632ba2c2adb0f95c63f6706ae0c52 | cb2679bfd0a557b2dc0d8a6116822f3fcbe281ca3f3e18d3855aa7ea378fa373
Funded this address: 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX which was generated using that P2PK output's public key.
No, I didn't buy a wallet.dat, I am doing some tries with dormant addresses using the SIGHASH_SINGLE vulnerability for P2PKH addresses.
Is it based from this or something similar: http://joncave.co.uk/2014/08/bitcoin-sighash-single/?Because if you did, you totally misunderstood the article (read the first paragraph carefully); you're trying to spend a P2PK output and P2PKH outputs that you don't have the control over.
The output(s) that you should try to spend are the ones affected by the bug (created by other clients, maybe), not a random dormant outputs.
The signatures from your transaction suggest that you're following that exact article.
The redeem script that you've used is even the same as the sample transaction's (Go to "Stealing coins in a new transaction"), it's the same redeem script
