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  >  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). >  Same as , 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  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  -> 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  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 _______________________________________________ bitcoin-dev mailing list email@example.com https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev