Why does there need to be a limit on amount of transactions?

[phillipsjk]

So there are a couple scenarios:
a) limit totally removed from code. unlimited block size. Tomorrow a miner could produce a 80GB block if they desired to

Really? If the 1 MB limit was lifted right now via a simultaneous upgrade of the entire network, what would actually happen if a miner tried to produce a 80 GB block 10 minutes from now?

Assuming the outputs can't be spent (remember, this was an evil miner doing this): 80GB must be stored forever. To put that in perspective, I was hopping to buy an 80GB SSD for my full node, and simply upgrade as the block-chain gets too large. I was hoping that would be on the order of a year or more, not 10 minutes

Edit: since 80GB would take a long time for most nodes to download, such a large block may actually get orphaned because it does not propagate fast enough.

[1715042594]

1715042594

[TalkingAntColony]

I think from an economic standpoint, it makes sense to scale block size based on Tx fees. For example, at each difficulty adjustment, calculate average Tx fees in a block over all blocks since last adjustment, and scale block size based on that. That way, the extra cost to miners of storing larger blocks is made up by larger Tx fees. When competition for block space increases and people start paying more in Tx fees, the block size scales accordingly. This of course opens an attack vector where a miner mines many blocks himself, collecting his own Tx fees, to raise or lower the block size artificially. Also the equation to calculate block size from average block fees would still be an arbitrary/magic component.

[justusranvier]

Edit: since 80GB would take a long time for most nodes to download, such a large block may actually get orphaned because it does not propagate fast enough.

Unless the miner controls a majority of hashing power such that his chain will always have the largest accumulated work, a block that large in today's network is guaranteed to be orphaned.

Even without a hard cap on block size 80 GB blocks will not be possible until the majority of mining nodes have sufficient bandwidth to move that much data in a timely fashion.

[franky1]

and now reveals why bitcoin mainstreaming wont happen anytime soon.

1. starbucks does more then 7 transactions a second.. add on the transactions of walmart.. instantly with just 2 major retailers bitcoin cannot cope.

The federal wire network processes about $1.6 quadrillion USD worth of transactions annually and it works out to roughly 7tps.  Not saying the cap can't be raised but the idea that all economic transactions must be on blockchain or bitcoin "fails" is a dubious binary distinction.  It is also possible the limit will be raised but there still will be a limit (as opposed to unlimited block size).
thats because walmart/starbucks dont take out the pennies instantly from individual customers, their bank  puts it together into batch and says eg "bank a: we require a total of $50,000- here is a list of transactions from the accounts." which then from the banking NETWORK appears as 1 large transaction, where as that is a whole days trade of many customers. leaving bank A to then internally off the network remove balances from the individual accounts.

2. buying a $1 loaf of bread with a visa card would cost the customer $1 and the retailer would get 99c. with bitcoin he would only get 93c.. why?

Actually VISA routinely charges $0.30 PLUS 2% so that retailer selling a loaf of bread (not sure what bread is only $1) would get ~$0.68.
in the UK merchants use to be charged 50p(75c) but now that has been reduced to just a small percentage. also in the UK i can buy a loaf of bread for 70p($1) i just converted the amounts to dollars to ease and please the main population of this forum (the yanks) for laymans understanding
 The 0.0001 (it was lowered in 0.8.2) min tx fee is just to avoid spam.  
the 0.0001 is a minimal fee, but miners add on their bits and if anyone that has done lots of small transactions soon finds trying to combine all the dust in the 'change' address costs more to recombine (large data size)
The market will decide the price of fast confirmations.  Also low value tx could be processed off blockchain so the merchant potentially could end up more.
totally agree, i have posted in different threads that for a vending machine/starbucks model to work there would need to be a pre-payment / debit/loyalty card type system, which then makes starbucks think why would it need to be bitcoins when they can start up their own off the chain balance ledger

3. as bitcoins fiat value increases gavin andressens ignore dust feature will also add more costs onto small transactions.

There is no ignore dust rule, there is a DON'T ALLOW CREATION OF NEW DUST.  Of course the "rule" has a default value one that smart miners will decrease over time.  Newever versions of the client will almost certainly adjust the default value for nodes which don't override the default as well.  I would point out the min tx fee (for low priority txs) was initially 0.01 BTC that was lowered to 0.001 BTC, 0.0005, and now finally 0.0001 as the value of a BTC has risen.  

