Thank you!  Finally, someone who understands!

Indeed.  If the block propagation can remove the transaction data, and simply expect all mining clients to already have that data in their queue; then the actual block transmitted can be reduced to the 80 byte header and the myrkel hash tree.  That should make the 6 second baseline trivial for any common broadband connection well into the future.

No, because it only addresses the effects of one variable resource, thus assuming that all other variables would remain either static or significantly independent from the effects of this variable so as to be ignored.  This might be a valid assumption, but I cannot accept that as a given.  The core purpose of economic analysis is to be able to predict the effects of changes to all the variables, not just those you assume are dominant.  The unseen is usually of greater net effect on the outcome than the seen.

It's been a while, but IIRC, the soft limit only counts fee paying transactions.  I certainly could be wrong about that, but if not, a block with an actual size over 250KB is possible without violating the soft limit.  Any such propagation rule would have to consider the blocksize in the same manner, and perhaps also add a fudge factor.

That's very similar to what I proposed earlier, except the relay delay would be infinity.

<sigh>

What if those big miners also had that same soft limit rule?  The mining pools of BTCGuild, 50BTC and Slush still collectively represent over 50% of the mining power of the bitcoin network, the rise of ASICs notwithstanding.  While it's true that small miners can leverage their bandwidth best by directly connecting to these three mining pools.  So, do these three mining pools have an economic incentive to disregard the community will and exceed the soft limit?  On the one hand, yes; for they stand to gain more transaction fees just as you guys presume.  On the other hand, no, for they depend upon their membership for that hashing power; and it's that hashing power that creates the other incentives to begin with.  All three pools depend upon their good reputations with their membership in order to dominate.  If even a minority of their membership disagreed with the owners of the pools exceeding the soft limits without the community's overall consent, the pools will suffer hashrate loss.  Thus, all three of these pools actually have a greater incentive to participate in the convention set by the community, and resist any players that would not abide.  They are, in fact, most likely among nodes to impose such a propagation rule upon their own systems; partly because of they control a large percentage of the mining power.

In fact, I would here propose that, at the same time that we are raising the soft limit to 500KB, we also ask these major mining pools to include my soft limit propagation rule.  Just these three alone would make such a rule quite effective.

Then comment upon it now, for you are working on an erroneous understanding of my proposal and it's implications.


That is a static view, and not one that is supportable.  With each smaller increment, the percentage of marginal miners forced out would be smaller than otherwise, and thus the likelyhood that they would be able to return as both their own local infrastructure and the average infrastructure improves.  The limits exist for several reasons, not the least of which is artificial scarcity, but we still have to balance the future against the present.  Even without my proposed propagation rule, I'm pretty sure that the 250KB limit has never been broken to date.  Why is that?  Do you presume that it's only because there are not enough transactions to justify it to the miners?  I would think that part of it is that the soft limit is an agreed upon rule, to be exceeded once that has been agreed upon also.  My rule would only add a bit of risk to ignoring this rule that doesn't presently exist.  I don't doubt that, eventually, some miners are going to test the soft limit.  I want some of those tests to fail.


That's conjecture.  Show me why you believe that this is so, not just your assumptions about what the future holds using overly simplified mental models.  Thus far you have failed to present an argument for this perspective.  I'm not even willing to claim that it's incorrect, only that it remains unsupported.  Can you really not imagine any other incentives that would contradict the "logical conclusion" you have come to?I can think of at least three.


Only someone who assumes that only a hard limit is actually the only limiting factor.  Again, we've already bumped up against the 250KB soft limit on several occasions; and amazingly, none of the miners have chosen to comment out that line of code.  Obviously there is some kind of cost to the miners for doing so, or a presumption of a cost, that would exceed the benefits to the miner for doing so.  One such cost is simply the work involved in commenting out that line of code and recompiling their mining programs over a relatively few number of tiny transaction fees.  That condition is bound to change, certainly.  This does not mean that miners will start to ignore the soft limit.  It is a community convention that, while not presently enforceble by the running protocol, is still enforceable by the community.  If some miner actually did this prior to the community deciding to raise that soft limit, the offender would prompt some kind of response.  What kind of response, I won't hazard a guess; but those miners certainly don't desire to prompt the community to include rules more strict than what I'm proposing.  It's not in the interest of the miners to invoke a response.

Don't be a dick.  I read your posts.  I believe that I understood them, but apparently you didn't understand my arguments.  The soft limit is a voluntary limit at present, but there are things that can be done to disincentive miners from attempting to break that limit when it suits them.  Did you not understand what I was trying to communicate concerning adding a 'soft limit' propagation rule to the clients?  Truly harmless to the network and the client, and only somewhat damaging to the miner, unless a significant enough of a minority of clients participate in this rule, and the miner with an overlarge block ends up with an orphaned block as a direct result.  It doesn't have to work every time, just enough for the miners to notice.

