[Cryptography] BitCoin bug reported

Theodore Ts'o tytso at mit.edu
Sun Feb 16 08:18:37 EST 2014

On Sun, Feb 16, 2014 at 11:24:34AM +0300, ianG wrote:
> This is where words matter.  It has never been possible for more than
> one transaction to exist, covering the same inputs.  The definition of
> transaction is quite well established in computer science, it is that
> which is, that which results.

I think you are engaging in pedantry.  The problem was that the
defined the abstract transaction in terms of something like an ASN.1
structure, and failed to specify the use of a canonical encoding for
that structure when it is passed on the wire.  I.e., the difference
between DER and BER.  This had been a known problem, and for
compatibility reasons, most implementations (including the reference
implementation) were sending the DER encoding, but accepting a more
liberal encoding of tha transaction, and matching against the actual
structure elements of the structure.

Unfortunately, there were older implementations that were sending
non-canonical encodings, and worse, trying to rely on the hash of the
encoding without verifying that the encoding was in fact the canonical

Furthermore, there are in fact many definitions of transactions, even
with the computer industry, and context matters.  There is the
accounting deifnition of the word "transaction", which for financial
applications, is just a perfectly valid system.  You would agree that
if you complained that a double-entry accouting system, even if it
were computerized, used "transaction" in the way any accountant would
accept and understand it, and complained that program was not using
the word "transaction" in the database sense (which is what I think
you mean by "well established in computer science"), that "words
matter" and clearly the accounting program was using the terminology
wrongly, that this would be pedantry, I hope.

I will note that the question of multiple encodings is a very old
problem, and we've seen it with x.509 certificates, and with Kerberos
tickets, and many others.  It's one of the reasons why I am not very
fond of complex encoding schemes, such as ASN.1, when used in complex
cryptographic protocols.  Yes, such protocols are extensible, which is
wonderful from a protocol author's point of view.  From the point of
view of an attacker looking for mistakes engendered by all that
complexity, it is even more wonderful....

	    					- Ted

More information about the cryptography mailing list