public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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