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>
Subject: Re: [bitcoin-dev] Clarification about SegWit transaction size and
 bech32
Precedence: list


--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--