Well then, the way that he is presenting it becomes a strawman argument.  Could you show me why this is inevitable?  Are there really no other factors?  Does an increase in resource demands not also incentivize the bandwidth starved mining operation to invest in better infrastructure?  This is over simple, and does not consider that the infrastructure itself is not static.  There are also other resource factors to be considered, which may or may not be of greater influence.  I have, for years, predicted that the city of Reykjavík, Iceland will one day become a center of the Bitcoin mining industry; for the simple reason that they have both relatively low electric rates (due to the blessings of geothermal power) and a very high domestic heating demand.  This has not yet come to pass, but it's not because Reykjavík has substandard international bandwidth connections, because that's not so.

Granted.

Upon further consideration, I think that this might be a great way to move the soft limit, but I still think we need to have a (much higher) hard limit.  For the reasons that I stated before, and others, a hard limit removes many of the incentives for big players to engage in anti-competitive activities; since it puts a very real limit to the long term effectiveness of such underhanded methods.

No, not everyone is free to mine gold.  One must have physical access to the land, and the ability (legal and physical) to tear up the landscape.  This is not true for at least 80% of the population of the Earth.

This is such a contrived situation that I have to reject it as a strawman argument.

Interesting, an intergrated voting method.  I can't say which direction that I'd consider it more likely that most miners would prefer, which is a good sign that it's a viable solution.  However, I don't know that I'd agree that a 1% change per difficulty adjustment is going to be enough.  After all, there will only be roughly 26 such adjustments in one year.  Taking into account the compounding of prior adjustments, off of the top of my head I'd guess that it's not possible for the blocksize to increase by more than 35% in one calender year.  And only then if all the vote adjustments move in the same direction.  I'd say a better number would be 5% per adjustment if the vote was a supermajority (i.e. 80% of votes in one direction) or 2.5% (or so) for a simple majority.  This would, at least, make it possible for the blocksize to double in a calender year, even if it doesn't make such an outcome likely.

And practically speaking, most people would like to be able to use their broadband connection for other things.  Offically, my cable service is a 10Mbit/sec connection, but practically I can't sustain more than 1.5Mbps to any single IP address.  If I let my bittorrent client full access, it peaks around 1.5Mbps but averages about half that.  Your bandwidth needs are further complicated by the fact that once you have downloaded and verified a block, you're expected to then upload that block to your connected peers.  Since most broadband connections are half as fast uphill, this limits your connected peer's download to half of what you're offically capable of.  In conclusion, anything beyond a 1MB limit is too resource intensive for the at-home full client to be able to keep up with at present, but with the advancements in Internet tech and infrastructure, we can assume that an at home connection would be able to manage a 10-20 MB block within a decade.  We would want to aim for the hard limit to be at least this high, while continuing to depend upon soft limits in the meantime.


International bandwidth is much more complicated than this, with respect to a p2p network such as Bitcoin.  Much like bittorrent, the bandwidth for Singapore is functionally replicated for all of the Bitcoin clients in all of Singapore, so it's not true that the international connection is divided among the many peers all trying to download the same block, it's effectively shared data as if there were a locally available seed on Bittorrent.  Granted, it's not the same as saying that all of Singapore could be regarded as one node, and then the block replicates across the entire nation-state from one copy; but once one copy of the block has made it across the bottleneck, the local bandwidth effectively becomes the limiting factor to propagation.

I remember the same complaint from some people when Craigslist was new.

It's not about the pretties, it's about the content.  And these sites are very much targeted to a worldwide, but mostly English reading, customer base.  There are way too many websites these days that functionally require either a broadband connection or an image filtering system just so that they can be navigated.

I have broadband, but I still miss the "load images" button that early Netscape browsers had.  I don't doubt that a great many end users, particularly those in nations werein broadband is still rare and bandwidth usage is metered, very much appreciate the low-bandwidth nature of many Bitcoin related sites.

Simplicity.  The number of really old accounts with less than 5 posts would be really small.

Pretty much.  Talk like a human, though.  The main goal is to catch spambots before they make it into the main forum, which makes their presence both more annoying and more difficult to clean out.

Dude!  I've had that dream!  Air was thin at the corners.

No, I'm not saying that I actually reject an otherwise valid block, because it's bigger than I like.  That would certainly force a hard fork.  I'm saying that, as a client, I have a rule that does not forward blocks over my chosen limit to my other peers. If I'm alone, or otherwise in the minority on the issue, I've caused zero harm to anyone while managing to save myself some bandwidth.  However, if any significant minority of the total number of full clients that participate in the network, whether or not they mine themselves, also adopt this rule; the effective result is that this creates a delay in the propagation of overlarge blocks, effectively granting a bandwidth advantage to miners who choose to stay within the soft limit.  Thus, miners who create blocks over the limit effectively have their hashrate handicapped by delays in propagation.  As for myself, even if the block is overlarge, if it passes the standard "hard" block validity rules, it still does not get rejected from my own blockchain, as that would prevent myself from participating in the network in the event that said overlarge block is still the one that is built upon.  I'm doing nothing with my soft limit rule other than choosing not to forward the block.  

My highlighted sentence above implies that as the bandwidth requirements increase for full nodes, someone is going to implement something functionally similar anyway, in order to save bandwidth.  Worse would be for some programmer to take the easy route, and simply modify the code so that a full client quietly never forwards a valid block to it's peers, and it's peers never notice.

No, I haven't.  You don't even know that I dropped your block.  I can participate as a node just fine, just not as a miner.  It's a balance of forces.