MIME-Version: 1.0
In-Reply-To: <7B918396-5968-4908-83C8-0F77DA8DB037@xbt.hk>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
	<CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
	<CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
	<7B918396-5968-4908-83C8-0F77DA8DB037@xbt.hk>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Tue, 9 May 2017 13:19:13 -0300
Message-ID: <CAKzdR-rKQaiKF18j44HjxuHY5pcmPwsce5ab-+zGRDnxjhBQdw@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=001a113a6592d8b69e054f19b92f
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit
	Discount
Precedence: list

--001a113a6592d8b69e054f19b92f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Johnson and Hampus for the clarifications.
However, I would rather do the opposite: soft-fork to 50% now, and
soft-fork again to 75% discount later if needed, because it doesn't affect
the max transactions/second.

Segwit as it is today should be activated. However if it is not before
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.


On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2012@xbt.hk> wrote:

>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >
> > So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This
> is not a bad idea, as it's the only direction Bitcoin can scale without a
> HF.
> > But it's a bad idea if we end up doing, for example, a 2X blocksize
> increase HF in the future. In that case it's much better to use a 50%
> witness discount, and do not make scaling risky by making the worse case
> block size 8 Mbytes, when it could have been 2*2.7=3D5.4 Mbytes.
> >
>
> As we could change any parameter in a hardfork, I don=E2=80=99t think thi=
s has any
> relation with the current BIP141 proposal. We could just use 75% in a
> softfork, and change that to a different value (or completely redefine th=
e
> definition of weight) with a hardfork later.
>
>
>

--001a113a6592d8b69e054f19b92f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks Johnson and Hampus for the clarifications.=C2=A0<di=
v>However, I would rather do the opposite: soft-fork to 50% now, and soft-f=
ork again to 75% discount later if needed, because it doesn&#39;t affect th=
e max transactions/second.=C2=A0<div><br></div><div>Segwit as it is today s=
hould be activated. However if it is not before November, then for the next=
 Segwit attempt I would choose a more conservative 50% discount.</div><div>=
<div><br></div><div><div><br></div></div></div></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Tue, May 9, 2017 at 12:45 PM, =
Johnson Lau <span dir=3D"ltr">&lt;<a href=3D"mailto:jl2012@xbt.hk" target=
=3D"_blank">jl2012@xbt.hk</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D""><br>
&gt; On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr=
>linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; So it seems the 75% discount has been chosen with the idea that in the=
 future the current transaction pattern will shift towards multisigs. This =
is not a bad idea, as it&#39;s the only direction Bitcoin can scale without=
 a HF.<br>
&gt; But it&#39;s a bad idea if we end up doing, for example, a 2X blocksiz=
e increase HF in the future. In that case it&#39;s much better to use a 50%=
 witness discount, and do not make scaling risky by making the worse case b=
lock size 8 Mbytes, when it could have been 2*2.7=3D5.4 Mbytes.<br>
&gt;<br>
<br>
</span>As we could change any parameter in a hardfork, I don=E2=80=99t thin=
k this has any relation with the current BIP141 proposal. We could just use=
 75% in a softfork, and change that to a different value (or completely red=
efine the definition of weight) with a hardfork later.<br>
<br>
<br>
</blockquote></div><br></div>

--001a113a6592d8b69e054f19b92f--