From: Matt Corallo <lf-lists@mattcorallo•com>
To: Gregory Maxwell <greg@xiph•org>,
Sergio Demian Lerner <sergio.d.lerner@gmail•com>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit Discount
Date: Tue, 9 May 2017 19:42:56 +0000 [thread overview]
Message-ID: <f4605b47-03be-7493-fa3a-19ad4def3fa8@mattcorallo.com> (raw)
In-Reply-To: <CAAS2fgQsT7c+CEfC+U9N+g-+V4s8WnQjRqDddfCKMb6+BkJ3-A@mail.gmail.com>
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.
>
next prev parent reply other threads:[~2017-05-09 19:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-08 22:42 Sergio Demian Lerner
2017-05-08 23:47 ` Alphonse Pace
2017-05-09 13:49 ` Sergio Demian Lerner
2017-05-09 14:33 ` James Hilliard
2017-05-09 15:45 ` Johnson Lau
2017-05-09 16:19 ` Sergio Demian Lerner
2017-05-09 16:27 ` Johnson Lau
2017-05-09 16:27 ` James Hilliard
2017-05-09 18:15 ` Matt Corallo
2017-05-09 18:58 ` Sergio Demian Lerner
2017-05-09 19:15 ` Sergio Demian Lerner
2017-05-09 19:30 ` Gregory Maxwell
2017-05-09 19:42 ` Matt Corallo [this message]
2017-05-09 20:13 ` Gregory Maxwell
2017-05-09 20:58 ` Sergio Demian Lerner
2017-05-10 5:37 ` Jorge Timón
2017-05-10 14:05 ` Matt Corallo
2017-05-10 15:25 ` Sergio Demian Lerner
2017-05-10 16:39 ` Matt Corallo
2017-05-10 19:40 ` Sergio Demian Lerner
2017-05-08 23:56 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4605b47-03be-7493-fa3a-19ad4def3fa8@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
--cc=sergio.d.lerner@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox