[cryptography] bitcoin scalability to high transaction rates

lodewijk andré de la porte lodewijkadlp at gmail.com
Thu Jul 21 18:22:35 EDT 2011


There's currently a limited amount of transactions per block, this limit can
be changed. There's certain stuff in place to give bigger transactions,
older transactions and transactions with higher fee's precedence. That
should kill the possibility to truly DoS the network, although it's possible
to get blocks filled all the time, possibly forever. It's also possible to
DoS certain nodes, although the network will not likely suffer from it.
After sifting through all of this stuff the network seems quite inherently
robust. The only thing I worry about is when the amount of transactions
become too great for any single PC to manage, since a large part of the work
is done everywhere. Then all those pc's'll have to sync up, it's a data
nightmare. The block chain('s) will likely split and merge continuously. To
mine effectively the pools[1] might be the biggest mergers.
The optimizations suggested in the original whitepaper will have to have
been implemented. Actually thinking about it it shouldn't be THAT big a
problem.

Seems that bitcoins are one of the few things that make the future seem cool
again. After my dreams of spaceflight were destroyed by understanding of
physics :P.

- Lewis

[1] - mining pools are miners (hashers/signers for the blocks) that work
together in hopes of getting a more reliable income.

2011/7/22 Marsh Ray <marsh at extendedsubset.com>

> 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<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
>
> ______________________________**_________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20110722/88eb2a92/attachment.html>


More information about the cryptography mailing list