Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Gregory Maxwell <greg@xiph.org>]

On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The non-witness data weight factor should not be 4 but 2.35. The closest
> integer value is 2, which leads to a 50% witness discount.

Sergio, You've provided absolutely no information to qualify your
"should be".  It sounds like you are only measuring how much data is
witness vs non-witness while completely ignoring the relative cost of
UTXO bloat?  It's perfectly acceptable to increase the worst case in
one dimension while decreasing it in another-- and thats what segwit
does.

This sounds like a misunderstanding of what the factors should have
accomplish. The non-witness factor should be as large as possible
because the prunable witness data has little to no long term cost to
the system, no cost to lite clients, etc-- as eventually the system's
survival will require transitioning to starting from a state snapshot.
But it cannot be too large because of the hyperbolic increase in worst
case bandwidth.   Also, when starting from a state snapshot security
will require starting from an old one-- otherwise the whole system
becomes much closer to SPV security, so the cost of witness data
between there and the tip will still matter.

If I had any leaning to adjust it, it would be towards five-- not
towards even lower values.

> The Bitcoinj source code is available for anyone to review.

Where is it? (I have to say, I haven't found bitcoinj based things at
all readable but it would be worth seeing.)