Bitcoin transaction malleability: looking at the bytes

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.

Also, with the difficulty increasing, block are going to be rarer and you'll have to wait way longer to get a confirmation right?

And what if 3 guys find the same block, at the same time, at 3 very different places in the world? Can't imagine what would happen.

At least as long as people aren't using the selfish mining strategy.

If one or more large pools were doing selfish mining, you might see long parallel chains with some regularity.

I agree that the current system of address management is impractical for some applications.

It should be possible to automatically organize addresses in a way that small amounts are sent from addresses that also have small balances, so that this problem does not occur. Your salary payment provider could split up the payment into 9 + 10 * 0.1 Bitcoin.

But it will take a while until the concept and the UI is there.

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

A minor nitpick: you can demonstrate the accounts are under your control, just not via a "normal" bitcoin transaction.

#1: What if your client kept your bitcoins spliced over several addresses ? So, each address kept just 10 BTC. Now, when you make a 99BTC transaction, you use up 10 addresses and 1 BTC change gets tied up for further confirmation. (adjust the numbers as convenient of course)

Thus, you basically can't spend your change until 6 confirmations but now it's far lesser than the 9.99 you surmised.

#2: (this one's better!) Or what if you just kept 10 separate addresses and used 1 at a time manually ? You'll tie up 1 address for up to an hour but the likelihood of making 10 transactions an hour is fairly low, and if you did want to do that, you could still split and proceed.

Entropy for BTC addresses is fairly high and each person on the planet can have far more than 10 so this is a non-issue in terms of availability.

Clients could manage these scenarios fairly easily if unconfirmed inputs/outputs were indeed to become a limiting factor.

edit: To clarify, once the mutated transaction is on the blockchain even once, the wallet should be able to figure out what the correct transaction is now. True, when it's not on the blockchain at all, the transaction can get rejected.

It's just the risk of third-party mutation, as under the current mischief-making malleability attack, plus the compounded risk created by chains of unconfirmed-transactions, that makes this a problem.

Long before the current attacks, I had my own outgoing payments stuck when they were inadvertently arranged as a dependent chain, and the first transaction never confirmed.

But once you (or the people writing your software) know of such risk, mitigating workarounds are easy and automatable:

You arrange for receipts of large amounts to be broken into smaller units, capping the amount of change that might be 'in flight'. (If necessary, you do this break-up yourself upon receipt, knowing there's a period of up to an hour before that completes.)

Or more generally, you keep small working amounts of mixed-size coins ready for short-term use, simply not expecting to spend a large new receipt instantly. (No one who is living 'hand to mouth' should be relying on Bitcoin for all their life's necessities, anyway. It's still beta!)

When the third-party mutated-transactions risk is contained – within a week or two, all major miners will probably blockade tampered transactions – this risk of stuck funds will evaporate... but the lessons and new software practices for handling corner cases will persist, ready for future similar situations.

It's interesting that patio11 is using receipt-of-salary as an example. Until your bank knows you, classic paychecks can be held for a day or more before full funds are available. Until clearing-practices were changed in the US a few years ago, large paychecks often had most of their funds held as unavailable for 7-10 days – even for checks between large American banks in the same city. This situation persisted for decades.

Further, the fraud of "check-kiting", which is vaguely like the interplay-of-timing-bugs that has tricked some bitcoin-payout systems, was possible in the traditional banking system, on and off, for decades.

Compared to that, are Bitcoin's temporary problems, perhaps involving an hour's holdup, and likely fixable within a week via rapid software iteration, that big of a deal?

When patio11 makes people aware of the transient gotchas and rough-edges, so they can adjust their near-term expectations, that's a public service.

But if these things are portrayed as inherent and insurmountable weaknesses that doom the system? That viewpoint is going to look like 1995 Clifford Stoll.