[cryptography] bitcoin scalability to high transaction rates

Marsh Ray marsh at extendedsubset.com
Thu Jul 21 17:00:36 EDT 2011


On 07/21/2011 10:41 AM, Sampo Syreeni wrote:
> HST is just an example of a mechanism which creates prodigious
> amounts of transaction data. There are others, starting simply with
> wide enough adoption of Bitcoin. So if the amount of transaction data
> being shipped around can become a bottleneck here, it could indicate
> a scalability limit on Bitcoin in more realistic situations.

That implies you suspect there may be a DoS attack against the Bitcoin
network. I've heard this sentiment stated more explicitly from others,
but haven't looked into it deeply myself.

More often than not, distributed protocols have to go through multiple
iterations of vulnerability and mitigation before they're really robust.
Bitcoin even seems to have the added challenge of nodes being actively
adversarial.

OK I can't resist a quick look at the protocol spec. Searching...

Hmmm. The page that currently "looks" the most comprehensive for the
protocol description (on en.bitcoin.it/wiki) appeals to the original
source release for its authority. Not a great sign.

The protocol has a built-in script interpreter which must run to verify
any transaction. But opcodes are being retroactively disabled! Like when
"it was found that some of the arithmetic ones could be exploited to
crash all Bitcoin nodes"
https://forum.bitcoin.org/index.php?topic=4723.msg68823#msg68823

E.g., OP_2MUL (multiply by 2) was disabled for "security reasons". (Hope
you didn't accept any coin requiring it!) But they didn't disable the
ability to add a number to itself. Will this be the next Callas
Highlander operation?

What if an attacker simply did a zero-sum exchanges of coins all day
long, seeding crafted opcodes into a percentage of the circulating
supply? Later, he could roll over his supply to "clean" coins and then
disclose the vulnerability for those now being held by everyone else.

Note that the script language includes a SHA-256 primitive opcode. What
would be even more clever would be use the parasitic computation in the
verification network as a mining cluster. Perhaps the results could be
propagated back hidden in the distributed block database.

All-in-all, this is not atypical for the evolution of a piece of network
software, but some Bitcoin proponents seem to be attaching utopian hopes
and/or hard cash value to this thing.

Are there examples of other untrusted-peer distributed protocols
maturing to become unassailably resilient for use across the wide internet?

- Marsh



More information about the cryptography mailing list