Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E2D19CB3 for ; Mon, 18 Dec 2017 17:38:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C74B83F9 for ; Mon, 18 Dec 2017 17:38:03 +0000 (UTC) Received: by mail-pf0-f172.google.com with SMTP id p84so9967163pfd.3 for ; Mon, 18 Dec 2017 09:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=v54sgp0n6GBc3rECf1EhbdyOBD7phEXzTN4hRTPFMRs=; b=YrlqcHO11jFGg513Ur+atCILPD6gSGXOJ5u4xoFRqZzelXvL79tn2dANtsXIW5HIFM b+6scgDccfMWJhnaupRD91cfOwUYZIJlgK0ghsOYapaIIBsYuQKXI8GMoLltwF+w+K/v A5qWr8i9EVaC662zRsCZqXqCW2lAOoBnR2KELgZuXmjaaxz8UsIVE537Kn2/vcxqwUrA fLxXKALAA8uEW9deq6Ty28hlOr6/ixeY1yFmd37Q3Gj3OMB74baudWdMtt8U/uUyobx/ h1yHWcnydDZjdEIK7EVPhWPeivYjTMVEhca8jfcaP2bZAQi0p+xSi0lqwBffsNOmxHp1 5Zrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=v54sgp0n6GBc3rECf1EhbdyOBD7phEXzTN4hRTPFMRs=; b=GnoC9VOU1kdqW5JS7LpeyE/t8bmauz839JLeKUa2zYlGGLj9mqewcom3N0AsACwm2C Kr2UlZyPurX/GqUZi/Cj8AeUc1GFBsrGTdN2HbxWfaPrgf4OnWCNqtxQpQa9bJUSZnrl PF/OhUzWHyCVSJrcLJJEch2YSM9ffSI6uh/QjC0uHNlXYnY69opcym4SUAghAICeQfrJ lzOfDbWI1vaj3vufzZmUDMOnWU+qePKUsuIMm9ZqT7q7fzDNEKpBvrcO/BAJIR7GLhW6 PBgmJ2SLKeThCljfOlZkTrBY09BpKEbvVa0XtX7vAbeExVFmtTiUjkCMGeLilDu8JwzU zeNA== X-Gm-Message-State: AKGB3mIraspjDwjtCQQnUY73OWQ3W3l/TyzYxDYiV0/6klmSm+NDhhZX bPnKE+i2GowI48B4BFaPEcitJMZTf6Y= X-Google-Smtp-Source: ACJfBos/RK7K28WIerAdPK9Ps+lus+NYFEWmqzDyVz01dgACUnUwDxPsMjEQTaBQPNFSliTUBzcmvA== X-Received: by 10.101.80.138 with SMTP id r10mr404240pgp.428.1513618683291; Mon, 18 Dec 2017 09:38:03 -0800 (PST) Received: from ?IPv6:2601:646:8080:4dbb:949b:6f19:8460:3d9? ([2601:646:8080:4dbb:949b:6f19:8460:3d9]) by smtp.gmail.com with ESMTPSA id p24sm23734425pfh.170.2017.12.18.09.38.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 09:38:02 -0800 (PST) From: Mark Friedenbach Content-Type: multipart/alternative; boundary="Apple-Mail=_0DD73C35-2435-4B77-8204-99FA2158CA87" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Dec 2017 09:38:01 -0800 References: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com> To: Alberto De Luigi , Bitcoin Protocol Discussion In-Reply-To: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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] Clarification about SegWit transaction size and bech32 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:38:05 -0000 --Apple-Mail=_0DD73C35-2435-4B77-8204-99FA2158CA87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Addresses are entirely a user-interface issue. They don=E2=80=99t factor = into the bitcoin protocol at all. The bitcoin protocol doesn=E2=80=99t have addresses. It has a generic = programmable signature framework called script. Addresses are merely a = UI convention for representing common script templates. 1.. addresses = and 3=E2=80=A6 addresses have script templates that are not as optimal = as could be constructed with post-segwit assumptions. The newer bech32 = address just uses a different underlying template that achieves better = security guarantees (for pay-to-script) or lower fees (for = pay-to-pubkey-hash). But this is really a UI/UX issue. A =E2=80=9Cfork=E2=80=9D in bitcoin-like consensus systems has a very = specific meaning. Changing address formats is not a fork, soft or hard. There are many benefits to segregated witness. You may find this page = helpful: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ = > On Dec 18, 2017, at 8:40 AM, Alberto De Luigi via bitcoin-dev = wrote: >=20 > Hello guys, > I have a few questions about the SegWit tx size, I'd like to have = confirmation about the following statements. Can you correct mistakes or = inaccuracies? Thank you in advance. > =20 > In general, SegWit tx costs more than legacy tx (source = https://bitcoincore.org/en/2016/10/28/segwit-costs/ = ): > =20 > Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the = scriptPubKey, and the same number of witness bytes as P2PKH scriptSig. > Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the = scriptPubKey, and the same number of witness bytes as P2SH scriptSig. > Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due to = using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH = scriptPubKey, and the same number of witness bytes as P2PKH scriptSig. > Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to = using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig = compared to P2SH scriptPubKey, and the same number of witness bytes as = P2SH scriptSig. > =20 > But still it is convenient to adopt segwit because you move the bytes = to the blockweight part, paying smaller fee. In general, a tx with 1 = input and 1 output is about 190kb. If it's a Segwit tx, 82kb in the = non-witness part (blocksize), 108 in the witness part (blockweight). > See source: > 4 bytes version > 1 byte input count > Input > 36 bytes outpoint > 1 byte scriptSigLen (0x00) > 0 bytes scriptSig > 4 bytes sequence > 1 byte output count > 8 bytes value > 1 byte scriptPubKeyLen > 22 bytes scriptPubKey (0x0014{20-byte keyhash}) > 4 bytes locktime > = https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transact= ions-what-would-be-the-max-number-of-transaction-confi = > =20 > Which means, if you fill a block entirely with this kind of tx, you = can approximately double the capacity of the blockchain (blocksize = capped to 1mb, blockweight a little bit more than 2mb) > =20 > My concern is about segwit adoption by the exchanges.=20 > SegWit transactions cost 10bytes more than legacy transactions for = each output (vout is 256 bits instead of 160). Exchanges aggregate tx = adding many outputs, which is of course something good for bitcoin = scalability, since this way we save space and pay less fees. > But when a tx has at least 10 outputs, using segwit you don't save = space, instead: > - the total blockweight is at least 100bytes higher (10bytes x 10 = outputs), so the blockchain is heavier=20 > - you don't save space inside the blocksize, so you cannot validate = more transactions of this kind (with many outputs), nor get cheaper fee > - without cheaper fees exchanges have no incentives for segwit = adoption before they decide to adopt LN > =20 > In general we can say that using SegWit: > - you decrease the fee only for some specific kind of transactions, = and just because you move some bytes to the blockweight > - you don=E2=80=99t save space in the blockchain, on the contrary the = total weight of the blockchain increases (so it's clear to me why some = time ago Luke tweeted to not use SegWit unless really necessary... but = then it's not clear why so much haste in promoting BIP148 the 1st august = risking a split) > =20 > If it's all correct, does something change with bech32? I'm reading = bech32 allows to save about 22% of the space. Is this true for whatever = kind of tx? Immediate benefits of segwit for scalability are only with = bech32? > =20 > Bech32 is non-compatible with the entire ecosystem (you cannot receive = coins from the quasi-totality of wallets in circulation), I would say it = is a hard fork. But the bare segwit is really so different? the soft = fork is "soft" for the reference client Bitcoin Core, but outside you = cannot know what happens, there are plenty of implementations = (especially frontend customization) which don=E2=80=99t work with segwit = and need to upgrade. To upgrade takes a lot of time, especially when = services are so crowded and so many new people want to step in. At this = point, if bech32 brings only efficiency (but correct me if it=E2=80=99s = not so) and it is well planned, it could be a consensual upgrade, maybe = together with a 2x blocksize? Is there a specific plan for some upgrade = in 2018? I personally think it is far easier to reach consensus on a = blocksize increase una tantum rather than a dynamic increase. You cannot = predict the technology growth: will it be linear, exponential, or = suddenly stop for a while, maybe right before a huge innovation? I think = a hard fork bech32 upgrade + 2x could help a lot in scalability while we = test LN, and it might be the only way to effectively promote (or should = I say enforce?) SegWit adoption. > =20 > thank you, > Alberto De Luigi > (.com) > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = --Apple-Mail=_0DD73C35-2435-4B77-8204-99FA2158CA87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Addresses are entirely a user-interface issue. They don=E2=80=99= t factor into the bitcoin protocol at all.

