Topic: B-Etiquette (Read 866 times)

You're right, I mixed two concepts here.  The client software is designed right now with a lot of flood-defense features, because it is known that the network is not hosting the volume of transactions you're talking about.  ATM, it is assumed that if there is that much traffic, it is someone trying to spam/flood the network, not legitimate users.  However, if volume legitimately increases, then surely the devs will loosen up a bit on those defenses...

I'm not entirely up to date on leading theories for dealing with massive transaction volume (i.e. if BTC were trying to replace all CC transactions), but much of it has to do with converting the standard user to lite nodes (not storing the entire blockchain, only scanning and keeping what is relevant), and only the miners/pools need to store the whole chain. 

Two ways that I'm familiar with are not particularly easy:  the blockchain could be converted into distributed storage, so that very few nodes will have to maintain the entire thing.  Alternatively, the way transactions are executed, allows for pruning of old transactions.  Individual nodes could do this without problem.  But if tx volume really gets big, even expensive nodes might not be able to handle it, and it might be necessary to reach some kind of global agreement to forget the distant past, and "lock in" the current state of the network at a given time.  This would be a major coordinated effort/problem, but if it is "solved" this could allow the network to reset the storage requirements every couple of years...

I'm sure there's other options and theories, but I haven't been following it too closely.  You might consider starting here, where you can see a well-known security researcher asking the same question.  I'm sure there's a lot of discussion on this in the forums.

I'd love to hear some "option to deal with it" as you said besides the plethora of protocol because i'm not thinking about an attack nor fake transaction but about real transactions taking place from a big network of different addresses. I gues that MTG or TH use some sort of internal db aceptance between their own users but how do such get finnaly reflected on the blockchain or they dont? Perhaps if the transaction were irrelevant for the btc network until they must leave their controled db to addreses outside their network, they are then centralized as one unique added transaction (guess this is what traderes do) risking them self as happened to MtGox to get their db vulnerated.

Why do you say the network isn't ready? What makes it to be ready? What if there is not such a "plenty of time"?

That's a topic of great debate these days.  You just described what credit card companies process perpetually, and there's no way the BTC network as it's currently implemented could handle such transaction volume.  But there's lots of options for dealing with it, and sufficient time to figure it out before it's necessary.

Until then, there's a plethora of protocol protections against this.  Most of it falls under the category of "flood defense."  Peers that transmit too much data get disconnected, transaction fees would make this very expensive, and the the tx prioritizaiton scheme does a good job of making sure legitimate transactions can get through first.

What if all of a sudden thousands of small transactions occurred daily or hourly on the BTC blockchain? Will it affect into what way the processing time for transactions and confirmations? Will the BLK data file support such amount of data? Will something collapse? Ideas?