Topic: New Attack Vector - page 4. (Read 46618 times)

Yup. The chain is stuffed full of old violations too. You can rig it to always be strict and reindex the chain and watch it reject it if you're bored.

Oh, I get it - its the fStrictEncodings.
Thanks for explaining

Yeah, it would not have caused a hard fork - sorry for messing up.
I once analyzed the byte problem (I mentioned before) and then realized that fixing it would require a hard fork. And this mislead me.

Are you sure?
From what I see, the only place where IsCanonicalSignature is called from is EvalScript - the same function the blockchain parser uses.

As this thread politely explains, OpenSSL violates the ASN.1/DER standard and will accept encoding which are invalid in a multitude of ways.  Because of this any implementation of the Bitcoin protocol— no matter what library it used— have to be bug for bug compatible with OpenSSL.  Worse, the behavior creates malleability of signatures which create the attack describe in this thread and which actually turns out to be even somewhat worse than described here.

Malleability  was being actively employed on the network in order to double spend and dos attack.  To close the attacks a strict, canonical, valid encoding must be enforced. As a bonus, if the enforcement is eventually made a network rule alternative implementations will not have to emulate OpenSSL's signature handling bugs.

It's interesting to hear that it's _creating_ these signatures: IIRC, we did not need to change Bitcoin in any way to avoid creating signatures with non-canonical encoding, OpenSSL's weird behavior is on the decoding side. It would be useful to know how you're (ab)using OpenSSL to accomplish this and/or what version of it you're using. It would be concerning, indeed, if there were some way to get the reference software to produce such a thing— but it's certainly not done so on normal systems in the past.

In any case, this was tested for months, deployed in the codebase as non-enforced for months prior to activation, announced widely. Bitcoin will not remain vulnerable to attack just so you can be lazy and produce sloppy inefficiently encoded signatures. If you are unwilling to take the effort to understand this and get it right it seems unlikely that you'll get the rest of the protocol right. Cryptographic distributed consensus systems may not be rocket surgery, but perhaps they're a little too complicated for some people— perhaps the kind of people whos first recourse is to start slinging insults at people for correcting a security vulnerability— to safely implement.

Piotr_n, this is not yet a network rule. Presumably someday it will be. Today this signature correctness is not enforced against blocks, just against free transactions. This means that miners can still perform the related malleability attacks but other users cannot, and it still means that alternative implementations must remain bug for bug compatible with OpenSSL's buggy validation. This is also why it's not a forking-anything to change.

No offence, but all this work is being done to actually make it comply to the standard.

The problem was that even though OpenSSL always created transactions that were compliant, it accepts signatures in non-standard encodings. This is bad, as every alternate implementation is required to implement the rules exactly as OpenSSL is. We've known this issue for a while, brought it up several times on the development mailing list and on this forum, investigated who was creating such transactions and gotten them to upgrade, until the frequency of such transactions was low enough. Then finally we added a rule to make bitcoind not relay or mine such transaction - without making them invalid even.

In this case, if the signature created made by bitcoind is non-standard, then we have a serious bug in the signature creation code. AFAIK, no bitcoin(d/qt) ever has ever created signatures that are currently considered non-standard however. If you're creating them yourself, it's possible to create valid transactions that are being rejected now. I'm sure you prefer your bitcoin node to reject the transaction immediately over only have the network reject it with you wondering why it doesn't confirm.

There is no risk for a hard fork at all right now, by the way. This is just local client policy about which transactions are relayed.

no. such transactions don't exist. not in the blockchain.
it doesn't matter what other clients accept - it only matters what miners accept, and 99% of them are already at satoshi 0.8.x

No. But it will certainly come if the devs continue to behave like tards

no its not. there already exist transactions that violates the beauty checks, and other clients accept these transactions too.

kokjo, what was the OpenSSL command/code you used to generate that signature?

There are reasons canonical checks were adopted (it will fix a variety of attacks and sharp edges in the protocol). However if your OpenSSL is generating non canonical sigs, we'd very much like to find out why.

Is there a kokjo-coin available?

Don't talk to me like this - I only tried to help you, but I can swear as well.
11 months ago is long enough to cause a hard fork, if they revert the change now.

You should have mined your ugly tx before this change - that would surely prevent it

Oh, the irony .

You basically want openSSL to be the standard.  That makes it harder for clients to be sure they are compatible.  

With the "beauty" checks, a script parser can be sure that it covers every valid signature.

Destroying?  Nonsense.

Leave your hyperbole at home and go read up on why non-canonical encodings are bad, and why the developers decided to mark them as non-standard.  (That the satoshi client refuses to emit anything it considers to be nonstandard should be obvious.)

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

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.

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.

Well, good luck with that, I guess.

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.

You have two bytes of padding in there.

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