To: Gregory Maxwell <greg@xiph.org>,
	Sergio Demian Lerner <sergio.d.lerner@gmail.com>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
	<CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
	<CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
	<e86d9b29-f7dd-75da-e6c6-f55648bea104@mattcorallo.com>
	<CAKzdR-pyE2f0jdsU+QGbJQ9gMepsyS880kntE9MRvDBLG_Nchg@mail.gmail.com>
	<CAKzdR-pN0B-wjhPh3n6Jw7L6wsz9yQ=kyVX7NYx5ACZC3bg8OA@mail.gmail.com>
	<CAAS2fgQsT7c+CEfC+U9N+g-+V4s8WnQjRqDddfCKMb6+BkJ3-A@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <f4605b47-03be-7493-fa3a-19ad4def3fa8@mattcorallo.com>
Date: Tue, 9 May 2017 19:42:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <CAAS2fgQsT7c+CEfC+U9N+g-+V4s8WnQjRqDddfCKMb6+BkJ3-A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit
 Discount
Precedence: list

There is something in between throwing the SegWit goals out the window
(as Sergio seems to be advocating for) and having a higher discount
ratio (which is required for the soft fork version to be useful).

When I first started looking at the problem I very much wanted to reduce
the worst-case block size (though have come around to caring a bit less
about that thanks to all the work in FIBRE and other similar systems
over the past year or two), but rapidly realized that just reducing the
Segwit discount wasn't really the right solution here.

You might as well take the real win and reduce the cost of the input
prevout itself so that average inputs are less expensive than outputs
(which SegWit doesn't quite achieve due to the large prevout size - 40
bytes). This way you can reduce the discount, still get the SegWit goal,
and get a lower ratio between worst-case and average-case block size,
though, frankly, I'm less interested in the last one these days, at
least for reasonable parameters. If you're gonna look at hard forks,
limiting yourself to just the parameters that we can tweak in a soft
fork seems short-sighted, at beast.

Matt

On 05/09/17 19:30, Gregory Maxwell wrote:
> On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
>> block size is the same.
> 
> And the UTXO bloat potential is twice as large and the cost of that
> UTXO bloat is significantly reduced.  So you're basically gutting the
> most of the gain from weight, making something incompatible, etc.
> 
> I'm not sure what to explain-- even that page on segwit.org explains
> that the values are selected to balance worst case costs not to
> optimize one to the total exclusion of others. Raw size is not very
> relevant in the long run, but if your goal were to optimize for it
> (which it seems to be), then the limit should be pure size.
>