Do any alts deal with scalability better?

[notig]

I was just wondering...... with some people not wanting bitcoin to be able to scale by changing the hard block size limit do any others deal with this issue better?

[Sunny King]

Not that I know of. All altcoins have much smaller block chain than bitcoin at the moment so no one needed to tamper with the block size limit.

Think about it, without raising the block size limit of bitcoin (1MB), suppose each block is 1/4 MB (supposed limit for minimum tx fees), that means block chain will grow by 12GB annually for bitcoin. How long would a client need to wait to download a 20GB block chain? a 50GB block chain?

Personally I would worry about recycling block chain first than increasing block size limit.

[markm]

If you mean, do any alt chains already, as they are, allow much more transactions per hour than bitcoin's six blocks per hour...

...The champion is LiQuidCoin, with fixed difficulty so you can basically spew out as many blocks as you like, as fast as you like, and the more people who do that the less chance there is of any block not being orphaned, but some folks do get blocks so I guess if you spew them out faster, yet with higher actual difficulty (just because you don't have to have high difficulty to qualify doesn't mean higher isn't better), you can get into the chain.

You can spew out blocks fastest with LQC, but, it is mostly a hands on demonstration of why we don't want to flood the network or of what flooding is like.

Next up, geistgeld. Ten second targetted time between blocks. That is sixty times as many blocks as bitcoin!

I tried to fire it up again last night, I ran out of swap space and it used over 20% of my RAM, before my machine being totally lagged out caused me to kill it. But don't let that discourage you, I used to run two instances of it at once back before I added more and more other stuff to my mix of things that all run t once on my machine 24/7. Just because I couldn't add it to my mix while already merged-mining bitcoin, namecoin, devcoin, groupcoin, ixcoin, i0coin and coiledcoin doesn't mean geistgeld is untenable! I could have killed this firefox reseource-hog, and the CoffeeMUD instance that is using 28.7% of my RAM. It was definitely not geistgeld alone's fault my puny little 8 gigs of RAM, eight cores box wasn't up to adding it to the merge.

So hey, this one might be the one you're looking for! Sixty megs of blocks every ten minutes, without even touching the max block size constant.

Next up, litecoin and whichever others have two to two and a half minute target time between blocks.

Chances are no alt-chain ever messed with max block size, so basically figure all of them have one meg max block size and get more transactions done by doing more blocks faster.

-MarkM-

[Jutarul]

I was just wondering...... with some people not wanting bitcoin to be able to scale by changing the hard block size limit do any others deal with this issue better?

No. But it may be the perfect innovation point. The bitcoin consensus mechanism has these 2 properties:
- scales linear with the number of users U
- scales linear with the number of transactions per user T
thus you get a system which scales to O(U*T).

If users keep the average number of transactions low, there's still plenty of room for new users...

If a cryptocurrency implements a system which scales with O(U*log(T)) or O(log(U)*T) it would solve this dilemma. First one would be good for micro transactions, second one would be good for world wide use.

[markm]

Haha, maybe do it similar to how that newfangled way of getting past the Shannon limit with radio is done, exploiting interference so the values at each location come out right despite (actually even because of) the interference.

Hologramatic in a way even maybe?

Rate of change of balance of an account might be a similar problem to packing information into a "channel" thus admit of similar solutions to "the Shannon limit".

-MarkM-

[Sunny King]

I was just wondering...... with some people not wanting bitcoin to be able to scale by changing the hard block size limit do any others deal with this issue better?

No. But it may be the perfect innovation point. The bitcoin consensus mechanism has these 2 properties:
- scales linear with the number of users U
- scales linear with the number of transactions per user T
thus you get a system which scales to O(U*T).

If users keep the average number of transactions low, there's still plenty of room for new users...

If a cryptocurrency implements a system which scales with O(U*log(T)) or O(log(U)*T) it would solve this dilemma. First one would be good for micro transactions, second one would be good for world wide use.

Honestly this type of approach is very dangerous. At current fee level an attacker could potentially bloat bitcoin block chain by 100GB with a million dollar thrown on fees.

If bitcoin adopts such a scheme I would most likely disable it when refreshing ppcoin.

[Jutarul]

If a cryptocurrency implements a system which scales with O(U*log(T)) or O(log(U)*T) it would solve this dilemma. First one would be good for micro transactions, second one would be good for world wide use.

Honestly this type of approach is very dangerous. At current fee level an attacker could potentially bloat bitcoin block chain by 100GB with a million dollar thrown on fees.

If bitcoin adopts such a scheme I would most likely disable it when refreshing ppcoin.

Mmmm.. I am not following you. I was referring to the computational limits of the consensus mechanism, not any fee structure. Can you elaborate your concern?

[Sunny King]

Mmmm.. I am not following you. I was referring to the computational limits of the consensus mechanism, not any fee structure. Can you elaborate your concern?

I am referring to the adaptive block size limit proposals floating around lately with bitcoin. That's the OP's question about scalability, as in transaction throughput scalability. What I am more worried about is block chain size scalability, as in initial block chain download, as I believe that would hamper bitcoin's ability to scale (at least in the peer-to-peer sense).

Maybe you were talking about block chain size as well, I am not sure. Or maybe some design that doesn't store the full ledger at every node. I don't know, that would be quite a challenge to do.

[Jutarul]

I am referring to the adaptive block size limit proposals floating around lately with bitcoin. That's the OP's question about scalability, as in transaction throughput scalability. What I am more worried about is block chain size scalability, as in initial block chain download, as I believe that would hamper bitcoin's ability to scale (at least in the peer-to-peer sense).

Yes - it's a connected issue. You have
a) block updates
b) chain bootstrap

a) is the differential of b). For the "block chain size" to be scalable, any client must be able to bootstrap in a reasonable amount of time - ideally through an internet connection, i.e. the bitcoin network, since any private boot-straping exposes you to counter-party risk. So I agree with you on this issue. However, there are slow and fast internet connections. Thus one may be able to bootstrap the node on a fast connection, while maintaining the sync through a slow connection. However, it is crucial that clients are able to keep in sync with the network even with moderate internet connections (sub 1MBits).

So I'd say that b) is a weaker condition than a).

Maybe you were talking about block chain size as well, I am not sure. Or maybe some design that doesn't store the full ledger at every node. I don't know, that would be quite a challenge to do.

Yes. In fact I was talking about strategies to change the scaling behavior of the consensus model - but scoped to the client. So the whole network may still be allowed to scale with O(Users*TransactionsPerUser). But individual clients may not need to know the full state of the system. It only has to be good enough to prevent double spends - no solutions seen yet.