
Bitcoin transaction malleability: looking at the bytes - guan
http://www.righto.com/2014/02/bitcoin-transaction-malleability.html
======
codeflo
This post explains the _how_ very well. Now I wonder about the _why_.

Why is there extra data that's part of the transaction hash, but not part of
the cryptographic signature? (This fact seems to be the source of the
problem.)

This is probably not by accident, so what does this design accomplish? Why
isn't every bit of the transaction signed?

~~~
nullc
All of the transaction except the "signature"s is signed. The modifications
come from modifying the signatures and/or their encoding.

~~~
codeflo
Well, the signature itself can't be signed (obviously). But that's not a
problem for many other uses of cryptographic signatures, there's something
about the Bitcoin protocol that makes this an issue, and I'm trying to
understand what that is.

Why is there _any_ choice in how the signature is encoded? Why is there some
sort of "script" (I'm not sure I understand this part) that's important enough
to be hashed, but not important enough to be signed? This looks like a very
deliberate design decision.

~~~
oillio
Due to the intricacies of ECC (the cryptography used in signing transactions)
the signature can always be mutated to produce a different, but equally valid
signature.

If the developers want to avoid transaction malleability, they will not be
able to include the signature in the hash.

~~~
Anderkent
> If the developers want to avoid transaction malleability, they will not be
> able to include the signature in the hash.

Would that be a problem? Since a transaction is already uniquely identified by
the inputs, why not hash everything that's signed and use that as the
identifier in (tx, index) pair?

------
scottcanoni
Two questions:

1\. Do the attackers (users who abuse this), modify all transactions they see
or do they target those transactions that only involve their wallet?

2\. Even given the relative ease an attacker would have with modifying a
transaction, that transaction still needs to be accepted by the majority
otherwise their modification is ignored. So given 2 transactions for the same
bitcoin transfer, I would guess that 50% of the time their transaction is
accepted. I guess that the attacker could modify the transaction, for example,
4 times and then it's an 80% chance that one of their modification is accepted
(4 out of 5). Do I have that right?

This was a good article, I enjoyed it's breakdown with examples.

~~~
patio11
1) Someone appears to be modifying "a large portion of all transactions."

2) You don't have to make it to a majority, you only have to propagate your
transaction to the miner who wins the next block prior to the original
broadcaster propagating their transaction to miner of the next block. This is
really easy to arrange in a P2P network by, e.g., controlling more nodes than
the original party or by e.g. modifying the standard Bitcoin client to not
sleep between attempts to propagate transactions or by e.g. communicating
preferentially with nodes known to be controlled by or "close to" miners and
not bothering to propagate to the 99.X% of nodes which are not.

If you control thousands of nodes, which you can trivially do ("rent a
botnet"), you will ROFLstomp the propagation capabilities of most people
originating transactions.

The ease of creating extra nodes is why Satoshi designed Bitcoin as "One CPU
one vote" (for a transaction's correctness) rather than "One IP one vote."
Unfortunately, it appears that Satoshi did not anticipate that the transaction
_hash_ is, effectively, the latter. That wouldn't be problematic except
systems which interface with Bitcoin frequently rely on the transaction hash
being stable but it is, in effect, written on water for the first hour or so.

~~~
lockes5hadow
Satoshi did anticipate that DDoS would be a major problem for BitCoin, which
is essentially what this is.

------
patio11
I tried to explain the issue with change on Twitter earlier and got a few
Bitcoin advocates hot under the collar, but here it is:

Say you receive 10 Bitcoin as, I don't know, your salary. You then spend 0.01
Bitcoin on a sandwitch, leaving you with 9.99 in change. Because you cannot
safely spend change until after the sandwitch transaction is fixed in the
block chain, this freezes your 9.99 remaining Bitcoin for about an hour.
They're still yours, you just can't spend them.

If you hypothetically try to spend one after 10 minutes (maybe you need to, I
don't know, pay rent or do something people routinely do with actual money),
you have two options:

1) If your counterparty is on the ball, they'll say "Nope, you don't have a
single Bitcoin to your name right now." (You know you do, but he can't prove
it, as 100% of your Bitcoin are currently in flight rather than being in
accounts demonstrably under your control.)

2) If your counterparty is not on the ball, two outcomes:

a) If your sandwich transaction is mutated and the mutated version makes it
onto the block chain first, or if it is mutated and the mutated version loses
the race to be confirmed _but_ the confirmation of your original transaction
happens on a block that doesn't end up in the block chain due to
reorganization [+], then your rent payment _fails_. Your counterparty will
discover later that they don't have the money that they expected, even if they
watched you send it.

b) If everything goes right, your transaction succeeds, and your counterparty
does not realize that you just paid your rent with the Bitcoin equivalent of
"The check's in the mail! Honest!" This continues happily until the check is,
well, not in the mail.

Bitcoin is currently undergoing active attack, causing many transactions by
people who don't understand the inner workings of the system to fail. This
attack is capable of disrupting (a portion of) transactions worldwide on
Bitcoin for about a few tens or hundred dollars a day in botnet renting cost
and could be coded by a CS102 student, if you told them where to look and what
to do.

