Quote from: DeathAndTaxes on February 23, 2015, 09:45:50 PM

Quote from: NewLiberty on February 23, 2015, 09:21:19 PM

With all due respect, contrast this limit (or any limit) with unlimited.

Nobody (well nobody with influence to make it happen) has proposed unlimited blocks. 20MB is just as finite as 1MB and so is 1GB.

Quote

It does indeed prevent spam attacks.

No it limits the severity of the damage that such an attack can cause. It provides an upper limit not a prevention. Many corporate wire account have an upper limit on the value of wire's that can be sent in one day. That doesn't prevent a fraudulent wire transfer but it does prevent the most the company could lose due to such fraud. The bean counters at a company will impose a limit that balances the needs of the company vs the loss the company could face. If the upper bound of the loss is less than what would cripple the company than no single compromise could bring down the company. The block limit is the same thing. It is saying "worst case scenario, how much damage are we talking about?". How much is a good question to ask but you have to be asking the right question. The question of what limit prevents spam is the wrong question but the limit doesn't prevent spam.

We disagree and here's where.
It is the difference between preventing spam and preventing a spam attack.

Take your example of wire transfers. If initiating a wire transfer cost less to the initiator than it does in process-costs to the institution effecting it, and all of the counter-party institutions have to put forth some effort for no benefit and only cost, it would be similar. A competing bank could then flood another bank's wire transfer process with a very high load of transfers. There would be costs driving down all of its competition at only a tiny cost. This is what miners can do. The fees they pay to themselves cost them nothing, but EVERYONE has to store those transactions FOREVER.

The limit does nothing to prevent spam. Having a limit prevents using it for attacks on Bitcoin. You may think of it as an economic game-theory problem. If this were not a problem, then we could have unlimited blocks. In my nomenclature, that is a phase 3 solution.

Quote from: DeathAndTaxes on February 23, 2015, 09:45:50 PM

Quote

and the proposal is for 16x the current risk and x16000 over 20 years.

In nominal terms but then again in nominal terms but the cost per unit of bandwidth (and cpu time, memory, and storage as well) falls over time. I mean even 1MB blocks would have been massive 20 years ago as well when the most common form of connectivity was a 56K modem.

So the problem could expressed as both a short term and longer term problem. What is the maximum block size that could be created today without exceeding the bandwidth resources of a well connected node? If it is x and bandwidth availability per unit of cost increases by y per year, then in n years a block size of x*(1+y)^n presents no more of a burden than a block size of x today.

For the record I think Gavin's proposal is too aggressive. It uses Moore's law but bandwidth has trailed moore's law. A 20% YOY increase more closely resembles bandwidth availability over the last 20 years. Also 20MB as "x" is pretty aggressive as well. So something like 11MB * 1.2^n gets us to the same place (~16B) in 50 years instead of 20 and with a higher confidence that bandwidth requirements will grow slower than bandwidth availability. Still I got a little off track no matter what limit is adopted it doesn't prevent spam. Economics and relaying rules prevent spam.

Yeah, I remember when 1200 baud was a good thing. Gavin started with Moore's law but has now hewed closer to Neilson's law (which exhibits the slower growth you describe).

From my reading of him, he expects to rely on miners to continue to use lower limits. I do not trust this reliance so much. There are very real threat models when you start to consider the self interests of both Bitcoin economic interests, as well as non-Bitcoin economic interests. If you think "its not possible because logistics/economics/practicalities...read just a few more paragraphs.

I don't generally like discussing threat vectors in public forums. Bad people sometimes get ideas and do stupid things. CitizenFour let us know that there aren't really any private forums anyhow so...
One of the other effects that doesn't get discussed is that this could very viably open up new service models for miners. They may do some sort of bulk package where some transaction initiator pays for unlimited transactions and fills every block a miner can win. The marginal cost to the miner is the orphan cost... but if this were also done with all the other miners, that marginal cost is quite low. In this way all the block space could be bought for a de-minimus amount of fiat, and it would be in each one of the miner's interests to do so.

So if you imagine that there may be some fiat-based entity that feels an existential threat looming from Bitcoin and would just love to strangle it in its cradle... Bad people could do bad things with a too-large limit. This is just a small sample of what an evil mind may contemplate. This is something that should have careful handling. Queueing up some transactions and filling some blocks with some transaction bidding is also quite bad, but not the end of the world.

FWIW: I don't think developers are slacking, but I do consider there are vast competing initiatives, and furthermore laziness is a sort of programming virtue. Getting computers to do things with the minimum code is a very good thing. This is a realm where Gavin is especially good. His code is thin and tight.