Quote from: gmaxwell on June 14, 2017, 10:54:41 PM

Quote from: jbreher on June 14, 2017, 01:58:16 PM

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.

What is this - some sort of bait and switch? You seem to be confused and conflating two separate sub-threads of this discussion. Shall we review?

You said:

Quote from: gmaxwell on June 14, 2017, 11:06:26 AM

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 seems to me that you must be referring to the so-called prunability of the signatures - no? It certainly seems to be the case from the following, because when I responded:

Quote from: jbreher on June 14, 2017, 11:51:51 AM

It 'fixes' the incentives only in cases where nodes throw away data needed for any future validations of the transactions. Whether or not this 'pruning' is a good idea is a matter of reasonable debate.

you replied with:

Quote from: gmaxwell on June 14, 2017, 12:22:50 PM

Regardless of if you prune the data or not, you don't need to access it, so it doesn't impact your working set size.

Maybe we are conflicted about what you mean by 'working set size'? When one is validating, the witness data is part of the data you are working with, right? (duh - otherwise there would be nothing to validate against). Accordingly, is it not part of the 'working set'? Are are we dealing with an arcane ephemeral definition-of-passion?

So again I ask: How, pray tell, does one validate a transaction, if one does not possess the signature data?

Quote

Quote

Quote

Quote

UTXO set size is some function of (# users) * (# of addresses holding value per user). As far as privacy is concerned, best practice dictates distributing your value across several addresses. 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.

Are you intentionally misrepresenting my position again? It is there plain as day. I asked you a question trying to get you to clarify your position, as I was somewhat incredulous that you would claim that which you seem to claim. I never claimed that "segwit recomemnds [sic] each user hold all their Bitcoin in a single address". I merely pointed out that your claim of SegWit fixing some imagined flaw in UTXO set size is marginal at best.

Let me ask you directly: Do you claim that UTXO set size is NOT some function of (# users) * (# of addresses holding value per user)?

Sorry - let me quote you directly, so I don't misrepresent you in turn. Your claim was:

Quote

Finding a way to address the UTXO incentives issue was a major sticking point and breakthrough ...

So again, with SegWit's 'way to address the UTXO incentives issue' shown to be marginal at best, where did I claim what you assert I claim?

Quote

Quote

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.

Finally something we can agree on. So why are you ~~choking the baby in the crib~~ artificially constraining transaction throughput again?

Quote

Quote

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 ...

Hey! Another thing with which I can agree! However, it is only tangentially related to my point. Let us again review, removing the portion that seems to have distracted you:

Quote from: jbreher on June 14, 2017, 01:58:16 PM

Quote

Quote

Preferential incentive for offchain transactions over onchain transactions? Myopic much?

Nothing about segwit is "preferential for offchain"-- if anything it's slightly the opposite.

I have yet to see a cogent argument which supports your case. Regardless, the challenge is to your assertion that "As to why Bitmain would complain about it, I am aware of no sensible reason."