[Cryptography] BitCoin bug reported

[ianG]

On 16/02/2014 16:18 pm, Theodore Ts'o wrote:
> 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.


As I mentioned.  In my experience, there are two sorts of payments
system.  There are those that understand what a transaction is, and
those that lose money.  Call it pedantry if you like, but it's pretty
clear in history of payment systems that if there isn't a good solid
understanding of transactional integrity, and/or that understanding
isn't pushed through aggressively to all players, then money is lost.

Which is where we are.  Mt.Gox lost money.  I don't like being called a
pedant, but I hate losing money 1000 times more, and if that is what it
takes, slap it on.


> 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.


Encodings are at the bits & bytes layer, transactions are at a much
higher layer.  They both exist as tools for the programmer, and they
both apply to this problem.  Just because they've spotted the flaw at
the bits&bytes means little for other layers.

The fact that there was looseness in the definition of the encodings is
an issue that is solved ultimately by the blockchain -- that transaction
which is in the blockchain has the encoding that is correct, by
definition.  We are agreed that the transactions in the confirmed
blockchain are transactions, right?  ACID and all that?

Then, any other encoding, whether defined, canonical, displayed or
etched in stone are simply for convenience, they aren't the encoding
that is in the blockchain.  And any pre-transaction identifier is simply
a prediction as to what to look for in the next blockchain.  It helps,
sure.  Just don't rely on it.


> 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
> one.


Right, so as an assist to the applications, Bitcoin attempted to come up
with an identifier that was consistent before and after the transaction.
 A noble goal.


> Furthermore, there are in fact many definitions of transactions, even
> with the computer industry, and context matters.


I fully agree that 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 agree.  Above, you clearly established the context of the term within
the field of accountants.  I would not complain, especially as with
double entry systems, the "accounting transactions" are typically
reversable.

However, Bitcoin is not accounting, it is a payment system, and by the
nature of money, it is transactional according to the CS/database sense.
 Any other interpretation is a state of sin.  If you do not subscribe to
this, I have a transaction I wish to share with you.


> 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....


Indeed.  In encodings, there be gremlins.

But lack of transactional integrity is a far greater sin.



iang