From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A7289F38 for ; 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 ; Sat, 19 Dec 2015 23:03:21 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id o124so76328422oia.1 for ; 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: References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> <20151217175541.GA10809@sapphire.erisian.com.au> Date: Sat, 19 Dec 2015 15:03:20 -0800 X-Google-Sender-Auth: f2a6uD3xuyw53JcVNjWBw8zblTc Message-ID: From: Dave Scotese To: Mark Friedenbach 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 , Anthony Towns 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "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
A couple observations:
  • 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 "not correct."= =C2=A0 Less concrete is my usual impression, "you're both right.&q= uot;

  • "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.=C2=A0 Of course it's a tr= ade-off (because we suffer through that extra time with the unsolved proble= m), but using (or thinking of) "kicking the can" as bad is a mist= ake.

  • Whether or not there is a massive campaign targeting <= i>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 o= ne LOC, since we want an if-then around it so it doesn't happen til the= agreed date.=C2=A0 But I still support it.


On Fri, Dec 18, 2015 at 11:50 PM, M= ark Friedenbach via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:
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.

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 bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; 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 plus 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 94= B
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 t= he 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/mail= man/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev




--
I like to provide some work at no charge to pr= ove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm th= e webmaster for T= he Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante= .
"He ought to find it more profitable to play by the rules" -= Satoshi Nakamoto
--001a11407c8c1de4e7052748431c--