so if you want to buy a drink, sandwich or coffee at a vending machine. don't look at bitcoin for your solution.

Maybe?  Bitcoin is an experiment in progress.  It may be that:
a) you can use on blockchain tx for these transactions but merchants would prefer (and thus offer a discount) if you use off-blockchain txs for. hmm sounds like what amazon coin is.
b) you end up using an alt-coin backed by Bitcoin specifically designed for high volume low value transactions.  Bitcoin remains used for larger transfers of value.if fiat is legal currency and bitcoin is not "required" for the transaction. then amazon coin will remain pegged to FIAT not bitcoin, the only difference is an ability to buy amazon coins using bitcoin
c) you can't economically use a crypto-currency for these types of transactions and Bitcoin still becomes the worlds largest value transfer network in the history of the human race.

[caveden]

Personally I think a is impossible and has a lot of unintended consequences.  It would allow centralization through bloat.  Eventually a handful of companies would be the only ones with enough resources to run a full node.  This can be done by intentionally mining massive amounts of data to push the full node requirements (think TB per day of storage, the need for 24/7 high bandwidth low latency links, and 128GB of RAM) to kill off existing full nodes.  Eventually this cartel of full nodes could gain enough power to require governmental approval to add new full nodes (we will call this a charter) and the ability to charge users for access through their node.  Many users will deposit their coins directly at these full nodes.  Congratulations you just invented banking.

Really? Even you buy this story that without central planning we'll get an "evil cartel"?

You're very active in this forum so you're probably aware that miners could set their own soft limits to block sizes, and only accept a block beyond such limit if it's "deep enough" (that being whatever they want). This feature could be coded in bitcoind with some values by default, as the transaction fee policy, making it very easy for miners to perform such decentralized block size control.
So, how could this "centralization by bloat" actually happen?

Don't forget that the probability of being orphaned increases if you create extremely large blocks - even if we ignore the chance of hitting some soft limits, chance that we should not ignore. Just look at the examples we see today. I've heard some pools were voluntarily censoring SD just to avoid the extra propagation time.
Oh, and don't forget either that you generate storage costs for yourself too if you start bloating the chain.

Certain costs and risks in exchange of a hypothetical possibility to kick out a few pool operators with limited bandwidth? No way.
Actually, DDoSers have unfortunately already done much more damage than this hypothetical risk you claim could possibly do... many pool operators have to hide themselves behind DDoS resistant ISPs already, which means large bandwidth. And that doesn't seem to be creating any "unbreakable evil cartel". It's not that difficult to start a pool today.
You should check Hearn's calculations on bandwidth costs and bandwidth demands for running a full node, they are somewhere in this forum I think. You won't ever need millions of dollars to run full nodes. A few thousands per year would be enough, even with Visa-like volumes. That's far from being an insurmountable barrier of entry capable of protecting "evil cartels".