The bitcoin protocol doesn=E2=80=99t = have addresses. It has a generic programmable signature framework called = script. Addresses are merely a UI convention for representing common = script templates. 1.. addresses and 3=E2=80=A6 addresses have script = templates that are not as optimal as could be constructed with = post-segwit assumptions. The newer bech32 address just uses a different = underlying template that achieves better security guarantees (for = pay-to-script) or lower fees (for pay-to-pubkey-hash). But this is = really a UI/UX issue.

A =E2=80=9Cfork=E2=80=9D in bitcoin-like consensus systems = has a very specific meaning. Changing address formats is not a fork, = soft or hard.

There are many benefits to segregated witness. You may find = this page helpful:

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

On Dec 18, 2017, at 8:40 AM, Alberto De Luigi = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hello guys,
I have a few questions about the SegWit tx = size, I'd like to have confirmation about the following statements. Can = you correct mistakes or inaccuracies? Thank you in advance.
 
In = general, SegWit tx costs more than legacy tx (source https://bitcoincore.org/en/2016/10/28/segwit-costs/):
 
  • Compared to P2PKH, P2WPKH uses 3 fewer bytes = (-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH = scriptSig.
  • Compared to P2SH, = P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same = number of witness bytes as P2SH scriptSig.
  • Compared to P2PKH, = P2WPKH/P2SH uses 21 additional bytes (11%), due to using 24 bytes in = scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH scriptPubKey, and = the same number of witness bytes as P2PKH scriptSig.
  • Compared to P2SH, = P2WSH/P2SH uses 35 additional bytes (19%), due to using 24 bytes in = scriptPubKey, 11 additional bytes in scriptSig compared to P2SH = scriptPubKey, and the same number of witness bytes as P2SH = scriptSig.
 
But still it is convenient to = adopt segwit because you move the bytes to the blockweight part, paying = smaller fee. In general, a tx with 1 input and 1 output is about 190kb. = If it's a Segwit tx, 82kb in the non-witness part (blocksize), 108 in = the witness part (blockweight).
See = source:
4 bytes version
1 byte input count
Input
36 = bytes outpoint
1 byte scriptSigLen = (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes value
1 byte scriptPubKeyLen
22 bytes scriptPubKey (0x0014{20-byte = keyhash})
4 bytes locktime
https://bitcoin.stackexchange.com/questions/59408/with-100-segw= it-transactions-what-would-be-the-max-number-of-transaction-confi
 
Which = means, if you fill a block entirely with this kind of tx, you can = approximately double the capacity of the blockchain (blocksize capped to = 1mb, blockweight a little bit more than 2mb)
 
My = concern is about segwit adoption by the exchanges. 
SegWit transactions cost 10bytes more than = legacy transactions for each output (vout is 256 bits instead of 160). = Exchanges aggregate tx adding many outputs, which is of course something = good for bitcoin scalability, since this way we save space and pay less = fees.
But when a tx has at least 10 = outputs, using segwit you don't save space, instead:
- the = total blockweight is at least 100bytes higher (10bytes x 10 outputs), so = the blockchain is heavier 
- you don't save space inside the blocksize, = so you cannot validate more transactions of this kind (with many = outputs), nor get cheaper fee
- = without cheaper fees exchanges have no incentives for segwit adoption = before they decide to adopt LN
 
In general we can say that = using SegWit:
- you decrease the fee only = for some specific kind of transactions, and just because you move some = bytes to the blockweight
- you = don=E2=80=99t save space in the blockchain, on the contrary the total = weight of the blockchain increases (so it's clear to me why some time = ago Luke tweeted to not use SegWit unless really necessary... but then = it's not clear why so much haste in promoting BIP148 the 1st august = risking a split)
 
If it's all correct, does = something change with bech32? I'm reading bech32 allows to save about = 22% of the space. Is this true for whatever kind of tx? Immediate = benefits of segwit for scalability are only with bech32?
 
Bech32 = is non-compatible with the entire ecosystem (you cannot receive coins = from the quasi-totality of wallets in circulation), I would say it is a = hard fork. But the bare segwit is really so different? the soft fork is = "soft" for the reference client Bitcoin Core, but outside you cannot = know what happens, there are plenty of implementations (especially = frontend customization) which don=E2=80=99t work with segwit and need to = upgrade. To upgrade takes a lot of time, especially when services are so = crowded and so many new people want to step in. At this point, if bech32 = brings only efficiency (but correct me if it=E2=80=99s not so) and it is = well planned, it could be a consensual upgrade, maybe together with a 2x = blocksize? Is there a specific plan for some upgrade in 2018? I = personally think it is far easier to reach consensus on a blocksize = increase una tantum rather than a dynamic increase. You cannot predict = the technology growth: will it be linear, exponential, or suddenly stop = for a while, maybe right before a huge innovation? I think a hard fork = bech32 upgrade + 2x could help a lot in scalability while we test LN, = and it might be the only way to effectively promote (or should I say = enforce?) SegWit adoption.
 
thank you,
Alberto = De Luigi
(.com)
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

= --Apple-Mail=_0DD73C35-2435-4B77-8204-99FA2158CA87--