Topic: is this a Satoshi client bug in an old transaction ? (Read 1063 times)

I didn't mean to discourage your work, I was just suggesting extreme caution because there are many subtle features which are hard to test and must be exact.

Diversity is good and may help discover issues.  But as Gavin was saying and as I like to point out: The most dangerous kind of failure in bitcoin isn't an implementation bug— any blockchain validation inconsistencies in widely deployed implementations are significantly worse than pretty much anything other than a full private key leak or remote root exploit... and are even harder to avoid.

There are many useful 'test' cases in the mainnet chain and in the testnet chain, but those only test valid blocks. Bugs that accept thing which should be rejected wouldn't be found by those.  Matt has been working on a test feeder tool as part of his effort to make full node support for bitcoinj which is very promising. There are also tests included with the reference software. There needs to be more of them.

I am here to help, not to fork.

Using your example: for a while HTML was defined by Netscape but that did not save us from the Microsoft fork.
Hundred pages of standard did not work there either.

What might work is a set of test suites that major implementations and new releases have to pass. I am willing to contribute to such.

Okey dokey.

Reality is that the protocol IS defined by Satoshi's implementation.

This isn't like HTML where the worst thing that happens if two implementations disagree about the spec you get different looking web pages.  Our worst case is much worse (if two popular implementations disagree then we potentially wind up with a blockchain split, and, essentially, two different currencies).

We need help creating tests to make sure different implementations agree on the rules; as you re-implement the protocol please set aside some time to think about that and help!

Thanks Yes, I am done with a high performance P2P kernel using Java NIO, do all verifications of blocks I found on wiki, in Satoshi and bitcoinj code base and some more as this thread illustrates. I store the blockchain in a normalized cross linked and indexed relational database using JPA, Support for BCCAPI, servlet interface is in works, assemly using Spring. Expect to be impressed should I choose to release.

Holy cow, all by yourself? I'm impressed! Maybe Satoshi really was just one guy then..

Thanks, that is I was afraid of. I know, since this is old we can only declare it a "feature".

To uncover those "quirks" is exactly the reason I do tho effort.

I think the protocol should not be defined by a particular implementation, even if that one was written by Satoshi. I will add this "feature" to the wiki.

I re-implement the protocol independently since I believe a bug in the dominant implementation is the most present danger to the ecosystem.

I hope the community understands that diversity of implementations is what we need.

Just some poorly documented behavior, if you'll note there is no explicit mention of SIGHASH_ALL in the script code; SIGHASH_ALL is what you get when it isn't the other things.

If you implemented based on material in the wiki I would be concerned about the correctness of your implementation unless compared very carefully with the reference code and tested thoroughly because of the many possible sources of little quirks like this.

While bootstrapping and verifying the chain using my implementation of the protocol (that shares no code with the Satoshi client) I found that transaction

c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73

does not verify. Since it looks regular and my implementation verified all 110299 block before this one, I am concerned.

This transaction is at chain height 110300, block 000000000000b8c3ad583c44e2655f5384f3e4e6a1f2a932b512ecc69a07cc24

Here my JSON dump of the transaction:

{hash:"c99c49da4c38af669dea436d3e73780dfdb6c1ecf9958baa52960e8baee30e73",version:1,inputs:[{sourceHash:"406b2b06bcd34d3c8733e6b79f7a394c8a431fbf4ff5ac705c93f4076bb77602",sourceIx:0,script:"OP_PUSH73 3046022100d23459d03ed7e9511a47d13292d3430a04627de6235b6e51a40f9cd386f2abe302210 0e7d25b080f0bb8d8d5f878bba7d54ad2fda650ea8d158a33ee3cbd11768191fd00 OP_PUSH65 04b0e2c879e4daf7b9ab68350228c159766676a14f5815084ba166432aab46198d4cca98fa3e998 1d0a90b2effc514b76279476550ba3663fdcaff94c38420e9d5",sequence:0}],outputs:[{value:4000000,script:"OP_DUP OP_HASH160 OP_PUSH20 9a7b0f3b80c6baaeedce0a0842553800f832ba1f OP_EQUALVERIFY OP_CHECKSIG"}],lockTime:0}

I think the problem is that the bold byte at the end of the signature, that should be 01 for SIGHASH_ALL. The value 00 does not map to any flavor. IMHO this is/was a "bug" in the Satoshi client.