path: root/55/4fbbedaced801359f0bbd052f9f89e5bb7d22b

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E2D19CB3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 17:38:03 +0000 (UTC)
Received: by mail-pf0-f172.google.com with SMTP id p84so9967163pfd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <mark@friedenbach.org>
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 <mail@albertodeluigi.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com>
Message-Id: <B0012211-15E8-45F8-881C-D4C120288CA4@friedenbach.org>
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 <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: 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/ =
<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:
>=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/ =
<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 =
<https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transac=
tions-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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">Addresses are entirely a user-interface issue. They don=E2=80=99=
t factor into the bitcoin protocol at all.<div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">There are many benefits to segregated witness. You may find =
this page helpful:</div><div class=3D""><br class=3D""></div><div =
class=3D""><a =
href=3D"https://bitcoincore.org/en/2016/01/26/segwit-benefits/" =
class=3D"">https://bitcoincore.org/en/2016/01/26/segwit-benefits/</a></div=
><div class=3D""><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Dec 18, 2017, at 8:40 AM, Alberto De Luigi =
via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"WordSection1" style=3D"page: WordSection1; font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">Hello guys,<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">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.<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">In =
general, SegWit tx costs more than legacy tx (source<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"https://bitcoincore.org/en/2016/10/28/segwit-costs/" =
style=3D"color: rgb(149, 79, 114); text-decoration: underline;" =
class=3D"">https://bitcoincore.org/en/2016/10/28/segwit-costs/</a>):<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><ul =
type=3D"disc" style=3D"margin-bottom: 0cm; margin-top: 0cm;" =
class=3D""><li class=3D"MsoListParagraph" style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span =
lang=3D"EN-US" class=3D"">Compared to P2PKH, P2WPKH uses 3 fewer bytes =
(-1%) in the scriptPubKey, and the same number of witness bytes as P2PKH =
scriptSig.<o:p class=3D""></o:p></span></li><li class=3D"MsoListParagraph"=
 style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;"><span lang=3D"EN-US" class=3D"">Compared to P2SH, =
P2WSH uses 11 additional bytes (6%) in the scriptPubKey, and the same =
number of witness bytes as P2SH scriptSig.<o:p =
class=3D""></o:p></span></li><li class=3D"MsoListParagraph" =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;"><span lang=3D"EN-US" class=3D"">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.<o:p =
class=3D""></o:p></span></li><li class=3D"MsoListParagraph" =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;"><span lang=3D"EN-US" class=3D"">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.<o:p class=3D""></o:p></span></li></ul><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">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).<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">See =
source:<o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">4 bytes version<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">1 byte input count<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">Input<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">36 =
bytes outpoint<o:p class=3D""></o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">1 byte scriptSigLen =
(0x00)<o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">0 bytes scriptSig<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">4 bytes sequence<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">1 byte output count<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">8 bytes value<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">1 byte scriptPubKeyLen<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">22 bytes scriptPubKey (0x0014{20-byte =
keyhash})<o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm =
0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">4 bytes locktime<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><a =
href=3D"https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-=
transactions-what-would-be-the-max-number-of-transaction-confi" =
style=3D"color: rgb(149, 79, 114); text-decoration: underline;" =
class=3D"">https://bitcoin.stackexchange.com/questions/59408/with-100-segw=
it-transactions-what-would-be-the-max-number-of-transaction-confi</a><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">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)<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">My =
concern is about segwit adoption by the exchanges.<span =
class=3D"Apple-converted-space">&nbsp;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">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.<o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">But when a tx has at least 10 =
outputs, using segwit you don't save space, instead:<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">- the =
total blockweight is at least 100bytes higher (10bytes x 10 outputs), so =
the blockchain is heavier<span =
class=3D"Apple-converted-space">&nbsp;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D"">- you don't save space inside the blocksize, =
so you cannot validate more transactions of this kind (with many =
outputs), nor get cheaper fee<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">- =
without cheaper fees exchanges have no incentives for segwit adoption =
before they decide to adopt LN<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">In general we can say that =
using SegWit:<o:p class=3D""></o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">- you decrease the fee only =
for some specific kind of transactions, and just because you move some =
bytes to the blockweight<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">- 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)<o:p class=3D""></o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">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?<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><span =
lang=3D"EN-US" class=3D""><o:p class=3D"">&nbsp;</o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D"">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.<o:p class=3D""></o:p></span></div><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;" class=3D""><span lang=3D"EN-US" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D""><span lang=3D"EN-US" class=3D"">thank you,<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;" class=3D"">Alberto =
De Luigi<o:p class=3D""></o:p></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" =
class=3D"">(.com)<o:p class=3D""></o:p></div></div><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" =
class=3D"">_______________________________________________</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;" class=3D"">bitcoin-dev mailing list</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" style=3D"color: =
rgb(149, 79, 114); text-decoration: underline; font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
style=3D"color: rgb(149, 79, 114); text-decoration: underline; =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a></div></blockquote></div><br class=3D""></div></body></html>=

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