From: Mark Friedenbach <mark@friedenbach.org>
To: "sickpig@gmail.com" <sickpig@gmail.com>
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
Date: Sat, 19 Dec 2015 15:50:41 +0800 [thread overview]
Message-ID: <CAOG=w-tO+QCtobd=pJe_0DTNi53svKkqMY2DMO7a8x53tT0+9w@mail.gmail.com> (raw)
In-Reply-To: <CA+c4Zoxp91rpcKFqs_FJD_o1e6QzUH0Hk+jm1r9ZVsL4so_VHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
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ón wrote:
>> > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
>> > > equivalent to the 2-4-8 "compromise" proposal [...]
>> > isn't SegWit gain ~75%? hence 2mb x 1.75 = 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 = 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 = 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=148 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 = 800kB of base data plus 800kB of witness data,
>> where 800kB+800kB/4=1MB), 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 = 3.6
>
> Is it right?
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3978 bytes --]
next prev parent reply other threads:[~2015-12-19 7:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
2015-12-16 20:50 ` Matt Corallo
2015-12-16 21:51 ` Jameson Lopp
2015-12-16 22:29 ` Matt Corallo
2015-12-16 22:32 ` Matt Corallo
2015-12-17 2:21 ` Jeff Garzik
2015-12-17 2:44 ` Eric Lombrozo
2015-12-17 2:58 ` Jeff Garzik
2015-12-17 3:48 ` Adam Back
2015-12-17 5:32 ` jl2012
2015-12-17 7:54 ` Corey Haddad
2015-12-17 13:09 ` Jorge Timón
2015-12-17 15:51 ` sickpig
2015-12-17 17:55 ` Anthony Towns
2015-12-18 10:01 ` sickpig
2015-12-19 7:50 ` Mark Friedenbach [this message]
2015-12-19 23:03 ` Dave Scotese
2015-12-17 9:33 ` Mark Friedenbach
2015-12-17 10:00 ` jl2012
2015-12-17 10:57 ` Anthony Towns
2015-12-17 6:14 ` Marcel Jamin
2015-12-16 20:59 ` Pieter Wuille
2015-12-16 21:27 ` Jeff Garzik
2015-12-16 21:36 ` Pieter Wuille
2015-12-16 22:09 ` Jeff Garzik
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik
2015-12-17 18:46 ` jl2012
2015-12-17 18:52 ` Jeff Garzik
2015-12-17 21:18 ` Eric Lombrozo
2015-12-17 21:31 ` Adam Back
2015-12-17 3:52 ` Anthony Towns
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='CAOG=w-tO+QCtobd=pJe_0DTNi53svKkqMY2DMO7a8x53tT0+9w@mail.gmail.com' \
--to=mark@friedenbach.org \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=sickpig@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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