1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 35967C4D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 17:55:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C757411D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 17:55:47 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
id 1a9cmH-0001aQ-7Y for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 03:55:46 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 18 Dec 2015 03:55:41 +1000
Date: Fri, 18 Dec 2015 03:55:41 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151217175541.GA10809@sapphire.erisian.com.au>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+c4Zow4qnhQZFgaY-hOJA4LUtuM_rb1xRbMAOD7gW3i2KzB9A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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: Thu, 17 Dec 2015 17:55:48 -0000
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.
Cheers,
aj
|
