Segwit eliminates the size limit and replaces it with a weight limit. The weight is computed so non-witness data (e.g. the above outputs) count 4x as much towards the limit as witness data (signatures). The fixes the incentives by balancing the costs of signatures vs outputs to be roughly equal. It's also how segwit achieves a capacity increase in a way which is fully backwards compatible with old nodes.
I'm really confused on this, can you clarify?
As far as I understand it, segwit does not eliminate the size limit. The size limit is still 1mb. It just adds a weight limit of 3+1=4mb. Correct?
And the witness discount is only used for relative fee prioritization, right?
So in that light, miners could easily decide they can earn more by modifying the code to prioritize transactions differently, primarily by the limit that gets hit first(probably the 1mb limit). Right?
It seems to me that the witness discount is an inherent property of the lower blocksize limit versus the higher blockweight limit. And in the decade-long persepctive, there would/should be no cost for the witness data, as that isn't the constraint the miners have to prioritize on (unless blockweight is consistently hit before blocksize). Am I confused on how this works? Does witness data weight actually count against the blocksize limit itself?
You are confused as to how it works.
Segwit actually does _eliminate_ the size limit. The weight limit is constructed in a way which is compatible with the old limit, such that pre-segwit nodes will not think their limit is violated under any condition.
There are not two distinct limits, avoiding that was a design _requirement_ because multiple limits require multidimensional optimization in mining which would be a serious computational burden and because it would make accurate fee estimation intractable. (because the fees you would need to pay would depend on the relative contention of the various limits, which depends on the compositions of the transactions in the future after you author your own.)
Weight = 3 x witness-stripped-size + size; and the limit is that the weight must be less than 4 million. Old nodes receive witness stripped blocks and so they always accept the blocks under their own limits.
(And, FWIW, this is how Bitcoin does all the calculations since 0.13-- the results are the same as the only logic when there are no segwit txn-- so the size is already gone, just witness tx are not yet in use).
Selecting transactions by highest fee per weight is the unique income maximizing solution, no other priority order can produce more fee income (+/- small knapsack boundary effects-- e.g. you might skip a higher rate input in order to fill the block more completely).
This is economically unsound and flawed. Bastiat: What is seen and what is unseen - the unseen part has not been recognised by developers who specialise in codings and not economics.
I doubt you know anything about the background and specialties of the developers. And, the stable fee behavior in the network today is a testament to Satoshi's ideas actually working here.
How, pray tell, does one validate a transaction, if one does not possess the signature data?
By validating everything else. You don't validate the new features that the transaction is using which you don't understand (but which you know you don't understand)-- but they're also not relevant to you.
Are we to follow The SegWit Omnibus Changeset with a recommendation for each user to hold all their Bitcoin on a single address? Privacy be damned?
Segwit provides absolutely no pressure to use fewer addresses for your managing your own coins.
I did not say that The SegWit Omnibush Changeset creates new pressure to use fewer addresses. I merely point out that any benefit to UTXO set size of The SegWit Omnibus Changeset is marginal at best.
I think you need to reread your own message you claim that segwit recomemnds each user hold all their Bitcoin in a single address, and I pointed out that segwit creates no benefit for a typical user to do that. You presented no argument that the UTXO benefit is marginal.
Yes, '1' is a variable. However, there is indeed a neutral option. And it is '1'. Because what is being paid for is space on the chain, in the form of bytes contained in a transaction.
Space on the chain is not relevant to the operating costs of nodes today and will be increasingly irrelevant to the operating costs in the future. If the system has fees related to irrelevant imaginary costs instead of actual costs its capacity will necessarily be much lower.
Or does your position not include an implication that Lightning is the step-function scalability jump that is enabled by The SegWit Omnibus Changeset?
Lightning isn't "enabled" by segwit (and not that lightning was proposed long before Segwit) other than the fact that flaws in the protocol make it exceptionally difficult to write correct and safe automatic transaction processing software, so lightning implementations have based their work so far on using segwit.