New Attack Vector

[kjj]

@kokjo: mind sharing the code how to embed the OpenSSL-created signature into a sigScript? I expect the problem is caused by how you wrap/pad it, rather than with the signature itself.

Code:

sc = [script.OP_PUSH(sig+"\x01"), script.OP_PUSH(key.publickey)]
tx.inputs[0].script = script.encode_script(sc)

as said before its the statoshi clients problem, not me generating bad(wrongly padded) signatures. i already have tracked down the problem in the satoshi client.

I decoded the transaction you provided by hand.  It is wrong, and I told you where it was wrong.

The satoshi client is only broken if you got that hex as the output of signrawtransaction.

[kokjo]

Why should Bitcoin protocol accept all openssl formats?

What we need is a protocol, not mad people whining in a forum. That sure won't make them change.

the fix in the satoshi client includes this:

Code:

    // See https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623
    // A canonical signature exists of: <30> <total len> <02> <len R> <R> <02> <len S> <S> <hashtype>
    // Where R and S are not negative (their first byte has its highest bit not set), and not
    // excessively padded (do not start with a 0 byte, unless an otherwise negative number follows,
    // in which case a single 0 byte is necessary and even required).

a link to this thread, is not the way of creating a good protocol standard.
Again:
bitcoin is a big hack job, create a standard and stick too it.

btw. would you please include my transaction in a block?

[kokjo]

The satoshi client is only broken if you got that hex as the output of signrawtransaction.

So the satoshi client can just troll around and smash things up, so no other client gets a fair chance to be able to create transactions.
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L261 <-- this is where the satoshi client fail. the client is bad, and sipa(the dev who commited this) should feel bad.

[piotr_n]

The satoshi client is only broken if you got that hex as the output of signrawtransaction.

So the satoshi client can just troll around and smash things up, so no other client gets a fair chance to be able to create transactions.
https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L261 <-- this is where the satoshi client fail. the client is bad, and sipa(the dev who commited this) should feel bad.

I disagree that he should feel bad.
Your signature  is inconsistent - one length clearly does not match the other.
IMHO, he's right treating it like he does; a probably broken signature.

[Pieter Wuille]

The standard was using DER-encoded signatures, we're not making anything up - we're just enforcing a correct encoding rule that should have been there all along. The code comment is just a nice summary of the rules. This was announced several times on the development list and on this forum, and in release notes. We did wait until only a minority of transactions with non-canonical encodings remained, but it's impossible to find every possible (future) misbehaving client code.

If you disagree that standard-conforming signatures should be enforced on the network, we have little to talk about.

In any case, kjj is right - there are 2 weird padding bytes there, and I don't understand why your code is adding them. In any case, it's clearly wrong - go find why and fix it.

[gmaxwell]

Code:

        assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
        return mb_sig.raw

I believe this code is wrong.

ECDSA_sign takes a pointer siglen for the length of the buffer. The reason it passes a reference there and not a value is because it writes the resulting length back to it. Otherwise there would be no way to know the length other than the maximum since, obviously, char * doesn't encode a size.  Your code appears to do nothing with the returned size. This is wrong, and it means you're reading past the end of the destination array. Be glad the additional space contains only zeros and not your private key.

[piotr_n]

Be glad the additional space contains only zeros and not your private key.

It could have, indeed.

[kjj]

Code:

        assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
        return mb_sig.raw

I believe this code is wrong.

ECDSA_sign takes a pointer siglen for the length of the buffer. The reason it passes a reference there and not a value is because it writes the resulting length back to it. Otherwise there would be no way to know the length other than the maximum since, obviously, char * doesn't encode a size.  Your code appears to do nothing with the returned size. This is wrong, and it means you're reading past the end of the destination array. Be glad the additional space contains only zeros and not your private key.

pwn3d

[kokjo]

Code:

        assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
        return mb_sig.raw

I believe this code is wrong.

ECDSA_sign takes a pointer siglen for the length of the buffer. The reason it passes a reference there and not a value is because it writes the resulting length back to it. Otherwise there would be no way to know the length other than the maximum since, obviously, char * doesn't encode a size.  Your code appears to do nothing with the returned size. This is wrong, and it means you're reading past the end of the destination array. Be glad the additional space contains only zeros and not your private key.

+1 you are right, and i have broadcasted a double spend. Thank you.

pwn3d

I accept defeat, but still thinks that we need a standard, and that the satoshi client a bunch of hacks.

[piotr_n]

