path: root/67/25e1dc44f97cf9dd455c2e7e2fdd91339ab642

Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A7289F38
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 19 Dec 2015 23:03:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com
	[209.85.218.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6DB9AA9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 19 Dec 2015 23:03:21 +0000 (UTC)
Received: by mail-oi0-f41.google.com with SMTP id o124so76328422oia.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 19 Dec 2015 15:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=4HdjSKjKpOnAP3j9cDcJ0RT4LGK3c2hJxTcBLvKGPT0=;
	b=LoojSigHQ+p3a8DtR6offZ5zANYQ/xDHmlMe4X34BVMxzcDIr26nPyjbnJ3Mvn4iwC
	prpJHUD/F+FkjUn7zLkrS7HT9++Q5fncFzuivQ8IFU3nhfVtyr0HeQ1uJJZ2CT7Ge8zi
	1HWb9Xq5Y7BuCx9GhscoTjQ2FqhOLOrIfvKPJEKYztj3hiBTWVYxTf5qMo9lxQsCtazD
	7tCy67fSvsoHJ0uJLlQsEUEO3Sig08C7adr+wz4gEUc2Yhzjjm9xQZUhzgRGNHXZZTzO
	9KtWz9ZbnvM06l7nii0dmA/MGLJx2z5rsDL5WFCF1/68OVRr6WLHCjdbMcdT6TlTKZpI
	xcUQ==
MIME-Version: 1.0
X-Received: by 10.202.227.199 with SMTP id a190mr3938780oih.35.1450566200712; 
	Sat, 19 Dec 2015 15:03:20 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.135.101 with HTTP; Sat, 19 Dec 2015 15:03:20 -0800 (PST)
In-Reply-To: <CAOG=w-tO+QCtobd=pJe_0DTNi53svKkqMY2DMO7a8x53tT0+9w@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
	<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
	<CAK_HAC-QmFiQGePpPH7n7qV-A4mkQdsWmgwA__mc1GBkTa6oFA@mail.gmail.com>
	<CABm2gDp+UFua=ZqzDFhZ7F6MeLbc_fBv13WYcpttSP1Lyy1ngg@mail.gmail.com>
	<CA+c4Zow4qnhQZFgaY-hOJA4LUtuM_rb1xRbMAOD7gW3i2KzB9A@mail.gmail.com>
	<20151217175541.GA10809@sapphire.erisian.com.au>
	<CA+c4Zoxp91rpcKFqs_FJD_o1e6QzUH0Hk+jm1r9ZVsL4so_VHA@mail.gmail.com>
	<CAOG=w-tO+QCtobd=pJe_0DTNi53svKkqMY2DMO7a8x53tT0+9w@mail.gmail.com>
Date: Sat, 19 Dec 2015 15:03:20 -0800
X-Google-Sender-Auth: f2a6uD3xuyw53JcVNjWBw8zblTc
Message-ID: <CAGLBAhei-TobR5qkFKpdMGfj7dA8Jaiy1etLvVM7_=cymyiQkQ@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a11407c8c1de4e7052748431c
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
	Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Dec 2015 23:03:22 -0000

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

A couple observations:

   - The consensus block limit is different than the disk space required to
   do validation.  Some participants are worried about one and some about t=
he
   other, and sometimes they feel what amounts to an imaginary contention
   because they perceive these two different things as the same.  They are
   both addressed by scaling solutions, but to different degrees.  This is =
the
   most concrete I can get about my impression whenever someone writes "not
   correct."  Less concrete is my usual impression, "you're both right."

   - "Kicking the can" has value, but no one has connected the value to the
   phrase, so here it is: The more time we have to make changes, the better
   the changes will be.  Of course it's a trade-off (because we suffer thro=
ugh
   that extra time with the unsolved problem), but using (or thinking of)
   "kicking the can" as bad is a mistake.

   - Whether or not there is a massive campaign targeting *current
   bitcoiners* has a very strong effect on upgrade rates.

