Let's use market-based mechanisms to solve this putative free rider problem.

If Monero (or any altcoin) wants a monero.bitcointalk.org subdomain, its supporters must donate 10 BTC to Thermos.

That's win/win, because the altcoin gets it's own dedicated high visibility/SEO friendly subdomain, while the mothership forum gets funding at the same time as tangential content self-segregates in areas outside of the altcoin ghetto.

If we don't do this, Altcoin Jesus may take the opportunity to profit from selling more bitcoin.com subdomains, as he's already created a casino and some other goofy shit on there.

It is backwards compatible. If the current implementations that already exist chose not to use segwit, they would be fine and can continue to function. What I meant is that if those implementations want to support segwit, it is up to them to implement it in their own software without any bugs. They can follow the publicly available documents that specify the exact changes that segwit makes.

The real limits are the bandwidth, computing and memory resources of participating nodes. For the sake of argument suppose a 1 TB block was released into the network right now and we'll also assume there was no block size limit of any kind. Many nodes would likely not be able to successfully download this block in under 10-30 minutes, so there is a very good chance that other miners will have generated two blocks before this block makes its way to them.

What does this mean? The miner generating a 1 TB block knows this would happen. So in terms of economic self interest he will generate the largest possible block that he is still confident that other miners will accept and process. A miner who receives a block will also consider whether to build on it based on whether they think other miners will be able to download it. In other words, if I receive a large block I may decide not to mine on it, because I believe that the majority of mining power will not mine on it - because it is either too large for them to download or because their rules against large blocks reject it.

Ignore the obvious problem of Sybil attacks, especially those exploiting BTC's current crummy P2P code and superlinear vulnerability to maliciously construed (ie very slow to verify) blocks.

I invite you, and everyone else, to find holes and tear the above apart, always in the spirit of reaching a solution and if no holes can be found, then lets end this thing and have a reunited celebration party.

Really? How? So far what I have seen is that a new block size limit in BU takes effect immediately. There is no mechanism that does the supermajority fork process.

Unlimiturd: you may have any block size you want, so long as it's <16MB.

Am I wrong about ^this^?  If so, please advise on the actual maximum value.

The comments by testing1567 are showing up for me.

[...]

A signal can be more a less reliable, miners will analyze their environment like every intelligent human beings are able to do so.

For example :
- transactions are slow because blocksize limit is often hit + nothing suspicous in the nodes activity + a majority of nodes signals their wish to increase the blocksize => miners will choose to increase the blocksize according to the nodes
- blocks are way below the limit + suspicious nodes activity + a majority of nodes signal their wish to increase the blocksize => miners will choose to no increase the blocksize

Basically it's likely that the blocksize will only be increased when it's needed.

We have covered this 10 times in the thread now, yet we are given no answer to how you would prevent an incremental Sybil attack like brg444 posted.

Plus, the need for BU review stands regardless.

So does BU follow the longest chain or not?

If not, than it obviously can't work, as it was pointed out a million times already - everybody will fork off randomly according to their limit.

If it follows the longest chain, then your limit doesn't matter, as eventually you will have to switch (otherwise, again, you will be forked off).

Since BU can only work if it follows miners, your personal limit becomes irrelevant: if you insist on setting it, you will just hurt yourself and will still have to eventually switch if you plan to continue using Bitcoin.

This limit cannot be used as a signal to miners because of Sybil attacks, so it's pointless.

Yet BU proponents push it as the main feature of BU

Yup, I noticed that one.


Exactly! Too easy to pull off. So we are back to square one. Why choose BU when it cannot resist a simple Sybil attack.

So still not one person on the BU side is willing to tackle the faulty assumption that user defined parameters is somehow a good way to signal the economic majority's preferred blocksize to miners, making its one distinctive aspect pretty much worthless.

If it is supposed to be a "vote" then I agree with the other comments here that it is trivially sybil attackable and pointless. If it is supposed to be an anti-spam protection that avoids having your node flooded by huge blocks that the longest chain does not accept, that is not necessarily pointless. In the latter case, the miners will have to come to their own conclusions as to the "best" block size to produce, almost entirely independently of this propertied "vote" (using market research, experimentation, etc.). I agree with you that a "vote" of nodes is information, but it is almost worthless information so it should be almost entirely ignored.

I still am curious as to what the difference is besides the nodes being able to signal to the ecosystem in a slightly easier way through a GUI that they wish larger blocks. Is this it?

Nodes will then have to follow the rules ascribed by miners, and their vote is pointless as consensus is formed by those who mine. Which means, Adam will still get kicked off the network, when the winning miners decide on 2MB blocks, and Adam only accepts 1.1MB.

My initial reaction is that I don't think its a good idea to empower non-technical people with the ability to control such an important variable with a click of a button. I suppose they would be held into account by the miners and this would essentially be a node vote which would allow individual nodes to confirm larger blocks easier. The difference may not be significant as an attacker isn't going to be limited by the code and this could be a signal to allow users to vote. This change appears to me to have more political implications than anything.  

And longest chain is a rule set by nodes, correct? Meaning, that consensus is formed by the highest voting number of nodes, in this scenario, my 2000 nodes.

If we go by the standard 6 confirmations, 6 depths, then we can safely assume it will be the longest chain. So after my 2000 nodes vote for a 200MB block, I wait 1h for the longest chain to become 200MB. Or for the real paranoid, we wait 2 hours, and I am certain that the 200MB rule is enforced and that there is probably not another chain.

I then spam it with 200MB data, and thus we get 200MB blocks until someone can form a better consensus (launch more nodes with a different blocksize consensus).

All this, I can do in less than one day, and cripple the network for less than $5000.

Thank You. So if it follows the longest chain than that is exactly how bitcoin currently works , so I am amiss to what that "1%" cited  difference actually is. Any hints?