I'm with Gavin and Mike Hearn on this one: there's no reason for a hard limit. Even if such catastrophic scenario you describe ever materialize (it won't), it wouldn't be difficult to fix it by just going back and adding some limits.

[caveden]

Edit: since 80GB would take a long time for most nodes to download, such a large block may actually get orphaned because it does not propagate fast enough.

Unless the miner controls a majority of hashing power such that his chain will always have the largest accumulated work, a block that large in today's network is guaranteed to be orphaned.

Even without a hard cap on block size 80 GB blocks will not be possible until the majority of mining nodes have sufficient bandwidth to move that much data in a timely fashion.

Not only it would not propagate in time, but even if it did, it'd likely hit everybody's soft limits so everybody would just ignore this block and keep building on top of the previous one.

[TangibleCryptography]

caveden I think you misunderstood I wasn't talking about miners but full nodes.  

Right now today there are x nodes.

If the average block size increased to 10MB the cost of those nodes (who receive no revenue) would increase.  It is likely the number of full nodes would thus decrease leading to an increased amount of centralization.
Now what if the average block size is 20MB, 50MB, 300MB, 1GB?  

I wasn't talking about miners.  Miners are already highly centralized.  I was talking about independent full nodes which the network requires a large number to operate effectively.  As the block size increases the (uncompensated) cost on those full nodes increases and the % of participants in the system running a full node (and thus paying the full cost) will decline in favor of SPV and other lite solution (which are "free").   If eventually the network handles 100,000 tps but the demands on a full node are so high that only the largest of the largest of companies operating in massive datacenters can run a full node then you might as well call those "full nodes" .... banks.  As the network grows those established large entities have an incentive to encourage more growth as it acts as a barrier to entry against smaller participants.  Barriers to entry = higher profits it is both rational for entities to attempt this and realistic to expect it.

The idea that miners would soft fork blocks which are "too big" is equally disturbing.  First of all it is unlikely it would work.  Nobody is going to make a block larger than what all but the tiniest fraction of miners says it "too big".  If 10% of miners say they will soft fork blocks over 5MB only an idiot miner would make a block larger than 5MB.  You are taking a 10% orphan chance by making the block even a few bytes over the limit.  Another element is that Bitcoin works on the concept (at least in theory) that miners are independent actors.  If various miners will soft fork at various levels you have created a disincentive to remain independent.  You NEED to know what all your peer miners are doing.  We shouldn't be building a system where independent miners (the desired state) is at a disadvantage to miners in coordination.  Lastly if various miners do have differing soft for levels than an attacker can exploit that to degrade the effective hashrate of the network.  This would open the network to a 51% style attack with less than 51% of hashpower.  What matters is effective haspower (i.e. hashpower applied to the longest chain).  If miner X has a soft fork level of x MB and miner y has a soft fork level of y then by planting various blocks of differing size the attacker could fragment the good miners into working on competing chains.  Anytime miners are on multiple chains the network is only as strong as the hashpower on the chain with the most hashpower.  Note miner in this case is the entity (pool for most hashers) that is making the strategic decision of what chain to extend and what tx to include.  Hash processors aren't truly miners in that they are already following an authority (the pool server).

[amincd]

Even at 100,000 tps, small companies could afford to run full nodes.

[justusranvier]

I wasn't talking about miners.  Miners are already highly centralized.  I was talking about independent full nodes which the network requires to operate effectively.  As the block size increases the (uncompensated) cost on those full nodes increases and the % of participants running a full node will decline.   If eventually the network handles 100,000 tps but the demands on a full node are so high that only the largest of the largest of companies operating in massive datacenters can run a full node then you might as well call those "full nodes" .... banks.

The current implementation of the P2P network is not particularly efficient in terms of bandwidth usage and storage requirements. There's a lot that can be (and is being) done to improve this and also as more businesses of all sizes become dependent on Bitcoin they'll have an incentives to operate full nodes and to promote the development needed to reduce the resources needed to run them.

[TangibleCryptography]

Even at 100,000 tps, small companies could afford to run full nodes.

I never said that that nobody could run a full node. Although 100,000 tps with 16 peers would require ~5 Gbps of bandwidth.  I doubt most small businesses could afford that type of server costs.  Even if they "could" the cost to run a SPV is "free" by comparison so you WILL see less full nodes than say a network capable of "only" 1,000 tps.

[kokojie]

Yes, but the longer we wait, the harder it's going to become to gather overwhelming support. You think the average joe is going to care about this?

The average Joe will just see "There is a update available for your Bitcoin Wallet" and just install it. I would rather worry that this will make nefarious changes easier.

The average Joe is not running a qt client.

[amincd]

Small companies can afford that. This assumes 16 peers, where I think the average is now 8, bandwidth not getting cheaper, and SPV clients not paying full nodes microamounts for transaction data.

[justusranvier]

This assumes 16 peers, where I think the average is now 8, bandwidth not getting cheaper, and SPV clients not paying full nodes microamounts for transaction data.

And that there will continue to be a difference in security between SPV and "full" nodes.

[vokain]

You'd think with all this processing power we could harness it a -bit- more efficiently

[johnyj]

Have OP watched this: http://www.youtube.com/watch?v=cZp7UGgBR0I  

This is always a political and economic discussion instead of a technical one. In one word: Scarcity create value, aboundant destroy value, as a currency you want it to have highest value possible, so transaction capacity should be scarce, people will adjust their behavior accordingly

VISA is transferring inflative fiat money for the purpose of spending, people will always spend inflative currency at the first place, so even bitcoin's network are capable of handle huge amount of transaction per second, it still will seldom be used to buy milk everyday

[jdbtracker]

so in the end the 1mb limit is a factor in the evolution of the Bitcoin ecosystem.

We want as many people as possible to participate as possible with as little access as they have, so little bandwidth needed for a node to be run on a cell phone or a computer with a dial up connection, even making it effective to run over TOR or a mesh network effectively.

Maybe this limit creates better compression protocols for the transactions in the future? making them smaller squeezing more transactions into a block: Turning the average T from .36kb to .10 kb much easier for the network to send and increasing over all speed as well.

It can also bring the issue forward about the status of the network, giving it time for high speed mesh networks to be built or vpn corridors to be assembled, targeting nodes with high speed internet offers, etc. have you guys heard of hyperboria? that can be a solution as well free internet access to bypass the cost of running a node.

The economic aspects of the Bitcoin experiment could be enhanced by the limit as people begin to saturate not only the block chain limit but the 24 hour cycle so that no one without a fee can squeeze in, transaction acceptance by market decision, that aspect of the experiment is still left to be truly observed. The limit after all is 400,000 transaction per day, or 144,000 if we consider all the bloat from dust transactions. I do like satoshi dice by the way, that may be another target for optimisation

who knows how else a discussed and debated limit can create change.

What other limits does Bitcoin have?

[amincd]

Have OP watched this: http://www.youtube.com/watch?v=cZp7UGgBR0I  

This is always a political and economic discussion instead of a technical one. In one word: Scarcity create value, aboundant destroy value, as a currency you want it to have highest value possible, so transaction capacity should be scarce, people will adjust their behavior accordingly

VISA is transferring inflative fiat money for the purpose of spending, people will always spend inflative currency at the first place, so even bitcoin's network are capable of handle huge amount of transaction per second, it still will seldom be used to buy milk everyday

Scarcity only matters to the extent that it contributes to value. The value of the currency comes from the demand to supply ratio. Demand will be limited if transactions are limited. The supply is 21 million BTC regardless of how many transactions are allowed, so more transactions = more demand for each unit of BTC.

And that there will continue to be a difference in security between SPV and "full" nodes.

Exactly.

[justusranvier]

I just thought of another reason to keep the block size limited.

Perhaps it's true that without a protocol limit the blockchain would grow to the point that even the most well funded datacenters would find that keeping the entire history all the way back to the Genesis Block was unfeasible.

That by itself wouldn't be a problem for Bitcoin - the only essential data in the blockchain is the UTXO set, plus enough recent history to handle a reorg event. If the blockchain got too large too quickly it would grow to a point at which pruning becomes essential and nobody is able to keep a permanent record of every transaction that has ever happened since 2009.

That would be wonderful for privacy and could be implemented with a negligible reduction in network security. I can understand why some people would be opposed to that.

[bg002h]

If Bitcoin is to achieve mass adoption, the protocol will need to be handle way more than 7 tps. This change would be better performed sooner rather than later. The userbase is growing, and it will only become increasingly difficult to get everyone to update to the latest client with time.

You can't simply change the client.  The existing protocol is incompatible with a larger blocksize.  Period.  You can't force that protocol to cease to exist.  Today we call that protocol Bitcoin.  The only option is a hard fork, an incompatible version of the protocol but that means the existing protocol still exists as well.  Essentially two incompatible Bitcoins.   The only viable solution is before making a hard fork you have such overwhelming support that a super super super majority of all users (not just miners but merchants, exchanges, service providers, full nodes, and active users) switch that the old fork dies off.  If you don't one of two things will happen:
a) most people won't leave and your forked Bitcoin will just die off
OR
b) both forks gain significant backing and people end up with differing wealth of both chains.  Both "camps" have a vested interest in their chain surviving so you end up with chaos.  Two Bitcoins both calling themselves Bitcoin but completely incompatible to each other.  (Yes this is the bad news scenario which is why hard forks should never be considered trivial changes).

We did just hard fork a few days ago...not sure many noticed   It _can_ be done relatively seamlessly.

[bg002h]

Can the client not be updated now (or soon) to handle more TPS and larger block sizes but not yet create them?  Leave this change in place until needed - 1 or 2 years.  Then when miners actually implement larger block sizes most people will already have a client that can deal with it.

Yes...that's more or less what satoshi suggested.