It seems that a hardfork to a 2MB limit on 5/5/16 is a tad more than one
LOC, since we want an if-then around it so it doesn't happen til the agreed
date.  But I still support it.

On Fri, Dec 18, 2015 at 11:50 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not entirely correct, no. Edge cases also matter. Segwit is described as
> 4MB because that is the largest possible combined block size that can be
> constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you
> have to be confident that an 8MB relay size would be acceptable, even if =
a
> block full of actual transactions would be closer to 3.5MB.
>
> On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Anthony,
>>
>>
>> On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev
>>> wrote:
>>> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Tim=C3=B3n wrote:
>>> > > Unless I'm missing something, 2 mb x4 =3D 8mb, so bip102 + SW is
>>> already
>>> > > equivalent to the 2-4-8 "compromise" proposal [...]
>>> > isn't SegWit gain ~75%? hence 2mb x 1.75 =3D 3.5.
>>>
>>> Segwit as proposed gives a 75% *discount* to witness data with the
>>> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
>>> of 650kB of base block data plus 1.4MB of witness data; where 650kB +
>>> 1.4MB/4 =3D 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plu=
s
>>> 2.8MB of witness, for 1.3MB+2.8MB/4 =3D 2MB at a 2MB limit.
>>>
>>> > 4x is theoric gain you get in case of 2-2 multisig txs.
>>>
>>> With segregated witness, 2-2 multisig transactions are made up of 94B
>>> of base data, plus about 214B of witness data; discounting the witness
>>> data by 75% gives 94+214/4=3D148 bytes. That compares to about 301B for
>>> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
>>> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
>>> to get the numbers above.
>>>
>>> You get further improvements with, eg, 3-of-3 multisig, but to get
>>> the full, theoretical 4x gain you'd need a fairly degenerate looking
>>> transaction.
>>>
>>> Pay to public key hash with segwit lets you move about half the
>>> transaction data into the witness, giving about a 1.6x improvement by
>>> my count (eg 1.6MB =3D 800kB of base data plus 800kB of witness data,
>>> where 800kB+800kB/4=3D1MB), so I think a gain of between 1.6 and 2.0 is
>>> a reasonable expectation to have for the proposed segwit scheme overall=
.
>>>
>>>
>> many thanks for the explanation.
>>
>> so it should be fair to say that BIP 102 + SW would bring a gain between
>> 2*1.6 and 2*2.
>>
>> Just for the sake of simplicity if we take the middle of the interval we
>> could say
>> that BIP102 + SW will bring us a max block (virtual) size equal to 1MB *
>> 2 * 1.8 =3D 3.6
>>
>> Is it right?
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


--=20
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

<div dir=3D"ltr">A couple observations:<br><ul><li>The consensus block limi=
t is different than the disk space required to do validation.=C2=A0 Some pa=
rticipants are worried about one and some about the other, and sometimes th=
ey feel what amounts to an imaginary contention because they perceive these=
 two different things as the same.=C2=A0 They are both addressed by scaling=
 solutions, but to different degrees.=C2=A0 This is the most concrete I can=
 get about my impression whenever someone writes &quot;not correct.&quot;=
=C2=A0 Less concrete is my usual impression, &quot;you&#39;re both right.&q=
uot;<br><br></li><li>&quot;Kicking the can&quot; has value, but no one has =
connected the value to the phrase, so here it is: The more time we have to =
make changes, the better the changes will be.=C2=A0 Of course it&#39;s a tr=
ade-off (because we suffer through that extra time with the unsolved proble=
m), but using (or thinking of) &quot;kicking the can&quot; as bad is a mist=
ake.<br><br></li><li>Whether or not there is a massive campaign targeting <=
i>current bitcoiners</i> has a very strong effect on upgrade rates.</li></u=
l><p>It seems that a hardfork to a 2MB limit on 5/5/16 is a tad more than o=
ne LOC, since we want an if-then around it so it doesn&#39;t happen til the=
 agreed date.=C2=A0 But I still support it.<br></p></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Fri, Dec 18, 2015 at 11:50 PM, M=
