New Attack Vector

[ByteCoin]

For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.

Now that this is well known, I have to point out the following:

If some subset of clients rebroadcast transactions while flipping the sign of s then the transactions have different ids (because currently the signatures are included when hashing to find the transaction ID) and there may be some problems if the flipped version makes it into the block instead of the vanilla version as I believe the originator wouldn't recognise the flipped transaction has spent his coins.

ByteCoin

[1713568390]

1713568390

[1713568390]

1713568390

[1713568390]

1713568390

[gmaxwell]

Now that this is well known, I have to point out the following:

Transaction malleability has been known and discussed many times— including padding and other encoding differences. Is there some reason that you believe the s-flip to have distinct implications from all of the other signature encoding differences?

The understood risk of this in prior discussions has primarily been that troublemakers could create confusion by changing the transaction ID of confirmed transactions to be something different than the transaction participants were expecting (so, e.g. they'd see two transactions doing the same thing, one which never confirms). There is a secondary risk that parasites could 'hijack' other people's transaction to pay the way to embed data in the blockchain for them.

I believe the originator wouldn't recognise the flipped transaction has spent his coins.

In the reference client the spent-ness of candidate inputs when drafting a transaction are checked with IsSpent(), the txid of the spending transaction should be irrelevant. Can you elaborate on what you're thinking here?

[kokjo]

BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:

ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over

[kjj]

BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:

ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over

What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?

[kokjo]

blockchain.info accepts my transaction vis pushtx, but bitcoind does not find it aesthetically pleasing enough.

if bitcoin fails, the blame goes to the developers for not having a standard to implement, but making shit up as you go along.

[kokjo]

What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?

nope not at all, i give it the key(generated by the satoshi client, btw) and the transaction hash, it gives me the signature and i append hashtype.

blockchain.info accepts but bitcoind rejects.

you people should really stop implementing features, and sit down create a standard and start fix bitcoin instead.

[kjj]

Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length.  When you attach your hashtype, are you changing the total length?

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

[piotr_n]

there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:

Code:

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

it is taken using this expression:

Code:

unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

[kjj]

there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:

Code:

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

it is taken using this expression:

Code:

unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical.  When the signature is in the proper form, the last bye is the last byte.

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

I'm having a hard time understanding what you are talking about here.  The SIGHASH values apply to signatures.  The txout being redeemed has no bearing on them.

[piotr_n]

there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:

Code:

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

it is taken using this expression:

Code:

unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical.  When the signature is in the proper form, the last bye is the last byte.

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

I'm having a hard time understan what you are talking about here.  The SIGHASH values apply to signatures.  The txout being redeemed has no bearing on them.

Check this - it's a real signature from tx 67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2:

Code:

3045022052538ceefdadef44696559b5b135e48218403f10120bcf592825b924af804821022100ed30a2a2218ad85438fd6a38f909b5ac55bc322033b63ddf17b3b9db11cd61800001 

Following the format, the hashtype should be 00, while in fact it is 01.

[kokjo]

Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length.  When you attach your hashtype, are you changing the total length?

0x30  <total_length> 0x02 <length_of_R> <R> 0x02 <length_of_S> <S> <hashtype>

Code:

0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb5000000006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f0100000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000

why would i change the length, are bitcoin in the business of messing with other people's standard?

[piotr_n]

0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb500000 0006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020 c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f01 00000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000

this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?

[jackjack]

0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb500000 0006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020 c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f01 00000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000

this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?

Returning

Code:

ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

because of a too low fee is rather strange

[piotr_n]

Returning

Code:

ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

because of a too low fee is rather strange

that makes sense.
so blockchain.info does not use bitcoind - I was always wondering..

@kokjo your tx won't get mined.
it does not like the fact that the 44 (<total_length> field) in your sig is not the actual sig length minus 3.

Code:

    if (vchSig[1] != vchSig.size()-3)
        return error("Non-canonical signature: wrong length marker");

[kjj]

You have two bytes of padding in there.

You may want to look at the bitcoind code to see how it gets unpadded signatures.

Code:

6c - script length
49 - signature length - should be 47 once the padding is removed
30 - marker
44 - rs length <total_length>
02 - marker
20 - R length
3ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 - R
02 - marker
20 - S length
14247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c5173 - S
00 - garbage - invalid
00 - garbage - invalid
01 - SIGHASH flag
21 - pubkey length
02 - pubkey is compressed and even
0c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95 - pubkey

[kokjo]

you don't have to tell my where my perfectly valid transaction fails bitcoind's beauty check, you need to remove the check from the satoshi client and stop adding useless crap to it.

the signature was generated with openssl, and is perfectly valid, my client and blockchain.org agrees.
The satoshi client should not be the protocol standard, of cource i could fix my transaction and give you people a free pass to fuck around more with bitcoin.

I will not allow this, and i object to the elitist culture among the main developers.

fix bitcoin, go make a standard and stick to it.

[kjj]

you don't have to tell my where my perfectly valid transaction fails bitcoind's beauty check, you need to remove the check from the satoshi client and stop adding useless crap to it.

the signature was generated with openssl, and is perfectly valid, my client and blockchain.org agrees.
The satoshi client should not be the protocol standard, of cource i could fix my transaction and give you people a free pass to fuck around more with bitcoin.

I will not allow this, and i object to the elitist culture among the main developers.

fix bitcoin, go make a standard and stick to it.

Well, good luck with that, I guess.

[kokjo]

Well, good luck with that, I guess.

so you are okay with that the developers is destroying bitcoin by trying to make it better?

prediction:
in a few years bitcoin will be worth nothing and a altcoin not based on the satoshi source with a solid standard will thrive.
because developers fucked bitcoin up, with all kind of insane checking and worse coding skills. bitcoin will nothing more then a bunch of dirty hacks.

[piotr_n]

Well, good luck with that, I guess.

so you are okay with that the developers is destroying bitcoin by trying to make it better?

this code if very old.
if they "fix" it now, it would surely create a hard fork soon - you don't really want it.
better change your code, adapting it to the beauty checks.
that is the reality all the new emerging bitcoin implementation will need to live in.
no altcoin can also be perfect from the first release, and they all are going to face similar issues in a future.

[kokjo]

Well, good luck with that, I guess.

so you are okay with that the developers is destroying bitcoin by trying to make it better?

this code if very old.
if they "fix" it now, it would surely create a hard fork soon - you don't really want it.
better change your code, adapting it to the beauty checks.
that is the reality all the new emerging bitcoin implementation will need to live in.
no altcoin can also be perfect from the first release, and they all are going to meet exactly the same issues.

Fuck you liar! sipa added the check only 11 months ago.

Source:
https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp
https://github.com/bitcoin/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c