yeah, we need a standard. the only question is: who is going to develop a voting system that will decide about the standard?
thank god, we have a primitive bitcoin mining concept, backed with a billion dollar stability fund.
because if the future of this currency was based only on getting together the people developing its IT infrastructure, it would have been pretty fucking doomed.

[gmaxwell]

+1 you are right, and i have broadcasted a double spend. Thank you.

Perhaps you're competent to review this change? https://github.com/jgarzik/python-bitcoinlib/pull/6  I am not.

[kokjo]

yeah, we need a standard. the only question is: who is going to develop a voting system that will decide about the standard?
thank god, we have a primitive bitcoin mining concept, backed with a billion dollar stability fund.
because if the future of this currency was based only on getting together the people developing its IT infrastructure, it would have been pretty fucking doomed.

voting is not needed. we just need a guy with some balls to act as a dictator for a short period of time, and an army of typing monkeys implementing the standard.

what is done at https://en.bitcoin.it/wiki/Protocol_specification is usable, but most is yanked out of the satoshi client and lots of stuff have changed so the wiki is not up to date either. again: make a standard and implement it.

+1 you are right, and i have broadcasted a double spend. Thank you.

Perhaps you're competent to review this change? https://github.com/jgarzik/python-bitcoinlib/pull/6  I am not.

looks good enough... i have already committed a similar change to my code.

[piotr_n]

yeah, we need a standard. the only question is: who is going to develop a voting system that will decide about the standard?
thank god, we have a primitive bitcoin mining concept, backed with a billion dollar stability fund.
because if the future of this currency was based only on getting together the people developing its IT infrastructure, it would have been pretty fucking doomed.

voting is not needed. we just need a guy with some balls to act as a dictator for a short period of time, and an army of typing monkeys implementing the standard.

what is done at https://en.bitcoin.it/wiki/Protocol_specification is usable, but most is yanked out of the satoshi client and lots of stuff have changed so the wiki is not up to date either. again: make a standard and implement it.

from my experience, the only standard there is, is the satoshi source code.
the wiki is very helpful though and it almost nowhere contradicts the actual protocol, but the standard is in the code.
and maybe its not such a bad idea for a standard to be in a code.
as long as this code is not stupid

[kokjo]

yeah, we need a standard. the only question is: who is going to develop a voting system that will decide about the standard?
thank god, we have a primitive bitcoin mining concept, backed with a billion dollar stability fund.
because if the future of this currency was based only on getting together the people developing its IT infrastructure, it would have been pretty fucking doomed.

voting is not needed. we just need a guy with some balls to act as a dictator for a short period of time, and an army of typing monkeys implementing the standard.

what is done at https://en.bitcoin.it/wiki/Protocol_specification is usable, but most is yanked out of the satoshi client and lots of stuff have changed so the wiki is not up to date either. again: make a standard and implement it.

from my experience, the only standard there is, is the satoshi source code.
the wiki is very helpful though and it almost nowhere contradicts the actual protocol, but the standard is in the code.
and maybe its not such a bad idea for a standard to be in a code.
as long as this code is not stupid

it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?

[jgarzik]

it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?

The standard does not mutate all the time (though I do agree client diversity is a good thing).

[kokjo]

it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?

The standard does not mutate all the time (though I do agree client diversity is a good thing).

It mutates with every commit to the satoshi client repo. Code is not a standard.

[piotr_n]

so what do you propose?

[kokjo]

so what do you propose?

stop writing code, and sit down and make a standard. Its not that hard, nobody just wants to do it because they are lazy bastard who like to code crap code, instead of doing things the right way.

Just like the rfc's describe what the protocol look like down to the smallest detail, and then don't change it. Describe how clients interact with keyword defined in http://www.ietf.org/rfc/rfc2119.txt.

[kjj]

it makes it nearly impossible to create a alternative client, when the "standard" mutates all the time. bitcoin needs diversity in clients.
Would you like to only be able to use internet explore? sure it would work good. but really?

The standard does not mutate all the time (though I do agree client diversity is a good thing).

It mutates with every commit to the satoshi client repo. Code is not a standard.

No, it really doesn't.

Sipa's patch last year changed how this particular implementation behaves, only.  It was not a change in the protocol.  The change was not binding on anyone else.

P.S.  The standardization thing is discussed in endless detail in many other threads.  Please read some of those before posting again.  You have contributed nothing new to the debate; even your pointless personal attacks are reruns.

[piotr_n]

stop writing code, and sit down and make a standard. Its not that hard, nobody just wants to do it because they are lazy bastard who like to code crap code, instead of doing things the right way.

They don't strike me like people who like to write code
And I guess you never tried to describe what a code does, in a human readable language.
Otherwise you would know that it's impossible.