The miners don't set the fee directly.  Essentially there is a dual auction; users bid up, while miners work down.

Users set the fee in each of their transactions often/mostly relying on automation to calculate it.  Even if every miner set a high minimum fee, if every user set their fees below that then eventually some miner would break rank in order to earn the lower fees.  But some users want a faster confirmation and so they set a higher fee.

Organizing users to act in unison to keep fees low seems unlikely.  Some users will break rank and use a slightly higher fee in order to get their transaction done quicker.  The users bid up the fees; the miners just take it happily.  The miners work down the fees; if the users united they could keep fees low.

Btw, I recently set a fee to 0 and it only took 11 days to confirm; Bitfury did it.  Your mileage may vary.  Past performance is not a reliable indicator of future behavior.  Be prepared to recover if your no-fee transaction doesn't ever commit.

One word; hurry.

Oh, and also, hire a good public relations team.

This is way off point but just to pick nits; Since there is only one fixed size block header then the ratio of transactions to block size does scale even in your definition although granted it is a tiny amount and not worthy of this mighty discussion.

I think we misunderstand each other because we are using a different definitions of scaling.

Recognizing this will help future discussions.

What is the term you prefer to use for changing the rate of processing?

It changes the rate of processing.

Seriously? Clearly we have a difference in definitions.  I am not talking about taking the scales off of a fish here.  I'm talking about the term scaling where we are talking about the processing rate changing.  An increase in the processing rate is positive scaling.  A decrease in the processing rate is negative scaling.  Scaling can be linear or non-linear.  Linear scaling simply means that we get a 1:1 change in the processing rate as we vary some parameter.  How are you using the term scaling?

Today we are pumping somewhere between 2-7 transactions per second through into blocks on average.  Anything that changes that rate ability is a scaling factor.  If the block size limit were increased from 1MB to 2MB then we would see roughly twice that number flowing through.  That's pretty much scaling in my book.  Even if it were sub-linear so that we got only 3-8 transactions per second through on average, that's still scaling up.  Yes, it would grow the size of the block chain faster but something has to give until a superior algorithm is deployed.

Block size limit changes have way more than nothing to do with scaling the transaction rate through.  If it has nothing to do with it then decreasing the limit wouldn't hurt, right?

Improving the algorithm is often/always? the better way to go but while we're waiting it is not unreasonable to tweak parameters.

True enough; a gigantic block size limit does not necessarily lead to negative scaling but it does make it possible.  If the block size limit is constrained to something reasonable then we can safely avoid negative scaling at the risk of building a backlog.

Obviously there are two transaction rates;

1) the rate at which transactions are presented to the system by users
2) the rate at which transactions are booked into blocks.

These are related over time -- if the first rate exceeds the second for a long enough period of time then a backlog will grow; queueing theory 101.  Try driving on a highway during rush hour.

Increasing the current block size of 1MB to say 2MB would roughly allow twice as many transactions to be booked into blocks thereby increasing the second rate.  Naturally we'd have to constrain the size of individual transactions to avoid problems with them.  Miners that don't fill a block up are missing out on fees.

Negative scaling just refers to a situation where increasing a resource/parameter decreases the processing rate.  In the case of Bitcoin, there is a block size which is "too" big.  A block that is too big would lead to some processing problem, e.g. excessive page faulting, etc., and so the second rate would actually drop lower.

What's to stop them from invading the HF?

Scaling, in general, is a complex topic.  To thoroughly examine all aspects of the scaling of Bitcoin would involve a lot of work.

Often improving/replacing an algorithm can provide much more improvement than any other activity.  I always applaud/encourage/support efforts in this direction but realize they can take substantial time/investment especially as compared to just tweaking parameters.

If instead we try holding the algorithms pretty still (for now) while adjusting resources then maybe at least some progress can be made.

In terms of transaction rate (as opposed to any other measure), surely, at first, there would be some positive scaling (linear or not) increasing the current 1MB block size a little bit but eventually (as we continue to increase the size of the block) there could be/would be negative scaling.  Is anyone thinking/saying that a small block size increase would immediately *reduce* the transaction rate?  Does anyone think/say that a gigantic enough block won't lead to negative scaling?

Dismissing a reasonable amount of block size increase because gigantic enough blocks will scale negatively is misguided.

To me it seems like a pretty obvious tactic to cap the size of individual transactions to something like 1MB while increasing the block size.  Someone wanting a bigger transaction can just launch two or more transactions to effectively get the same work done.  Question: under SegWit are transaction sizes capped?

Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

Hmm, if I switch later (sometime after Flag Day = June 14, 2017) to a 0.13.1 or higher version then will my node catchup on all of the witness data blocks?

If I were to run a 0.13.1 or higher version and then downgrade (not sure why, just thinking out loud) then would my full node be ok or would it get confused by the witness data blocks?  Hmm, is downgrading a risky behavior?  Ah, or would downgrading safely involve starting from scratch (in terms of the whole blockchain)?

Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate?  Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

So, my full node (no matter what version I'm running) will see these SW blocks; will they be ok?  Hmm, do SW blocks come in two flavors?  One with the witness data and one without?  Which will my full node get?  If a block with witness data is delivered couldn't it be bigger than 1MB?

Btw, the non-Core camps could embrace SegWit (or is FlexTran their choice instead?) to compromise, right?

I'm truly sorry to be so thick about this but I truly want to try to understand.

Which is the more desirable outcome; one currency or two?  If two then finish the war and split off already -- I know, I know, who gets to claim the legacy.  If one then a compromise (no matter how dangerous, etc.) will have to be entered; hurry.  Given human nature (righteousness) I have lost confidence in this approach.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?

Frankly, I'm surprised someone doesn't make a >1MB block and ignite this.  What's keeping them from doing it?  Good behavior?  I can't do it; I don't command enough hashing power.

Is *anyone* making blocks >1MB right now?  Where would one go to see such?

Man, you guys are killing me.  Ok, so, I shutdown my Core version of Bitcoin and downloaded/installed the BU version.  I will switch back if I want to.

https://coin.dance/blocks is the place to watch the drama?

I am not happy.  I want the two camps to come together.  This might be impossible given human nature but it is what I want.

Love that word "nonplussed".

I can't remember exactly where (somewhere in this forum for sure; getting too old) but I saw something about neither SW nor BU gaining enough "votes" and so Bitcoin would just plod along as it is (I could easily have misunderstood).  From there I speculated that neither camp would be content and so they would both hard fork into new altcoins.

It probably isn't safe/reasonable for me to speculated thusly; it's kinda like letting kids play with matches.

Why does Core automatically get to keep the legacy?  Why does BU have to fork off?

I think, if it is even functionally possible, we might end up with three coins;

1) Bitcoin as it is running right now with no significant development team to love it at first
2) Bitcoin-SW as envisioned by the "Core" development team
3) Bitcoin-BU ...

One thing I know for sure; I will continue to run my own full node (which variant I need to think about).  If SW does indeed soft fork then I will need to remain vigilant and either move my non-SW-UXTO to SW-UXTO (it's too early for that, right?) or move it to the -BU coin (how is that done or am I confused?).  I don't want to lose my investment.  All this debating/fighting is undermining my confidence.  Maybe I should punt it all over to ETH (although I may have missed the majority of the run up already but at least maybe I could hold value there).  Otherwise maybe I should just take my profits back to the fiat world (yuk).