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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
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 29274F37
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Jan 2016 09:46:27 +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 9E06579
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Jan 2016 09:46:26 +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 1aMYIQ-0004X4-U4 for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Jan 2016 19:46:25 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Fri, 22 Jan 2016 19:46:18 +1000
Date: Fri, 22 Jan 2016 19:46:18 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160122094618.GA18567@sapphire.erisian.com.au>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208024224.GA32631@sapphire.erisian.com.au>
<20151208045803.GA1042@sapphire.erisian.com.au>
<20160118120251.GA14507@sapphire.erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160118120251.GA14507@sapphire.erisian.com.au>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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] Capacity increases for the Bitcoin system.
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: Fri, 22 Jan 2016 09:46:27 -0000
On Mon, Jan 18, 2016 at 10:02:51PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think these numbers are slightly mistaken -- I was only aware of version
> 1 segwit scripts at the time, and assumed 256 bit hashes would be used
> for all segwit transaction, however version 0 segwit txns would be more
> efficient for p2pkh, with the same security as bitcoin currently has
> (which seems fine).
Latest segwit code just has version 0 witness format, and treats a 32
byte push as the sha256 of a script, and a 20 byte push as the hash of
the pub key. Also, the witness scriptPubKey format uses "OP_0 [hash]" to
push the version and hash to the script separately, rather than "[0x00
script]" or "[0x01 hash]" (this changes allows segwit transactions to
be encoded backwards compatibly as a p2sh payment).
> p2pkh:
> segwit: 10+41i+36o + 0.25*105*i [1]
> [0] 10 bytes for version (4), input count (1), output count (1) and
> locktime (4); 146 bytes per input consisting of tx hash (32), txout
> index (4), script length (1), scriptsig (signature and pubkey =
> 105), CHECKSIG = 25), and sequence number (4); 34 bytes per output
> consisting of value (8), script length (1) and scriptpubkey (DUP
> HASH160 PUSH20 EQVERIFY CHECKSIG = 25).
> [1] Same as [0], except two extra bytes per output script (segwit push
> and segwit version byte), and moving the 105 bytes of signature
> script directly into the segregated witness
So this change means segwit p2pkh needs 31 bytes per output not 36 bytes (value,
length stay the same, scriptpubkey becomes "OP_0 PUSH20" for 22 bytes
instead of 25+2 bytes). This gives another couple of percent gain, so:
segwit: 10+41i+31o + 0.25*105*i [1]
Setting i=o makes:
> p2pkh 2-of-2 msig
> now 10+180i 10+286i
> segwit 10+104i 10+140i
become:
segwit 10+99i 10+140i
and therefore,
> p2pkh 2-of-2 msig
> now 100% 100%
> segwit 166%-173% 197%-204%
becomes:
segwit 174%-181% 197%-204%
Constantly creeping up! Pretty nice.
Also, p2pkh with segwit-via-p2sh is probably interesting, those numbers
work out as:
segwit: 10+41i+31o + 0.25*105*i (for comparison)
segp2sh: 10+60i+32o + 0.25*105*i [0]
-> 10+119i
-> 147%-151%
So that still looks like a reasonable improvement even if (eg) in the
short term merchants are the only ones that upgrade, and customers just
use non-segwit-aware wallets with a p2sh address that's only redeemable
by a segwit-aware wallet.
Cheers,
aj
[0] 10 bytes standard. For each input, tx hash (32) plus index (4),
script length (1) and scriptsig which is a push of the standard segwit
pubscript (22+1) totaling to 60, and witness data is the same as for
normal segwit (105). Each output is standard p2sh, which is value
(8), length (1) and script (23) for a total of 32.
Cheers,
aj
|