ark Friedenbach via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">Not entirely correct, no. Edge cases also matter. Segwit is =
described as 4MB because that is the largest possible combined block size t=
hat can be constructed. BIP 102 + segwit would allow a maximum relay of 8MB=
. So you have to be confident that an 8MB relay size would be acceptable, e=
ven if a block full of actual transactions would be closer to 3.5MB.<br></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div clas=
s=3D"h5">On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <span =
dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:=
<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div =
dir=3D"ltr">Anthony, <br><br><div class=3D"gmail_extra"><div><div><br><div =
class=3D"gmail_quote">On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bi=
tcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Dec 17, 2015 at =
04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:<br>
<span>&gt; On Thu, Dec 17, 2015 at 2:09 PM, Jorge Tim=C3=B3n wrote:<br>
&gt; &gt; Unless I&#39;m missing something, 2 mb x4 =3D 8mb, so bip102 + SW=
 is already<br>
</span>&gt; &gt; equivalent to the 2-4-8 &quot;compromise&quot; proposal [.=
..]<br>
<span>&gt; isn&#39;t SegWit gain ~75%? hence 2mb x 1.75 =3D 3.5.<br>
<br>
</span>Segwit as proposed gives a 75% *discount* to witness data with the<b=
r>
same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up<br>
of 650kB of base block data plus 1.4MB of witness data; where 650kB +<br>
1.4MB/4 =3D 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus<br=
>
2.8MB of witness, for 1.3MB+2.8MB/4 =3D 2MB at a 2MB limit.<br>
<span><br>
&gt; 4x is theoric gain you get in case of 2-2 multisig txs.<br>
<br>
</span>With segregated witness, 2-2 multisig transactions are made up of 94=
B<br>
of base data, plus about 214B of witness data; discounting the witness<br>
data by 75% gives 94+214/4=3D148 bytes. That compares to about 301B for<br>
a 2-2 multisig transaction with P2SH rather than segwit, and 301/148<br>
gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed<br>
to get the numbers above.<br>
<br>
You get further improvements with, eg, 3-of-3 multisig, but to get<br>
the full, theoretical 4x gain you&#39;d need a fairly degenerate looking<br=
>
transaction.<br>
<br>
Pay to public key hash with segwit lets you move about half the<br>
transaction data into the witness, giving about a 1.6x improvement by<br>
my count (eg 1.6MB =3D 800kB of base data plus 800kB of witness data,<br>
where 800kB+800kB/4=3D1MB), so I think a gain of between 1.6 and 2.0 is<br>
a reasonable expectation to have for the proposed segwit scheme overall.<br=
>
<br></blockquote><br></div></div></div>many thanks for the explanation. <br=
><br></div><div class=3D"gmail_extra">so it should be fair to say that BIP =
102 + SW would bring a gain between 2*1.6 and 2*2. <br></div><div class=3D"=
gmail_extra"><br>Just for the sake of simplicity if we take the middle of t=
he interval we could say <br></div><div class=3D"gmail_extra">that BIP102 +=
 SW will bring us a max block (virtual) size equal to 1MB * 2 * 1.8 =3D 3.6=
<br><br></div><div class=3D"gmail_extra">Is it right? <br></div><div class=
=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra"><br></div></div>
<br></div></div><span class=3D"">__________________________________________=
_____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr">I like to provide some work at no charge to pr=
ove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.l=
itmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.m=
emeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I&#39;m th=
e webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">T=
he Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=
=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>=
.<br>&quot;He ought to find it more profitable to play by the rules&quot; -=
 Satoshi Nakamoto</div></div>
</div>

--001a11407c8c1de4e7052748431c--