Quote from: Holliday on February 17, 2017, 09:30:35 PM

Just recently, in a different thread, PeterR pointed out that he had his BU node set to accept 16 MB blocks today!

I'm guessing he was referring to the EB parameter - Excessive Block - which is the limit at which your BU node will provisionally (i.e., up to the AD - Acceptance Depth) accept as a provisionally admissible blockchain tip. For reasons (heh), BU defaults that parameter to 16MB. However, it is just a GUI setting to change it. I have mine set to 2MB.

Quote

I'm of the opinion that if you build it, they will come, meaning it will not take long for those blocks to be full of no-fee-paying transactions, for whatever purpose someone happens to come up with. If that would be the case, there is no way my home internet could possibly do much more than a few connections at a time.

I understand that concern. However, I think we will never again see an era of miners accepting zero-fee transactions as they have done in the past. Bear in mind that each additional byte that a miner includes in a block is a real cost to that miner, in the form of a larger probability of his block (if indeed that miner solves that round) being orphaned. Bigger block, more likely to be orphaned. This is where some of us believe the proper market forces should operate to set block size - not some central planning edict from the devs.

Quote

I, personally, believe this would lead to a lot of people to refuse incoming connections entirely. If a Bitcoin fanatic like myself can't afford to run a full (non-gimped) node, well there will probably be a steep drop in available nodes. I don't think this is the direction we want to be going at this point in the experiment.

I understand that too. Indeed, all things being equal, more nodes is better than less nodes. Couple of points to consider:

- BU does not necessarily lead to larger blocks. I believe it likely will, but it may not. What it does is make it easy for each user to signal his preferences and set his limits. Inasmuch as Bitcoin operates _at_all_ because it harnesses the interests of its participants to 'do right', we believe the participants are the correct parties to determine the maxblocksize.

- The SegWit Omnibus Changeset allows 4MB blocks as well. Perhaps you do not support The SegWit Omnibus Changeset either, but it does bear mentioning.

- In the meantime, Bitcoin -- at 1MB blocks -- is hard-capped at ~250,000 transactions per day. Period. The consequences of this could rationally be argued to be constraining new entrants into the system. (Indeed, I would say it is obvious that it does, but grant that others may have a differing opinion.) The pool of node operators is a self-selected subset of Bitcoiners. If we prevent new Bitcoiners from entering the system, the potential population from which node operators are selected cannot grow. Many of us think it likely that some percentage of new entrants will start up nodes. So increasing block size may actually result in more operational full nodes.

Quote

It's obvious to me that increasing the traffic required to keep the network running does harm decentralization to some degree.

As stated immediately above, I don't believe that is a foregone conclusion.

Quote

Quote from: jbreher on February 17, 2017, 08:53:02 PM

IOW: I can keep it up longer than you can hold your breath. Certainly long enough to resolve the current scaling solution impasse, AAR.

You mean the impasse that is 3-4 years old now? Heh, a lot can happen in that amount of time.

Yes, that's the one. Years ago, I shouted down bitcoin disbelievers telling them that 'of course the block size will be increased by the time they get full'. I didn't dream that there would be others who would resist this idea. Mea culpa.