[+] "What?" Glad you asked. See, the fundamental theory of Bitcoin is that
miners throw immense amounts of hashing power to create "blocks" in a
sequence. Each block references the last block. Each block also encodes
transactions. However, everyone is racing to discover the N+1 block after N is
released, so there can actually be multiple N+1 blocks. Only one of them will
eventually win. (Bitcoin breaks ties based on height, so if N+1 #1 gets
another block concatenated to it before N+1 #2, then it is much more likely to
be the block which actually matters. #2 vanishes from consensus history,
_along with all of the transactions inside of it_. That normally isn't a
problem if you just rebroadcast your transaction, but if N+1 #2 had "your"
transaction and #1 won with the mutated version of your transaction, then the
transaction which you actually made is suddenly, _retroactively_ , different
from the one you think you made.)

The reason everyone keeps talking about "roughly an hour" is because blocks
happen at plus or minus every ten minutes, and after N+6 blocks, it is
vanishingly unlikely that a transaction in block N will be removed from
history by block N being replaced by a totally new chain. You could, for lower
risk transactions, count it as "Probably good enough!" after N+2, as long as
you're OK with occasionally having your transactions retroactively vanish.

~~~
jimrandomh
The key thing here is that this is strictly about what happens to transactions
which don't have confirmations yet. The standard recommendation has always
been to wait an hour (6 confirmations) before crediting someone as having sent
you Bitcoins, and doing so is an absolute defense against all the shenanigans
being talked about.

~~~
Xylakant
> The standard recommendation has always been to wait an hour (6
> confirmations) before crediting someone as having sent you Bitcoin

Seriously, how should Bitcoin replace real money if that remains true? There's
a book store round the corner accepting bitcoin - so I go, select a book, pay
and hang around an hour until I get to leave with the book? At least I'd have
enough reading material...

~~~
patio11
The Bitcoin community has two answers to this:

#1: "Well if you buy a book with a credit card, the bookstore has no guarantee
that that charge actually settles successfully."

#2: "Most people won't use Bitcoin directly. They'll keep their Bitcoin with a
trusted provider. The trusted provider can verify capability to pay as quickly
as a SQL transaction, via any mechanism mutually acceptable to it and the
bookstore, which need not involve the blockchain. Providers which routinely
allow their customers to steal from other members of the ecosystem won't be
trusted for very long, and be forced to transact through the blockchain versus
being being extended instantaneous credit."

The response to #2 is typically "We could call those providers 'banks'" and
the Bitcoin community is, how shall I put this, divided by how much they like
that outcome.

~~~
simias
#2 seems reasonable but #1 isn't, if the card payment is accepted I'm sure the
bookstore has some kind of a guarantee? Otherwise I expect the fraud would be
overwhelming. Although that might just be a difference between the USA and
Europe, I never quite understood this concept of credit cards in the USA.

And regarding the creation of banks for bitcoin I find it interesting that we
keep coming back towards old and tried solutions. As a bystander it's pretty
educative, I feel I've learned quite a lot about how money works (or doesn't
work) in all those bitcoin threads we've had lately.

~~~
patio11
This is why credit cards are, I kid you not, one of the crowning achievements
of the 20th century: there _is no guarantee_ and _they still work_. Even
before we had constant-on connections which could phone home and verify with a
database, possession of plastic which looked mostly cardlike was Good Enough
(TM) to suggest that a bank trusted a bank trusted a bank trusted you to make
good on your debts, and accordingly the hotel/restaurant/bookstore/etc should
grant you services immediately on the assumption that you'll settle up as
promised and not attempt to cheat them.

The best guarantee you get when you run a card in the US is "As of the current
instant in time, that card is valid and has sufficient credit on it to cover
the amount you just charged", but that is very far from a guarantee that the
charge will actually be settled without incident. But it's still good enough.

(And if you're scandalized by this, ask me about checks!)

~~~
sp332
To be specific, credit card companies put the bulk of the risk on the
merchant. If someone steals your card and buys a book, the credit card company
will reimburse you and (most likely) not pay the bookstore. They set up the
incentives this way because customers are more likely to use their card when
they are protected, but stores can't afford not to accept credit cards.

~~~
cpach
The risk might be on the merchant, but the premium will of course be paid by
the consumers.

~~~
conception
Don't forget, merchants also pay a premium in their fees for every
transaction.

~~~
samworm
Which is paid by everyone, even people that settle their transaction in case.
I use a cash-back credit-card and effectively my fellow shoppers are
subsidising my purchases, because we're all collectively paying the card fees
which I'm getting a rev-share on. CCs are a deeply weird model.

------
ChristianMarks
Interesting. I have been "receiving" .00001 BTC from an address beginning with
1Enjoy (1Enjoy1C4bYBr3tN4sMKxvvJDqG8NkdR4Z). This has been ongoing since Feb
10. Another .00001 BTC unconfirmed showed up from another address starting
with 1Sochi...

~~~
Zidewinder
People have speculated that this is an attempt by some attacker to correlate
ownership of older and newer addresses en masse. Some wallets give the user no
control over which address(es) are used as the source for any given payment.
When a tiny sum shows up in some old empty address still being tracked by the
wallet, those coins will eventually be sent on automatically as part of a
larger payment, alongside coins from one of the user's currently active
addresses, and suddenly the common ownership of those two addresses becomes
public record.

~~~
oscilloscope
Most wallets only have the crudest tools to prevent identity attacks like
this, such as setting a preferred address for the next payment. Frequently,
you won't even see what the inputs and outputs of a transaction will be before
it's broadcast to the network.

------
greatsuccess
Ken is amazing for providing this level of detail. Thanks dude.

