From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Fri, 22 Jan 2016 19:46:18 +1000 [thread overview]
Message-ID: <20160122094618.GA18567@sapphire.erisian.com.au> (raw)
In-Reply-To: <20160118120251.GA14507@sapphire.erisian.com.au>
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
next prev parent reply other threads:[~2016-01-22 9:46 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 22:02 Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08 2:42 ` Anthony Towns
2015-12-08 4:58 ` Anthony Towns
2015-12-08 5:21 ` Gregory Maxwell
2015-12-08 6:54 ` Anthony Towns
2016-01-18 12:02 ` Anthony Towns
2016-01-22 9:46 ` Anthony Towns [this message]
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14 ` Jorge Timón
2015-12-08 15:12 ` Gavin Andresen
2015-12-08 15:55 ` Justus Ranvier
2015-12-08 17:41 ` Mark Friedenbach
2015-12-08 18:43 ` Justus Ranvier
2015-12-08 19:08 ` Tier Nolan
2015-12-08 19:31 ` Gregory Maxwell
2015-12-08 23:40 ` Jonathan Toomim
2015-12-08 23:48 ` Luke Dashjr
2015-12-09 0:54 ` Jonathan Toomim
2015-12-08 23:50 ` Jorge Timón
2015-12-09 0:56 ` Jonathan Toomim
2015-12-08 23:59 ` Gregory Maxwell
2015-12-09 0:58 ` Jorge Timón
2015-12-09 1:02 ` Jorge Timón
2015-12-09 1:09 ` Gavin Andresen
2015-12-09 1:31 ` Gregory Maxwell
2015-12-09 4:44 ` Ryan Butler
2015-12-09 6:29 ` Gregory Maxwell
2015-12-09 6:36 ` Ryan Butler
2015-12-09 6:59 ` Mark Friedenbach
2015-12-09 7:17 ` Gregory Maxwell
2015-12-09 7:54 ` Jorge Timón
2015-12-09 8:03 ` Gregory Maxwell
2015-12-09 8:46 ` Mark Friedenbach
2015-12-09 11:08 ` Jorge Timón
2015-12-09 16:40 ` Gavin Andresen
2015-12-11 16:18 ` Jorge Timón
2015-12-11 16:43 ` Gavin Andresen
2015-12-12 5:13 ` digitsu
2015-12-12 15:18 ` Mark Friedenbach
2015-12-14 11:21 ` Jonathan Toomim
2015-12-14 12:44 ` Adam Back
2015-12-09 4:51 ` Anthony Towns
2015-12-09 14:51 ` Chris
[not found] ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
[not found] ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21 4:33 ` Pieter Wuille
2015-12-21 4:42 ` Justus Ranvier
2015-12-21 4:44 ` Alex Morcos
2015-12-21 4:50 ` Mark Friedenbach
2015-12-21 5:29 ` Douglas Roark
2015-12-21 5:21 ` Btc Drak
2015-12-21 8:07 ` Anthony Towns
2015-12-21 9:56 ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09 0:23 ` Gregory Maxwell
[not found] ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09 0:40 ` Jonathan Toomim
2015-12-09 12:28 Daniele Pinna
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=20160122094618.GA18567@sapphire.erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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